* [pmg-devel] [PATCH pmg-docs 2/4] cli tools: language fixup
2021-07-13 15:54 [pmg-devel] [PATCH pmg-docs 1/4] service daemons: language fixup Dylan Whyte
@ 2021-07-13 15:54 ` Dylan Whyte
2021-07-13 15:54 ` [pmg-devel] [PATCH pmg-docs 3/4] faq: " Dylan Whyte
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: Dylan Whyte @ 2021-07-13 15:54 UTC (permalink / raw)
To: pmg-devel
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
^ permalink raw reply [flat|nested] 5+ messages in thread* [pmg-devel] [PATCH pmg-docs 3/4] faq: language fixup
2021-07-13 15:54 [pmg-devel] [PATCH pmg-docs 1/4] service daemons: language fixup Dylan Whyte
2021-07-13 15:54 ` [pmg-devel] [PATCH pmg-docs 2/4] cli tools: " Dylan Whyte
@ 2021-07-13 15:54 ` Dylan Whyte
2021-07-13 15:54 ` [pmg-devel] [PATCH pmg-docs 4/4] certificate management: langauge fixup Dylan Whyte
2021-07-13 16:41 ` [pmg-devel] applied-series: [PATCH pmg-docs 1/4] service daemons: language fixup Stoiko Ivanov
3 siblings, 0 replies; 5+ messages in thread
From: Dylan Whyte @ 2021-07-13 15:54 UTC (permalink / raw)
To: pmg-devel
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
^ permalink raw reply [flat|nested] 5+ messages in thread* [pmg-devel] [PATCH pmg-docs 4/4] certificate management: langauge fixup
2021-07-13 15:54 [pmg-devel] [PATCH pmg-docs 1/4] service daemons: language fixup Dylan Whyte
2021-07-13 15:54 ` [pmg-devel] [PATCH pmg-docs 2/4] cli tools: " Dylan Whyte
2021-07-13 15:54 ` [pmg-devel] [PATCH pmg-docs 3/4] faq: " Dylan Whyte
@ 2021-07-13 15:54 ` Dylan Whyte
2021-07-13 16:41 ` [pmg-devel] applied-series: [PATCH pmg-docs 1/4] service daemons: language fixup Stoiko Ivanov
3 siblings, 0 replies; 5+ messages in thread
From: Dylan Whyte @ 2021-07-13 15:54 UTC (permalink / raw)
To: pmg-devel
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
^ permalink raw reply [flat|nested] 5+ messages in thread* [pmg-devel] applied-series: [PATCH pmg-docs 1/4] service daemons: language fixup
2021-07-13 15:54 [pmg-devel] [PATCH pmg-docs 1/4] service daemons: language fixup Dylan Whyte
` (2 preceding siblings ...)
2021-07-13 15:54 ` [pmg-devel] [PATCH pmg-docs 4/4] certificate management: langauge fixup Dylan Whyte
@ 2021-07-13 16:41 ` Stoiko Ivanov
3 siblings, 0 replies; 5+ messages in thread
From: Stoiko Ivanov @ 2021-07-13 16:41 UTC (permalink / raw)
To: pmg-devel
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[]
^ permalink raw reply [flat|nested] 5+ messages in thread