beckermj/vaguerent
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge pull request #12834 from danbarr/fix-capitalization

Browse Source 
Fix capitalizations in docs
This commit is contained in:
Sophia Castellarin 2022-09-09 17:00:26 -04:00 committed by GitHub
commit 241810b28a
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
19 changed files with 60 additions and 60 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
website/content/docs/cli/destroy.mdx
View File

@ -15,7 +15,7 @@ destroys all resources that were created during the machine creation process.
After running this command, your computer should be left at a clean state,
as if you never created the guest machine in the first place.
For linux-based guests, Vagrant uses the `shutdown` command to gracefully
For Linux-based guests, Vagrant uses the `shutdown` command to gracefully
terminate the machine. Due to the varying nature of operating systems, the
`shutdown` command may exist at many different locations in the guest's `$PATH`.
It is the guest machine's responsibility to properly populate the `$PATH` with

4
website/content/docs/cli/halt.mdx
View File

@ -16,13 +16,13 @@ Vagrant will first attempt to gracefully shut down the machine by running
the guest OS shutdown mechanism. If this fails, or if the `--force` flag is
specified, Vagrant will effectively just shut off power to the machine.
For linux-based guests, Vagrant will:
For Linux-based guests, Vagrant will:
1. Attempt to detect and use Systemd to execute `systemctl poweroff`; but otherwise,
2. Fallback to using the `shutdown` command to gracefully
terminate the machine.
Due to the varying nature of operating systems, these executables may exist at many
Due to the varying nature of operating systems, these executables may exist at many
different locations in the guest's `$PATH`.
It is the guest machine's responsibility to properly populate the `$PATH` with
directory containing the `shutdown` command.

2
website/content/docs/cli/powershell.mdx
View File

@ -2,7 +2,7 @@
layout: docs
page_title: vagrant powershell - Command-Line Interface
description: |-
The "vagrant powershell" command is used to open a powershell prompt running
The "vagrant powershell" command is used to open a PowerShell prompt running
inside the guest machine.
---

4
website/content/docs/cli/ssh.mdx
View File

@ -38,7 +38,7 @@ Connection to 127.0.0.1 closed.
$
```
On multi-machine setups, you can login to each vm using the name as displayed
On multi-machine setups, you can login to each VM using the name as displayed
on `vagrant status`
```shell-session
@ -135,5 +135,5 @@ from Pageant will not be available for forwarding when using the
`vagrant ssh` command.
Third party programs exist to allow the SSH executable to access Pageant
by creating a unix socket for the SSH executable to read. For more information
by creating a Unix socket for the SSH executable to read. For more information
please see [ssh-pageant](https://github.com/cuviper/ssh-pageant).

2
website/content/docs/disks/hyperv/usage.mdx
View File

@ -29,7 +29,7 @@ For examples of how to use the disk feature with Hyper-V, please refer to the
Most options are used for either creating or attaching a hard disk to your guest.
Vagrant supports most options for these operations. You should be able to define
the powershell specific argument to a given Hyper-V command in the provider_config
the PowerShell specific argument to a given Hyper-V command in the provider_config
hash, and Vagrant should properly pass it along to the command.
To define a provider specific option, please refer to the [Disk Options documentation page](/docs/disks/configuration) for more info.

8
website/content/docs/disks/vmware/common-issues.mdx
View File

@ -1,6 +1,6 @@
---
layout: docs
page_title: Common Issues - Disks VMWare Provider
page_title: Common Issues - Disks VMware Provider
description: |-
HashiCorp develops an official VMware Fusion and VMware Workstation provider
for Vagrant. This provider allows Vagrant to power VMware based machines and
@ -10,13 +10,13 @@ description: |-
# Common Issues and Troubleshooting
This page lists some common issues people run into with Vagrant and VMWare
This page lists some common issues people run into with Vagrant and VMware
as well as solutions for those issues.
## Are my disks attached?
A handy way to figure out what disks are attached (or not attached) to your guest
is to open up the VMWare GUI and open up the guest settings and selecting the
is to open up the VMware GUI and open up the guest settings and selecting the
disks options.
## How many disks can I attach?
@ -37,5 +37,5 @@ If snapshots exist for a VM, disk functionality will be limited. Vagrant will re
an error for any actions that are limited due to the existence of snapshots. In order
to restore functionality the snapshots must be removed. This can be done using the
[`vagrant snapshot delete`](/docs/cli/snapshot) command. To delete all snapshots
for a VMWare backed VM try `vagrant cap provider delete_all_snapshots --target <target vm name>`.
for a VMware backed VM try `vagrant cap provider delete_all_snapshots --target <target vm name>`.
Note once a snapshot is deleted, it can not be restored.

8
website/content/docs/disks/vmware/index.mdx
View File

@ -1,6 +1,6 @@
---
layout: docs
page_title: Disks for VMWare Provider
page_title: Disks for VMware Provider
description: |-
HashiCorp develops an official VMware Fusion and VMware Workstation provider
for Vagrant. This provider allows Vagrant to power VMware based machines and
@ -8,7 +8,7 @@ description: |-
offers.
---
# VMWare
# VMware
~> **Warning!** This feature is experimental and may break or
change in between releases. Use at your own risk. It currently is not officially
@ -24,11 +24,11 @@ Please note that `VAGRANT_EXPERIMENTAL` is an environment variable. For more
information about this flag visit the [Experimental docs page](/docs/experimental/)
for more info. Without this flag enabled, any disks defined will not be configured.
Because of how VMWare handles disk management, a Vagrant guest _must_ be powered
Because of how VMware handles disk management, a Vagrant guest _must_ be powered
off for any changes to be applied to a guest. If you make a configuration change
with a guests disk, you will need to `vagrant reload` the guest for any changes
to be applied.
For more information on how to use VMWare to configure disks for a guest, refer
For more information on how to use VMware to configure disks for a guest, refer
to the [general usage](/docs/disks/usage) and [configuration](/docs/disks/configuration)
guide for more information.

2
website/content/docs/disks/vmware/usage.mdx
View File

@ -1,6 +1,6 @@
---
layout: docs
page_title: Usage - Disks VMWare Provider
page_title: Usage - Disks VMware Provider
description: |-
HashiCorp develops an official VMware Fusion and VMware Workstation provider
for Vagrant. This provider allows Vagrant to power VMware based machines and

66
website/content/docs/experimental/vagrant_go.mdx
View File

@ -7,9 +7,9 @@ description: Introduction to Vagrant Go
# Vagrant Go
Vagrant-go is Vagrant implemented in Go. This version of Vagrant is compatible
with Ruby based Vagrant plugins as well as Vagrantfiles. However, there are
with Ruby based Vagrant plugins as well as Vagrantfiles. However, there are
some significant changes to how Vagrant-go works which make it NOT interchangeable
with Vagrant (Ruby).
with Vagrant (Ruby).
~> **Warning!** Vagrant-go is in alpha and should be expected to be unstable.
Users are not recommended to use Vagrant-go for normal day to day operations.
@ -21,7 +21,7 @@ machines managed with Vagrant (Ruby) can not be managed by Vagrant-go and vice v
### Vagrant-go binary
The Vagrant-go binary is shipped with the Vagrant installer. In order to run the Vagrant-go
The Vagrant-go binary is shipped with the Vagrant installer. In order to run the Vagrant-go
binary do:
```
@ -32,14 +32,14 @@ $ vagrant-go global-status
Vagrant-go still depends on Vagrant-ruby being available in order to run Ruby plugins
and for parsing Vagrantfiles. So, Vagrant-go runs Vagrant-ruby as a server in a subprocess,
providing it access to all the Ruby functionality.
providing it access to all the Ruby functionality.
### Scopes
Vagrant-go has a notion of an information hierarchy. There are three main components:
**Target**: A target is the most specific component in the information hierarchy. It
represents the guest that Vagrant may manipulate. It is similar to the notion of a
represents the guest that Vagrant may manipulate. It is similar to the notion of a
Vagrant Machine.
**Project**: A project is similar to the concept of an Environment. It represents
@ -47,7 +47,7 @@ a group of targets. A project may have plugins installed that are not available
to other projects. A project directory is any directory that has a Vagrantfile.
**Basis**: The basis is the most general component. It represents the root of the Vagrant
execution environment and may contain multiple projects. A user may define multiple basis'
execution environment and may contain multiple projects. A user may define multiple basis'
for their installation. Plugins installed into the basis will be available to all projects
within the basis. Vagrantfiles setup in the basis will be applied to all projects.
@ -56,7 +56,7 @@ within the basis. Vagrantfiles setup in the basis will be applied to all project
The default Vagrant-go data directory and config directory have changed to meet the
[XDG specification](https://pkg.go.dev/github.com/adrg/xdg).
The data directory is now at the XDG data home. The config directory is now at the
XDG config home. In addition, project level information is no longer available in
XDG config home. In addition, project level information is no longer available in
`PROJECT_DIR/.vagrant`. Instead, this information is available with the data and config dirs.
The form of these directories is as follows:
@ -65,8 +65,8 @@ The form of these directories is as follows:
|- $XDG_CONFIG_DIR
\- default # basis name
|- Vagrantfile # a basis level Vagrantfile will be applied to all machines in the basis
\- project
\- project_one # project name
\- project
\- project_one # project name
\- target
|- target_one # target name
|- target_two
@ -78,9 +78,9 @@ The form of these directories is as follows:
```
|- $XDG_DATA_DIR
|- data.db # Vagrant database
|- data.db # Vagrant database
\- default # basis name
|- insecure_private_key
|- insecure_private_key
\- boxes # box directory
\- hashicorp-VAGRANTSLASH-bionic64 # box name
\- 1.0.282 # box version
@ -90,7 +90,7 @@ The form of these directories is as follows:
|- metadata.json
|- ubuntu-18.04-amd64-disk001.vmdk
\- project
\- project_one # project name
\- project_one # project name
\- target
|- target_one # target name
|- target_two
@ -100,14 +100,14 @@ The form of these directories is as follows:
|- a
|- b
```
Vagrant-go does not have knowledge of the Vagrant-ruby data directories so does not
Vagrant-go does not have knowledge of the Vagrant-ruby data directories so does not
have access to that data and vice versa. Both Vagrant-go and Vagrant-ruby
respect the [Vagrant environment variables](/docs/other/environmental-variables/) for
setting data directory paths. However, the layout and content of these directories
are different for Vagrant-go and Vagrant-ruby.
respect the [Vagrant environment variables](/docs/other/environmental-variables/) for
setting data directory paths. However, the layout and content of these directories
are different for Vagrant-go and Vagrant-ruby.
~> **Warning!** Vagrant-go users should not attempt to use an existing `VAGRANT_HOME`
directory as it may corrupt it.
@ -125,13 +125,13 @@ at `$XDG_DATA_DIR`. The ramifications of this are:
The machine index for Vagrant-go is backed by the `data.db` in the data directory.
The ramifications of this are:
- Vagrant-go and Vagrant-ruby do not share a machine index. They have no knowledge of
each other, so machines you bring up in one will not be available in the other. There is
- Vagrant-go and Vagrant-ruby do not share a machine index. They have no knowledge of
each other, so machines you bring up in one will not be available in the other. There is
currently no way to “import” or “export” a machine index entry
## Installing Go Vagrant plugins
Vagrant-go can load external plugins that are packaged as executables. Plugins can be
Vagrant-go can load external plugins that are packaged as executables. Plugins can be
launched from the basis (`VAGRANT_CONFIG_DIR/plugins`) or the project directory
(`VAGRANT_PROJECT/.vagrant/plugins`).
@ -148,31 +148,31 @@ The `-c` argument does work to specify a single command to run. For example:
vagrant ssh -c "echo hello world"
```
Users may still access the Vagrant machine over ssh by running the ssh command. For example:
Users may still access the Vagrant machine over SSH by running the ssh command. For example:
```
# Get the ssh configuration for the target machine
vagrant ssh-config <target>
# Get the SSH configuration for the target machine
vagrant ssh-config <target>
# Use the info provided to ssh into the target machine using the ssh command
# Use the info provided to SSH into the target machine using the ssh command
ssh vagrant@<ip> -p <port> -i <path to key>
```
### `vagrant plugin` command only manipulates Ruby plugins
The Vagrant plugin command uses bundler to manage Ruby based plugins. To install/uninstall
go based plugins, users must manually add the plugin binary to the plugins path.
go based plugins, users must manually add the plugin binary to the plugins path.
Uninstalling Ruby Vagrant plugins does not currently work.
### Vagrant does not work on Windows
The go plugin setup currently is built on unix sockets. So, Vagrant-go is not expected to
The go plugin setup currently is built on Unix sockets. So, Vagrant-go is not expected to
work on Windows. This will be addressed in a future release.
### Secret interactive input
Vagrant relies on secret interactive input to allow users to pass in SMB credentials when
using SMB synced folders. Currently, interactive input works for Vagrant-go, however, the
user input is not hidden. Users who wish to use SMB folders and avoid exposing their
using SMB synced folders. Currently, interactive input works for Vagrant-go, however, the
user input is not hidden. Users who wish to use SMB folders and avoid exposing their
credentials can work around this issue by specifying the [credentials in the Vagrantfile](/docs/synced-folders/smb/)
### Concurrent Vagrant runs don’t work
@ -181,17 +181,17 @@ Only one Vagrant-go process may run at a time.
### Puppet and Chef provisioners do not work
These provisioners require Vagrant to modify synced folders on the fly during a Vagrant run.
These provisioners require Vagrant to modify synced folders on the fly during a Vagrant run.
This capability will not be implemented for 2.3.0, so, these provisioners will not work as
expected.
### Each machine must specify their own ssh port for multi machine environments
### Each machine must specify their own SSH port for multi machine environments
Currently, Vagrant-go does not check for port collisions when forwarding ports. Instead, it
will allow for multiple forwarded ports to be defined on the same host port. This results in
the ssh ports for machines to all be assigned to the same default port if none is specified.
will allow for multiple forwarded ports to be defined on the same host port. This results in
the SSH ports for machines to all be assigned to the same default port if none is specified.
This causes Vagrant to time out when connecting to a machine in multimachine environments. To
avoid this issue you may specify the ssh port for the machines, for example:
avoid this issue you may specify the SSH port for the machines, for example:
```
Vagrant.configure("2") do |config|
config.vm.define "one" do |c|

2
website/content/docs/providers/virtualbox/boxes.mdx
View File

@ -57,7 +57,7 @@ must be installed so that things such as shared folders can function.
Installing guest additions also usually improves performance since the guest
OS can make some optimizations by knowing it is running within VirtualBox.
Before installing the guest additions, you will need the linux kernel headers
Before installing the guest additions, you will need the Linux kernel headers
and the basic developer tools. On Ubuntu, you can easily install these like
so:

2
website/content/docs/providers/vmware/vagrant-vmware-utility.mdx
View File

@ -117,7 +117,7 @@ $ sudo sv start vagrant-vmware-utility
## Utility Service Configuration
When installing the Vagrant VMware utility service, a configuration file is generated
that is used when the process is started. On windows, this can be found at:
that is used when the process is started. On Windows, this can be found at:
```text
C:\ProgramData\HashiCorp\vagrant-vmware-desktop\config\service.hcl

2
website/content/docs/provisioning/ansible_local.mdx
View File

@ -168,7 +168,7 @@ This section lists the _specific_ options for the Ansible Local provisioner. In
### Install Galaxy Roles in a path owned by root
~> **Disclaimer:** This tip is not a recommendation to install galaxy roles out of the vagrant user space, especially if you rely on ssh agent forwarding to fetch the roles.
~> **Disclaimer:** This tip is not a recommendation to install galaxy roles out of the vagrant user space, especially if you rely on SSH agent forwarding to fetch the roles.
Be careful that `ansible-galaxy` command is executed by default as vagrant user. Setting `galaxy_roles_path` to a folder like `/etc/ansible/roles` will fail, and `ansible-galaxy` will extract the role a second time in `/home/vagrant/.ansible/roles/`. Then if your playbook uses `become` to run as `root`, it will fail with a _"role was not found"_ error.

2
website/content/docs/provisioning/puppet_apply.mdx
View File

@ -90,7 +90,7 @@ Vagrant.configure("2") do |config|
end
```
~> `puppet` need to be installed in the guest vm.
~> `puppet` needs to be installed in the guest VM.
By default, Vagrant will configure Puppet to look for manifests in the
"manifests" folder relative to the project root, and will use the

4
website/content/docs/synced-folders/virtualbox.mdx
View File

@ -18,11 +18,11 @@ the guest to the host and vice versa.
## Options
- `automount` (boolean) - If true, the `--automount` flag will be used when
using the VirtualBox tools to share the folder with the guest vm. Defaults to false
using the VirtualBox tools to share the folder with the guest VM. Defaults to false
if not present.
- `SharedFoldersEnableSymlinksCreate` (boolean) - If false, will disable the
ability to create symlinks with the given virtualbox shared folder. Defaults to
ability to create symlinks with the given VirtualBox shared folder. Defaults to
true if the option is not present.
## Caveats

2
website/content/docs/triggers/usage.mdx
View File

@ -94,7 +94,7 @@ running either `vagrant destroy` or `vagrant halt` would stop tinyproxy.
### Ruby Option
Triggers can also be defined to run Ruby, rather than bash or powershell. An
Triggers can also be defined to run Ruby, rather than bash or PowerShell. An
example of this might be using a Ruby option to get more information from the `VBoxManage`
tool. In this case, we are printing the `ostype` defined for thte guest after
it has been brought up.

2
website/content/docs/vagrantfile/ssh_settings.mdx
View File

@ -44,7 +44,7 @@ defaults are typically fine, but you can fine tune whatever you would like.
- `config.ssh.extra_args` (array of strings) - This settings value is passed directly
into the ssh executable. This allows you to pass any arbitrary commands to do things such
as reverse tunneling down into the ssh program. These options can either be
as reverse tunneling down into the SSH program. These options can either be
single flags set as strings such as `"-6"` for IPV6 or an array of arguments
such as `["-L", "8008:localhost:80"]` for enabling a tunnel from host port 8008
to port 80 on guest. **Note:** This option only affects the `ssh` command or instances

2
website/content/docs/vagrantfile/tips.mdx
View File

@ -54,7 +54,7 @@ every node will actually provision with the same text.
This is an easy mistake to make, and Vagrant cannot really protect against it,
so the best we can do is mention it here.
## Overwrite host locale in ssh session
## Overwrite host locale in SSH session
Usually, host locale environment variables are passed to guest. It may cause
failures if the guest software do not support host locale. One possible solution

2
website/content/vagrant-cloud/request-limits.mdx
View File

@ -23,7 +23,7 @@ If you have received a 429 HTTP status code in the response to your request, you
- **X-RateLimit-Limit**: The current maximum number of requests allowed from your client.
- **X-RateLimit-Remaining**: How many requests you have remaining in the time window.
- **X-RateLimit-Reset**: The unix timestamp for when the window resets.
- **X-RateLimit-Reset**: The Unix timestamp for when the window resets.
## My use case requires more requests. What do I do?

2
website/data/docs-nav-data.json
View File

@ -474,7 +474,7 @@
]
},
{
"title": "VMWare",
"title": "VMware",
"routes": [
{
"title": "Overview",