This chapter describes how to use a configuration management tool with your Oracle Communications Messaging Server deployment.
Configuration management tools streamline the task of configuring and maintaining hosts in your deployment. Messaging Server does not supply its own tool for configuration management. However, with proper initial setup, you can use a third-party configuration management tool, such as Chef or Puppet, to maintain your Messaging Server deployment.
A configuration management tool makes sense to use when you have many Messaging Server hosts to install and maintain, and also when you deploy the Cassandra message store. For example, with Cassandra message store, reliability is provided by application-level redundancy across hosts. As a result, if a disk fails, you merely add a new Cassandra host, and remove the old one from the deployment. You would also use the same procedure to replace an entire host that is itself failing. A configuration management tool works well in these types of situations where you must add a new host to the deployment.
When creating the proper Messaging Server environment in which to use a configuration management tool, you must first understand the role of the Messaging Server init-config script. You use the init-config script to create an initial, run-time configuration for a Messaging Server host. From that base working configuration, you then make specific customizations.
To summarize, the init-config script:
Creates the Unix user and group for Messaging Server, if needed.
Creates Oracle Directory Server Enterprise Edition (Directory Server) entries (or LDIF) for the default domain, administrative user and postmaster, along with access control lists.
Creates Directory Server entries (or LDIF) for an administrative group and user for the host where init-config is run; this administrative group and user have limited write access to the directory.
Creates DataRoot and ConfigRoot directories with correct permissions.
Creates subdirectories of the DataRoot and ConfigRoot directories with correct permissions.
Generates a random secret for authentication to local-only services, such as the job_controller and watcher.
Prompts you with the minimum number of questions about your environment to create an initial Messaging Server configuration with correct permissions.
Attempts to disable mail servers that come with the operating system, for example, Postfix and Sendmail.
Runs the imsimta chbuild command to create character set conversion tables.
Creates symbolic links (symlinks) from the install directory to the DataRoot, ConfigRoot, and log directories.
With Messaging Server 8.0.1 and prior, you must run the init-config script on each Messaging Server host in your deployment. Starting with Messaging Server 8.0.2, the configure script has been modified so that you only need run init-config once per deployment to perform the preceding steps 2 and 3. Also starting with Messaging Server 8.0.2, you do not need to perform the preceding step 9 (unless you customize character set tables), and the preceding steps 5 and 10 are optional.
Follow these best practices to use a configuration management tool with Messaging Server:
The directory that contains the Messaging Server data files should always be /var/MessagingServer_home. For example, when you install Messaging Server software in the default installation directory of /opt/sun/comms/messaging64, the data directory is /var/opt/sun/comms/messaging64. The Messaging Server configuration directory is created as a subdirectory of the /var/opt/sun/comms/messaging64 directory, that is, /var/opt/sun/comms/messaging64/config.
Use the configuration management tool to apply the appropriate operating system patches to your Messaging Server hosts.
Use the configuration management tool to perform steps 1 and 8 (for Messaging Server 8.0.1 and prior), or steps 1, 4, and 8 (Messaging Server 8.0.2) in the preceding section as appropriate.
Use Unified Configuration (not legacy configuration) to configure and administer Messaging Server.
For Messaging Server 8.0.1 and prior, use the configuration management tool to run the init-config script. For Messaging Server 8.0.2, use the configuration management tool to perform step 4 in the preceding section, and to deploy the three configuration files (config.xml, xpass.xml, and restricted.cnf) that were created when you first ran the init-config script for the deployment. Ensure that you correctly set the permissions on these files.
As you change or update your initial Messaging Server configuration, use the configuration management tool to run msconfig recipes. Ensure that these recipes are idempotent (that is, running them a second time does not alter the configuration). It is helpful to use more than one msconfig recipe so that recipes shared by multiple roles (for example, configuring affinity groups) are separate from recipes used by a single role (for example, enabling the MMP). If you use more than one recipe, ensure that each recipe modifies a separate part of the configuration to avoid ordering issues. For a good starting point, see the recipes provided in Messaging Server 8.0.2 for front-end and access-tier hosts (CasFrontEnd.rcp and CasAccessTier.rcp).
In general, Messaging Server Unified Configuration is compatible with prior releases. If changes do occur to Unified Configuration in a new release, the idempotent ConfigUpgrade.rcp recipe performs these changes. The ConfigUpgrade.rcp recipe runs automatically the first time the start-msg command runs after a Messaging Server upgrade. When you evaluate a Messaging Server upgrade, you can manually run the ConfigUpgrade.rcp recipe on the configuration to see how the configuration has changed.
This section describes security issues to keep in mind when using a configuration management tool with Messaging Server.
Use credentials that have limited write access to the directory (step 3 in "Creating the Environment to Use a Configuration Management Tool") to isolate directory security from Messaging Server security. However, using different LDAP credentials for each Messaging Server host does not significantly improve overall deployment security. As a result, there is no requirement to make changes to the Directory Server LDAP when adding a host to the Messaging Server deployment.
Generate a different, random secret for local-only services for each Messaging Server host. If you choose not to run the init-config script on each host in the deployment, then write an msconfig recipe, using the strongrandom recipe language function, to perform step 6 in "Creating the Environment to Use a Configuration Management Tool".
Use the configuration management tool's security capabilities to deploy passwords or credentials to your Messaging Server hosts. For example, Chef provides encrypted data bag items that you can use to protect files containing passwords or credentials. For Messaging Server, this includes statefiles (used for silent installation and configuration) and the xpass.xml file.
Enable ENS authentication for the deployment. This is particularly important when affinity groups are used (as required by both Cassandra message store and classic store with automatic failover). For more information, see the topic about ENS support for password based authentication in Messaging Server System Administrator's Guide.
Use the PORT_ACCESS mapping table so that LMTP servers only accept connections from known LMTP clients. For more information about the PORT_ACCESS mapping table, see the topic on mapping tables in Messaging Server System Administrator's Guide.
Use a deployment firewall to prevent external hosts from spoofing internal IP addresses and to block access to all ports except those intended to be externally visible. Setting up an external system that probes key internal ports (including LMTP, ENS, mshttpd, and WMAP) can be helpful to detect accidental firewall misconfiguration. More information about using a firewall with Messaging Server is available in Messaging Server Security Guide.
Having the IP address of SMTP clients available is important for the correct operation of anti-spam/anti-abuse mechanisms, and to track various forms of mail abuse. If you choose to terminate SMTP SSL/STARTTLS at a firewall or load balancer, that firewall or load balancer should support the SMTP XCLIENT extension (especially for enterprise deployments) and RFC 2979.