MAILbus_400 _________________________________________ Installing on Tru64 UNIX System Revision/Update Information: Version 3.1 This card contains the information that you need to install the MAILbus 400 MTA on a Tru64 UNIX system. Use this card in conjunction with Part III of MAILbus 400 MTA Planning and Setup. Hewlett-Packard Development Company, L.P makes no representations that the use of its products in the manner described in this publication will not infringe on existing or future patent rights, nor do the descriptions contained in this publication imply the granting of licenses to make, use, or sell equipment or software in accordance with the description. Possession, use, or copying of the software described in this publication is authorized only pursuant to a valid written license from Hewlett- Packard Development Company, L.P or an authorized sublicencor. No responsibility is assumed for the use or reliability of software on equipment that is not supplied by Hewlett-Packard Development Company, L.P. or its affiliated companies. © Copyright 1994,1996,2003 Hewlett-Packard Development Company, L.P. The following are trademarks of Hewlett-Packard Development Company, L.P: DEC, DECnet, Digital, MAILbus 400, and the Compaq logo. OSI is a registered trademark of CA Management, Inc. UNIX is a registered trademark in the United States and other countries licensed exclusively through X/Open Company Ltd. Order Number: AV-Q2MUF-TE Installation Prerequisites Before you install the MAILbus 400[TM] MTA, do the following: o Make sure the following software is installed on your system. - Tru64 UNIX V4.0G DECnet-Plus for Tru64 UNIX V4.0C or later Tru64 UNIX Enterprise Directory V5.0 or later - Tru64 UNIX V5.0, V5.1, V5.1A DECnet-Plus for Tru64 UNIX 5.0-1 or later Tru64 UNIX Enterprise Directory V5.0 or later Note: If your system is running DECnet V4.0C, V5.0-1, V5.0A-1 or V5.1 you need to install the "libdnamgmt.so" DECnet patch for the CML process crash problem for distribution lists containing more than 320 entries. For more details please refer to section 5.2 of the MAILbus 400 MTA Release Notes. o Back up your system disk. o Register a valid MTA license, MAILBUS-400-MTA and MAILBUS-400-API. Use the Tru64 UNIX License Management Facility (LMF) to do this; see the Tru64 UNIX Guide for Software Licensing. o Make sure the MAILbus 400 MTA and any applications that use the MAILbus 400 MTA are shut down before you deinstall and reinstall the new version of the MTA except when performing an MTA Rolling Upgrade. For more details on MTA Rolling Upgrade refer to Section 4.2 of the MAILbus 400 MTA V3.1 Release Notes. o Deinstall any MAILbus 400 MTA or API subsets already installed on your system as follows: # setld -d MTAABASE14? MTAASRVR14? MTAANETMAN14? MTABCLNT14? MTABMAN14? # setld -d MTAABASE2?? MTAASRVR2?? MTAANETMAN2?? MTABCLNT2?? MTAAMAN2?? The question mark (?) in subset names is a wildcard character. 2 Information Required To install the MAILbus 400 MTA, you need the following information: o The device name for the drive where the CD-ROM will be mounted. o If you are installing the MAILbus 400 MTA from a RIS server area, the name of the RIS server area. Time Required It takes approximately 10 minutes to install all MAILbus 400 MTA subsets. Disk Space Required The following table shows the approximate amount of disk space required (in Kilobytes) for each of the MAILbus 400 MTA subsets in /usr/opt and /var/opt, and the corresponding softlinks for the MAILbus 400 MTA files in /usr and /var. ________________________________________________________________ Space Required Subset Title Subset Name (in kB) _______________________________________________/usr_______/var__ MAILbus 400 MTA Mgt (Compaq MTAANETMAN310 1800 80 Tru64 UNIX) MAILbus 400 MTA Server MTAASRVR310 29900 120 (Compaq Tru64 UNIX) MAILbus 400 MTA Base (Compaq MTAABASE310 4400 70 Tru64 UNIX) MAILbus 400 API (Compaq MTAABASE310 11000 minimal Tru64 UNIX) MAILbus 400 API Reference MTAABASE310 200 minimal Pages_(Compaq_Tru64_UNIX) ________________________________________________________________ 3 Installing the MAILbus 400 MTA a. Installing from CD 1. Log in with superuser privileges and make sure you are in the root directory. For a RIS installation, continue at step 3. 2. Mount the disk using the device name as follows: # mount -r -d /dev/device_name /mnt 3. Load the subsets as follows: for CD-ROM: # setld -l /mnt/MTAA310/kit for RIS, using the name of the RIS server area: # setld -l ris_area b. Installation from tar file 1. Copy the tar file to a directory, for example, /tmp1, on the target node. 2. Create a temporary directory, for example, /tmp2, to contain the MTA and API subsets. 3. Change current directory to /tmp2. 4. Unpack the tar file into this directory, for example: # tar -xvf /tmp1/mtaa310.tar 5. You can now install V3.1 from the temporary directory: # setld -l . The installation procedure starts and prompts you to specify the subsets that you want to install. To specify more than one of the options offered, enter the number associated with each option, with a space between each number. The MAILbus 400 API subsets MTAACLNT310 and MTAABASE310 supplied with this kit are TruCluster-enabled. Please note that these API subsets cannot be used to work with MAILbus 400 MTA versions less than V3.1. Also, the previous MAILbus 400 API subsets will continue to work 4 with MAILbus400 MTA V3.1. Refer to section 6.3.1 of the MAILbus 400 MTA V3.1 Release Notes for further details. Installing Subsets for the MTA On every node where you want to run an MTA, select the options to install the following subsets: MAILbus 400 MTA Mgt, MAILbus 400 MTA Server, and MAILbus 400 MTA Base. Installing Subset for Remote Management Select the option to install the MAILbus 400 MTA Mgt subset on every node where you want to remotely manage MTAs and the MTAs' routing information in the directory. Installing Subset for Remote Access by XAPI Agents Where an XAPI Agent (that is, an Agent using the X.400 API) is to be installed on a system remote from the MTA, select the option to install the MAILbus 400 MTA Base component on the node where the Agent is to be installed. After the Installation The set-up tasks required after installation, and the MTA verification procedure are described in Part III of MAILbus 400 MTA Planning and Setup. Before you continue and set up each MAILbus 400 MTA, make sure that the Base subset of the Tru64 UNIX Enterprise Directory (X.500) is installed on each node where you have installed the MAILbus 400 MTA Mgt subset. Refer to the Tru64 UNIX Enterprise Directory Service (X.500) documentation for details of how to install the Base subset of the above X.500 Directory Service. Installing and configuring MTA on TruCluster Prerequisite Software: To install the TruCluster enabled MAILbus 400 MTA V3.1 on a TruCluster system, make sure you install the following configurations of prerequisite software: Tru64 UNIX V5.1 (Rev. 732) or later; TruCluster Server T5.1-10 (Rev. 387) or later; DECnet-Plus for Tru64 UNIX V5.0A-1 (Rev. 4.4) or later; Tru64 UNIX Enterprise Directory V5.0 or later (not required for the API); 5 Note: If your system is running DECnet V4.0C, V5.0-1, V5.0A-1 or V5.1 you need to install the "libdnamgmt.so" DECnet patch. For more details please refer to section 5.2 of the MAILbus 400 MTA V3.1 Release Notes. Installing MTA Licenses: Obtain the following licenses 1. MAILBUS-400-MTA 2. MAILBUS-400-API Install the license on each of the cluster nodes where MAILbus 400 MTA has been configured using the 'lmf' utility. Installing MTA Subsets: The MTA subsets are installed using the setld command on any one of the nodes in the cluster. The setld command automatically propagates the installation to the other nodes of the cluster. Thus the MAILbus 400 installation is to be carried out only on one of the nodes in the cluster. The lists of subsets provided with MTA V3.1 are MTAABASE310, MTAACLNT310, MTAAMAN310, MTAANETMAN310, and MTAASRVR310. a. Installing from CD 1. Log in with superuser privileges and make sure you are in the root directory. For a RIS installation, continue at step 3. 2. Mount the disk using the device name as follows: mount -r -d /dev/device_name /mnt 3. Load the subsets as follows: for CD-ROM: # setld -l /mnt/MTAA310/kit for RIS, using the name of the RIS server area: # setld -l ris_area b. Installation from tar file 1. Copy the tar file to a directory, for example, /tmp1, on the target node. 6 2. Create a temporary directory, for example, /tmp2, to contain the MTA and API subsets. 3. Change current directory to /tmp2. 4. Unpack the tar file into this directory, for example: # tar -xvf /tmp1/mtaa310.tar 5. You can now install V3.1 from the temporary directory: # setld -l . The installation procedure starts and prompts you to specify the subsets that you want to install. To specify more than one of the options offered, enter the number associated with each option, with a space between each number. List of member-specific files Installed from the MAILbus 400 MTA Subsets The MTA installation procedure automatically creates the following CDSLs when installing on a Trucluster environment. The following directories in '/var/mta' are member- specific. /var/mta/accounting /var/mta/archive /var/mta/bad_msgs /var/mta/trace /var/mta/workspace /var/mta/api The following files in '/var/mta/' directory are member specific. /var/mta/mta_api_server_address /var/mta/mta_server_names /var/mta/mta_bp_map_table.template The following files in '/var/mta/scripts/' directory are member specific. 7 /var/mta/scripts/start_mta.ncl /var/mta/scripts/stop_mta.ncl /var/mta/scripts/mta_setup /var/mta/scripts/create_mta_clns_templates.ncl /var/mta/scripts/create_mta_cons_templates.ncl /var/mta/scripts/create_mta_extdef_bodyparts.ncl /var/mta/scripts/start_mta_event_dispatching.ncl The following file in '/usr/sbin/mta/' directory is member-specific. /usr/sbin/mta/mta_cml_script Installation procedure will take care of making the above mentioned directories and files as CDSL(Context-Dependent Symbolic Link) automatically in a Trucluster environment. Automatic Registration of port 200 and 102 The Port 200 will be registered for 'mta_api_server' service in the file /etc/clua_services as 'in_multi, static' during the MTA installation process in a Trucluster environment. Example entry created in the file /etc/clua_services 'mta_api_server 200/tcp in_ multi,static'. In a Trucluster Environment the Port 102 has to be registered for 'rfc1006' in the file /etc/clua_services as 'in_multi,static,out_alias'. To do this, do the following: Put the entry in file /etc/clua_services as below "rfc1006 102/tcp in_multi,static,out_alias" Run the command - 'cluamgr -f ' This has to be done only if the DECnet version on the system is less than V5.1A. The above registration will be done automatically during the DECnet Installation Procedure for V5.1A onwards. Running the MTA Verification Procedure After successful installation of the MTA on the cluster as described above, you need to bring up the MTA individually on each of the nodes and run the MTA verification procedure for each of them individually. 8 For making the MTA operational on each of the MTA nodes refer to the MAILbus 400 MTA "Getting Started" guide Chapter 4. In addition to the steps in chapter 4 of the guide the following points need to be taken note of before starting up the MTA: The "/mts=email-system-name" should be common to all MTA instances. The mta names for each MTA instance should be different. After starting up the MTA on each of the nodes as above the MTA installation verification procedure should be run separately on each node, one node at a time. Running it in parallel on two/more nodes is not recommended. Creating MTA Set An MTA Set needs to be defined on the cluster. The MTA Set includes all the MTA instances on the cluster as members. This MTA set needs to be specified in the routing instructions defined in the common cluster MTS. Following are example commands to achieve the above: ncl> create mts "/mts=email-system-name" mta "mta-set- name" ncl> set mts "/mts=email-system-name" mta "mta-set-name" - _ncl> type mta set, members {"mta1","mta2"} where "mta1" and "mta2" are example MTA instance names on two different nodes in a two node cluster. Note: When defining the routing instructions later the server mta field and boundary mta field for routing instructions have to use this "mta_set_name" . This is required for both the multiple delivery feature for UAs and Failover for peer MTAs. Following are example commands to achieve the above: ncl> create mts "/mts= email_system_name" oraddress "C=country_code; A=service_provider; P=organisation_name; O=organisation_name, CN=" routing instruction [action=deliver, SERVER MTA="", agent = ""] 9 ncl> create mts "/mts= email_system_name" domain routing instruction [action=transfer to domain, BOUNDARY MTA=""] Setting the MTA Presentation Address Ensure that the presentation address of each of the MTA instances on the cluster is same and includes the RFC1006 addresses of the cluster-alias. 1. For example if the MTA is configured on a cluster with two nodes - ashwa and astha, the MTA presentation address on ashwa/astha should be: ""MTA"/"MTA"/"MTA88-ASHWAASTHA"/RFC1006+ashwaastha. xko.dec.com,RFC1006" where ashwaastha is the default cluster-alias name. 2. Including the CLNS addresses in the presentation address is optional. 3. The above presentation address should be defined for each of the MTA entities in the common MTS for the cluster. Use the following command to set the presentation address ncl> set mts "/mts=clustermts" mta "mtaname" - _ncl> pres address """...RFC1006+..." 4. Stop and start each MTA instance on the cluster after executing the above command so that the change gets propagated to each MTA entity. Configuring User Agents for Distributed Delivery This involves setting up the client 'mta_api_server_ address' file to use the cluster alias to contact the cluster. On the cluster, there is a member specific file '/var/mta/mta_server_names'. On each MTA node in the cluster this file needs to contain the entries (IP Address) for all the MTA nodes in the cluster EXCLUDING the local node IP Address on each MTA node. Internally each User Agent session is multiplexed to all the MTA instances mentioned in the 'mta_server_names' file (and the local MTA node by default) for handling distributed delivery of MPDUs in a Trucluster environment. The following sections explain each of the above steps. Updating XAPI Configuration Files 10 To facilitate the User Agents to connect to all MTAs in the cluster, the following two files have to be updated: /var/mta/mta_api_server_address /var/mta/mta_server_names. i /var/mta/mta_api_server_address On the cluster this file is member-specific i.e. each member has an individual copy of this file. In addition each remote User Agent has a copy of this file on the system where it runs. The entries in this file are in the following format LOCAL #TCP xxxxxxxxxxxxxx #OSITP 49xxxxxxxxxxxxx The entries in the file have to be modified as follows #LOCAL TCP (eg. 16.121.137.111). #OSITP 49xxxxxxxxxxxx Note: 1. Any of the member node addresses could also be optionally used in this file. But in such a case the user agents will not have the automatic load balancing and failover features provided by the cluster alias. 2. The Multiple Delivery feature for UAs works only with the TCP option above. (And also with the LOCAL option only if the User Agent has been relinked with the new XAPI library provided with MTA V3.1.) Only IP addresses are allowed in this file. Node names are not allowed. ii /var/mta/mta_server_names This file is also a member specific file. It is a new file specific to MTA on cluster. It stores the information of all the currently configured and online MTA nodes in the cluster. Using an available editor the /var/mta/mta_server_names file has to be edited to include all the node names (except the local node name on each node) in the cluster on which MTA instances are running. The format of entries in this file is as 11 below; it is also included in the file available after a successful installation of MTA. TCP hostname-1 TCP hostname-2 . . TCP hostname-n Where each entry corresponds to a node in the cluster where the MTA is configured and online. Each hostname in this file should be the fully qualified hostname of the node, including the domain name. Or it could be the alias name of the node as defined in the '/etc/hosts' file on the cluster. The maximum limit for the number of node names to be put in this file is 8. Lines starting with a '#' character are treated as comment lines. White space characters can be used as separators between the words on a line. Note: 1. The administrator of this file should ensure that this file does not contain duplicate entries for any cluster node. 2. The administrator of this file should ensure that on each node this file does not contain the entry for the Local Node. Creating Agent entities for User Agents Each User Agent should be registered and enabled with all instances of the MTA on the cluster. For a User Agent to connect successfully with the MTA on the cluster, all the MTA instances on the Trucluster should have an agent entity definition for the User Agent, and the agent entities should be in an enabled state. This allows the User Agent to connect to each of the nodes from a single session and perform a distributed delivery of the MPDUs over the configured cluster nodes. Connecting to External Peer MTAs 12 In a cluster environment each external peer MTA is capable of connecting to any of the nodes in the cluster. This requires that each MTA instance on the cluster have the same peer entity definition for the peer domain. While in the peer domain it is required that the presentation address for the cluster be set in a definite fashion as explained below. These steps allow the peer MTA to connect to any one of the available MTA instances on the cluster. Refer to the MAILbus 400 Getting Started Guide - Chapter 6 for steps to define a Peer MTA connection. To get the peer connection working in a cluster the following additional steps need to be carried out. 1. Ensure that the presentation address of each of the MTA instances on the cluster is same and includes the RFC1006 addresses of the cluster-alias. 2. The peer MTA entity definition needs to be present in each of the MTA instances on the cluster. All the peer definitions for a single peer domain in the MTA instances on the cluster need to be the same. 3. The peer definition in the external peer MTA needs to use the Presentation Address as discussed in step 1 above. The following example command illustrates this point for the two-node (astha, ashwa) cluster: ncl> set mta peer mta [type=manually configured, Name="connection-name"] - _ncl> Presentation address - _ncl> ""MTA"/"MTA"/"MTA88-ASHWAASTHA"/RFC1006+ashwaastha. xko.dec.com,RFC1006" 4. The routing instructions for the peer domains in the cluster MTS need to use the mta-set-name in the boundary mta field of the routing instruction. Defining Routing Instructions When defining the routing instructions the server mta field and boundary mta field for routing instructions have to use the "mta_set_name". 13 This is required to exploit both the multiple delivery feature for UAs and Failover for peer MTAs. All routing instructions in the cluster MTS are required to be defined as above. Following are example commands to achieve the same: To set the routing instruction for delivery to a User Agent execute the following command. ncl> create mts "/mts= email_system_name" oraddress "c=country_code;a=service_provider;p=organisation_name; o=organisation_name,cn=" routinginstruction [action=deliver, SERVER MTA="", agent = ""] To set the routing instruction for setting the boundary mta for a peer domain execute the following command. ncl> create mts "/mts= email_system_name" domain routing instruction [action=transfer to domain, BOUNDARY MTA= ""] MTA.OUT and USER.LOG files 1. The mta.out file used to capture the MTA traces should be a member-specific file. This needs to be ensured by the user when specifying a path name for this file. Not using a member- specific path for specifying the mta.out file results in inter-mingling of trace information from all the MTA instances in a single file. 2. The /var/adm/syslog.dated/< date >/user.log file now logs the following additional information: - The names of the nodes to which the UA could not connect. When the agent comes up it tries to establish a connection with all the MTA instances as mentioned in the '/var/mta/mta_server_names' file. If it fails to connect to any of these MTA instances it logs information in the 'user.log' file about the failed attempt. - The node names on which the agents are not registered/enabled. Similarly if an agent definition entity does not exist/is disabled on one or more of the MTA instances, the connection attempt is 14 rejected and information about the MTA instance not containing the agent entity definition is logged in the 'user.log' file. Extra steps be followed before MTA startup If required define an environment variable for Reconnect timer as shown below in "mta_cml_script" file. XAPI_RECONNECT_TIME=