Following on from my previous posts on the PostPath collaboration platform, I can report that I have now completed my evaluation of the system. Let’s run through the installation procedure.
Preparing the environment
As discussed, the most vital pre-requisite for the installation of the PostPath collaboration server is Microsoft Active Directory. For some, Active Directory will already be in place, but for others deployment will be necessary. In order to evaluate PostPath, I obtained a 180-day free trial of Windows Server 2003 R2 Enterprise edition from Microsoft. While unsupported, this is full-featured and can be installed on up to four systems simultaneously for evaluation purposes. The evaluation will expire after 180 days–it cannot be upgraded to retail; so, don’t install this with the intention of putting systems straight into production after initial testing. To obtain an evaluation copy of Windows Server, visit the Microsoft Web site; disc images can be downloaded right away and a licence key will be delivered to your registered e-mail address.
Installation is straightforward, as is the configuration of Active Directory and a DNS server. I used the Windows domain of corp.test-mycompany.com, which is pretty standard practice. Don’t forget to create a reverse lookup zone while configuring the DNS server.
PostPath can be deployed on various Linux variants: Red Hat Enterprise Linux, Suse-Linux Enterprise Server and CentOS are all supported. I chose to use CentOS 4.4 (x86) for the evaluation as it’s the low-cost option and commercial support really isn’t required for a non-production system. CentOS can be downloaded here. While my evaluation was being run on a 64-bit-capable platform, I decided to use a 32-bit version of CentOS as PostPath is a 32-bit application; this means there would be no real advantage to using a 64-bit operating system, and I didn’t want to introduce issues related to library versions, etc. As with Windows Server, the basic installation of CentOS is self-explanatory. Once set up, a static DNS entry must be created for the PostPath server in the Windows Server DNS configuration (including a PTR record).
Before installing the PostPath applications, there are some steps which need to be taken in order to prepare the base system. The first is to make CentOS synchronise its system clock with the Active Directory domain controller via the NTP daemon. Secondly, some optional packages not included in the default installation must be downloaded and installed via the ‘yum’ package management tool. Finally, it is recommended that the main data store be installed on a partition formatted with the XFS file system with extended attributes enabled. In order to do this, an XFS kernel module must be loaded along with the XFS file system tools. Full details of how to carry out all of these procedures can be found in the appendix of the installation guide downloaded along with the free 12-user PostPath package.
Once the Active Directory environment and CentOS platform are fully prepared and tested, it’s time to deploy the PostPath application. The installation of PPSD (the PostPath engine), PPWM (webmail), and PPCT (the server control panel) are all performed via a single executable installer. Once executed, the installer presents us with a pretty standard licence agreement and then moves on to the installation options.
PPSD should be installed first; once launched the installer will ask for the following:
- Primary DNS server IP address
- Active Directory domain name
- Fully Qualified DNS name of the PostPath server
- Short (NETBIOS) name of the PostPath server
- Primary SMTP domain (e.g. test.mycompany.com)
- Active Directory administrative account name (Administrator)
- Administrative account password
Now we come to an interesting point: the installer asks whether or not it should prep the forest and domain for PostPath.
If there is no existing Exchange installation on the domain, then the answer should be yes. However, I tried to do this and ran in to various problems–it just wouldn’t work properly without an existing Exchange installation on the domain. I tried to find a workaround, but in the end, resorted to installing an evaluation copy of Microsoft Exchange 2003 on a fresh server in the test domain. Even if the installer properly preps the Active Directory schema, the standard Active Directory Users and Computers do not have the Exchange extensions. In order to install these, you must have a copy of Microsoft Exchange. For all intents and purposes, this means that unless considering migration from Exchange to PostPath; PostPath is currently a non-starter.
Moving on and assuming there is now an Exchange installation on the domain, you must answer no to the forest/domain prep question. The default values for the Exchange Organisation, Administrative Group, and Routing Groups will be picked up from the directory and simply need to be verified. Unless there is a specific reason to change them, the default locations for placement of PostPath’s binaries and message store can be accepted.
If sendmail is detected as running on the system (it usually is), then the installer will show a prompt asking whether it should remove sendmail, disable it, or quit the installation process. Disabling sendmail is fine. The installer will now check the systems’ time synchronisation with the domain controller, re-sync if necessary, and finally complete it. The installer now reverts to the original menu and PPWM can be installed.
Before installing PPWM, one must check that both /etc/samba/smb.conf and /etc/krb5.conf are properly populated. Take special care to ensure that while replacing the default entries in krb5.conf with those of your domain, you observe and preserve the case–they are case sensitive.
The installation of PPWM is much faster than that of PPSD; simply supply the requested details, which most likely will have been populated correctly by default. Most of these are repeats of the details supplied during the PPSD installation such as FQDN, NETBIOS name, and administrative account details.
Finally, to complete the installation process, the licence key must be activated by selecting option four from the installer’s main menu. I used the automatic activation, which worked without any issues (remember that this will require the machine to have internet connectivity).
To start the PostPath services use:
If everything went well (and it did for me after the initial problems related to the absence of an Exchange server), the PostPath server can now be used to host mailboxes and collaboration data.
Next week, I’ll discuss how I went about testing various features of PostPath and share my conclusions as to its viability.