tamtam-vagrant-reload 1.1.2 → 1.2.1

data/vendor/cache/vagrant-2092df529ae7/website/content/docs/providers/docker/networking.mdx

@@ -0,0 +1,289 @@
+---
+layout: docs
+page_title: Networking - Docker Provider
+description: |-
+  The Vagrant Docker provider supports using the private network using the
+  `docker network` commands.
+---
+
+# Networking
+
+Vagrant uses the `docker network` command under the hood to create and manage
+networks for containers. Vagrant will do its best to create and manage networks
+for any containers configured inside the Vagrantfile. Each docker network is grouped
+by the subnet used for a requested ip address.
+
+For each newly unique network, Vagrant will run the `docker network create` subcommand
+with the provided options from the network config inside your Vagrantfile. If multiple
+networks share the same subnet, Vagrant will reuse that existing network for multiple
+containers. Once these networks have been created, Vagrant will attach these
+networks to the requested containers using the `docker network connect` for each
+network.
+
+Vagrant names the networks inside docker as `vagrant_network` or `vagrant_network_<subnet here>`
+where `<subnet_here>` is the subnet for the network if defined by the user. An
+example of these networks is shown later in this page. If no subnet is requested
+for the network, Vagrant will connect the `vagrant_network` to the container.
+
+When destroying containers through Vagrant, Vagrant will clean up the network if
+there are no more containers using the network.
+
+## Docker Network Options
+
+Most of the options work similar to other Vagrant providers. Defining either an
+ip or using `type: 'dhcp'` will give you a network on your container.
+
+```ruby
+docker.vm.network :private_network, type: "dhcp"
+docker.vm.network :private_network, ip: "172.20.128.2"
+```
+
+If you want to set something specific with a new network you can use scoped options
+which align with the command line flags for the [docker network create](https://docs.docker.com/engine/reference/commandline/network_create/)
+command. If there are any specific options you want to enable from the `docker network create`
+command, you can specify them like this:
+
+```ruby
+docker.vm.network :private_network, type: "dhcp", docker_network__internal: true
+```
+
+This will enable the `internal` option for the network when created with `docker network create`.
+
+Where `option` corresponds to the given flag that will be provided to the `docker network create`
+command. Similarly, if there is a value you wish to enable when connecting a container
+to a given network, you can use the following value in your network config:
+
+```ruby
+docker_connect__option: "value"
+```
+
+When the docker provider creates a new network a netmask is required. If the netmask
+is not provided, Vagrant will default to a `/24` for IPv4 and `/64` for IPv6. To provide
+a different mask, set it using the `netmask` option:
+
+```ruby
+docker.vm.network :private_network, ip: "172.20.128.2", netmask: 16
+```
+
+For networks which set the type to "dhcp", it is also possible to specify a specific
+subnet for the network connection. This allows containers to connect to networks other
+than the default `vagrant_network` network. The docker provider supports specifying
+the desired subnet in two ways. The first is by using the `ip` and `netmask` options:
+
+```ruby
+docker.vm.network :private_network, type: "dhcp", ip: "172.20.128.0", netmask: 24
+```
+
+The second is by using the `subnet` option:
+
+```ruby
+docker.vm.network :private_network, type: "dhcp", subnet: "172.20.128.0/24"
+```
+
+### Public Networks
+
+The Vagrant docker provider also supports defining public networks. The easiest way
+to define a public network is by setting the `type` option to "dhcp":
+
+```ruby
+docker.vm.network :public_network, type: "dhcp"
+```
+
+A bridge interface is required when setting up a public network. When no bridge
+device name is provided, Vagrant will prompt for the appropriate device to use. This
+can also be set using the `bridge` option:
+
+```ruby
+docker.vm.network :public_network, type: "dhcp", bridge: "eth0"
+```
+
+The `bridge` option also supports a list of interfaces which can be used for
+setting up the network. Vagrant will inspect the defined interfaces and use
+the first active interface when setting up the network:
+
+```ruby
+docker.vm.network :public_network, type: "dhcp", bridge: ["eth0", "wlan0"]
+```
+
+The available IP range for the bridge interface must be known when setting up
+the docker network. Even though a DHCP service may be available on the public
+network, docker will manage IP addresses provided to containers. This means
+that the subnet provided when defining the available IP range for the network
+should not be included within the subnet managed by the DHCP service. Vagrant
+will prompt for the available IP range information, however, it can also be
+provided in the Vagrantfile using the `docker_network__ip_range` option:
+
+```ruby
+docker.vm.network :public_network, type: "dhcp", bridge: "eth0", docker_network__ip_range: "192.168.1.252/30"
+```
+
+Finally, the gateway for the interface is required during setup. The docker
+provider will default the gateway address to the first address available for
+the subnet of the bridge device. Vagrant will prompt for confirmation to use
+the default address. The address can also be manually set in the Vagrantfile
+using the `docker_network__gateway` option:
+
+```ruby
+docker.vm.network :public_network, type: "dhcp", bridge: "eth0", docker_network__gateway: "192.168.1.2"
+```
+
+More examples are shared below which demonstrate creating a few common network
+interfaces.
+
+## Docker Network Example
+
+The following Vagrantfile will generate these networks for a container:
+
+1. A IPv4 IP address assigned by DHCP
+2. A IPv4 IP address 172.20.128.2 on a network with subnet 172.20.0.0/16
+3. A IPv6 IP address assigned by DHCP on subnet 2a02:6b8:b010:9020:1::/80
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.define "docker"  do |docker|
+    docker.vm.network :private_network, type: "dhcp", docker_network__internal: true
+    docker.vm.network :private_network,
+        ip: "172.20.128.2", netmask: "16"
+    docker.vm.network :private_network, type: "dhcp", subnet: "2a02:6b8:b010:9020:1::/80"
+    docker.vm.provider "docker" do |d|
+      d.build_dir = "docker_build_dir"
+    end
+  end
+end
+```
+
+You can test that your container has the proper configured networks by looking
+at the result of running `ip addr`, for example:
+
+```
+brian@localghost:vagrant-sandbox % docker ps                                                             ±[●][master]
+CONTAINER ID        IMAGE                                  COMMAND                  CREATED             STATUS              PORTS                                              NAMES
+370f4e5d2217        196a06ef12f5                           "tail -f /dev/null"      5 seconds ago       Up 3 seconds        80/tcp, 443/tcp                                    vagrant-sandbox_docker-1_1551810440
+brian@localghost:vagrant-sandbox % docker exec 370f4e5d2217 ip addr                                      ±[●][master]
+1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
+    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
+    inet 127.0.0.1/8 scope host lo
+       valid_lft forever preferred_lft forever
+    inet6 ::1/128 scope host
+       valid_lft forever preferred_lft forever
+24: eth0@if25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
+    link/ether 02:42:ac:11:00:03 brd ff:ff:ff:ff:ff:ff link-netnsid 0
+    inet 172.17.0.3/16 brd 172.17.255.255 scope global eth0
+       valid_lft forever preferred_lft forever
+27: eth1@if28: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
+    link/ether 02:42:ac:13:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
+    inet 172.19.0.2/16 brd 172.19.255.255 scope global eth1
+       valid_lft forever preferred_lft forever
+30: eth2@if31: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
+    link/ether 02:42:ac:14:80:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
+    inet 172.20.128.2/16 brd 172.20.255.255 scope global eth2
+       valid_lft forever preferred_lft forever
+33: eth3@if34: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
+    link/ether 02:42:ac:15:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
+    inet 172.21.0.2/16 brd 172.21.255.255 scope global eth3
+       valid_lft forever preferred_lft forever
+    inet6 2a02:6b8:b010:9020:1::2/80 scope global nodad
+       valid_lft forever preferred_lft forever
+    inet6 fe80::42:acff:fe15:2/64 scope link
+       valid_lft forever preferred_lft forever
+```
+
+You can also connect your containers to a docker network that was created outside
+of Vagrant:
+
+```shell-session
+$ docker network create my-custom-network --subnet=172.20.0.0/16
+```
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.define "docker"  do |docker|
+    docker.vm.network :private_network, type: "dhcp", name: "my-custom-network"
+    docker.vm.provider "docker" do |d|
+      d.build_dir = "docker_build_dir"
+    end
+  end
+end
+```
+
+Vagrant will not delete or modify these outside networks when deleting the container, however.
+
+## Useful Debugging Tips
+
+The `docker network` command provides some helpful insights to what might be going
+on with the networks Vagrant creates. For example, if you want to know what networks
+you currently have running on your machine, you can run the `docker network ls` command:
+
+```
+brian@localghost:vagrant-sandbox % docker network ls                                                     ±[●][master]
+NETWORK ID          NAME                                        DRIVER              SCOPE
+a2bfc26bd876        bridge                                      bridge              local
+2a2845e77550        host                                        host                local
+f36682aeba68        none                                        null                local
+00d4986c7dc2        vagrant_network                             bridge              local
+d02420ff4c39        vagrant_network_2a02:6b8:b010:9020:1::/80   bridge              local
+799ae9dbaf98        vagrant_network_172.20.0.0/16               bridge              local
+```
+
+You can also inspect any network for more information:
+
+```
+brian@localghost:vagrant-sandbox % docker network inspect vagrant_network                                ±[●][master]
+[
+    {
+        "Name": "vagrant_network",
+        "Id": "00d4986c7dc2ed7bf1961989ae1cfe98504c711f9de2f547e5dfffe2bb819fc2",
+        "Created": "2019-03-05T10:27:21.558824922-08:00",
+        "Scope": "local",
+        "Driver": "bridge",
+        "EnableIPv6": false,
+        "IPAM": {
+            "Driver": "default",
+            "Options": {},
+            "Config": [
+                {
+                    "Subnet": "172.19.0.0/16",
+                    "Gateway": "172.19.0.1"
+                }
+            ]
+        },
+        "Internal": false,
+        "Attachable": false,
+        "Ingress": false,
+        "ConfigFrom": {
+            "Network": ""
+        },
+        "ConfigOnly": false,
+        "Containers": {
+            "370f4e5d2217e698b16376583fbf051dd34018e5fd18958b604017def92fea63": {
+                "Name": "vagrant-sandbox_docker-1_1551810440",
+                "EndpointID": "166b7ca8960a9f20a150bb75a68d07e27e674781ed9f916e9aa58c8bc2539a61",
+                "MacAddress": "02:42:ac:13:00:02",
+                "IPv4Address": "172.19.0.2/16",
+                "IPv6Address": ""
+            }
+        },
+        "Options": {},
+        "Labels": {}
+    }
+]
+```
+
+## Caveats
+
+For now, Vagrant only looks at the subnet when figuring out if it should create
+a new network for a guest container. If you bring up a container with a network,
+and then change or add some new options (but leave the subnet the same), it will
+not apply those changes or create a new network.
+
+Because the `--link` flag for the `docker network connect` command is considered
+legacy, Vagrant does not support that option when creating containers and connecting
+networks.
+
+## More Information
+
+For more information on how docker manages its networks, please refer to their
+documentation:
+
+- https://docs.docker.com/network/
+- https://docs.docker.com/engine/reference/commandline/network/

data/vendor/cache/vagrant-2092df529ae7/website/content/docs/providers/hyperv/boxes.mdx

@@ -0,0 +1,100 @@
+---
+layout: docs
+page_title: Creating a Base Box - Hyper-V Provider
+description: |-
+  As with every Vagrant provider, the Vagrant Hyper-V provider has a custom box
+  format that affects how base boxes are made.
+---
+
+# Creating a Base Box
+
+As with [every Vagrant provider](/vagrant/docs/providers/basic_usage), the
+Vagrant Hyper-V provider has a custom box format that affects how base boxes are made.
+
+Prior to reading this, you should read the
+[general guide to creating base boxes](/vagrant/docs/boxes/base). Actually,
+it would probably be most useful to keep this open in a separate tab
+as you may be referencing it frequently while creating a base box. That
+page contains important information about common software to install
+on the box.
+
+Additionally, it is helpful to understand the
+[basics of the box file format](/vagrant/docs/boxes/format).
+
+~> **Advanced topic!** This is a reasonably advanced topic that
+a beginning user of Vagrant does not need to understand. If you are
+just getting started with Vagrant, skip this and use an available
+box. If you are an experienced user of Vagrant and want to create
+your own custom boxes, this is for you.
+
+## Additional Software
+
+In addition to the software that should be installed based on the
+[general guide to creating base boxes](/vagrant/docs/boxes/base),
+Hyper-V base boxes require some additional software.
+
+### Hyper-V Kernel Modules
+
+You will need to install Hyper-V kernel modules. While this improves performance,
+it also enables necessary features such as reporting its IP address so that
+Vagrant can access it.
+
+You can verify Hyper-V kernel modules are properly installed by
+running `lsmod` on Linux machines and looking for modules prefixed with
+`hv_`. Additionally, you will need to verify that the "Network" tab for your
+virtual machine in the Hyper-V manager is reporting an IP address. If it
+is not reporting an IP address, Vagrant will not be able to access it.
+
+For most newer Linux distributions, the Hyper-V modules will be available
+out of the box.
+
+Ubuntu 12.04 requires some special steps to make networking work. These
+are reproduced here in case similar steps are needed with other distributions.
+Without these commands, Ubuntu 12.04 will not report an IP address to
+Hyper-V:
+
+```shell-session
+$ sudo apt-get install linux-tools-3.11.0-15-generic
+$ sudo apt-get install hv-kvp-daemon-init
+$ sudo cp /usr/lib/linux-tools/3.11.0-15/hv_* /usr/sbin/
+```
+
+## Packaging the Box
+
+To package a Hyper-V box, export the virtual machine from the
+Hyper-V Manager using the "Export" feature. This will create a directory
+with a structure similar to the following:
+
+```
+.
+|-- Snapshots
+|-- Virtual Hard drives
+|-- Virtual Machines
+```
+
+Delete the "Snapshots" folder. It is of no use to the Vagrant Hyper-V
+provider and can only add to the size of the box if there are snapshots
+in that folder.
+
+Then, create the "metadata.json" file necessary for the box, as documented
+in [basics of the box file format](/vagrant/docs/boxes/format). The proper
+provider value to use for the metadata is "hyperv".
+
+Finally, create an archive of those contents (but _not_ the parent folder)
+using a tool such as `tar`:
+
+```shell-session
+$ tar cvzf ~/custom.box ./*
+```
+
+A common mistake is to also package the parent folder by accident. Vagrant
+will not work in this case. To verify you've packaged it properly, add the
+box to Vagrant and try to bring up the machine.
+
+## Additional Help
+
+There is also some less structured help available from the experience of
+other users. These are not official documentation but if you are running
+into trouble they may help you:
+
+- [Ubuntu 14.04.2 without secure boot](https://github.com/hashicorp/vagrant/issues/5419#issuecomment-86235427)

data/vendor/cache/vagrant-2092df529ae7/website/content/docs/providers/hyperv/configuration.mdx

@@ -0,0 +1,57 @@
+---
+layout: docs
+page_title: Configuration- Hyper-V Provider
+description: |-
+  The Vagrant Hyper-V provider has some provider-specific configuration options
+  you may set.
+---
+
+# Configuration
+
+The Vagrant Hyper-V provider has some provider-specific configuration options
+you may set. A complete reference is shown below:
+
+- `auto_start_action` (Nothing, StartIfRunning, Start) - Automatic start action for VM on host startup. Default: Nothing.
+- `auto_stop_action` (ShutDown, TurnOff, Save) - Automatic stop action for VM on host shutdown. Default: ShutDown.
+- `cpus` (integer) - Number of virtual CPUs allocated to VM at startup.
+- `differencing_disk` (boolean) - **Deprecated** Use differencing disk instead of cloning entire VHD (use `linked_clone` instead) Default: false.
+- `enable_virtualization_extensions` (boolean) - Enable virtualization extensions for the virtual CPUs. Default: false
+- `enable_checkpoints` (boolean) Enable checkpoints of the VM. Default: true
+- `enable_automatic_checkpoints` (boolean) Enable automatic checkpoints of the VM. Default: false
+- `enable_enhanced_session_mode` (boolean) - Enable enhanced session transport type for the VM. Default: false
+- `ip_address_timeout` (integer) - Number of seconds to wait for the VM to report an IP address. Default: 120.
+- `linked_clone` (boolean) - Use differencing disk instead of cloning entire VHD. Default: false
+- `mac` (string) - MAC address for the guest network interface
+- `maxmemory` (integer) - Maximum number of megabytes allowed to be allocated for the VM. When set Dynamic Memory Allocation will be enabled. Set to `nil` to disable Dynamic Memory.
+- `memory` (integer) - Number of megabytes allocated to VM at startup. If `maxmemory` is set, this will be amount of memory allocated at startup.
+- `vlan_id` (integer) - VLAN ID for the guest network interface.
+- `vmname` (string) - Name of virtual machine as shown in Hyper-V manager. Default: Generated name.
+- `vm_integration_services` (Hash) - Hash to set the state of integration services. (Note: Unknown key values will be passed directly.)
+  - `guest_service_interface` (boolean)
+  - `heartbeat` (boolean)
+  - `key_value_pair_exchange` (boolean)
+  - `shutdown` (boolean)
+  - `time_synchronization` (boolean)
+  - `vss` (boolean)
+
+## VM Integration Services
+
+The `vm_integration_services` configuration option consists of a simple Hash. The key values are the
+names of VM integration services to enable or disable for the VM. Vagrant includes an internal
+mapping of known services which allows them to be provided in a "snake case" format. When a provided
+key is unknown, the key value is used "as-is" without any modifications.
+
+For example, if a new `CustomVMSRV` VM integration service was added and Vagrant is not aware of this
+new service name, it can be provided as the key value explicitly:
+
+```ruby
+config.vm.provider "hyperv" do |h|
+  h.vm_integration_services = {
+    guest_service_interface: true,
+    CustomVMSRV: true
+  }
+end
+```
+
+This example would enable the `GuestServiceInterface` (which Vagrant is aware) and `CustomVMSRV` (which
+Vagrant is _not_ aware) VM integration services.

data/vendor/cache/vagrant-2092df529ae7/website/content/docs/providers/hyperv/index.mdx

@@ -0,0 +1,36 @@
+---
+layout: docs
+page_title: Hyper-V Provider
+description: |-
+  Vagrant comes with support out of the box for Hyper-V, a native hypervisor
+  written by Microsoft. Hyper-V is available by default for almost all
+  Windows 8.1 and later installs.
+---
+
+# Hyper-V
+
+Vagrant comes with support out of the box for [Hyper-V](https://en.wikipedia.org/wiki/Hyper-V),
+a native hypervisor written by Microsoft. Hyper-V is available by default for
+almost all Windows 8.1 and later installs.
+
+The Hyper-V provider is compatible with Windows 8.1 and later only. Prior versions
+of Hyper-V do not include the necessary APIs for Vagrant to work.
+
+Hyper-V must be enabled prior to using the provider. Most Windows installations
+will not have Hyper-V enabled by default. Hyper-V is available by default for
+almost all Windows Enterprise, Professional, or Education 8.1 and later installs.
+To enable Hyper-V, go to "Programs and Features", click on "Turn Windows
+features on or off" and check the box next to "Hyper-V". Or install via
+PowerShell with:
+
+```powershell
+Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All
+```
+
+See official documentation [here](https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/quick-start/enable-hyper-v).
+
+~> **Warning:** Enabling Hyper-V will cause VirtualBox, VMware,
+and any other virtualization technology to no longer work. See
+[this blog post](http://www.hanselman.com/blog/SwitchEasilyBetweenVirtualBoxAndHyperVWithABCDEditBootEntryInWindows81.aspx)
+for an easy way to create a boot entry to boot Windows without Hyper-V enabled, if
+there will be times you will need other hypervisors.

data/vendor/cache/vagrant-2092df529ae7/website/content/docs/providers/hyperv/limitations.mdx

@@ -0,0 +1,34 @@
+---
+layout: docs
+page_title: Limitations - Hyper-V Provider
+description: |-
+  The Hyper-V provider works in almost every way like the VirtualBox
+  or VMware provider would, but has some limitations that are inherent to
+  Hyper-V itself.
+---
+
+# Limitations
+
+The Vagrant Hyper-V provider works in almost every way like the VirtualBox
+or VMware provider would, but has some limitations that are inherent to
+Hyper-V itself.
+
+## Limited Networking
+
+Vagrant does not yet know how to create and configure new networks for
+Hyper-V. When launching a machine with Hyper-V, Vagrant will prompt you
+asking what virtual switch you want to connect the virtual machine to.
+
+A result of this is that networking configurations in the Vagrantfile
+are completely ignored with Hyper-V. Vagrant cannot enforce a static IP
+or automatically configure a NAT.
+
+However, the IP address of the machine will be reported as part of
+the `vagrant up`, and you can use that IP address as if it were
+a host only network.
+
+## Snapshots
+
+Restoring snapshot VMs using `vagrant snapshot pop` or
+`vagrant snapshot restore` will sometimes raise errors when mounting
+SMB shared folders, however these mounts will still work inside the guest.

data/vendor/cache/vagrant-2092df529ae7/website/content/docs/providers/hyperv/usage.mdx

@@ -0,0 +1,24 @@
+---
+layout: docs
+page_title: Usage - Hyper-V Provider
+description: |-
+  The Hyper-V provider is used just like any other provider. Please read the
+  general basic usage page for providers.
+---
+
+# Usage
+
+The Vagrant Hyper-V provider is used just like any other provider. Please
+read the general [basic usage](/vagrant/docs/providers/basic_usage) page for
+providers.
+
+The value to use for the `--provider` flag is `hyperv`.
+
+Hyper-V also requires that you execute Vagrant with administrative
+privileges. Creating and managing virtual machines with Hyper-V requires
+admin rights. Vagrant will show you an error if it does not have the proper
+permissions.
+
+Boxes for Hyper-V can be easily found on
+[HashiCorp's Vagrant Cloud](https://vagrantcloud.com/boxes/search). To get started, you might
+want to try the `hashicorp/bionic64` box.

data/vendor/cache/vagrant-2092df529ae7/website/content/docs/providers/index.mdx

@@ -0,0 +1,27 @@
+---
+layout: docs
+page_title: Providers
+description: |-
+  While Vagrant ships out of the box with support for VirtualBox, Hyper-V, and
+  Docker. Vagrant has the ability to manage other types of machines as well.
+  This is done by using other providers with Vagrant.
+---
+
+# Providers
+
+While Vagrant ships out of the box with support for [VirtualBox](https://www.virtualbox.org),
+[Hyper-V](https://learn.microsoft.com/en-us/virtualization/hyper-v-on-windows/about/), and [Docker](https://www.docker.io),
+Vagrant has the ability to manage other types of machines as well. This is done
+by using other _providers_ with Vagrant.
+
+Alternate providers can offer different features that make more sense in your use case.
+For example, if you are using Vagrant for any real work, [VMware](https://www.vmware.com)
+providers are recommended since they're well supported and generally more
+stable and performant than VirtualBox.
+
+Before you can use another provider, you must install it. Installation of other providers
+is done via the Vagrant plugin system.
+
+Once the provider is installed, usage is straightforward and simple, as
+you would expect with Vagrant. Read into the relevant subsections found in
+the navigation to the left for more information.

data/vendor/cache/vagrant-2092df529ae7/website/content/docs/providers/installation.mdx

@@ -0,0 +1,15 @@
+---
+layout: docs
+page_title: Installation - Providers
+description: |-
+  Providers are distributed as Vagrant plugins, and are therefore installed
+  using standard plugin installation steps. After installing a plugin which
+  contains a provider, the provider should immediately be available.
+---
+
+# Provider Installation
+
+Providers are distributed as Vagrant plugins, and are therefore installed
+using [standard plugin installation steps](/vagrant/docs/plugins/usage). After
+installing a plugin which contains a provider, the provider should
+immediately be available.