affordable, robust, cross-platform email server that supports nearly every mail
standard out there. I recently migrated a live CommuniGate Pro installation from Windows NT 4.0 to Red Hat Linux 9 and improved my client’s messaging performance. The process wasn’t difficult, but if you’re contemplating a similar migration, let me warn you about a few things to watch out for.
My client needed to upgrade his messaging because his Windows NT-based server was a bit long in the tooth and straining under the current demand for its services. Based mostly on cost and partly on my
recommendation, the organization chose not to upgrade to Windows 2000. Continuing to use Windows
NT was not an option due to Microsoft’s choice to stop supporting the product.
The cross platform nature of CommuniGate Pro is a virtue for current and potential customers. The software runs natively on more than 30 OS and platform combinations ranging from Windows 95 to IBM OS/400. An issue tied closely with platform compatibility is scaleability. CommuniGate Pro, through clustering, can scale to millions of user accounts. A German company uses CommuniGate Pro to service over 4.5 million customers.
Stalker sells a MAPI connector that can replace the majority of functions found in Microsoft Exchange. It also provides a native Web server that allows user access to email and administration of all mail
functions. Administration of mail domains can be delegated to both protect and help sysadmins. People addicted to a command line interface will find an abundance of tools with which to manipulate CommuniGate Pro.
CommuniGate Pro was designed from the beginning to separate the program code from the accounts and
configuration information, allowing organizations to quickly upgrade to new versions, or downgrade in the rare instance when Murphy strikes. All account and configuration information is stored in a single base directory. In this instance the base directory on the NT server was C:CommuniGate Files, and on the Linux server /var/CommuniGate.
In preparation for the migration, I upgraded the old NT server to release 4.0-6 of CommuniGate
Pro. I downloaded the install for the same version on the Linux platform; in this case a self-contained RPM. The new server was a Dell PowerEdge 1600 with a 2.4GHz Pentium 4 CPU, preconfigured by Dell with Red Hat Linux Professional 9 for $100 extra. The drive subsystem consisted of an IDE RAID controller and
two mirrored 80GB IDE drives. The machine was configured with 1GB of RAM, but it would have been fine with 256MB due to the low overhead of a stock Linux kernel coupled with the resource-friendly CommuniGate Pro.
Round one
Moving a CommuniGate Pro install between machines of the same platform is as simple as
zipping up the base directory and restoring it to the base directory on the new machine. The
same-platform migration of a typical small to medium enterprise can be done in less than 30
minutes.
Moving between platforms can be a bit more tricky in that newline and EOF characters in text files can differ among platforms, especially when moving from Windows to Linux. The documentation clearly points out this potential pitfall and recommends using FTP, which automatically corrects this problem, to transfer the files from the base directory.
Forewarned, I installed a trial version of IPSWITCH Software’s WS_FTP server on the NT server. A few minutes of configuration later the server was ready to
go. I then proceeded to use the Linux gFTP client to download the NT base directory across the wire to
a holding area on the new Linux server. Using vi to examine a few files verified that they
appeared intact, with one curious exception: every file transferred via FTP carried the executable
attribute. Issuing a quick chmod -R -x * solved the attribute issue. In accordance with the
manual, the owner was verified to be root, and the group changed to mail. Again, using chmod
and chgrp with recursion switches (-R) worked as billed.
I must confess to cheating a little bit in the previous step. I installed the CommuniGate Pro RPM
in order to configure the environment for me, with the exception of the /var/CommuniGate directory. The key was to install the software, but not start the daemon.
The next order of business was to disable other mail services. Red Hat’s distribution insists on
installing and starting sendmail. Turning sendmail off is a simple command: chkconfig sendmail. Finally, even though I used default directories, I checked the daemon startup script at /etc/rc.d/init.d/CommuniGate to ensure that the variables had correct values.
off
After double-checking the pre-flight checklist, I unplugged
the network cable and entered the final command: ./CommuniGate start. Nothing happened.
Issuing a pgrep CGS confirmed that no threads survived.
Round two
CommuniGate still wouldn’t start after I looked for inane oversights and ran ldconfig for grins, so I hit Google for a hint. Stalker’s complete Web site is indexed in Google, offering
a great place to start looking for support information. Stalker’s CommuniGate Pro mailing list
yielded one hit of someone having a similar problem. The answer from Stalker was to configure
the software to do a core dump and then send the file to the support address; the core dump instructions did not work for me. Since Stalker support asked the previous list member for a core dump right off
the bat, it was apparent that I should look deeper into the problem before crying on the listserv.
I went back to the production server and changed the settings to increase the amount of logging.
A quick restart of the CommuniGate service allowed the server to pick up queued mail from the
upstream provider. I shut down the service and again transferred the contents of the base
directory to the Linux box via FTP. Repeat. What followed was a vicious cycle of changed
configurations and FTP downloads without success.
Round 15
A wise man once told me that if what you’re doing ain’t working, try something else, idiot. At this
point I began to suspect the FTP process. I began to put configuration files into the base directory one at a time between program runs. Most of my time is spent on Microsoft platforms, which explains my general pessimism towards helpful error messages; I mention this only because The Clue hit me like a
thunderbolt. For some time I had been scrolling through the CommuniGate Pro log file in a terminal window using the tail -f <FILE> command. I suddenly realized
that even though the logs recorded various activity at the crash point, the logs always
reflected a syntax error in reading the Router.data configuration file prior to the crash.
A melee between the operator and the Router.data file ensued. I finally emerged victorious 10 minutes later after retyping the entire routing file in vi. The system did not like the EOF marker in the file, despite its having been transferred via FTP. Here is another tip: when CommuniGate Pro parses the Router.data file, comments are simply ignored, thus the error position reported in the log is not the absolute position of the erroneous statement in the file.
Even before I could gloat over my victory, CommuniGate began to download mail that had queued in the past three hours. Yes, I had forgotten to unplug the patch cord after troubleshooting.
The final housekeeping consisted of changing the previous server’s IP addresses and adding the
old addresses to the new server. A good practice is to virtualize services in order to reduce
reliance on the underlying platform. The IP addresses in question were assigned to the mail
service, not the machine running the mail. A quick and dirty shell script allowed me to add and
remove the virtual addresses at will, thus assuring there was no confusion on the wire. The
method used on the NT server to prevent IP overlap was even simpler: unplug the network patch
cord.
Alias addresses are added in Linux with the ifconfig command: ifconfig eth0:0 xxx.xxx.xxx.xxx where classic subnetting is assumed. This change is not permanent until you add an ifcfg-ethX:Z
file to /etc/sysconfig/network-scripts. The X is your Ethernet card and the Z is the virtual IP
number starting from zero; note that the separating colon is needed syntax. Making virtual IP
addresses persistent can also be done in the rc.local start up file, but the previous method is better
and is recommended by Red Hat.
With the new server in place and running, I quickly verified all the settings via the Web
administration interface. After sending test messages and watching the logs for 30 minutes, I was
confident that the transfer was a complete success. Last tip: make sure at least one domain is
configured to use all available IP addresses; if not, you run the risk of being locked out of the Web
administration pages.
Migrating the server from Windows to Linux was only the first step in a broader project. The
next task is to install an unsolicited mail filter and a virus scanner, neither of which existed
on the previous platform. The client is already impressed with the performance improvement and
is anxious to implement the rest of the plan.
A note on choice
Some readers will point out that I could have saved even more money by using a “free”
distribution like Debian and the ever-present sendmail, coupled with something like RPOP. In my
practice, using FOSS solutions is about customer choice and using the correct tools for the job at
hand. Customers choose not to use Microsoft products for a variety of reasons, but the common
thread is always avoiding lock-in to The Microsoft Way. If I propose to replace Microsoft’s
monolithic solution set with my smaller monolithic solution set, the customer saves
money, but is now addicted to my revenue needs and worse, my specious availability. By
choosing Dell hardware, Red Hat Linux, and CommuniGate Pro, the customer gets the benefit
of choice that continues even if our relationship is severed.
Scott Stahl is a professional systems administrator with more than 12 years of
experience. For the past three years he has worked with Computer and Network Specialists of Homewood, IL, as a senior project consultant. Concurrently for the past two years he has been engaged by Provena Health as a regional LAN/WAN administrator.
