This chapter describes the post-installation tasks that you must complete to finish the Oracle Communications Messaging Server installation.
This chapter includes the following topics:
This information describes the schema and provisioning options for Messaging Server. Because of the complexity in provisioning Messaging Server, you need to understand your options before installing the product.
Two schema options are available and supported with Messaging Server: LDAP Schema version 1 and LDAP Schema version 2.
Note:
For information on how to migrate from Sun Java System LDAP Schema version 1 to Sun Java System LDAP Schema version 2, see:LDAP Schema 1 is a provisioning schema that consists of both an Organization Tree and a DC Tree. This set of schema (at the time, it was simply called ”schema”) was supported in earlier Messaging Server versions.
In Schema 1, when Messaging Server searches for user or group entries, it looks at the user's or group's domain node in the DC Tree and extracts the value of the inetDomainBaseDN attribute. This attribute holds a DN reference to the organization subtree containing the actual user or group entry.
LDAP Schema 1 and Messaging Server Supported Provisioning Tools
Schema 1 is supported by both Sun ONE Delegated Administrator and Oracle Communications Delegated Administrator. For more information, see "Understanding Messaging Server Provisioning Tools."
LDAP Schema 2 is a set of Organization nodes (each may serve one or more domain names) and users entries typically live beneath the Organization nodes.
Note:
If you have an existing Messaging Server installation that uses Schema 1, and you want to integrate with other Communications Suite products, you should migrate your directory to Schema 2 after you upgrade Messaging Server. For information on how to migrate from LDAP Schema version 1 to LDAP Schema version 2, see:LDAP Schema 2 and Messaging Server Supported Provisioning Tools
Schema 2 supports Delegated Administrator. For more information, see "Understanding Messaging Server Provisioning Tools."
Schema 2 compatibility mode is an interim mode between Schema 1 and Schema 2 native mode. Schema 2 compatibility mode supports both schemas and enables you to retain the existing two-tree design you already have.
Use Schema 2 Compatibility if you have existing applications that require Schema 1, but you also need functionality that requires Schema 2.
Note:
Schema 2 compatibility mode is provided as a convenience in migrating to the Schema 2 Native mode. Do not use Schema 2 compatibility mode as your final schema choice. The migration process from Schema 1 to Schema 2 compatibility mode and then finally to Schema 2 native mode is more complex that simply migrating from Schema 1 to Schema 2 native mode. For more information, see:This section describes supported provisioning tools that enable you to query, modify, add, or delete user, group, and domain entry information in your LDAP directory.
Through supported Messaging Server provisioning tools, you can query, modify, add, or delete user, group, and domain entry information in your LDAP directory. This section examines these Messaging Server provisioning tools.
You should use Messaging Server Provisioning Mechanisms to evaluate your schema and provisioning tool options.
Note:
Prior to installing and configuring Messaging Server, you need to decide upon a schema model and tool or tools for provisioning your Messaging Server entries.The following sections provide high-level information about the supported provisioning tools:
Schema 1 users and groups can be provisioned using the LDAP Directory tools (Schema 2 is not supported). Unlike the Delegated Administrator graphical and command-line interfaces, you can directly provision users and groups by adding, removing, and modifying the LDIF records through LDAP without having to use a user interface.
Table 11-1 shows the various supported schema, provisioning tools, provisioning limitations, and recommended documentation for additional information.
Table 11-1 Messaging Server Provisioning Mechanisms
| Supported Provisioning Tool | Provisioning Tool Functionality | Provisioning Tool Limitations | For Further Information |
|---|---|---|---|
|
LDAP Provisioning Tools Uses: Schema 1 |
Provides tools to directly modify LDAP entries or for creating custom provisioning tools. |
|
Read the Schema Reference. Describes the LDAP Schema 1 provisioning model. In addition, this guide explain how to use LDAP provisioning tools and the usage of specific attributes and object classes. |
|
Delegated Administrator Uses: Schema 2 |
Provides graphical and command-line interfaces for administrators to manage users, groups, domains, and mailing lists. Compatible with other Communications Suite products. |
|
Read the Delegated Administrator System Administrator's Guide. Provides syntax and usage for the command-line utility. |
The configure program prompts you to enter host IP addresses that are allowed as SMTP relay hosts. The configure program uses this information to construct the appropriate mapping entries.
By default, Messaging Server is configured to block attempted SMTP relays. That is, Messaging Server rejects attempted message submissions to external addresses from unauthenticated external sources (external systems are any other system than the host on which the server itself resides). This default configuration is quite aggressive in blocking SMTP relaying in that it considers all other systems to be external systems.
IMAP and POP clients that attempt to submit messages by using Messaging Server system's SMTP server destined for external addresses, and which do not authenticate using SMTP AUTH (SASL), find their submission attempts rejected. Which systems and subnets are recognized as internal is typically controlled by the INTERNAL_IP mapping table. In Unified Configuration, this mapping table is part of the overall configuration, and is viewed or edited by using the msconfig command. In legacy configuration, this mapping table is found in the MessagingServer_home/config/mapping file.
For instance, on a Messaging Server system whose IP address is 192.45.67.89, the default INTERNAL_IP mapping table would appear as follows:
INTERNAL_IP $(192.45.67.89/32) $Y 127.0.0.1 $Y * $N
The initial entry, using the S (IP-pattern/significant-prefix-bits) syntax, is specifying that any IP address that matches the full 32 bits of 192.45.67.89 should match and be considered internal. the second entry recognizes the loopback IP address 127.0.0.1 as internal. The final entry specifies that all other IP addresses should not be considered internal.
You can add additional entries by specifying additional IP addresses or subnets before the final $N entry. These entries must specify an IP address or subnet (using the $(.../...) syntax to specify a subnet) on the left side and $Y on the right side. Or you can modify the existing $(.../...) entry to accept a more general subnet.
For instance, if this same sample site has a class C network, that is, it owns all of the 192.45.67.0 subnet, then the site would want to modify the initial entry so that the mapping table appears as follows:
INTERNAL_IP $ (192.45.67.0/24) $Y 127.0.0.1 SY * $N
Or if the site owns only those IP addresses in the range 192.45.67.80-192.45.67.99, then the site would want to use:
INTERNAL_IP ! Match IP addresses in the range 192.45.67.80-192.45.67.95 $ (192.45.67.80/28) $Y ! Match IP addresses in the range 192.45.67.96-192.45.67.99 $ (192.45.67.96/30) $Y 127.0.0.1 $Y * $N
The MessagingServer_home/bin/imsimta test -match utility can be useful for checking whether an IP address matches a particular $(.../...) test condition. The imsimta test -mapping utility can be more generally useful in checking that your INTERNAL_IP mapping table returns the desired results for various IP address inputs.
After modifying your INTERNAL_IP mapping table, be sure to issue the MessagingServer_home/bin/imsimta cnbuild (if you are using a compiled configuration) and the MessagingServer_home/bin/imsimta restart utilities so that the changes take effect.
Further information on the mapping file and general mapping table format, as well as information on imsimta command line utilities, can be found in the Messaging Server System Administrator's Guide. In addition, information on the INTERNAL_IP mapping table can be found in the Messaging Server System Administrator's Guide.
SMF support has been integrated into the product. Messaging Server provides a single SMF service definition file.
SMF was added in Solaris OS 10 as a replacement to the /etc/init.d scripts for starting, stopping, and restarting services. SMF dramatically decreases boot time as it is aware of dependencies between services, and starts services in parallel where possible.
<MessagingServer_home>/data/install/messaging.xml
The SMF service definitions can be imported using the svccfg command.
svccfg import <MessagingServer_home>/data/install/messaging.xml
The following example shows how to check initial Messaging Server status, enable SMF, then verify status. Please note that Messaging Server must be stopped prior to using the svcadm enable command.
svcs messaging_server STATE STIME FMRI disabled 8:58:29 svc:/network/messaging_server:default svcadm enable messaging_server svcs messaging_server STATE STIME FMRI online 9:08:54 svc:/network/messaging_server:default
For more information on SMF, see the overview about Managing Services in the Solaris System Administration Guide. This guide provides an overview of SMF, including SMF concepts, administrative and programming interfaces, components, and run levels.
You can enable Messaging Server startup after system reboots by using the bootup script. On Linux, this script is MessagingServer_home/data/install/Sun_MsgSvr. For Solaris OS 10, you should use the Service Management Framework. That is, by default, Messaging Server is not restarted after a system reboot unless you run this script. In addition, this script can also start up your MMP, if enabled.
Copy the MessagingServer_home /data/install/Sun_MsgSvr script into the /etc/init.d directory.
Change the following ownerships and access modes of the Sun_MsgSvr script:
Change directories to the /ect/rc2.d directory and create the following link:
ln /etc/init.d/Sun_MsgSvr S92Sun_MsgSvr
Change directories to the /ect/rc0.d directory and create the following link:
ln /etc/init.d/Sun_MsgSvr K08Sun_MsgSvr
Products that Messaging Server uses need to be started in a specific order to ensure that any pre-requisite services are enabled prior to the product starting. This ordering is especially important when starting the products when booting the server.
The ordering of the product start-up is as follows:
When the server is shut-down, the ordering is (roughly) reversed.
Directory Server (relies on network interface availability)
JMQ (for Messaging Server notifications)
Messaging Server (relies on Directory Server for user-group information)
Oracle Linux and Red Hat Enterprise Linux provide the chkconfig utility to control the ordering of the product start-up and shut-down. A good explanation of the Red Hat Linux chkconfig functionality is available here:
http://www.linuxjournal.com/article/4445
The logs of each product being started/stopped during of the boot-up and shut-down is stored in /var/log/boot.log file on the server.
For information on performance and tuning considerations for Messaging Server, see "Performance Tuning Considerations for a Messaging Server Architecture."
After installing Messaging Server, its directories and files are arranged in the organization described in Table 11-3. The table shows only those directories and files of most interest for typical server administration tasks.
Table 11-3 Post-Installation Directories and Files
| Directory | Default Location and Description |
|---|---|
|
Messaging Server Base MessagingServer_home |
/opt/sun/comms/messaging64 (default location) The directory on the Messaging Server machine dedicated to holding the server program, configuration, maintenance, and information files. To configure more than one Messaging Server base directory per machine, see the discussion on the ALTROOT command-line argument in "commpkg Reference." |
|
Configuration config |
MessagingServer_home/config/ Contains all of the Messaging Server configuration files, such as config.xml for Unified Configuration, or the imta.cnf and the msg.conf files, for legacy configuration. This directory is symbolically linked to the config subdirectory of the data and configuration directory (default: /var/opt/sun/comms/messaging64/) that you specified in the initial runtime configuration. |
|
Log log |
MessagingServer_home/log/ A convenience symbolic link to MessagingServer_home/data/log, which contains the Messaging Server log files like the mail.log_current file. |
|
Data data |
MessagingServer_home/data/ Contains databases, configuration, log files, site-programs, queues, store and message files. The data directory includes the config and log directories. This directory is by default symbolically linked (on UNIX platforms) to the data and configuration directory (default: /var/opt/sun/comms/messaging64) that you specified in the initial runtime configuration. |
|
System Administrator Programs bin |
MessagingServer_home/bin/ Contains the Messaging Server system administrator executable programs and scripts such as imsimta, msconfig, configutil, stop-msg, start-msg, and uninstaller. |
|
Library lib |
MessagingServer_home/lib/ Contains shared libraries, private executable programs and scripts, daemons, and non-customizable content data files. For example: imapd and qm_maint.hlp. |
|
SDK Include Files include |
MessagingServer_home/include/ Contains Messaging header files for Software Development Kits (SDK). |
|
Examples examples |
MessagingServer_home/examples/ Contains the examples for various SDKs. |
|
Installation Data install |
MessagingServer_home/data/install/ and MessagingServer_home/data/setup/ Contains installation-related data files such as installation log files, silent installation files, factory default configuration files, and the initial runtime configuration log files. |
In the installation and initial runtime configuration programs, port numbers are chosen for various services. These port numbers can range from 1 to 65535. Select numbers that do not conflict with port numbers used by enabled system services or other third-party software. The authoritative list of registered port numbers is available at http://www.iana.org. The /ect/services also lists a subset of these numbers.
Table 11-4 lists the port numbers that are designated after installation.
Table 11-4 Port Numbers Designated During Installation
| Service | Port | Unified Configuration Option to Change Port | Legacy Configuration Option to Change Port | Unified Configuration Option to Enable/Disable Service | Legacy Configuration Option to Enable/Disable Service |
|---|---|---|---|---|---|
|
Message Store |
NA |
NA |
NA |
store.enable (1) |
local.store.enable (1) |
|
IMAP Server |
143 |
imap.port |
service.imap.port |
imap.enable (1) |
service.imap.enable (1) |
|
POP Server |
110 |
pop.port |
service.pop.port |
pop.enable (1) |
service.pop.enable (1) |
|
IMAPS Server |
993 |
imap.sslport |
service.imap.sslport |
imap.enablesslport (0) |
service.imap.enablesslport (0) |
|
POPS Server |
995 |
pop.sslport |
service.pop.sslport |
pop.enablesslport (0) |
service.pop.enablesslport (0) |
|
LMTP Server |
225 |
dispatcher.service:LMTP.tcp_ports |
dispatcher.cnf |
dispatcher.service:LMTP.enable |
dispatcher.cnf (disabled) |
|
MTA |
NA |
NA |
NA |
mta.enable |
local.imta.enable (1) |
|
SMTP Relay |
25 |
dispatcher.service:SMTP.tcp_ports |
dispatcher.cnf |
dispatcher.service:SMTP.enable |
dispatcher.cnf (enabled) |
|
SMTP Submit |
587 |
dispatcher.service:SMTP_SUBMIT.tcp_ports |
dispatcher.cnf |
dispatcher.service:SMTP_SUBMIT.enable |
dispatcher.cnf (enabled) |
|
SMTPS Submits |
465 |
dispatcher.service:SMTP_SUBMIT.tcp_ports |
dispatcher.cnf |
dispatcher.service:SMTP_SUBMIT.enable |
dispatcher.cnf (disabled) |
|
http mail proxy |
8990 |
http.port |
service.http.port |
http.enable (1) |
local.http.enable (1) |
|
https mail proxy |
8991 |
http.sslport |
service.http.sslport |
http.enablesslport (0) |
service.http.enablesslport (0) |
|
MMP |
NA |
NA |
NA |
mmp.enable (0) |
local.mmp.enable (0) |
|
IMAP Proxy |
143 |
imapproxy.tcp_listen:imapproxy1.tcp_ports |
Aservice.cfg |
NA |
Aservice.cfg (0) |
|
POP Proxy |
110 |
popproxy.tcp_listen:popproxy1.tcp_ports |
Aservice.cfg |
NA |
Aservice.cfg (0) |
|
Submit Proxy |
587 |
submitproxy.tcp_listen:popproxy1.tcp_ports |
Aservice.cfg |
NA |
Aservice.cfg (0) |
|
IMAPS Proxy |
993 |
proxyimapssl |
Aservice.cfg and ImapProxyAService.cfg |
NA |
Aservice.cfg and ImapProxyAService.cfg (disabled) |
|
POPS Proxy |
995 |
popproxy.tcp_listen:ssl_ports |
Aservice.cfg and PopProxyAService.cfg |
NA |
Aservice.cfg and PopProxyAService.cfg (disabled) |
|
Submits Proxy |
465 |
submitproxy.tcplisten:ssl_ports |
Aservice.cfg and SmtpProxyAService.cfg |
NA |
Aservice.cfg and SmtpProxyAService.cfg (0) |
|
Internal Servers |
NA |
NA |
NA |
NA |
NA |
|
watcher |
49994 |
watcher.port |
local.watcher.port |
watcher.enable (1) |
local.watcher.enable (1) |
|
job_controller |
27442 |
job_controller.tcp_ports |
job_controller.cnf |
mta.enable (1) |
local.imta.enable (1) |
|
ENS |
7997 |
ens.port |
local.ens.port |
ens.enable (0) |
local.ens.enable (0) |
Messaging Server can use Oracle GlassFish Message Queue, a standards-based messaging service, to send event notifications. Message Queue is provided as a shared component when you install Messaging Server or other Communications Suite products.
For more information, see the discussion on integrating JMQ and Messaging Server in the Messaging Server System Administrator's Guide.
Messaging Server supports client certificate authentication. For more information, see the discussion on certificate based authentication for Messaging Server in the Messaging Server Security Guide.