This chapter describes how to install Oracle Communications Messaging Server.
For information about installing Cassandra message store, see Messaging Server Installation and Configuration Guide for Cassandra Message Store.
Before installing Messaging Server, read these chapters:
When you install Messaging Server, you install and configure one or more of the following components:
Message Store. Consists of a set of components that store, retrieve, and manipulate messages for mail clients.
Message Transfer Agent (MTA). Receives, routes, transports, and delivers mail messages using the SMTP protocol. An MTA delivers messages to a local mailbox or to another MTA.
Messaging Multiplexor (MMP). Enables scaling of the Message Store across multiple physical machines by decoupling the specific machine that contains a user's mailbox from its associated DNS name.
Webmail Server (mshttpd). Acts as a front-end host that handles the HTTP protocol retrieval of messages from the message store. This component is used by Convergence to provide web-based access to end users.
The instructions in this chapter assume:
You are deploying Messaging Server on a single host or Solaris zone, or multiple hosts or Solaris zones.
Each Messaging Server component is one functional component of your multi-host deployment.
You are installing the Messaging Server component on a separate host or Solaris zone; you are not bundling the component with other Communications Suite products on the same host.
Oracle Directory Server Enterprise Edition (Directory Server) is already installed.
The instructions also assume the following for the specific Messaging Server components:
Message Store: If you are distributing multiple partitions of the message store across several hosts or zones, you can follow these instructions for each host on which you install store partitions.
Message Transfer Agent (MTA): This MTA relay in and MTA relay out is one functional component of your multi-host deployment.
Messaging Multiplexor (MMP): You are installing only the MMP front end; you are not installing message store or SMTP functions.
Webmail Server (mshttpd): You are installing only the Webmail Server front end; you are not installing message store or SMTP functions.
The recommendation is to use Unified Configuration for new Messaging Server installations. You must manage a Cassandra message store deployment by using Unified Configuration.For more information, see the discussion on Unified Configuration in Messaging Server System Administrator's Guide.
This section includes steps to take before installing Messaging Server. The topics in this section include:
The following steps must be completed for all Messaging Server components: Message Store, Message Transfer Agent (MTA), Messaging Multiplexor (MMP), and Webmail Server (mshttpd).
Ensure that DNS is running and configured properly.
For details, see "Checking the DNS Configuration".
Ensure you have sufficient file descriptors on Linux. For details, see "Checking the Number of File Descriptors".
Make sure you do not configure conflicting port numbers on a host when various components are running on a single machine.
Table 9-1 lists the default port numbers used by Messaging Server.
Table 9-1 Messaging Server Default Ports
| Port Number | Purpose |
|---|---|
|
25 |
Standard SMTP port or MMP SMTP Proxy |
|
110 |
Standard POP3 port or MMP POP3 Proxy |
|
143 |
Standard IMAP4 port or MMP IMAP Proxy |
|
225 |
Default port for communications to back-end store through LMTP |
|
465 |
SMTP/SUBMIT over SSL or MMP SMTP Proxy over SSL |
|
587 |
Standard Message Submission (SMTP SUBMIT) port |
|
993 |
IMAP over SSL or MMP IMAP Proxy over SSL |
|
995 |
POP3 over SSL or MMP POP Proxy over SSL |
|
7997 |
Event Notification Service port |
|
8990 |
mshttpd daemon port |
|
8991 |
mshttpd over SSL daemon port |
|
27442 |
Used by Job Controller for product internal communication |
|
49994 |
Used by the Watcher for internal product communication |
You prepare your Directory Server by running the comm_dssetup.pl script against it. You can run the comm_dssetup.pl script in either interactive or silent mode. For silent mode instructions, see "Running the comm_dssetup.pl Script in Silent Mode".
Download the comm_dssetup.pl script from the Oracle software delivery website, located at:
You can either download the Oracle Communications Directory Server Setup (comm_dssetup.pl) file separately, or as part of the Messaging Server software.
Copy the Directory Server Setup ZIP file to a temporary directory on your Directory Server hosts and extract the files.
To prepare Directory Server and run the comm_dssetup.pl script in interactive mode:
On the host where Directory Server is installed, log in as root or become the superuser (root).
Start Directory Server, if necessary.
Copy the Comms DSsetup ZIP file to a temporary directory on your Directory Server hosts and extract the files.
Run the Installer.
rpm -i
Select Comms DSsetup and proceed with the installation.
Run the comm_dssetup.pl script in interactive mode (without any arguments), then enter your choices when prompted.
/usr/bin/perl comm_dssetup.pl
For more information, see "comm_dssetup.pl Reference".
Note:
You can use either LDAP Schema 2 or Schema 1.If necessary, provision users in the Directory Server.
If Directory Server is already installed at your site, users have already been provisioned. If you have just installed Directory Server at your site, then you need to provision users. For information, see the discussion on provisioning users and schema in the Schema Reference.
The following conditions might prevent you from configuring Messaging Server against a Directory Server host:
You do not have Directory Server credentials.
Messaging Server cannot communicate directly with the Directory Server master.
To configure your deployment to be able to run Messaging Server against a Directory Server replica, you must update the Directory Server master, which then feeds the replica with the necessary changes. You cannot update the Directory Server replica directly because the master Directory Server overwrites it.
To configure Messaging Server against a Directory Server replica:
Run the Messaging configure program using the replicated Directory Server credentials as described in "Configuring Messaging Server".
Use the --ldif option to produce MessagingServer_home/data/install/configure.ldif file that is needed to allow proper privileges to the Directory Server.
Move the configure.ldif file to the Directory Server master.
Run the ldapmodify command on the configure.ldif file.
Once the changes are replicated to the Directory Server replica, it is now configured to work with your Messaging Server.
The tasks to install Messaging Server are as follows:
Download the media pack for Oracle Communications Messaging Server from the Oracle software delivery website, located at:
Copy the Messaging Server ZIP file to a temporary directory on your Messaging Server hosts and extract the files.
For each Messaging Server component, you must install the Messaging Server software on each individual server host (Message Store, MTA, MMP, and Webmail Server).
To install the Messaging Server software:
On each server host (Message Server, MTA, MMP, and Webmail Server), log in as or become the superuser (root).
Go to the directory where you extracted the Messaging Server ZIP file.
Run the installer.
rpm -i
Choose the installation directory or accept the default.
Select Messaging Server and proceed with the installation.
When the installation is complete, continue with "Configuring Messaging Server".
This information explains how to install Messaging Server on Solaris OS Zones.
You can install Messaging Server components in the global zone, whole root non-global zones, and sparse non-global zones. Follow these guidelines:
Treat the global zone as an ”administration zone.”
Install shared components and OS patches in the global zone that are to be shared among all zones. However, do not install and run products from the global zone.
Use whole root non-global zones to run Messaging Server.
Do not use the global zone or sparse zones. A whole root zone can have versions that are different from other whole root zones, thus giving it a measure of being ”self-contained.”
The one exception to these two guidelines is to install the HA agent (MS_SCHA) only in the global zone. The Messaging Server Installer automatically propagates HA agents to all non-global zones. That is, the pkgadd -G switch is not used for HA agents.
Be aware of the following zone aspects:
You can have different shared component versions in the whole root non-global zone, but it isn't entirely insulated. If you do a packaging or patching operation in the global zone for a shared component, that operation is also attempted in the whole root zone. Thus, to truly have different shared component versions, use an alternate root.
To avoid affecting whole root zones you can attempt to never install and patch shared components in the global zone. However, it might not be realistic to never have to install or patch a shared component in the global zone. For example, NSS is a shared component, but it is part of Solaris OS. So to expect to never install and patch NSS in the global zone seems unrealistic, especially given it is a security component.
Although it isn't a recommended best practice, you can use Messaging Server in sparse non-global zones. Do note that shared components cannot be installed into the default root because many of them install into the read-only shared file system (/usr). Thus, you must run the installer in the global zone to install shared components into the default root. Prepend your selection with ~ in the global zone to install only the dependencies (that is, shared components). You do not have to install in the global zone first before installing in the sparse zone. The installer allows you to continue even when you do not install all the dependencies. However, upgrading the shared components in the global zone affects the sparse non-global zones, thus requiring downtime for all affected zones simultaneously.
Note:
Sparse root zones are not available beginning with Oracle Solaris 11.The non-global whole root zone scenario is the equivalent of installing Messaging Server on a single box with no zones. Simply install Messaging Server as you normally would.
Caution:
Any operations performed in the global zone (such as installations, uninstallations, and patching) affect the whole root zones.Although it isn't a recommended best practice, you can use Messaging Server in a non-global sparse root zone on Solaris 10. To install Messaging Server in a non-global sparse root zone, you first need to install/upgrade the applicable OS patches and shared components in the global zone. You are unable to do so in the sparse root zone, because the /usr directory (where the shared components reside) is a read-only directory in the sparse root zone.
Follow the pre-installation requirements as described in "Messaging Server Pre-Installation Tasks".
Verify that you are about to install the shared components and OS patches in the global zone and not the sparse root zone. To verify you are in the global zone, run zonename. The output should be global.
Run the installer in the global zone and only install/upgrade the OS patches and the Shared Components. Do not install Messaging Server components in the global zone. To do this, add a ~ (tilde) to the component number you want to install in the sparse zone.
For example, if you plan to install Messaging Server in the sparse zone, you select ~1 during the global zone installation. The installer will know to only install dependencies and not the product itself.
Once you have the shared components and OS patches installed, install Messaging Server components in the sparse root zone.
After installing Messaging Server, continue with the following chapters:
Follow the instructions in "Configuring Messaging Server" to finish installing and configuring Messaging Server and its individual components.
Go to "Configuring Messaging Server for High Availability" if you need to configure Messaging Server for high availability.
Follow the instructions in "Messaging Server Post-Installation Tasks" to perform post-installation tasks.