Configuring the synchronization of two iRedMail mailers on two channels
What is there
What is needed
Resiliency of the mail server in case of failure of one of the mail servers or the fall of the channel of one of the providers. The ability to conduct those. work, testing new modules, etc. on one of the mail servers. Organization of cluster similarity.
Scheme
Why is that
iRedMail - OpenSoures mailer, the basis of postfix, dovecot, openldap, antivirus, antispam (look at the off site ). All packages are native, support system updates apt-get update, upgrade, support for the Russian language and in the admin too. I foresee statements that all these designers are not good - “I will install and adjust everything”, I will not argue ... this is just my experience - I share what I have.
1. Install Ubuntu 12.04 LTS x64 (don't forget about SSH, for how to remotely manage ... :))
go to the page of the installation guide iRedMail. We use everything as written - ubuntu 12.04 LTS, RAM - 250Mb, HDD - 10G (not enough for the mailer, but we will store the boxes on a separate server)
2. We will hold preparatory activities
To store mail, we will use the mounted folder on another server, which will give us the opportunity to disconnect or overload any of the clustered mail servers without fear of losing access to user boxes.
There are two options for mounting SAMBA and NFS, the best solution, I think NFS is native, they say the speed is bigger and the processor is less loaded. I will describe both options, you decide what to use.
')
2.1 NFS
On the mail storage server, we install NFS support:
Create a folder to store mail
Create a vmail user with UID 1001 (if iRedMail was installed on a mailer on a clean system, it will be with that UID) with the / var / vmail-str home folder and / sbin / nologin shell.
Rule exports
Here our letters will be stored, we open it on NFS.
2.2 SMB (currently not working - error with access / rights)
3. On the client (or rather, on one of the servers with iRedMail) connect the folder via NFS
Install the NFS client
Rule / etc / fstab
adding a line
4. The installation of iRedMAIL itself is quite well described at the office. manufacturer's website.
www.iredmail.org/doc.html
Installation was performed on Ubuntu server 12.04 LTS
Further, all as in the standard manual
and further on the manual .
After installing at least one server, you need to check the rights in the / var / vmail directory (remember, it is connected to us from the MAIL-STORAGE server)
should be like this:
If necessary, change, going to our MAIL-STORAGE:
5. Installing iRedAdmin-Pro (we bought)
unpack the archive
rewrite rights
change symlink
we copy settings
You can enter the admin area
6. Repeat pp 3, 4 and 5
for the second and Nth servers. As a result, we will get N servers with iRedMail that have users as their repository - their own LDAP and mail storage in one array - MAIL-STORAGE.
7. Configure LDAP Sync
Choose a replication method - a mirror (if you turn off any server, all the others continue to work and serve clients)
From the office. site excerpt .
7.1 First we add a line to /etc/ldap/slapd.conf
for without this, no synchronization will take place at all and the addition of this parameter is not explicitly described.
Next, set up the supplier / consumer 192.168.1.10
In the main directives (at the beginning of the /etc/ldap/slapd.conf file) add the server ID
Add to the end of the file:
Immediately set up as a consumer
The hardest part is not to make a mistake and find binddn credentials
And we search from the file: iRedMail.tips in the directory from where the mailer was installed or in the letter to the admin who we will connect to (192.168.1.20) We are looking for a line
This will be our login and password.
You also need to add the provider functions in /etc/ldap/slapd.conf:
7.2 Next, set up the supplier / consumer 192.168.1.20
In the main directives (at the beginning of the /etc/ldap/slapd.conf file) add the server ID
Add to the end of the file:
Immediately set up as a consumer
We are looking for in the file: iRedMail.tips in the directory from where the mailer was installed or in the letter to the admin to which we will connect (192.168.1.10) We are looking for a line
This will be our login and password.
You also need to add the provider functions in /etc/ldap/slapd.conf:
8. We skip LDAP on both servers and see the log:
If something like that
That means something is wrong and you need to carefully edit slapd.conf
10. Check
Go to the admin panel of one and the other server.
We add the user, the domain, etc. And we watch its emergence on the second server.
We perform actions to remove, modify, add data to one server and check the appearance on the other.
11. Conclusion
We received a mail cluster running on two Internet channels on two white IP.
Provided that in DNS we have two IP for one domain name
mail.domen.my - 1.1.1.1
mail.domen.my - 2.2.2.2
and the availability of two DNS under different channels we have:
In case of failure of one of the channels or exit from a standing (shutdown for service) of one of the mail servers, clients will have access and maintenance on the second mail server.
Also, some unloading of channels and servers is achieved in case of random issuance of IP mailers by DNS servers.
12. Sources
- Two channels on the Internet from different providers
- Two different pools of IP addresses (1.1.1.1/28, 2.2.2.1/28)
- Two DNS servers on their own sites supporting the doman.my zone with MX records mail.domen.my - 1.1.1.1; mail.domen.my - 2.2.2.2
- Two PTR records for two providers (1.1.1.1 - mail.domen.my, 2.2.2.2 - mail.domen.my)
- SSL certificate for domain * .doman.my
- Inside the DMZ mailers will have IP 192.168.1.10 and 192.168.1.20
What is needed
Resiliency of the mail server in case of failure of one of the mail servers or the fall of the channel of one of the providers. The ability to conduct those. work, testing new modules, etc. on one of the mail servers. Organization of cluster similarity.
Scheme
Why is that
iRedMail - OpenSoures mailer, the basis of postfix, dovecot, openldap, antivirus, antispam (look at the off site ). All packages are native, support system updates apt-get update, upgrade, support for the Russian language and in the admin too. I foresee statements that all these designers are not good - “I will install and adjust everything”, I will not argue ... this is just my experience - I share what I have.
1. Install Ubuntu 12.04 LTS x64 (don't forget about SSH, for how to remotely manage ... :))
go to the page of the installation guide iRedMail. We use everything as written - ubuntu 12.04 LTS, RAM - 250Mb, HDD - 10G (not enough for the mailer, but we will store the boxes on a separate server)
2. We will hold preparatory activities
To store mail, we will use the mounted folder on another server, which will give us the opportunity to disconnect or overload any of the clustered mail servers without fear of losing access to user boxes.
There are two options for mounting SAMBA and NFS, the best solution, I think NFS is native, they say the speed is bigger and the processor is less loaded. I will describe both options, you decide what to use.
')
2.1 NFS
On the mail storage server, we install NFS support:
$sudo apt-get install nfs-kernel-server nfs-common Create a folder to store mail
$sudo mkdir /var/vmail-str Create a vmail user with UID 1001 (if iRedMail was installed on a mailer on a clean system, it will be with that UID) with the / var / vmail-str home folder and / sbin / nologin shell.
Rule exports
$sudo vim /etc/exports /var/vmail-str 192.168.1.0/24(rw,sync,no_root_squash,no_subtree_check) Here our letters will be stored, we open it on NFS.
2.2 SMB (currently not working - error with access / rights)
Install the SMBFS package
- mail storage, here we mount the ball.
Add line to / etc / fstab
There is an unresolved problem: the mailer cannot access the mail storage folder on the SMB server, although the rights are 0777 root: root to all folders in the / var / vmail / directory. It is necessary to dig in the direction of rights on the side of the SMB server
sudo apt-get install smbfs mkdir /var/vmail - mail storage, here we mount the ball.
Add line to / etc / fstab
//192.168.1.3/vmail /var/vmail smbfs user=pochta,pass=pismo,rw,utf8,dir_mode=0777,file_mode=0777 0 0 There is an unresolved problem: the mailer cannot access the mail storage folder on the SMB server, although the rights are 0777 root: root to all folders in the / var / vmail / directory. It is necessary to dig in the direction of rights on the side of the SMB server
3. On the client (or rather, on one of the servers with iRedMail) connect the folder via NFS
Install the NFS client
$sudo apt-get install nfs-common Rule / etc / fstab
adding a line
192.168.1.3:/var/vmail-str /var/vmail nfs user,rw 0 0 4. The installation of iRedMAIL itself is quite well described at the office. manufacturer's website.
www.iredmail.org/doc.html
Installation was performed on Ubuntu server 12.04 LTS
Further, all as in the standard manual
hostname -f... post-t1.domen.my and further on the manual .
After installing at least one server, you need to check the rights in the / var / vmail directory (remember, it is connected to us from the MAIL-STORAGE server)
should be like this:
$sudo ls -l /var/vmail drwxr-xr-x 4 root root 4096 5 03:30 backup drwx------ 2 vmail vmail 4096 18 16:03 sieve drwx------ 6 vmail vmail 4096 . 10 13:23 vmail1 If necessary, change, going to our MAIL-STORAGE:
$sudo chown -R vmail:vmail /var/vmail/vmail1 $sudo chown -R vmail:vmail /var/vmail/sieve 5. Installing iRedAdmin-Pro (we bought)
unpack the archive
$tar xfz iRedAdmin-Pro-LDAP-1.7.2.tar.bz2 /usr/share/apache2 rewrite rights
$sudo chown -R iredadmin:iredadmin iRedAdmin-Pro-LDAP-1.7.2/ change symlink
$sudo ln -s /usr/share/apache2/iRedAdmin-Pro-LDAP-1.7.2/ /usr/share/apache2/iredadmin we copy settings
$sudo cp /usr/share/apache2/iRedAdmin-0.1.8/settings.ini /usr/share/apache2/iRedAdmin-Pro-LDAP-1.7.2/ You can enter the admin area
https: // ip_server / iredadmin /login: postmaster@domen.my pass:% which% was entered during installation
6. Repeat pp 3, 4 and 5
for the second and Nth servers. As a result, we will get N servers with iRedMail that have users as their repository - their own LDAP and mail storage in one array - MAIL-STORAGE.
7. Configure LDAP Sync
Choose a replication method - a mirror (if you turn off any server, all the others continue to work and serve clients)
From the office. site excerpt .
To read
18.2.3. Mirror Mode Replication (MirrorMode)
Mirror mode is a hybrid configuration that provides all the guarantees of data integrity, as in replication with a single main server, while simultaneously providing high availability, as in replicating with several main servers. In the mirror mode, two vendors are configured to replicate from each other (as is the case with multiple master servers), but some external interface is used that sends all update requests to only one of the two servers. In case of failure of the first supplier, the above interface will switch all update requests to the second supplier, and he, in turn, will receive and process them. When restoring and restarting a failed supplier, it will automatically request all changes from a functioning supplier and will resynchronize.
18.2.3.1. Positive moments of replication in mirror mode
High-availability solution (high-availability, HA) for both catalog update operations and subsequent synchronization with consumer replicas.
As long as at least one provider is operational, you can safely receive update operations.
Supplying servers are replicated from each other, so they are constantly up to date and are always ready to replace each other (hot swap).
Syncrepl also allows supplier northers to rebrain after idle times of any length.
18.2.3.2. Negative Replication Times in Mirror Mode
Replication in the mirror mode is not what is commonly called a solution with several main servers, since the update operations at a certain point in time are accepted only by one of the mirror servers.
The mirror mode can be designated as two active servers with hot swapping of each other (Active Active Active Hot-Standby), therefore, to decide which supplier server is currently active, an external server is required (slapd in proxy mode) or a device (hardware balancer load).
Somewhat different backup management:
If you are backing up the Berkeley database itself and periodically backing up transaction log files, then until the next database backup is made, you need to make copies of the same server log files from a pair of mirror servers.
Delta-syncrepl is still not supported.
Mirror mode is a hybrid configuration that provides all the guarantees of data integrity, as in replication with a single main server, while simultaneously providing high availability, as in replicating with several main servers. In the mirror mode, two vendors are configured to replicate from each other (as is the case with multiple master servers), but some external interface is used that sends all update requests to only one of the two servers. In case of failure of the first supplier, the above interface will switch all update requests to the second supplier, and he, in turn, will receive and process them. When restoring and restarting a failed supplier, it will automatically request all changes from a functioning supplier and will resynchronize.
18.2.3.1. Positive moments of replication in mirror mode
High-availability solution (high-availability, HA) for both catalog update operations and subsequent synchronization with consumer replicas.
As long as at least one provider is operational, you can safely receive update operations.
Supplying servers are replicated from each other, so they are constantly up to date and are always ready to replace each other (hot swap).
Syncrepl also allows supplier northers to rebrain after idle times of any length.
18.2.3.2. Negative Replication Times in Mirror Mode
Replication in the mirror mode is not what is commonly called a solution with several main servers, since the update operations at a certain point in time are accepted only by one of the mirror servers.
The mirror mode can be designated as two active servers with hot swapping of each other (Active Active Active Hot-Standby), therefore, to decide which supplier server is currently active, an external server is required (slapd in proxy mode) or a device (hardware balancer load).
Somewhat different backup management:
If you are backing up the Berkeley database itself and periodically backing up transaction log files, then until the next database backup is made, you need to make copies of the same server log files from a pair of mirror servers.
Delta-syncrepl is still not supported.
7.1 First we add a line to /etc/ldap/slapd.conf
# Modules. moduleload syncprov.la for without this, no synchronization will take place at all and the addition of this parameter is not explicitly described.
Next, set up the supplier / consumer 192.168.1.10
In the main directives (at the beginning of the /etc/ldap/slapd.conf file) add the server ID
serverID 1 # Add to the end of the file:
index objectClass,entryCSN,entryUUID eq,pres Immediately set up as a consumer
syncrepl rid=001 provider=ldap://192.168.1.20 bindmethod=simple interval=00:00:10:00 binddn="cn=vmail,dc=domen,dc=my" credentials=yzjiFdasfkoZSDbladfjoweotHgWiNxFHcb searchbase="dc=domen,dc=my" schemachecking=off type=refreshAndPersist retry="60 +" The hardest part is not to make a mistake and find binddn credentials
And we search from the file: iRedMail.tips in the directory from where the mailer was installed or in the letter to the admin who we will connect to (192.168.1.20) We are looking for a line
* LDAP bind dn (read-only): cn=vmail,dc=domen,dc=my, password: yzjiFdasfkoZSDbladfjoweotHgWiNxFHcb This will be our login and password.
You also need to add the provider functions in /etc/ldap/slapd.conf:
mirrormode on overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 7.2 Next, set up the supplier / consumer 192.168.1.20
In the main directives (at the beginning of the /etc/ldap/slapd.conf file) add the server ID
serverID 2 Add to the end of the file:
index objectClass,entryCSN,entryUUID eq,pres Immediately set up as a consumer
syncrepl rid=001 provider=ldap://192.168.1.10 bindmethod=simple interval=00:00:10:00 binddn="cn=vmail,dc=domen,dc=my" credentials=lkfjalfkoZSDbladfjoweotHSDFasjfASfj searchbase="dc=domen,dc=my" schemachecking=off type=refreshAndPersist retry="60 +" We are looking for in the file: iRedMail.tips in the directory from where the mailer was installed or in the letter to the admin to which we will connect (192.168.1.10) We are looking for a line
* LDAP bind dn (read-only): cn=vmail,dc=domen,dc=my, password: lkfjalfkoZSDbladfjoweotHSDFasjfASfj This will be our login and password.
You also need to add the provider functions in /etc/ldap/slapd.conf:
mirrormode on overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 8. We skip LDAP on both servers and see the log:
$ sudo service slapd restart && sudo tail -f /var/log/syslog | grep slpad $ sudo service slapd restart && sudo tail -f /var/log/syslog | grep slpad If something like that
Oct 24 11:35:03 server slapd[6992]: slap_client_connect: URI=ldap://192.168.1.10 DN="cn=vmail,dc=domen,dc=my" ldap_sasl_bind_s failed (-1) Oct 24 11:35:03 server slapd[6992]: do_syncrepl: rid=001 rc -1 retrying That means something is wrong and you need to carefully edit slapd.conf
10. Check
Go to the admin panel of one and the other server.
https://192.168.1.10/iredadmin/ https://192.168.1.20/iredadmin/
We add the user, the domain, etc. And we watch its emergence on the second server.
We perform actions to remove, modify, add data to one server and check the appearance on the other.
11. Conclusion
We received a mail cluster running on two Internet channels on two white IP.
Provided that in DNS we have two IP for one domain name
mail.domen.my - 1.1.1.1
mail.domen.my - 2.2.2.2
and the availability of two DNS under different channels we have:
In case of failure of one of the channels or exit from a standing (shutdown for service) of one of the mail servers, clients will have access and maintenance on the second mail server.
Also, some unloading of channels and servers is achieved in case of random issuance of IP mailers by DNS servers.
12. Sources
Source: https://habr.com/ru/post/156059/
All Articles