AN OPEN SOURCE MAIL SERVER MIGRATION EXPERIENCE: IREDMAIL

Servers are systems that set up to run for years, but it may be necessary to migrate to a new, better server when they have completed their lifetime or become inadequate. In this study, the open-source iRedMail e-mail server has been successfully migrated to another high-capacity physical server which uses an open-source CentOS operation system. Migration is a process that every step has to be very well planned. However, although planning is well done, unexpected errors may occur. For this reason, it is also essential to choose migration time. The experience gained as a result of the study is a guide for the new ones.


INTRODUCTION
Servers are often built to serve for a long time. E-mail servers are also one of these critical servers. Failure of a vital e-mail to reach its recipient can damage individuals or organizations. For this reason, the e-mail server must be in continuous working conditions and not be interrupted. However, when the servers expire or there is an unexpected condition, physical server replacement may be needed to provide better service and may have to migrate to new and more advanced servers.
It is preferred that the service is not interrupted during the migration process, but sometimes it may be obliged to be interrupted. In this case, the downtime should be kept to a minimum so, migration should be planned very well.
All infrastructure preparations must be completed before migrating a server. Especially after activating systems with a high number of users, the possibility of intervention is limited. Therefore, it is expected that the hardware infrastructure should be well designed before the systems are installed.
Server systems with a high number of users and global access are always at risk of attack. The risk of attack can be minimized with well-designed and professionally configured systems, but this risk cannot always be eliminated entirely. Also, unexpected hardware failures may occur on the server. In such cases, although the disconnection of access can be tolerated for a certain period of time, especially in institutional structures, there is very little tolerance for data loss. For this reason, the most crucial section after the preparation of the hardware infrastructure is the preparation of the disaster recovery and backup part. The most important thing expected from a mail server is that it can provide uninterrupted and lossless service. So this situation should be planned in detailly during infrastructure section.
During the preparation part, it should be made by considering how long the server will serve, how many users can be supported, and how much disk capacity it must have. Although it is thought that servers are used in incorporate structures should survive for at least five years, this period can be extended to decades with proper planning and modular architecture (Why Expected Server Lifetime Is in the Eye of the Beholder, n.d.). Therefore, the most critical and time-consuming part of doing * Corresponding author before installing the server is the planning part. Server installation is the part that takes the least amount of time if unexpected errors are not counted. After the server installation, the most time-consuming part will be maintenance and sustainability. Because as long as the server is running maintenance, sustainability, and updating will never end. Server systems should always use software with the latest version to keep the vulnerabilities to the minimum. Therefore, one of the most important issues to be considered in the selection of software is that the support period must be as long as possible.
To summarize, before the server is migrated, infrastructure, hardware, and software needs should be determined and provided accordingly according to the number of users and intensity of usage. Then, a new server should be installed, and migration should be ensured in a suitable time frame. The general steps of a migration process are given in Fig. 1. If we look at the studies in the literature, we come across studies on this issue and also patents. Barkie et al have worked on assisting server migration (Barkie et al., 2014). Papatla et al. (Papatla, Schenk, 2008) and Rawal et al. (Rawal et al., 2012) studied on web server migration system and method. Smooth et al. studied for migration from physical server to virtual server (Smoot, 2009). Ahmad et al. have showed the current methods about virtual server migration (Ahmad et al., 2015). Ranjan et al. studied on Qos-driven server migration for internet data centers (Ranjan et al., 2002). Besides, there are different studies related to server migration (Utsunomiya, Sekiguchi, 2010, Sundaram, Faber, 2011, Korupolu, 2012, Smaragdakis et al., 2013. If we look at for migration of an e-mail server, Dennis et al. have a patent about Autonomous configuration of e-mail clients during an e-mail server migration and automation (Dennis et al., 2013, Dennis et al., 2018 when Alarid et al. have also a patent study about mail object migration (Alarid et al., 2013).
In this study, iRedMail (Huangbin, n.d.), a free, open source mail server solution, was migrated from a physical server with insufficient processing power and disk capacity to another new, powerful and large capacity physical server.
The informations such as operating systems, software versions, organization planning, user statistics, server details and architecture were not given against possible cyber attacks.

METHODOLOGY
In this section, the steps of the migration process are given. Firstly, infrastructure works for migration are explained. Then the preparations made on the server for migration are given. In the next step, the migration process and finally, the activation of the new server is explained.

Infrastructure works
The e-mail server of our university, which was on an old server with limited disk capacity and processor power, started to be insufficient. When considering the increasing number of students and employees, it was inevitable to switch to a new server that could serve the university for years. For this reason, first of all, the estimated number of future 5-year users was calculated. According to this calculation, disk size, processor power, and memory amount to be needed were calculated.
Disaster recovery scenarios, possible disk, ram and power supply failures, and source budget were also reviewed. By considering all these factors, a server that is suitable for the existing system room and cabinets that can meet all needs have been determined and purchased.
It was decided whether the server would be virtual or physical. One of the most critical elements in server installation is the storage and disk partitioning strategy. It is possible to see frequent disk failures in systems that will work for many years and have high disk usage (read and write). For this reason, since one of the disks is damaged, the system should be able to be replaced without stopping and data loss. Accordingly, planning was done for data mirroring. The disk space to be used by the database and user accounts have been adjusted to the experiences gained from the previous server. The most disk partition has been given to the area where user accounts are kept, and other partitions also were tailored to the needs.
It was concluded that the existing e-mail server solution is sufficient. It was also considered that the software is open-source, and update support could continue for many years, and it was decided that the migration will be in the same software.
One of the essential parts to be planned is the backup strategy. Therefore, it was planned which files of the software and database will be backed up and how often.
After all the physical works were completed, an open-source operating system (CentOS) was installed on the server. Basic server programs such as apache web server that need to be installed on the server and specific applications such as SSL certificate were installed, and preparations were completed.

Preparations for migration
Before migrating the iRedMail server, it should be checked if the existing server and the new server have the same version because both servers must be the same software. Upgrading the current server to the latest version and migrate it to the new server that has the latest version installed is the best way of migration. If the current server is not up to date and the update cannot be performed due to a problem, you can install the same version of your current server on the new server and update the server after migration.
Once the compatible version has been detected, it must be downloaded from the website. It should then be installed on the new server according to the current configuration and settings. Help is available from the iRedmail website (https://www.iredmail.org) for installation steps. It is useful to take a backup after completing the installation because if there is a problem in the next stages, it will save you from losing time by re-installing.
If you are using an older version, the setup tool may not find some files to download automatically. In this case, it will notify you of the missing files. You must download these manually and put them in the folders it specifies. The installation can then be continued. You should also update the e-mail graphical user interface (GUI) before migrating. Our e-mail GUI (webmail) is open-source Roundcube software (https://roundcube.net). If you also use Roundcube as the user interface, you need to make all the files readable and writable for all (Chmod 777) in the folder where the upgrade script installto.sh. Apart from software directly needed and installed by the software and general software that should be available on the server, also, Rsync software must be installed on the server.

Migration
The files and informations we needed to move from the existing server to the new server were as follows; • The directory containing user accounts (var/vmail/), The directory where the user accounts are located is /var/vmail/.. if there is no change during installation. This directory contains all mail information of users such as incoming, outgoing, spam mails and attachments, etc. User accounts should be copied to the same directory on the new server. After copying, the owner of the directory should be determined as vmail.
Secondly, we full backed-up of the database of the current server. When the entire database server is backed up, it will give us the SQL files of 5 Thirdly, the backup of the backend of storing mail accounts on the existing server will be restored to the new server. The backend application has detail information and definitions for the users and also provides quite a convenience in the authentication. iRedMail supports LDAP, MySQL, or PGSQL applications as the backend of storing mail accounts. Whichever of these is used should be backed up and restored to the new server.
Finally, the *.pem file under the /var/lib/dkim/ folder is moved to the same location on the new server.
In summary, after installing the operating system, the corresponding version of iRedMail is installed on the server. Then the user files were copied to the relevant directory, then the database and the backend application backup was restored. After that, the DKIM file was copied to the new server. Finally, the manually edited configuration files were put on the server. The new server is now ready to be activated.

Activating the new server
After whole preparations have been completed, the new server has been tested locally, and any problems determined have been fixed. It was planned when the new server would be activated, and users were notified. At that time, the old server was deactivated. Then the incremental backup of the user files was taken and restored to the new server. The new server has been activated by making the necessary IP changing in the DNS records. Then, the test procedures were repeated. It was seen that there was no problem, and so, the users were informed that the maintenance works were completed. Thus, the migration process has been completed.

RESULTS AND CONCLUSION
Within the scope of this study, iRedMail, free and open-source mail system on an insufficient SUN brand physical server was migrated to another powerful DELL brand physical server. During the migration, first, iRedMail on the current server was updated. Then the same version was installed on the new server, and then the migration process was successfully carried out. After the migration, the system was tested, and errors were fixed. At the last stage, the IP addresses of the e-mail server were replaced with the IP of the new one in the DNS server, and the new server started to service. Mail types and numbers on the server are given in Table 1 The whole migration process is visualized in Fig. 2. Thanks to the migration in the scope of this study, the server will not need to be migration for years. Disk failure, which is one of the biggest problems of the systems where disk reading and writing is excessive, was solved by mirroring. Thus, if any disk is damaged, the system will give a warning but will continue to operate. The disc will be replaced as soon as possible so that the access to the server will not be interrupted, and there will be no data loss.
After the migration, the server entered the routine maintenance process that continuous monitoring is performed. As said before, the most common problem with the system can be a disk failure. Replacement discs have been bought for this. In case of a possible failure, the damaged disk will be replaced with a new drive, and this disk will automatically recover as soon as possible. Another problem that may arise is the power supply failure, so the new server has two power supplies. Thus, if one fails, the other can be continued to work. In this process, the defective power device should be replaced as soon as possible. The servers were connected to the generator considering the power outage. In the next process, operating systems and installed applications are updated continuously to protect the servers at the maximum level from cyber attacks.
The most time-consuming process for server migration was the planning and server selection (brand, model, and specifications) process. It took a day to install the operating system on the server and install, configure, and test iRedMail. The part that takes the most time after the migration starts is to copy the directory containing the user accounts. We made this transport with the rsync program running on Linux. It took about a day to sync the entire files. Incremental synchronization before activating the new server took nearly half an hour. The time between the closing of the old server and the activation of the new one was planned as one hour. But it took about five hours to fix the detected bugs and activate the server. So the server has been out of service for about five hours. Since the migration was out of working time, users were minimally affected by access interruption. As a result, no matter how detailed planning is done, it should be remembered that unexpected errors can occur. For this reason, such migration should be done outside working hours and when the server traffic is the minimum (weekend, night hours, holidays, etc.).
The migration of an open-source e-mail server exemplified in this study is a situation that system administrators can always need. Although the versions of the software change over the years, the underlying logic of the migration will remain the same, so the method given in the study will remain useful.