[pve-devel] SPAM: [PATCH docs] fix typos in various adoc files

Dylan Whyte d.whyte at proxmox.com
Thu Apr 29 12:57:56 CEST 2021


Hi,

Just a few small suggestions. Looking at some of the surrounding lines, 
certain sections could probably do with a proper fix up, but I'll look 
at that another day.


Reviewed-by: Dylan Whyte <d.whyte at proxmox.com>


On 4/29/21 11:46 AM, Oguz Bektas wrote:
> did quick proof reading for common misspellings or errors.
>
> some of the changes (like favourite vs. favorite or virtualization v.
> virtualisation) are because of US v. UK english
>
> Signed-off-by: Oguz Bektas <o.bektas at proxmox.com>
> ---
>   certificate-management.adoc |  2 +-
>   local-zfs.adoc              |  6 +++---
>   pve-firewall.adoc           |  2 +-
>   pveceph.adoc                |  8 ++++----
>   pveproxy.adoc               |  2 +-
>   pveum.adoc                  | 10 +++++-----
>   qm-cloud-init.adoc          | 10 +++++-----
>   qm-pci-passthrough.adoc     |  4 ++--
>   qm.adoc                     | 20 ++++++++++----------
>   translation.adoc            |  2 +-
>   vzdump.adoc                 |  2 +-
>   11 files changed, 34 insertions(+), 34 deletions(-)
>
> diff --git a/certificate-management.adoc b/certificate-management.adoc
> index 065433d..4fd2a8a 100644
> --- a/certificate-management.adoc
> +++ b/certificate-management.adoc
> @@ -313,7 +313,7 @@ root at proxmox:~# pvenode acme plugin config example_plugin
>   └────────┴──────────────────────────────────────────┘
>   ----
>   
> -At last you can configure the domain you want to get certitficates for and
> +At last you can configure the domain you want to get certificates for and
>   place the certificate order for it:
>   
>   ----
> diff --git a/local-zfs.adoc b/local-zfs.adoc
> index f024889..affd6fe 100644
> --- a/local-zfs.adoc
> +++ b/local-zfs.adoc
> @@ -249,7 +249,7 @@ Bootloader
>   
>   {pve} uses xref:sysboot_proxmox_boot_tool[`proxmox-boot-tool`] to manage the
>   bootloader configuration.
> -See the chapter on xref:sysboot[{pve} host bootladers] for details.
> +See the chapter on xref:sysboot[{pve} host bootloaders] for details.
>   
>   
>   ZFS Administration
> @@ -439,7 +439,7 @@ and you can install it using `apt-get`:
>   ----
>   
>   To activate the daemon it is necessary to edit `/etc/zfs/zed.d/zed.rc` with your
> -favourite editor, and uncomment the `ZED_EMAIL_ADDR` setting:
> +favorite editor, and uncomment the `ZED_EMAIL_ADDR` setting:
>   
>   --------
>   ZED_EMAIL_ADDR="root"
> @@ -515,7 +515,7 @@ to an external Storage.
>   
>   We strongly recommend to use enough memory, so that you normally do not
>   run into low memory situations. Should you need or want to add swap, it is
> -preferred to create a partition on a physical disk and use it as swapdevice.
> +preferred to create a partition on a physical disk and use it as swap device.
s/as swap/as a swap/
>   You can leave some space free for this purpose in the advanced options of the
>   installer. Additionally, you can lower the
>   ``swappiness'' value. A good value for servers is 10:
> diff --git a/pve-firewall.adoc b/pve-firewall.adoc
> index 648f8cb..faf580c 100644
> --- a/pve-firewall.adoc
> +++ b/pve-firewall.adoc
> @@ -475,7 +475,7 @@ Logging of firewall rules
>   -------------------------
>   
>   By default, all logging of traffic filtered by the firewall rules is disabled.
> -To enable logging, the `loglevel` for incommig and/or outgoing traffic has to be
> +To enable logging, the `loglevel` for incoming and/or outgoing traffic has to be
>   set in *Firewall* -> *Options*. This can be done for the host as well as for the
>   VM/CT firewall individually. By this, logging of {PVE}'s standard firewall rules
>   is enabled and the output can be observed in *Firewall* -> *Log*.
> diff --git a/pveceph.adoc b/pveceph.adoc
> index a45004a..04fce9a 100644
> --- a/pveceph.adoc
> +++ b/pveceph.adoc
> @@ -92,7 +92,7 @@ machines and containers, you must also account for having enough memory
>   available for Ceph to provide excellent and stable performance.
>   
>   As a rule of thumb, for roughly **1 TiB of data, 1 GiB of memory** will be used
> -by an OSD. Especially during recovery, rebalancing or backfilling.
> +by an OSD. Especially during recovery, re-balancing or backfilling.
>   
>   The daemon itself will use additional memory. The Bluestore backend of the
>   daemon requires by default **3-5 GiB of memory** (adjustable). In contrast, the
> @@ -121,7 +121,7 @@ might take long. It is recommended that you use SSDs instead of HDDs in small
>   setups to reduce recovery time, minimizing the likelihood of a subsequent
>   failure event during recovery.
>   
> -In general SSDs will provide more IOPs than spinning disks. With this in mind,
> +In general SSDs will provide more IOPS than spinning disks. With this in mind,
s/general SSDs/general, SSDs/
>   in addition to the higher cost, it may make sense to implement a
>   xref:pve_ceph_device_classes[class based] separation of pools. Another way to
>   speed up OSDs is to use a faster disk as a journal or
> @@ -623,7 +623,7 @@ NOTE: Further information can be found in the Ceph documentation, under the
>   section CRUSH map footnote:[CRUSH map {cephdocs-url}/rados/operations/crush-map/].
>   
>   This map can be altered to reflect different replication hierarchies. The object
> -replicas can be separated (eg. failure domains), while maintaining the desired
> +replicas can be separated (e.g., failure domains), while maintaining the desired
>   distribution.
>   
>   A common configuration is to use different classes of disks for different Ceph
> @@ -672,7 +672,7 @@ ceph osd crush rule create-replicated <rule-name> <root> <failure-domain> <class
>   |<rule-name>|name of the rule, to connect with a pool (seen in GUI & CLI)
>   |<root>|which crush root it should belong to (default ceph root "default")
>   |<failure-domain>|at which failure-domain the objects should be distributed (usually host)
> -|<class>|what type of OSD backing store to use (eg. nvme, ssd, hdd)
> +|<class>|what type of OSD backing store to use (e.g., nvme, ssd, hdd)
>   |===
>   
>   Once the rule is in the CRUSH map, you can tell a pool to use the ruleset.
> diff --git a/pveproxy.adoc b/pveproxy.adoc
> index a7538b0..dea8267 100644
> --- a/pveproxy.adoc
> +++ b/pveproxy.adoc
> @@ -112,7 +112,7 @@ You can define the cipher list in `/etc/default/pveproxy`, for example
>   Above is the default. See the ciphers(1) man page from the openssl
>   package for a list of all available options.
>   
> -Additionally you can define that the client choses the used cipher in
> +Additionally you can define that the client chooses the used cipher in

I would rephrase the line to:

"Additionally, you can set the client to choose the cipher used in"

>   `/etc/default/pveproxy` (default is the first cipher in the list available to
>   both client and `pveproxy`):
>   
> diff --git a/pveum.adoc b/pveum.adoc
> index 1f7c69f..7f34ae4 100644
> --- a/pveum.adoc
> +++ b/pveum.adoc
> @@ -171,7 +171,7 @@ description: This is the first test user.
>   The 'Base Domain Name' would be `ou=People,dc=ldap-test,dc=com` and the user
>   attribute would be `uid`.
>   +
> -If {pve} needs to authenticate (bind) to the ldap server before being
> +If {pve} needs to authenticate (bind) to the LDAP server before being
>   able to query and authenticate users, a bind domain name can be
>   configured via the `bind_dn` property in `/etc/pve/domains.cfg`. Its
>   password then has to be stored in `/etc/pve/priv/ldap/<realmname>.pw`
> @@ -181,13 +181,13 @@ single line containing the raw password.
>   To verify certificates, you need to to set `capath`. You can set it either
>   directly to the CA certificate of your LDAP server, or to the system path
>   containing all trusted CA certificates (`/etc/ssl/certs`).
> -Additionally, you need to set the `verify` option, which can also be doen over
> +Additionally, you need to set the `verify` option, which can also be done over
>   the web interface.
>   
>   Microsoft Active Directory::
>   
>   A server and authentication domain need to be specified. Like with
> -ldap an optional fallback server, optional port, and SSL
> +LDAP an optional fallback server, optional port, and SSL

s/LDAP an/LDAP, an/

s/fallback server, optional port/fallback server, port/

>   encryption can be configured.
>   
>   [[pveum_ldap_sync]]
> @@ -409,7 +409,7 @@ of predefined roles which satisfies most needs.
>   * `PVETemplateUser`: view and clone templates
>   * `PVEUserAdmin`: user administration
>   * `PVEVMAdmin`: fully administer VMs
> -* `PVEVMUser`: view, backup, config CDROM, VM console, VM power management
> +* `PVEVMUser`: view, backup, config CD-ROM, VM console, VM power management
>   
>   You can see the whole set of predefined roles on the GUI.
>   
> @@ -464,7 +464,7 @@ Virtual machine related privileges::
>   * `VM.Audit`: view VM config
>   * `VM.Clone`: clone/copy a VM
>   * `VM.Config.Disk`: add/modify/delete Disks
> -* `VM.Config.CDROM`: eject/change CDROM
> +* `VM.Config.CDROM`: eject/change CD-ROM
>   * `VM.Config.CPU`: modify CPU settings
>   * `VM.Config.Memory`: modify Memory settings
>   * `VM.Config.Network`: add/modify/delete Network devices
> diff --git a/qm-cloud-init.adoc b/qm-cloud-init.adoc
> index 895db9f..7fc86ea 100644
> --- a/qm-cloud-init.adoc
> +++ b/qm-cloud-init.adoc
> @@ -5,7 +5,7 @@ ifdef::wiki[]
>   :pve-toplevel:
>   endif::wiki[]
>   
> -http://cloudinit.readthedocs.io[Cloud-Init] is the defacto
> +http://cloudinit.readthedocs.io[Cloud-Init] is the de facto
>   multi-distribution package that handles early initialization of a
>   virtual machine instance. Using Cloud-Init, configuration of network
>   devices and ssh keys on the hypervisor side is possible. When the VM
> @@ -32,7 +32,7 @@ needs to store an encrypted version of that password inside the
>   Cloud-Init data.
>   
>   {pve} generates an ISO image to pass the Cloud-Init data to the VM. For
> -that purpose all Cloud-Init VMs need to have an assigned CDROM drive.
> +that purpose all Cloud-Init VMs need to have an assigned CD-ROM drive.
s/purpose all/purpose, all/
>   Also many Cloud-Init images assume to have a serial console, so it is
>   recommended to add a serial console and use it as display for those VMs.
>   
> @@ -70,11 +70,11 @@ qm set 9000 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-9000-disk-1
>   NOTE: Ubuntu Cloud-Init images require the `virtio-scsi-pci`
>   controller type for SCSI drives.
>   
> -.Add Cloud-Init CDROM drive
> +.Add Cloud-Init CD-ROM drive
>   
>   [thumbnail="screenshot/gui-cloudinit-hardware.png"]
>   
> -The next step is to configure a CDROM drive which will be used to pass
> +The next step is to configure a CD-ROM drive which will be used to pass
s/drive which/drive, which/
>   the Cloud-Init data to the VM.
>   
>   ----
> @@ -84,7 +84,7 @@ qm set 9000 --ide2 local-lvm:cloudinit
>   To be able to boot directly from the Cloud-Init image, set the
>   `bootdisk` parameter to `scsi0`, and restrict BIOS to boot from disk
>   only. This will speed up booting, because VM BIOS skips the testing for
> -a bootable CDROM.
> +a bootable CD-ROM.
>   
>   ----
>   qm set 9000 --boot c --bootdisk scsi0
> diff --git a/qm-pci-passthrough.adoc b/qm-pci-passthrough.adoc
> index abb9075..1f2fd88 100644
> --- a/qm-pci-passthrough.adoc
> +++ b/qm-pci-passthrough.adoc
> @@ -309,7 +309,7 @@ Mediated Devices (vGPU, GVT-g)
>   
>   Mediated devices are another method to reuse features and performance from
>   physical hardware for virtualized hardware. These are found most common in
> -virtualized GPU setups such as Intels GVT-g and Nvidias vGPUs used in their
> +virtualized GPU setups such as Intel's GVT-g and NVIDIA's vGPUs used in their
>   GRID technology.
>   
>   With this, a physical Card is able to create virtual cards, similar to SR-IOV.
> @@ -324,7 +324,7 @@ In general your card's driver must support that feature, otherwise it will
>   not work. So please refer to your vendor for compatible drivers and how to
>   configure them.
>   
> -Intels drivers for GVT-g are integrated in the Kernel and should work
> +Intel's drivers for GVT-g are integrated in the Kernel and should work
>   with 5th, 6th and 7th generation Intel Core Processors, as well as E3 v4, E3
>   v5 and E3 v6 Xeon Processors.
>   
> diff --git a/qm.adoc b/qm.adoc
> index a1d2f3d..61c8e27 100644
> --- a/qm.adoc
> +++ b/qm.adoc
> @@ -38,7 +38,7 @@ emulated computer which sees them as if they were real devices.
>   A guest operating system running in the emulated computer accesses these
>   devices, and runs as it were running on real hardware. For instance you can pass

s/as it were/as if it were/

s/For instance you/For instance, you/

>   an iso image as a parameter to Qemu, and the OS running in the emulated computer
> -will see a real CDROM inserted in a CD drive.
> +will see a real CD-ROM inserted in a CD drive.
s/inserted in/inserted into/
>   
>   Qemu can emulate a great variety of hardware from ARM to Sparc, but {pve} is
>   only concerned with 32 and 64 bits PC clone emulation, since it represents the
> @@ -49,8 +49,8 @@ architecture.
>   
>   NOTE: You may sometimes encounter the term _KVM_ (Kernel-based Virtual Machine).
>   It means that Qemu is running with the support of the virtualization processor
> -extensions, via the Linux kvm module. In the context of {pve} _Qemu_ and
> -_KVM_ can be used interchangeably as Qemu in {pve} will always try to load the kvm
> +extensions, via the Linux KVM module. In the context of {pve} _Qemu_ and
s/{pve} _Qemu_/{pve}, _Qemu_/
> +_KVM_ can be used interchangeably as Qemu in {pve} will always try to load the KVM
s/interchangeably as/interchangeably, as/
>   module.
>   
>   Qemu inside {pve} runs as a root process, since this is required to access block
> @@ -61,7 +61,7 @@ Emulated devices and paravirtualized devices
>   --------------------------------------------
>   
>   The PC hardware emulated by Qemu includes a mainboard, network controllers,
> -scsi, ide and sata controllers, serial ports (the complete list can be seen in
> +SCSI, IDE and SATA controllers, serial ports (the complete list can be seen in
>   the `kvm(1)` man page) all of them emulated in software. All these devices
>   are the exact software equivalent of existing hardware devices, and if the OS
>   running in the guest has the proper drivers it will use the devices as if it
> @@ -138,7 +138,7 @@ snapshots) more intelligently.
>   
>   {pve} allows to boot VMs with different firmware and machine types, namely
>   xref:qm_bios_and_uefi[SeaBIOS and OVMF]. In most cases you want to switch from
> -the default SeabBIOS to OVMF only if you plan to use
> +the default SeaBIOS to OVMF only if you plan to use
>   xref:qm_pci_passthrough[PCIe pass through]. A VMs 'Machine Type' defines the
>   hardware layout of the VM's virtual motherboard. You can choose between the
>   default https://en.wikipedia.org/wiki/Intel_440FX[Intel 440FX] or the
> @@ -271,10 +271,10 @@ However some software licenses depend on the number of sockets a machine has,
>   in that case it makes sense to set the number of sockets to what the license
>   allows you.
>   
> -Increasing the number of virtual cpus (cores and sockets) will usually provide a
> +Increasing the number of virtual CPUs (cores and sockets) will usually provide a
>   performance improvement though that is heavily dependent on the use of the VM.
> -Multithreaded applications will of course benefit from a large number of
> -virtual cpus, as for each virtual cpu you add, Qemu will create a new thread of
> +Multi-threaded applications will of course benefit from a large number of
> +virtual CPUs, as for each virtual cpu you add, Qemu will create a new thread of
>   execution on the host system. If you're not sure about the workload of your VM,
>   it is usually a safe bet to set the number of *Total cores* to 2.
>   
> @@ -282,7 +282,7 @@ NOTE: It is perfectly safe if the _overall_ number of cores of all your VMs
>   is greater than the number of cores on the server (e.g., 4 VMs with each 4
>   cores on a machine with only 8 cores). In that case the host system will
>   balance the Qemu execution threads between your server cores, just like if you
> -were running a standard multithreaded application. However, {pve} will prevent
> +were running a standard multi-threaded application. However, {pve} will prevent
>   you from starting VMs with more virtual CPU cores than physically available, as
>   this will only bring the performance down due to the cost of context switches.
>   
> @@ -492,7 +492,7 @@ vCPU hot-plug
>   ^^^^^^^^^^^^^
>   
>   Modern operating systems introduced the capability to hot-plug and, to a
> -certain extent, hot-unplug CPUs in a running systems. Virtualisation allows us
> +certain extent, hot-unplug CPUs in a running systems. Virtualization allows us
s/running systems/running system/
>   to avoid a lot of the (physical) problems real hardware can cause in such
>   scenarios.
>   Still, this is a rather new and complicated feature, so its use should be
> diff --git a/translation.adoc b/translation.adoc
> index f925d0a..b0b8945 100644
> --- a/translation.adoc
> +++ b/translation.adoc
> @@ -76,7 +76,7 @@ perl packages installed on your system. For Debian/Ubuntu:
>   Sending the Translation
>   ~~~~~~~~~~~~~~~~~~~~~~~
>   You can send the finished translation (`.po` file) to the Proxmox team at the address
> -office(at)proxmox.com, along with a signed contributor licence agreement.
> +office(at)proxmox.com, along with a signed contributor license agreement.
>   Alternatively, if you have some developer experience, you can send it as a
>   patch to the {pve} development mailing list. See
>   {webwiki-url}Developer_Documentation[Developer Documentation].
> diff --git a/vzdump.adoc b/vzdump.adoc
> index 0937fe2..3d9c1f9 100644
> --- a/vzdump.adoc
> +++ b/vzdump.adoc
> @@ -449,7 +449,7 @@ but will match relative to any subdirectory. For example:
>   
>    # vzdump 777 --exclude-path bar
>   
> -excludes any file or directoy named `/bar`, `/var/bar`, `/var/foo/bar`, and
> +excludes any file or directory named `/bar`, `/var/bar`, `/var/foo/bar`, and
>   so on, but not `/bar2`.
>   
>   Configuration files are also stored inside the backup archive




More information about the pve-devel mailing list