[pmg-devel] [PATCH pmg-docs 1/4] service daemons: language fixup

[pmg-devel] [PATCH pmg-docs 1/4] service daemons: language fixup

[Dylan Whyte]

Very minor language updates to the "Important Service Daemons" section
of the docs

Signed-off-by: Dylan Whyte <d.whyte@proxmox.com>
---
 pmg-smtp-filter.adoc |  8 ++++----
 pmgdaemon.adoc       |  2 +-
 pmgmirror.adoc       |  2 +-
 pmgpolicy.adoc       |  4 ++--
 pmgproxy.adoc        | 41 +++++++++++++++++++++--------------------
 pmgtunnel.adoc       |  6 +++---
 6 files changed, 32 insertions(+), 31 deletions(-)

diff --git a/pmg-smtp-filter.adoc b/pmg-smtp-filter.adoc
index 153178e..58033e4 100644
--- a/pmg-smtp-filter.adoc
+++ b/pmg-smtp-filter.adoc
@@ -23,14 +23,14 @@ pmg-smtp-filter - Proxmox SMTP Filter Daemon
 ============================================
 endif::manvolnum[]
 
-This is the Proxmox SMTP filter daemon, which does the actual spam
-filtering using the SpamAssassin and the rule database. It listens on
+The Proxmox SMTP Filter Daemon does the actual spam
+filtering, using {spamassassin} and the rule database. It listens on
 127.0.0.1:10023 and 127.0.0.1:10024. The daemon listens to a local
-address only, so you cannot access it from outside.
+address only, so you cannot access it from the outside.
 
 With our postfix configuration, incoming mails are sent to
 127.0.0.1:10024. Outgoing (trusted) mails are sent to
-127.0.0.1:10023. After filtering, mails are reinjected into postfix at
+127.0.0.1:10023. After filtering, mails are resent to Postfix at
 127.0.0.1:10025.
 
 
diff --git a/pmgdaemon.adoc b/pmgdaemon.adoc
index a809c02..4e9e03b 100644
--- a/pmgdaemon.adoc
+++ b/pmgdaemon.adoc
@@ -27,7 +27,7 @@ This daemon exposes the whole {pmg} API on `127.0.0.1:85`. It runs as
 `root` and has permission to do all privileged operations.
 
 NOTE: The daemon listens to a local address only, so you cannot access
-it from outside. The `pmgproxy` daemon exposes the API to the outside
+it from the outside. The `pmgproxy` daemon exposes the API to the outside
 world.
 
 
diff --git a/pmgmirror.adoc b/pmgmirror.adoc
index 2f2c12d..80d69c3 100644
--- a/pmgmirror.adoc
+++ b/pmgmirror.adoc
@@ -23,7 +23,7 @@ pmgmirror - Database Mirror Daemon
 ==================================
 endif::manvolnum[]
 
-{pmg} uses an application specific asynchronous replication
+{pmg} uses an application-specific, asynchronous replication
 algorithm to replicate the database to all cluster nodes.
 
 The daemon uses the ssh tunnel provided by 'pmgtunnel' to access
diff --git a/pmgpolicy.adoc b/pmgpolicy.adoc
index 813ed9e..1dbc0fb 100644
--- a/pmgpolicy.adoc
+++ b/pmgpolicy.adoc
@@ -25,8 +25,8 @@ endif::manvolnum[]
 
 This daemon implements the Postfix SMTP access policy delegation
 protocol on `127.0.0.1:10022`. It listens to a local address
-only, so you cannot access it from outside. We configure Postfix to
-use this service for greylisting and as SPF policy server.
+only, so you cannot access it from the outside. We configure Postfix to
+use this service for greylisting and as an SPF policy server.
 
 
 ifdef::manvolnum[]
diff --git a/pmgproxy.adoc b/pmgproxy.adoc
index d5c1112..6e48fba 100644
--- a/pmgproxy.adoc
+++ b/pmgproxy.adoc
@@ -23,12 +23,12 @@ pmgproxy - Proxmox Mail Gateway API Proxy Daemon
 ================================================
 endif::manvolnum[]
 
-This daemon exposes the whole {pmg} API on TCP port 8006 using
+This daemon exposes the whole {pmg} API on TCP port 8006, using
 HTTPS. It runs as user `www-data` and has very limited permissions.
 Operations requiring more permissions are forwarded to the local
 `pmgdaemon`.
 
-Requests targeted for other nodes are automatically forwarded to those
+Requests targeted at other nodes are automatically forwarded to those
 nodes. This means that you can manage your whole cluster by connecting
 to a single {pmg} node.
 
@@ -76,18 +76,18 @@ By default the `pmgproxy` daemon listens on the wildcard address and accepts
 connections from both IPv4 and IPv6 clients.
 
 
-By setting `LISTEN_IP` in `/etc/default/pmgproxy` you can control to which IP
-address the `pmgproxy` daemon binds. The IP-address needs to be configured on
+By setting `LISTEN_IP` in `/etc/default/pmgproxy`, you can control which IP
+address the `pmgproxy` daemon binds to. The IP-address needs to be configured on
 the system.
 
 Setting the `sysctl` `net.ipv6.bindv6only` to the non-default `1` will cause
-the daemons to only accept connection from IPv6 clients, while  usually also
-causing lots of other issues. If you set this configuration we recommend to
-either remove the `sysctl` setting, or set the `LISTEN_IP` to `0.0.0.0` (which
-will only allow IPv4 clients).
+the daemons to only accept connections from IPv6 clients, while usually also
+causing lots of other issues. If you set this configuration, we recommend either
+removing the `sysctl` setting, or setting the `LISTEN_IP` to `0.0.0.0` (which
+will allow only IPv4 clients).
 
-`LISTEN_IP` can be used to only to restricting the socket to an internal
-interface and thus have less exposure to the public internet, for example:
+`LISTEN_IP` can be used to restrict the socket to an internal
+interface, thus leaving less exposure to the public internet, for example:
 
 ----
 LISTEN_IP="192.0.2.1"
@@ -107,8 +107,8 @@ LISTEN_IP="fe80::c463:8cff:feb9:6a4e%vmbr0"
 ----
 
 WARNING: The nodes in a cluster need access to `pmgproxy` for communication,
-possibly on different sub-nets. It is **not recommended** to set `LISTEN_IP` on
-clustered systems.
+possibly across different subnets. It is **not recommended** to set `LISTEN_IP`
+on clustered systems.
 
 To apply the change you need to either reboot your node or fully restart the
 `pmgproxy` service:
@@ -118,24 +118,24 @@ systemctl restart pmgproxy.service
 ----
 
 NOTE: Unlike `reload`, a `restart` of the pmgproxy service can interrupt some
-long-running worker processes, for example a running console.So, please use a
-maintenance window to bring this change in effect.
+long-running worker processes, for example, a running console. Therefore, you
+should set a maintenance window to bring this change into effect.
 
 
 SSL Cipher Suite
 ----------------
 
-You can define the cipher list in `/etc/default/pmgproxy`, for example
+You can define the cipher list in `/etc/default/pmgproxy`, for example:
 
  CIPHERS="ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256"
 
-Above is the default. See the `ciphers(1)` man page from the `openssl`
+The above is the default. See the `ciphers(1)` man page from the `openssl`
 package for a list of all available options.
 
-The first of these ciphers, available to both the client and the `pmgproxy`,
+The first of these ciphers that is available to both the client and `pmgproxy`
 will be used.
 
-Additionally you can allow the client to choose the cipher from the list above
+Additionally, you can allow the client to choose the cipher from the list above,
 by disabling the HONOR_CIPHER_ORDER option in `/etc/default/pmgproxy`:
 
  HONOR_CIPHER_ORDER=0
@@ -146,7 +146,7 @@ Diffie-Hellman Parameters
 
 You can define the used Diffie-Hellman parameters in
 `/etc/default/pmgproxy` by setting `DHPARAMS` to the path of a file
-containing DH parameters in PEM format, for example
+containing DH parameters in PEM format, for example:
 
  DHPARAMS="/path/to/dhparams.pem"
 
@@ -160,7 +160,8 @@ COMPRESSION
 -----------
 
 By default `pmgproxy` uses gzip HTTP-level compression for compressible
-content if the client supports it. This can be disabled in `/etc/default/pmgproxy`
+content, if the client supports it. This can be disabled in
+`/etc/default/pmgproxy`
 
  COMPRESSION=0
 
diff --git a/pmgtunnel.adoc b/pmgtunnel.adoc
index 6847c69..792043e 100644
--- a/pmgtunnel.adoc
+++ b/pmgtunnel.adoc
@@ -23,10 +23,10 @@ pmgtunnel - Cluster Tunnel Daemon
 =================================
 endif::manvolnum[]
 
-This daemon creates a ssh tunnel to the postgres database in other
+This daemon creates an ssh tunnel to the Postgres databases on other
 cluster nodes (port 5432). The tunnel is used to synchronize the
-database using an application specific asynchronous replication
-algorythm.
+database, using an application-specific, asynchronous replication
+algorithm.
 
 ifdef::manvolnum[]
 include::pmg-copyright.adoc[]
-- 
2.30.2

[pmg-devel] [PATCH pmg-docs 2/4] cli tools: language fixup

[Dylan Whyte]

minor rewordings and corrections in section "Command Line Tools"

Signed-off-by: Dylan Whyte <d.whyte@proxmox.com>
---
 nmap.adoc       | 4 ++--
 pmgdb.adoc      | 4 ++--
 pmgperf.adoc    | 6 +++---
 pmgqm.adoc      | 2 +-
 pmgsh.adoc      | 2 +-
 pmgupgrade.adoc | 6 +++---
 pmgversion.adoc | 2 +-
 7 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/nmap.adoc b/nmap.adoc
index 1a06b79..3747254 100644
--- a/nmap.adoc
+++ b/nmap.adoc
@@ -3,8 +3,8 @@
 -------------------
 
 `nmap` is designed to allow system administrators to scan large
-networks to determine which hosts are up and what services they
-offer. You can use nmap to test your firewall settings, for example
+networks, to determine which hosts are up and what services they
+offer. You can use nmap to test your firewall settings, for example,
 to see if the required ports are open.
 
 .Test Razor port (tcp port 2703):
diff --git a/pmgdb.adoc b/pmgdb.adoc
index 60f6a76..9f51aa7 100644
--- a/pmgdb.adoc
+++ b/pmgdb.adoc
@@ -26,9 +26,9 @@ pmgdb - Database Management Toolkit
 endif::manvolnum[]
 
 The `pmgdb` toolkit is used to simplify common database management
-tasks. Most importantly, it is used internally to create and initialize
+tasks. It is primarily used internally to create and initialize
 the default database. You can also use it to reset the filter rules
-back to factory defaults:
+to factory defaults:
 
 ----
 pmgdb reset
diff --git a/pmgperf.adoc b/pmgperf.adoc
index 8cfcd8d..818d550 100644
--- a/pmgperf.adoc
+++ b/pmgperf.adoc
@@ -35,7 +35,7 @@ CPU BOGOMIPS:: bogomips sum of all CPUs
 REGEX/SECOND:: regular expressions per second (perl performance
   test), should be above 1000000.
 
-HD SIZE:: harddisk size
+HD SIZE:: hard disk size
 
 BUFFERED READS:: simple HD read test. Modern HDs should reach at
 least 100 MB/sec
@@ -45,14 +45,14 @@ values < 8 milliseconds. Common IDE/SATA disks get values from 15 to
 20 ms. SSD seek times should be below 1ms.
 
 FSYNCS/SECOND:: value should be greater than 200 (you should enable
-'write back' cache mode on you RAID controller - needs a battery
+'write-back' cache mode on you RAID controller - needs a battery
 backed cache (BBWC)).
 
 DNS EXT:: average time to resolve an external DNS name
 
 DNS INT:: average time to resolve a local DNS name
 
-Here is an example output generated by the tool:
+Here is an example of the output generated by the tool:
 
 ----
 # pmgperf
diff --git a/pmgqm.adoc b/pmgqm.adoc
index abbe023..08ad172 100644
--- a/pmgqm.adoc
+++ b/pmgqm.adoc
@@ -25,7 +25,7 @@ pmgqm - Quarantine Management Toolkit
 :pmg-toplevel:
 endif::manvolnum[]
 
-Toolkit to manage spam an virus quarantine, and send spam report mails.
+Toolkit to manage spam and virus quarantine, and send spam report mails.
 
 ifdef::manvolnum[]
 include::pmg-copyright.adoc[]
diff --git a/pmgsh.adoc b/pmgsh.adoc
index 0424f14..7d9ea3c 100644
--- a/pmgsh.adoc
+++ b/pmgsh.adoc
@@ -35,7 +35,7 @@ List entries:
 # pmgsh ls /
 ----
 
-Call method 'GET' on an specific API path:
+Call the 'GET' method on a specific API path:
 
 ----
 # pmgsh get /version
diff --git a/pmgupgrade.adoc b/pmgupgrade.adoc
index 03caabd..92913bb 100644
--- a/pmgupgrade.adoc
+++ b/pmgupgrade.adoc
@@ -25,9 +25,9 @@ pmgupgrade - Upgrade Proxmox Mail Gateway
 endif::manvolnum[]
 
 This is a small wrapper around `apt full-upgrade`. We use this to print
-additional information, like when a node reboot due to a kernel update is
-required. Additionally, it can run an interactive shell after the update, this
-is used when starting an upgrade using the web GUI.
+additional information, like when a node reboot is required, due to a kernel
+update. Additionally, it can run an interactive shell after the update. This is
+used when starting an upgrade using the web GUI.
 
 If you are already logged in on the console, it is preferable to invoke
 `apt` directly.
diff --git a/pmgversion.adoc b/pmgversion.adoc
index 9f86e7f..62cad69 100644
--- a/pmgversion.adoc
+++ b/pmgversion.adoc
@@ -41,7 +41,7 @@ List version details for important packages:
 # pmgversion -v
 ----
 
-Please use the Debian package management for details about other packages
+Please use the Debian package manager for details about other packages:
 
 ----
 # dpkg -l
-- 
2.30.2

[pmg-devel] [PATCH pmg-docs 3/4] faq: language fixup

[Dylan Whyte]

minor fixup for the FAQ section

Signed-off-by: Dylan Whyte <d.whyte@proxmox.com>
---
 pmg-faq.adoc | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/pmg-faq.adoc b/pmg-faq.adoc
index c3dbd0e..162a221 100644
--- a/pmg-faq.adoc
+++ b/pmg-faq.adoc
@@ -22,12 +22,12 @@ What distribution is {pmg} based on?::
 What license does the {pmg} project use?::
 
 {pmg} code is licensed under the GNU Affero General Public License,
-version 3 (since the 5.0 release).
+version 3 (as of the 5.0 release).
 
 Will {pmg} run on a 32bit processor?::
 
 {pmg} works only on 64-bit CPUs (AMD or Intel). There is no plan
-for 32-bit for the platform.
+for 32-bit platform support.
 
 [[faq-support-table]]
 How long will my {pmg} version be supported?::
@@ -35,7 +35,7 @@ How long will my {pmg} version be supported?::
 {pmg} versions are supported at least as long as the corresponding
 Debian Version is
 https://wiki.debian.org/DebianOldStable[oldstable]. {pmg} uses a
-rolling release model and using the latest stable version is always
+rolling release model, and using the latest stable version is always
 recommended.
 +
 [width="100%",cols="5*d",options="header"]
@@ -47,12 +47,12 @@ recommended.
 |===============================================================================
 
 NOTE: {pmg} releases before 5.0 are not listed here. As they are all EOL (End
-Of Life), it's highly recommended to upgrade to a newer version if still in use.
+Of Life), it's highly recommended to upgrade to a newer version, if still in use.
 
 [[faq-upgrade]]
 How can I upgrade {pmg} to the next release?::
 
-Minor version upgrades, for example upgrading from {pmg} in version 5.1
+Minor version upgrades, for example, upgrading from {pmg} version 5.1
 to 5.2, can be done just like any normal update, either through the
 __Node -> Updates__ panel or through the command line with:
 +
@@ -61,15 +61,15 @@ apt update
 apt full-upgrade
 ----
 +
-NOTE: Always ensure you correctly set up the
-xref:pmg_package_repositories[package repositories] and only continue with the
-actual upgrade if `apt update` did not hit any error.
+NOTE: Always ensure that you correctly set up the
+xref:pmg_package_repositories[package repositories], and only continue with the
+actual upgrade if `apt update` did not hit any errors.
 +
-Major version upgrades, for example going from {pmg} 5.4 to 6.0, are
-also supported. They must be carefully planned and tested and should
-*never* be started without having a current backup ready.
+Major version upgrades, for example, going from {pmg} 5.4 to 6.0, are
+also supported. They must be carefully planned and tested, and should
+*never* be started without having an up-to-date backup ready.
 Although the specific upgrade steps depend on your respective setup, we
-provide general instructions and advice of how a upgrade should be
+provide general instructions and advice on how an upgrade should be
 performed:
 +
 * https://pmg.proxmox.com/wiki/index.php/Upgrade_from_6.x_to_7.0[Upgrade from {pmg} 6.x to 7.0]
-- 
2.30.2

[pmg-devel] [PATCH pmg-docs 4/4] certificate management: langauge fixup

[Dylan Whyte]

Language fixup for the "Certificate Management" subsection of
"Configuration Management"

Signed-off-by: Dylan Whyte <d.whyte@proxmox.com>
---
 pmg-ssl-certificate.adoc | 100 +++++++++++++++++++--------------------
 1 file changed, 50 insertions(+), 50 deletions(-)

diff --git a/pmg-ssl-certificate.adoc b/pmg-ssl-certificate.adoc
index 64a2521..10a5c16 100644
--- a/pmg-ssl-certificate.adoc
+++ b/pmg-ssl-certificate.adoc
@@ -2,11 +2,11 @@
 Certificate Management
 ----------------------
 
-Access to the administration web-interface is always encrypted through `https`.
-Each {pmg} host creates by default its own (self-signed) certificate.
+Access to the web-based administration interface is always encrypted through
+`https`.  Each {pmg} host creates by default its own (self-signed) certificate.
 This certificate is used for encrypted communication with the host's `pmgproxy`
-service for any API call, between an user and the web-interface or between
-nodes in a cluster.
+service, for any API call between a user and the web-interface or between nodes
+in a cluster.
 
 Certificate verification in a {pmg} cluster is done based on pinning the
 certificate fingerprints in the cluster configuration and verifying that they
@@ -16,20 +16,20 @@ match on connection.
 Certificates for the API and SMTP
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-{pmg} knows two different certificates:
+{pmg} uses two different certificates:
 
 * `/etc/pmg/pmg-api.pem`: the required certificate used for {pmg} API requests.
 * `/etc/pmg/pmg-tls.pem`: the optional certificate used for SMTP TLS
   connections, see xref:pmgconfig_mailproxy_tls[mailproxy TLS configuration]
   for details.
 
-You have the following options for those certificates:
+You have the following options for these certificates:
 
-1. keep using the default self-signed certificate in `/etc/pmg/pmg-api.pem`.
-2. use an externally provided certificate (for example, signed by a commercial
+1. Keep using the default self-signed certificate in `/etc/pmg/pmg-api.pem`.
+2. Use an externally provided certificate (for example, signed by a commercial
 Certificate Authority (CA)).
-3. use an ACME provider like Let's Encrypt to get a trusted certificate with
-automatic renewal, this is also integrated in the {pmg} API and Webinterface.
+3. Use an ACME provider like Let's Encrypt to get a trusted certificate with
+automatic renewal; this is also integrated in the {pmg} API and web interface.
 
 Certificates are managed through the {pmg} web-interface/API or using the
 the `pmgconfig` CLI tool.
@@ -39,7 +39,7 @@ Upload Custom Certificate
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
 If you already have a certificate which you want to use for a {pmg} host, you
-can upload that certificate simply over the web interface.
+can simply upload that certificate over the web interface.
 
 [thumbnail="pmg-gui-certs-upload-custom.png"]
 
@@ -50,14 +50,14 @@ Trusted certificates via Let's Encrypt (ACME)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 {PMG} includes an implementation of the **A**utomatic **C**ertificate
-**M**anagement **E**nvironment **ACME** protocol, allowing {pmg} admins to
-use an ACME provider like Let's Encrypt for easy setup of TLS certificates
-which are accepted and trusted from modern operating systems and web browsers
+**M**anagement **E**nvironment (**ACME**) protocol, allowing {pmg} admins to
+use an ACME provider like Let's Encrypt for easy setup of TLS certificates,
+which are accepted and trusted by modern operating systems and web browsers
 out of the box.
 
 Currently, the two ACME endpoints implemented are the
-https://letsencrypt.org[Let's Encrypt (LE)] production and its staging
-environment. Our ACME client supports validation of `http-01` challenges using
+https://letsencrypt.org[Let's Encrypt (LE)] production and staging
+environments. Our ACME client supports validation of `http-01` challenges using
 a built-in web server and validation of `dns-01` challenges using a DNS plugin
 supporting all the DNS API endpoints https://acme.sh[acme.sh] does.
 
@@ -67,8 +67,8 @@ ACME Account
 
 [thumbnail="pmg-gui-acme-create-account.png"]
 
-You need to register an ACME account per cluster with the endpoint you want to
-use. The email address used for that account will serve as contact point for
+You need to register an ACME account per cluster, with the endpoint you want to
+use. The email address used for that account will serve as the contact point for
 renewal-due or similar notifications from the ACME endpoint.
 
 You can register or deactivate ACME accounts over the web interface
@@ -86,15 +86,15 @@ directory.
 ACME Plugins
 ^^^^^^^^^^^^
 
-The ACME plugins task is to provide automatic verification that you, and thus
+The ACME plugin's role is to provide automatic verification that you, and thus
 the {pmg} cluster under your operation, are the real owner of a domain. This is
-the basis building block for automatic certificate management.
+the basic building block of automatic certificate management.
 
 The ACME protocol specifies different types of challenges, for example the
-`http-01` where a web server provides a file with a certain content to prove
+`http-01`, where a web server provides a file with a specific token to prove
 that it controls a domain. Sometimes this isn't possible, either because of
 technical limitations or if the address of a record is not reachable from the
-public internet. The `dns-01` challenge can be used in these cases.  The
+public internet. The `dns-01` challenge can be used in such cases. This
 challenge is fulfilled by creating a certain DNS record in the domain's zone.
 
 [thumbnail="pmg-gui-acme-create-challenge-plugin.png"]
@@ -116,7 +116,7 @@ using the `pmgconfig` command.
 
 After configuring the desired domain(s) for a node and ensuring that the
 desired ACME account is selected, you can order your new certificate over the
-web-interface. On success the interface will reload after circa 10 seconds.
+web-interface. On success, the interface will reload after roughly 10 seconds.
 
 Renewal will happen xref:sysadmin_certs_acme_automatic_renewal[automatically].
 
@@ -125,13 +125,13 @@ ACME HTTP Challenge Plugin
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 There is always an implicitly configured `standalone` plugin for validating
-`http-01` challenges via the built-in webserver spawned on port 80.
+`http-01` challenges via the built-in web server spawned on port 80.
 
-NOTE: The name `standalone` means that it can provide the validation on it's
-own, without any third party service. So, this plugin works also for cluster
+NOTE: The name `standalone` means that it can provide the validation on its
+own, without any third party service. So this plugin also works for cluster
 nodes.
 
-There are a few prerequisites to use it for certificate management with Let's
+There are a few prerequisites to use this for certificate management with Let's
 Encrypts ACME.
 
 * You have to accept the ToS of Let's Encrypt to register an account.
@@ -154,7 +154,7 @@ Configuring ACME DNS APIs for validation
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 {pmg} re-uses the DNS plugins developed for the `acme.sh`
-footnote:[acme.sh https://github.com/acmesh-official/acme.sh] project, please
+footnote:[acme.sh https://github.com/acmesh-official/acme.sh] project. Please
 refer to its documentation for details on configuration of specific APIs.
 
 The easiest way to configure a new plugin with the DNS API is using the web
@@ -162,27 +162,27 @@ interface (`Certificates -> ACME Accounts/Challenges`).
 
 [thumbnail="pmg-gui-acme-create-challenge-plugin.png"]
 
-Add a new challenge plugin, here you can select your API provider, enter the
-credential data to access your account over their API.
+Here you can add a new challenge plugin by selecting your API provider and
+entering the credential data to access your account over their API.
 
 TIP: See the acme.sh
 https://github.com/acmesh-official/acme.sh/wiki/dnsapi#how-to-use-dns-api[How to use DNS API]
 wiki for more detailed information about getting API credentials for your
 provider. Configuration values do not need to be quoted with single or double
-quotes, for some plugins that is even an error.
+quotes; for some plugins that is even an error.
 
-As there are many DNS providers and API endpoints {pmg} automatically generates
-the form for the credentials, but not all providers are annotated yet. For
-those you will see a bigger text area, simply copy all the credentials
-`KEY`=`VALUE` pairs in there.
+As there are many DNS providers and API endpoints, {pmg} automatically generates
+the form for the credentials, but not all providers are annotated yet. For those
+you will see a bigger text area, into which you simply need to copy all the
+credential's `KEY`=`VALUE` pairs.
 
 DNS Validation through CNAME Alias
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-A special `alias` mode can be used to handle the validation on a different
+A special `alias` mode can be used to handle validation on a different
 domain/DNS server, in case your primary/real DNS does not support provisioning
 via an API. Manually set up a permanent `CNAME` record for
-`_acme-challenge.domain1.example` pointing to `_acme-challenge.domain2.example`
+`_acme-challenge.domain1.example` pointing to `_acme-challenge.domain2.example`,
 and set the `alias` property in the {pmg} node configuration file
 `/etc/pmg/node.conf` to `domain2.example` to allow the DNS server of
 `domain2.example` to validate all challenges for `domain1.example`.
@@ -193,10 +193,10 @@ Wildcard Certificates
 
 Wildcard DNS names start with a `*.` prefix and are considered valid for all
 (one-level) subdomain names of the verified domain. So a certificate for
-`*.domain.example` is valid for example for `foo.domain.example` and
+`*.domain.example` is valid for `foo.domain.example` and
 `bar.domain.example`, but not for `baz.foo.domain.example`.
 
-You can currently create wildcard certificates only with the
+Currently, you can only create wildcard certificates with the
 https://letsencrypt.org/docs/challenge-types/#dns-01-challenge[DNS challenge type].
 
 
@@ -217,9 +217,9 @@ Automatic renewal of ACME certificates
 
 If a node has been successfully configured with an ACME-provided certificate
 (either via pmgconfig or via the web-interface/API), the certificate will be
-automatically renewed by the `pmg-daily.service`. Currently, renewal is
-triggered if the certificate either already expired or if it will expire in the
-next 30 days.
+renewed automatically by the `pmg-daily.service`. Currently, renewal is
+triggered if the certificate either has already expired or if it will expire in
+the next 30 days.
 
 Manually Change Certificate over Command-Line
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -227,13 +227,13 @@ Manually Change Certificate over Command-Line
 If you want to get rid of certificate verification warnings, you have to
 generate a valid certificate for your server.
 
-Login to your {pmg} via ssh or use the console:
+Log in to your {pmg} via ssh or use the console:
 
 ----
 openssl req -newkey rsa:2048 -nodes -keyout key.pem -out req.pem
 ----
 
-Follow the instructions on the screen, see this example:
+Follow the instructions on the screen, for example:
 
 ----
 Country Name (2 letter code) [AU]: AT
@@ -249,9 +249,9 @@ A challenge password []: not necessary
 An optional company name []: not necessary
 ----
 
-After you finished this certificate request you have to send the file
+After you have finished the certificate request, you have to send the file
 `req.pem` to your Certification Authority (CA). The CA will issue the
-certificate (BASE64 encoded) based on your request – save this file as
+certificate (BASE64 encoded), based on your request – save this file as
 `cert.pem` to your {pmg}.
 
 To activate the new certificate, do the following on your {pmg}:
@@ -266,11 +266,11 @@ Then restart the API servers:
 systemctl restart pmgproxy
 ----
 
-Test your new certificate by using your browser.
+Test your new certificate, using your browser.
 
-NOTE: To transfer files from and to your {pmg}, you can use secure copy: If you
-desktop is Linux, you can use the `scp` command line tool. If your desktop PC
-is windows, please use a scp client like WinSCP (see https://winscp.net/).
+NOTE: To transfer files to and from your {pmg}, you can use secure copy: If your
+desktop runs Linux, you can use the `scp` command line tool. If your desktop PC
+runs windows, please use an scp client like WinSCP (see https://winscp.net/).
 
 Change Certificate for Cluster Setups
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- 
2.30.2

[pmg-devel] applied-series: [PATCH pmg-docs 1/4] service daemons: language fixup

[Stoiko Ivanov]

Huge Thanks for taking the time to improve the docs!!

applied all 4 patches.

the improvments for pmgproxy.adoc and pmg-ssl-certificate.adoc
should at some point also be carried over to pve-docs (where they were
orignally taken from)

thinking about it - we might consider eventually adding a dedicated
repository for shared documentation and then use that in all products
(maybe with some sed preprocessing)




On Tue, 13 Jul 2021 17:54:03 +0200
Dylan Whyte <d.whyte@proxmox.com> wrote:

> Very minor language updates to the "Important Service Daemons" section
> of the docs
> 
> Signed-off-by: Dylan Whyte <d.whyte@proxmox.com>
> ---
>  pmg-smtp-filter.adoc |  8 ++++----
>  pmgdaemon.adoc       |  2 +-
>  pmgmirror.adoc       |  2 +-
>  pmgpolicy.adoc       |  4 ++--
>  pmgproxy.adoc        | 41 +++++++++++++++++++++--------------------
>  pmgtunnel.adoc       |  6 +++---
>  6 files changed, 32 insertions(+), 31 deletions(-)
> 
> diff --git a/pmg-smtp-filter.adoc b/pmg-smtp-filter.adoc
> index 153178e..58033e4 100644
> --- a/pmg-smtp-filter.adoc
> +++ b/pmg-smtp-filter.adoc
> @@ -23,14 +23,14 @@ pmg-smtp-filter - Proxmox SMTP Filter Daemon
>  ============================================
>  endif::manvolnum[]
>  
> -This is the Proxmox SMTP filter daemon, which does the actual spam
> -filtering using the SpamAssassin and the rule database. It listens on
> +The Proxmox SMTP Filter Daemon does the actual spam
> +filtering, using {spamassassin} and the rule database. It listens on
>  127.0.0.1:10023 and 127.0.0.1:10024. The daemon listens to a local
> -address only, so you cannot access it from outside.
> +address only, so you cannot access it from the outside.
>  
>  With our postfix configuration, incoming mails are sent to
>  127.0.0.1:10024. Outgoing (trusted) mails are sent to
> -127.0.0.1:10023. After filtering, mails are reinjected into postfix at
> +127.0.0.1:10023. After filtering, mails are resent to Postfix at
>  127.0.0.1:10025.
>  
>  
> diff --git a/pmgdaemon.adoc b/pmgdaemon.adoc
> index a809c02..4e9e03b 100644
> --- a/pmgdaemon.adoc
> +++ b/pmgdaemon.adoc
> @@ -27,7 +27,7 @@ This daemon exposes the whole {pmg} API on `127.0.0.1:85`. It runs as
>  `root` and has permission to do all privileged operations.
>  
>  NOTE: The daemon listens to a local address only, so you cannot access
> -it from outside. The `pmgproxy` daemon exposes the API to the outside
> +it from the outside. The `pmgproxy` daemon exposes the API to the outside
>  world.
>  
>  
> diff --git a/pmgmirror.adoc b/pmgmirror.adoc
> index 2f2c12d..80d69c3 100644
> --- a/pmgmirror.adoc
> +++ b/pmgmirror.adoc
> @@ -23,7 +23,7 @@ pmgmirror - Database Mirror Daemon
>  ==================================
>  endif::manvolnum[]
>  
> -{pmg} uses an application specific asynchronous replication
> +{pmg} uses an application-specific, asynchronous replication
>  algorithm to replicate the database to all cluster nodes.
>  
>  The daemon uses the ssh tunnel provided by 'pmgtunnel' to access
> diff --git a/pmgpolicy.adoc b/pmgpolicy.adoc
> index 813ed9e..1dbc0fb 100644
> --- a/pmgpolicy.adoc
> +++ b/pmgpolicy.adoc
> @@ -25,8 +25,8 @@ endif::manvolnum[]
>  
>  This daemon implements the Postfix SMTP access policy delegation
>  protocol on `127.0.0.1:10022`. It listens to a local address
> -only, so you cannot access it from outside. We configure Postfix to
> -use this service for greylisting and as SPF policy server.
> +only, so you cannot access it from the outside. We configure Postfix to
> +use this service for greylisting and as an SPF policy server.
>  
>  
>  ifdef::manvolnum[]
> diff --git a/pmgproxy.adoc b/pmgproxy.adoc
> index d5c1112..6e48fba 100644
> --- a/pmgproxy.adoc
> +++ b/pmgproxy.adoc
> @@ -23,12 +23,12 @@ pmgproxy - Proxmox Mail Gateway API Proxy Daemon
>  ================================================
>  endif::manvolnum[]
>  
> -This daemon exposes the whole {pmg} API on TCP port 8006 using
> +This daemon exposes the whole {pmg} API on TCP port 8006, using
>  HTTPS. It runs as user `www-data` and has very limited permissions.
>  Operations requiring more permissions are forwarded to the local
>  `pmgdaemon`.
>  
> -Requests targeted for other nodes are automatically forwarded to those
> +Requests targeted at other nodes are automatically forwarded to those
>  nodes. This means that you can manage your whole cluster by connecting
>  to a single {pmg} node.
>  
> @@ -76,18 +76,18 @@ By default the `pmgproxy` daemon listens on the wildcard address and accepts
>  connections from both IPv4 and IPv6 clients.
>  
>  
> -By setting `LISTEN_IP` in `/etc/default/pmgproxy` you can control to which IP
> -address the `pmgproxy` daemon binds. The IP-address needs to be configured on
> +By setting `LISTEN_IP` in `/etc/default/pmgproxy`, you can control which IP
> +address the `pmgproxy` daemon binds to. The IP-address needs to be configured on
>  the system.
>  
>  Setting the `sysctl` `net.ipv6.bindv6only` to the non-default `1` will cause
> -the daemons to only accept connection from IPv6 clients, while  usually also
> -causing lots of other issues. If you set this configuration we recommend to
> -either remove the `sysctl` setting, or set the `LISTEN_IP` to `0.0.0.0` (which
> -will only allow IPv4 clients).
> +the daemons to only accept connections from IPv6 clients, while usually also
> +causing lots of other issues. If you set this configuration, we recommend either
> +removing the `sysctl` setting, or setting the `LISTEN_IP` to `0.0.0.0` (which
> +will allow only IPv4 clients).
>  
> -`LISTEN_IP` can be used to only to restricting the socket to an internal
> -interface and thus have less exposure to the public internet, for example:
> +`LISTEN_IP` can be used to restrict the socket to an internal
> +interface, thus leaving less exposure to the public internet, for example:
>  
>  ----
>  LISTEN_IP="192.0.2.1"
> @@ -107,8 +107,8 @@ LISTEN_IP="fe80::c463:8cff:feb9:6a4e%vmbr0"
>  ----
>  
>  WARNING: The nodes in a cluster need access to `pmgproxy` for communication,
> -possibly on different sub-nets. It is **not recommended** to set `LISTEN_IP` on
> -clustered systems.
> +possibly across different subnets. It is **not recommended** to set `LISTEN_IP`
> +on clustered systems.
>  
>  To apply the change you need to either reboot your node or fully restart the
>  `pmgproxy` service:
> @@ -118,24 +118,24 @@ systemctl restart pmgproxy.service
>  ----
>  
>  NOTE: Unlike `reload`, a `restart` of the pmgproxy service can interrupt some
> -long-running worker processes, for example a running console.So, please use a
> -maintenance window to bring this change in effect.
> +long-running worker processes, for example, a running console. Therefore, you
> +should set a maintenance window to bring this change into effect.
>  
>  
>  SSL Cipher Suite
>  ----------------
>  
> -You can define the cipher list in `/etc/default/pmgproxy`, for example
> +You can define the cipher list in `/etc/default/pmgproxy`, for example:
>  
>   CIPHERS="ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256"
>  
> -Above is the default. See the `ciphers(1)` man page from the `openssl`
> +The above is the default. See the `ciphers(1)` man page from the `openssl`
>  package for a list of all available options.
>  
> -The first of these ciphers, available to both the client and the `pmgproxy`,
> +The first of these ciphers that is available to both the client and `pmgproxy`
>  will be used.
>  
> -Additionally you can allow the client to choose the cipher from the list above
> +Additionally, you can allow the client to choose the cipher from the list above,
>  by disabling the HONOR_CIPHER_ORDER option in `/etc/default/pmgproxy`:
>  
>   HONOR_CIPHER_ORDER=0
> @@ -146,7 +146,7 @@ Diffie-Hellman Parameters
>  
>  You can define the used Diffie-Hellman parameters in
>  `/etc/default/pmgproxy` by setting `DHPARAMS` to the path of a file
> -containing DH parameters in PEM format, for example
> +containing DH parameters in PEM format, for example:
>  
>   DHPARAMS="/path/to/dhparams.pem"
>  
> @@ -160,7 +160,8 @@ COMPRESSION
>  -----------
>  
>  By default `pmgproxy` uses gzip HTTP-level compression for compressible
> -content if the client supports it. This can be disabled in `/etc/default/pmgproxy`
> +content, if the client supports it. This can be disabled in
> +`/etc/default/pmgproxy`
>  
>   COMPRESSION=0
>  
> diff --git a/pmgtunnel.adoc b/pmgtunnel.adoc
> index 6847c69..792043e 100644
> --- a/pmgtunnel.adoc
> +++ b/pmgtunnel.adoc
> @@ -23,10 +23,10 @@ pmgtunnel - Cluster Tunnel Daemon
>  =================================
>  endif::manvolnum[]
>  
> -This daemon creates a ssh tunnel to the postgres database in other
> +This daemon creates an ssh tunnel to the Postgres databases on other
>  cluster nodes (port 5432). The tunnel is used to synchronize the
> -database using an application specific asynchronous replication
> -algorythm.
> +database, using an application-specific, asynchronous replication
> +algorithm.
>  
>  ifdef::manvolnum[]
>  include::pmg-copyright.adoc[]