[pmg-devel] [PATCH docs] pmgcm.adoc: improve wording and grammar

Oguz Bektas o.bektas at proxmox.com
Wed Oct 30 16:09:51 CET 2019


hi,

found another typo :O

On Wed, Oct 30, 2019 at 04:05:07PM +0100, Oguz Bektas wrote:
> Signed-off-by: Oguz Bektas <o.bektas at proxmox.com>
> ---
>  pmgcm.adoc | 32 +++++++++++++++-----------------
>  1 file changed, 15 insertions(+), 17 deletions(-)
> 
> diff --git a/pmgcm.adoc b/pmgcm.adoc
> index aef2308..fa0db98 100644
> --- a/pmgcm.adoc
> +++ b/pmgcm.adoc
> @@ -105,7 +105,7 @@ Hot standby with backup `MX` records
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  
>  Many people do not want to install two redundant mail proxies, instead
> -they use the mail proxy of their ISP as fall-back. This is simply done
> +they use the mail proxy of their ISP as fallback. This is simply done
>  by adding an additional `MX` Record with a lower priority (higher
>  number). With the example above this looks like that:
>  
> @@ -113,20 +113,19 @@ number). With the example above this looks like that:
>  proxmox.com.            22879   IN      MX      100 mail.provider.tld.
>  ----
>  
> -Sure, your provider must accept mails for your domain and forward
> -received mails to you. Please note that such setup is not really
> -advisable, because spam detection needs to be done by that backup `MX`
> -server also, and external servers provided by ISPs usually don't do
> -that.
> +In such a setup, your provider must accept mails for your domain and forward
> +them to you. Please note that such setup is not really advisable, because spam
> +detection needs to be done also by that backup `MX` server, and external servers
> +provided by ISPs usually don't.
>  
> -You will never lose mails with such a setup, because the sending Mail
> +However, you will never lose mails with such a setup, because the sending Mail
>  Transport Agent (MTA) will simply deliver the mail to the backup
>  server (mail.provider.tld) if the primary server (mail.proxmox.com) is
>  not available.
>  
> -NOTE: Any resononable mail server retries mail devivery if the target

s/resosonable/reasonable

> +NOTE: Any resononable mail server retries mail delivery if the target
>  server is not available, i.e. {pmg} stores mail and retries delivery
> -for up to one week. So you will not loose mail if you mail server is
> +for up to one week. So you will not lose mail if your mail server is
>  down, even if you run a single server setup.
>  
>  
> @@ -140,8 +139,7 @@ avoid lower spam detection rates.
>  
>  Anyways, it’s quite simple to set up a high performance load balanced
>  mail cluster using `MX` records. You just need to define two `MX` records
> -with the same priority. I will explain this using a complete example
> -to make it clearer.
> +with the same priority. Here is a complete example to make it clearer.
>  
>  First, you need to have at least 2 working {pmg} servers
>  (mail1.example.com and mail2.example.com) configured as cluster (see
> @@ -154,7 +152,7 @@ mail1.example.com.       22879   IN      A       1.2.3.4
>  mail2.example.com.       22879   IN      A       1.2.3.5
>  ----
>  
> -Btw, it is always a good idea to add reverse lookup entries (PTR
> +It is always a good idea to add reverse lookup entries (PTR
>  records) for those hosts. Many email systems nowadays reject mails
>  from hosts without valid PTR records.  Then you need to define your `MX`
>  records:
> @@ -166,7 +164,7 @@ example.com.            22879   IN      MX      10 mail2.example.com.
>  
>  This is all you need. You will receive mails on both hosts, more or
>  less load-balanced using round-robin scheduling. If one host fails the
> -other is used.
> +other one is used.
>  
>  
>  Other ways
> @@ -175,7 +173,7 @@ Other ways
>  Multiple address records
>  ^^^^^^^^^^^^^^^^^^^^^^^^
>  
> -Using several DNS `MX` record is sometime clumsy if you have many
> +Using several DNS `MX` record is sometimes clumsy if you have many
>  domains. It is also possible to use one `MX` record per domain, but
>  multiple address records:
>  
> @@ -210,7 +208,7 @@ Creating a Cluster
>  
>  image::images/screenshot/pmg-gui-cluster-panel.png[]
>  
> -You can create a cluster from any existing Proxmox host. All data is
> +You can create a cluster from any existing {pmg} host. All data is
>  preserved.
>  
>  * make sure you have the right IP configuration
> @@ -245,7 +243,7 @@ Adding Cluster Nodes
>  
>  image::images/screenshot/pmg-gui-cluster-join.png[]
>  
> -When you add a new node to a cluster (join) all data on that node is
> +When you add a new node to a cluster (using `join`) all data on that node is
>  destroyed. The whole database is initialized with cluster data from
>  the master.
>  
> @@ -296,7 +294,7 @@ damaged hardware or disk. {pmg} uses an asynchronous
>  clustering algorithm, so you just need to reboot the repaired node,
>  and everything will work again transparently.
>  
> -The following scenarios only apply when you really loose the contents
> +The following scenarios only apply when you really lose the contents
>  of the hard disk.
>  
>  
> -- 
> 2.20.1
> 
> 



More information about the pmg-devel mailing list