From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id D25CB77FA5 for ; Thu, 29 Apr 2021 12:58:00 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id C2C991ABF5 for ; Thu, 29 Apr 2021 12:58:00 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id D1E841ABEA for ; Thu, 29 Apr 2021 12:57:58 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 9BB8D46367 for ; Thu, 29 Apr 2021 12:57:58 +0200 (CEST) To: Proxmox VE development discussion , Oguz Bektas References: <20210429094627.151780-1-o.bektas@proxmox.com> From: Dylan Whyte Message-ID: <43864a0e-0343-0f85-d034-0cfef4879989@proxmox.com> Date: Thu, 29 Apr 2021 12:57:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <20210429094627.151780-1-o.bektas@proxmox.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-SPAM-LEVEL: Spam detection results: 0 AWL -0.240 Adjusted score from AWL reputation of From: address KAM_ASCII_DIVIDERS 0.8 Spam that uses ascii formatting tricks KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.001 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [readthedocs.io, config.network, wikipedia.org] Subject: Re: [pve-devel] SPAM: [PATCH docs] fix typos in various adoc files X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2021 10:58:00 -0000 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 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 > --- > 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@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 ||name of the rule, to connect with a pool (seen in GUI & CLI) > ||which crush root it should belong to (default ceph root "default") > ||at which failure-domain the objects should be distributed (usually host) > -||what type of OSD backing store to use (eg. nvme, ssd, hdd) > +||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/.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