|
| |
| Sun Java Enterprise System 2005Q4 Deployment Example: Telecommunications Provider Scenario | |
Chapter 6
Software Installation and Configuration ProceduresThis chapter describes the procedures for implementing the architecture that is described in Chapter 3, "The Architecture". The implementation procedures are based on the specifications described in Chapter 4, "The Deployment Specifications" and the installation plan described in Chapter 5, "The Installation and Configuration Plan".
The installation and configuration procedures are described in two sections, as follows:
This section describes the software installations and hardware configurations needed to prepare the network and the individual computers for installation of the Java ES components. deployment components. This section includes such tasks as installing and configuring the operating system on each computer, setting up the Domain Name Service, and configuring the load balancers.
System PreparationTo fully deploy the Telco architecture, or a similar architecture that you develop, you must do more than install and configure the Java ES components. This section describes some other tasks you are likely to perform as part of deploying a Java ES system based on the Telco architecture. The tasks are described in a general way, that can be adapted to the specific hardware or software you may be using.
In general, Java ES components are installed on a set of networked computers, and both the individual computers and the network must be properly prepared before you begin to install the Java ES components. The network connections must be complete before you begin to install the Java ES components. Figure 4-1 illustrates the network connections required for the Telco deployment.
This section describes:
You set up the DNS first, since you will need the DNS for name/IP address resolution when you install the Solaris operating system on the computers used in the deployment.
Setting Up a Domain Name Service
A Domain Name Service (DNS) is maps host names to IP addresses, making it possible to access remote computers by host names. in Java ES deployments like the Telco deployment, the DNS also makes it possible to specify networked services by host names. When you install and configure the Java ES components, you configure component instances to interoperate with other component instances by specifying the named networked services provided by the other component instances. You also establish some named services that are accessible to remote users.
The DNS Mappings for the Telco Deployment
For the purpose of the Telco deployment a new domain called net.telco.com was established. The hostnames for all of computers implementing the deployment architecture belong to the net.telco.com domain.
The entries in the DNS specify the IP address and host name for each computer in the system. The host names and corresponding IP addresses for the Telco deployment are shown in Figure 4-1.
In addition to the host names and IP addresses shown in Figure 4-1, the Telco deployment uses a set of virtual host names and virtual IP addresses to reference the networked services provided by the components in the deployment.
Notice that the networked services provided by the component instances in the Telco deployment are logical services. Logical service are networked services provided by several distributed, redundant component instances but represented by a single host name defined in the DNS. Clients of the service address their requests to the logical host name; the requests are to delivered to one of the distributed instances that comprises the logical service.
Logical services are established to satisfy quality of service requirements such as availability, reliability, and network isolation (security). For example, the Telco deployment uses load balancers to distribute requests for a service between two component instances that provide a service, which increases both the availability and reliability of the service. Figure 4-1 shows the network connections between the load balancers and the component instances.
When you use load balancers in this way, you establish a logical service by mapping the logical service name to the load balancer. Then you configure clients of the service to address their requests for the service to the logical service name (the load balancer), which distributes the requests to the real instances that provide the service. For example, components that need directory services are configured to address requests to jesDPA.net.telco.com. Figure 4-1 shows you that the name jesDPA.net.telco.com is mapped to a load balancer that distributes the requests between to instances of Directory Proxy Server.
Table 6-1 lists the DNS entries that are needed to define the logical services in the Telco deployment. The DNS entries for the logical services must match the virtual host names and virtual IP addresses that you establish for the load balancers. For more information on configuring the load balancers, see Configuring the Load Balancers.
The DNS Architecture for the Telco Deployment
A DNS consists of both server and client components. In the Telco deployment, the DNS server component runs on a SunFire V240 Server (jesADM.net.telco.com). In The DNS server software was co-located with the Delegated Administrator component, as this computer has the least average usage.
Security considerations normally dictate separate DNS servers for the public, client-facing computers and load balancers and the protected computers and load balancers. The DNS server for the public, client-facing computers is typically located in the DMZ, while the DNS server for the internal, protected hardware is located on one of the protected computers, such as jesADM.net.telco.com.
Notice that The DNS Mappings for the Telco Deployment only describes the contents of the internal DNS server.
If greater security is needed, the internal DNS service can be placed in the innermost access zone. In this case, the integrity of the firewalls could be maintained by having load balancers in the other zones that provide virtual extensions of the DNS service.
DNS client components are needed on all other computers in the deployment. The client components are configured to point to the internal DNS server component. Alternatively the naming service could be changed to LDAP instead of DNS, for the internal hostname-to-IP address translation.
Configuring the Load Balancers
The load-balancers in the Telco deployment serve a number of purposes, which are described in Redundancy Strategies Used in the Architecture, and The Network and Connectivity Specification.
Before you can install, configure, and use any of Telco’s Java ES services, you must configure the load balancers to achieve the correct routing of network traffic.
Configuring Virtual Service Addresses
Figure 4-1 illustrates the physical connections in the Telco deployment between the load balancers and the computers running the Java ES components. For example, there is a load balancer, jesDPA.net.telco.com that is placed in front of two computers, jesDPA1.net.telco.com and jesDPA2.net.telco.com that are running Directory Proxy Server instances. The goal is to have the load balancer distribute requests for directory proxy services between the Directory Proxy Server instances running on jesDPA1 and jesDPA2. This section describes how to configure the load balancer to provide this function.
The mechanism for providing this function is the virtual service and the virtual IP address (VIP). You choose a virtual (logical) name, such as jesDPA.net.telco.com, for a service that is, in reality, provided by a number of component instances. You then configure the load balancer to map the virtual service name and virtual IP address to the component instances that actually provide the service. The configured load balancer appears to the clients of the service as a single device that provides the service, but it is actually the load balancer distributing the requests among the component instances that provide the service.
The basic configuration steps, which should apply to whatever load balancing hardware you are using, are the following:
- Identify the real hosts to which the load balancer routes requests. These real hosts are the computers running the Java ES component instances. You typically identify the real hosts by adding their IP addresses to the load balancer’s hosts table. For example, when you configure the load balancer for the jesDPA service, you add the IP addresses for jesDPA1.net.telco.com and jesDPA2.net.telco.com to the load balancer’s host table.
- Identify the real services to which the load balancer will be routing requests. The real services are the server application instances running on the host computers that you identified in Step 1. In the Telco deployment, the real services are the Java ES component instances. You typically identify a real service by its IP address and port. For example, when you configure the load balancer for the jesDPA.net.telco.com service, you identify the Directory Proxy Server instances at 129.138.11.3:489 and 129.138.11.4:489.
- Define the service groups. The service groups are sets of the real services that you defined in Step 2. The real services in the group must be capable of fulfilling the same type of request. The load balancer will distribute requests among the real services in the service group. For example, when you define the service group for the jesDPA.net.telco.com, you add the real services that specify the Directory Proxy Server instances, 129.138.11.3:489 and 129.138.11.4:489.
- Define the virtual (also called logical) service. The virtual service definition includes the outward facing IP address and port at which the load balancer accepts requests for a service. The definition of the virtual service also maps the virtual service to the service group (defined in Step 3) that actually handles the requests. The load balancer will accept requests at the virtual service address and distribute them among the service group. For example, the virtual service definition for the directory proxy service maps the virtual name jesDPA.net.telco.com and the virtual IP address 192.168.12.3:389, to the service group that includes the real services129.138.11.3:489 and 129.138.11.4:489.
Once the load balancer is configured, you configure the client components, such as the components that use the directory proxy service, to address their requests to the virtual service, rather than to a specific Directory Proxy Server instance. The requests are delivered to the load balancer, which distributes the requests between the Directory Proxy Server instances.
The configuration of virtual service IP addresses must be coordinated with the configuration of your DNS servers. For example, in the Telco deployment, the externally accessible DNS server maps the URL www.telcomail.com to the virtual service address for the load balancer in front of the Portal Server Secure Remote Access instances running on jesSRA1 and jesSRA2. The internal DNS server maps the hostname jesSRA.net.telco.com to the same virtual service address. This load balancer is configured to distribute requests for portal access between the two Portal Server Secure Remote Access instances.
SSL Termination
In the Telco deployment, users access portal services through the Portal Server Secure Remote Access gateway, over HTTPS connections. The problem that arises when HTTPS connections are used, is that any session persistence cookies you are using are encrypted when the traffic passes through the load balancers.
- The preferred way of implementing HTTPS secure session is to terminate the SSL connection at the load balancer and have the load balancer do all the encryption and decryption work, rather than computers running the Portal Server Secure Remote Access instances. This produces much better performance. However, not all load balancers have this feature.
- If the load balancer does not decrypt requests, HTTPS sessions pass through the load balancer, and the Portal Server Secure Remote Access instance does the encrypting and decrypting. In this case, the load balancer must still identify the user session and route the requests to the correct Portal Server Secure Remote Access instance. To accomplish this, you configure the load balancer to make routing decisions based on the SSL session ID. Configuring the load balancer to use the session cookie, as described in Configuring for Session Persistence, is not possible.
If the load balancers in your deployment support encrypting and decrypting of SSL requests, you should use this feature. If not, configure the load balancers to route base on the SSL session ID.
Configuring for Session Persistence
This section describes your options for configuring your load balancers to use session cookies to maintain session persistence. These options are available if you are able to terminate you HTTPS sessions at your load balancers. (These options are also available if you choose to use HTTP instead of HTTPS.)
The Telco deployment uses the Access Manager single sign-on mechanism, which adds the concept of state to the otherwise stateless HTTP protocol. When a user logs in through the Portal Server Secure Remote Access gateway, Access Manager creates a session, which is maintained until the user logs out. You can think of Access Manager sessions in much the same way that you think of the javax.servlet.http.HttpSession object.
In the Telco deployment, both portal and access manager services are provided by a service group that is comprised of the component instances running on two load-balanced computers, jesPAM1 and jesPAM2. When a user logs in, the request is routed to the instances on one computer, and the new session is established with the instances on that computer. The problem that arises is tracking the user’s session so that additional requests from the same user are routed to the instances to which the user originally connected.
To maintain the user’s session, you must configure the load balancer’s virtual service definition to support session persistence. You can do this is in either of the following two ways:
- Define and set a session cookie in Access Manager.
- To define the session cookie, edit the Access Manager configuration file (/etc/opt/SUNWam/config/AMConfig.properties) and add the following lines:
com.iplanet.am.lbcookie.name=pamlbcookie
com.iplanet.am.lbcookie.value=101 (on jesPAM1)or
com.iplanet.am.lbcookie.name=pamlbcookie
com.iplanet.am.lbcookie.value=102 (on jesPAM2)The value of the cookie identifies the computer on which the user’s session was established.
- To use the cookie, you configure the load balancer to read the cookie and route requests to the real host identified in the cookie. You typically accomplish this by establishing object and forwarding rules based on the HTTP Request and Response header predicate COOKIE. For example:
{COOKIE has pamlbcookie eq 101}
This technique makes use of the load balancer’s cookie persistence mechanism or level 7 stickiness. With this technique the load balancer knows exactly where to direct a user HTTP request.
If you are using load balancers that do not support level 7 stickiness, you can use level 4 stickiness.
- Set the session cookie with the load balancer.
Some load balancers have their own cookie persistence mechanisms. In this case you can implement session persistence without defining any extra cookies in Access Manager. If your load balancer supports its own persistence mechanism, follow the instructions in the load balancer documentation. Setting the cookie in Access Manager is a more general solution for load balancers that do not have their own cookie persistence mechanism.
Installing and Configuring the Java ES Software ComponentsThis section describes how to install and configure the Java ES software component instances. The procedures in this section are developed from the following information, which appears earlier in this document:
- The requirements are described in Chapter 2, "The Requirements".
- The architecture is described in Chapter 3, "The Architecture".
- The detailed specifications are described in Chapter 4, "The Deployment Specifications".
- The installation plan, which explains the sequencing and content of the modules, is described in Chapter 5, "The Installation and Configuration Plan".
Module #1: Directory Server with Multimaster Replication
In Module #1, you install and configure two instances of Directory Server. These two instances will serve as master replicas. However, you do not implement multimaster replication immediately. You implement multimaster replication only after you install and configure all of the other component instances.
Implementing multimaster replication as the last step of your installation and configuration process has an important benefit. When you install and configure component instances in modules 2-10, the component instances write their configuration data to the directory. If you write all of these changes to a single Directory Server instances, you can ensure that all of the configuration data is recorded correctly. After you install and configure the other components, you implement multimaster replication, which replicates the component configuration data to the second Directory Server instance.
When you implement multimaster replication as the last step of your installation and configuration process, you must re-create the directory indexes that support the Java ES components. You must create these indexes need in the second Directory Server instance by hand.
Because you implement multimaster replication as the last step of your installation and configuration process, this module is divided into two parts. Part A describes the basic Directory Server installation and configuration. Part B describes how to implement multimaster replication. You perform the procedures in Part B after you complete module 10, after all other component instances are installed and configured.
Installation and Configuration Summary
The installation and configuration procedures, detailed in the following sections, consist of the following steps:
Part A: Basic Directory Server Setup
Part B: Multimaster Replication
Procedure, Part A: Basic Directory Server Setup
- Install Java ES software on jesDSM1.
Use the Configure Now option of the Java ES installer.
- Select the following components:
- Enter the Directory Server configuration parameter values shown in the following table:
- Enter the Administration Server configuration parameter values shown in the following table:
- Start Directory Server on jesDSM1.
# /usr/sbin/directoryserver start
- Verify the operation of Directory Server on jesDSM1.
- Enter the following commands:
# cd /global/jesDSM1/opt/jes/mps/serverroot/shared/bin
# ./ldapsearch -b "dc=net,dc=telco,dc=com" -h jesDSM1 -p 389 \
-D "cn=Directory Manager" -w password "objectClass=*"- Check for the following results:
version: 1
dn: dc=net,dc=telco,dc=com
objectClass: top
objectClass: domain
dc: netdn: cn=Directory Administrators, dc=net,dc=telco,dc=com
objectClass: top
objectClass: groupofuniquenames
cn: Directory Administrators
- When installing enter the following parameter values shown in the following table:
Table 6-4 Directory Server Configuration Parameters
Parameter
Value
Configuration Directory Settings
Use an Existing Configuration Directory Server
2
- When installing enter the configuration parameter values shown in the following table:
Procedure, Part B: Multimaster Replication
The following steps are performed only after completing Modules 2 through 8.
- Set up multimaster replication between jesDSM1 and jesDMS2.
Before replication agreements can be configured, replication must first be enabled on both Directory Server instances.
Replication is achieved by using the Administration Server Console to configure one master instance (jesDSM1) and then replicating all the data to the other Directory Server instance (jesDSM2).
- Enable replication for Directory Server on jesDSM1.
- Add the o=NetscapeRoot suffix to Directory Server on jesDSM2.
Use the Administration Server Console that your started in Step a.
- Add schema extensions and indexes for Messaging Server and Calendar Server to the Directory Server instance on jesDSM2.
- Change directory on jesDSM2 to the location of the Directory Preparation Tool.
# cd /global/jesDSM2/opt/SUNWcomds/sbin
- Run the Directory Preparation Tool.
# perl comm_dssetup.pl
- Provide the following parameters requested by the script:
The Directory Preparation Tool adds schema extensions and indexes to the directory, including adding the following root suffixes:
- o=pab (for personal address books)
- o=PiServerDb (for personal address books)
- o=comms-config (for mapping the functions of Delegated Administrator, used to populate user data for Messaging Server and Calendar Server)
- Add indexes for Access Manager to the Directory Server instance on jesDSM2.
- Create replication agreements for the Directory Server instance on jesDSM1.
- Repeat Step a for the Directory Server instance on jesDSM2.
- From the Directory Server instance on jesDSM1, initialize the remote Directory Server on jesDSM2 for each of the root suffixes.
- Repeat Step e for the Directory Server instance on jesDSM2.
- Reindex all the suffixes on jesDSM1 and then on jesDSM2.
Use the Administration Console to perform the reindexing.
- Set the replication agreements on jesDSM1 and jesDSM2 for continuous refresh.
- Verify replication behavior.
- Insert a test organization entry in Directory Server on jesDSM1.
# ./ldapmodify -a -h jesDSM1 -p 389 -D "cn=Directory Manager"
-w passworddn: o=testOrg, o=data
objectClass: top
objectClass: organization
o: testOrg- Query Directory Server on jesDSM2 for the new entry.
# ./ldapsearch -b "dc=net,dc=telco,dc=com" -h jesDSM2 -p 389
-D "cn=Directory Manager" -w password "objectClass=*"- Check for the following results:
version: 1
...
dn: o=testOrg, dc=net,dc=telco,dc=com
objectClass: top
objectClass: organization- Set the Directory Server tuning parameters.
Set the parameters shown in Table 6-7.
.
Module #2 Directory Proxy Server
In this module you install Directory Proxy Server instances and configure the instances for load balancing.
Procedure, Part A: Directory Proxy Server in DMZ1 Layer
Directory Proxy Server set up.
- Install Java ES software on jesDPA1.
Use the Configure Now option of the Java ES installer.
- Select the following components:
- Select Remote Directory Installation
Specify the existing Directory Server instance on jesDS1.
- Enter the Directory Proxy Server configuration parameter values shown in the following table:
- Start the Directory Proxy Server on jesDPA1.
cd /global/jesDPA1/var/opt/mps/serverroot/dps-jesDPA1
./start-dps- Verify the operation of Directory Proxy Server on jesDPA1.
- Query Directory Server on jesDSM1 via the Directory Proxy Server.
# ldapsearch -b “dc=net,dc=telco,dc=com” -h jesDPA1 -p 489
-D “cn=Directory Manager -w password “objectClass=*”- Check for the following results:
ldap_simple bind: Insufficient access
ldap_simple bind: additional info: Not permitted to bindThis result indicates that the directory proxy has not yet been configured to allow access to the Directory Server.
- Configure Directory Proxy Server using the Directory Proxy Server console.
- Open jesDPA1 configuration.
- Select Network Groups.
- Select Group Configuration.
- Select Edit.
- Rename the Network Group from network-group-1 to trusted_zone_group.
- In the Group panel go the Network option.
- Set the client binding criteria:
162.168.11.0/255.255.255.0 quad mask
- In the Forwarding option, go to Operations.
Allow all operations.
- Save the configuration and exit the Group panel.
- Select Properties.
- Select Ldap Server
- Select ldap-server-1
- Select Edit.
Change the property name to jesDSM1.
Set the host to jesDSM1.net.telco.com.
- Save your changes.
- Restart Directory Proxy Server.
Use the Tasks menu on the Directory Proxy Server console.
- Verify the operation of Directory Proxy Server.
When you repeat, note the following changes:
- Configure the load balancer jesDPA in zone 2 (192.168.12.3) to balance http requests between the two Directory Proxy Server instances jesDPA1 (192.168.11.3) and jesDPA2 (192.168.11.4). For more information see Configuring the Load Balancers.
- Shut down the Directory Proxy Server on jesDPA2.
- Verify the operation of Directory Proxy Server on jesDPA1.
- Insert into the LDAP directory an o=id root suffix. Set the value to jesDSM1:
# ldapmodify -a -h jesDSM1 -p 389 -D cn=Directory Manager -w password
dn: o=id
objectClass: top
objectClass: organization
description: jesDSM1- Query the Directory Server instance on jesDSM1 via the Directory Proxy Server logical URL:
# ldapsearch -b o=id -h jesDPA -p 389 -D cn=Directory Manager
-w password objectClass=*- Check for the following results:
dn: o:=id
objectClass: top
objectClass:organization
description: jesDSM1This result verifies that the load balancer, Directory Proxy Server, and Directory Server are all working.
- Shut down the Directory Proxy Server on jesDPA1.
- Verify the operation of Directory Proxy Server on jesDPA2.
- Insert into the LDAP directory an o=id root suffix. Set the value to jesDSM2:
# ldapmodify -a -h jesDSM2 -p 389 -D cn=Directory Manager -w password
dn: o=id
objectClass: top
objectClass: organization
description: jesDSM2- Query the Directory Server on jesDSM2 via the Directory Proxy Server logical URL:
# ldapsearch -b o=id -h jesDPA -p 389 -D cn=Directory Manager
-w password objectClass=*- Check for the following results:
dn: o:=id
objectClass: top
objectClass:organization
description: jesDSM2This verifies that the load balancer, Directory Proxy Server, and Directory Server are all working.
Module #3: Portal Server and Access Manager on Web Server
In this module you install Portal Server and Access Manager instances and configure these instances for load balancing. For Access Manager, you run the Java ES installer in configure now mode, and the installer configures Access Manager, which includes extending the directory schema to support Access Manager. Configuring Access Manager for load balancing, however, is a procedure you must perform by hand.
Installation and Configuration Summary
The installation and configuration procedure, detailed in the following section, consists of the following steps:
Procedure
- Install Java ES software on jesPAM1.
Use the Configure Now option of the Java ES installer.
- Select the following components:
- Select the following Access Manager sub-components:
- Specify that Access Manager will use a remote Directory Server instance.
- Enter the configuration parameter values shown in the following table:
Table 6-9 Portal Server, Access Manager and Web Server Configuration Parameters
Parameter
Value
Installation Directories
Access Manager
/global/jesPAM1/opt
Web Server
/global/jesPAM1/opt/SUNWwbsvr
Portal Server
/global/jesPAM1/opt
Common Configuration Settings
Host Name
jesPAM1
DNS Domain Name
net.telco.com
IP Address
192.168.11.5
Administrator User ID
admin
Administrator Password
password
System User
root
System Group
root
Web Server: Administration
Server Admin User ID
admin
Admin User's Password
password
Host Name
jesPAM1.net.telco.com
Administration Port
8888
Administration Server User ID
root
Default Web Server Instance
System User ID
root
System Group
root
HTTP Port
80
Content Root
/global/jesPAM1/opt/SUNWwbsvr/docs
Do you want to automatically restart Web Server when system restarts?
Yes
Access Manager: Administration
Administrator User ID
amAdmin
Administrator Password
password
LDAP User ID
amldapuser
LDAP Password
password1
Password Encryption Key
password
Install Type
legacy
Access Manager: Web Container
Web container in which to deploy
2. Web Server
Access Manager: Web Server
Host Name
jesPAM1.net.telco.com
Web Server Instance Directory
/global/jesPAM1/opt/SUNWwbsvr/https-jesPAM1.net.telco.com
Web Server Port
80
Document Root Directory
/global/jesPAM1/opt/SUNWwbsvr/docs
Secure Server Instance Port
No
Web Container for Running Access Manager Services
Host Name
jesPAM1.net.telco.com
Services Deployment URI
amserver
Common Domain Deployment URI
amcommon
Cookie Domain
.net.telco.com
Administration Console
Yes
Console Deployment URI
amconsole
Password Deployment URI
ampassword
Access Manager: Directory Server
Directory Server Host
jesDPA.net.telco.com
Directory Server Port
389
Directory Root Suffix
dc=net,dc=telco,dc=com
Directory Manager DN
cn=Directory Manager
Directory Manager Password
password
Access Manager: Directory Server Data
Is Directory Server provisioned1
No
Portal Server: Web Container
Web Container
2. Sun Java System Web Server
Portal Server: Web Server
Installation Directory
/global/jesPAM1/opt/SUNWwbsvr
Server Instance
jesPAM1.net.telco.com
Server Instance Port
80
Instance Port Secure
No
Document Root
/global/jesPAM1/opt/SUNWwbsvr/docs
Portal Server: Web Container Deployment
Load Balancer
Yes
Load Balancer Protocol
1. HTTP
Load Balancer Host
jesPAM.net.telco.com
Load Balancer Port
80
Deployment URI
/portal
Install Sample Portal
Yes
1Value of No indicates that schema extensions and directory entries should be made. A Value of Yes means changes have already been made by installation or configuration of Java ES components, even if users have not yet been provisioned.
- Start Web Server on jesPAM1. Starting Web Server automatically starts Access Manager.
# cd /global/jesPAM1/opt/SUNWwebsvr/https-jesPAM1.net.telco.com
# ./start
- Verify the operation of Access Manager on jesPAM1.
- Install Java ES software on jesPAM2.
Use the Configure Now option of the Java ES installer.
- Select the following components:
- Select the following Access Manager sub-components:
- Specify that Access Manager will use a remote Directory Server instance.
- Enter the same configuration parameter values that you used for the jesPAM1 installation, with the exceptions shown in the following table:
Table 6-10 Access Manager and Web Server Configuration Parameters
Parameter
Value
Access Manager: Directory Server Data
Is Directory Server provisioned1
Yes
Organization Marker Object Class
sunISManagedOrganization
Organization Naming Attribute
o
User Marker Object Class
inetorgperson
User Naming Attribute
uid
1Value of No indicates that schema extensions and directory entries should be made. A Value of Yes means changes have already been made by installation or configuration of Java ES components, even if users have not yet been provisioned.
- Start Web Server on jesPAM2. Starting Web Server automatically starts Access Manager.
# cd /global/jesPAM1/opt/SUNWwebsvr/https-jesPAM2.net.telco.com
# ./start
- Verify the operation of Access Manager on jesPAM2.
# /usr/bin/ps -ef | grep webservd
and look for running Web Server processes.
or, in a web browser:
http://jesPAM1.net.telco.com/amconsole
and log in as the Access Manager administrator, amadmin.
- Log in to the Access Manager console on jesPAM1.
- In the Access Manager console, navigate:
- On both jesPAM1 and jesPAM2, edit the Access Manager configuration file and add an fqdnmap entry.
- Restart the Web Server instances on jesPAM1 and jesPAM2.
- Set up the SSO Adapter for the portal mail channel.
- In your web browser, log in to the Access Manager console. Open the following URL:
http://jesPAM.net.telco.com/amconsole
- Type the user ID (amadmin) and password (password).
- Click the Service Configuration tab.
- In the left pane, locate the SSO adapter service. Click the arrow for the adapter service.
- In the right pane, Locate the SUN-ONE-MAIL service. Click Edit Properties.
- Set the property values shown in the following table:
- Save the parameter settings. Do not close the Access Manager console.
- Set up the SSO Adapter for the portal calendar channel. In the Access Manager console:
- Click the Service Configuration tab.
- In the left pane, locate the SSO adapter service. Click the arrow for the adapter service.
- In the right pane, Locate the SUN-ONE-CALENDAR service. Click Edit Properties.
- Set the property values shown in the following table:
- Save the property settings.
Module #4: User Management
In this module you prepare the LDAP directory for the different classes of user that Telco supports. You set up two email domains, telcomail.com and telco.net. You also add two branches to the LDAP directory tree, o=telcomail.com and o=telco.net, which group the user entries for the two mail domains. Business class users who do not have hosted domain support are added to the telcomail.com email domain, and their account data is stored in the o=telcomail.com branch of the directory tree. Consumer class users are added to the telco.net email domain, and their account data is stored in the o=telco.net branch of the directory tree.
This specific tasks described in this module are the following:
- Preparing the LDAP directory for mail and calendar services.
- Creating the telcomail.com and telco.net email domains and the corresponding branches in the LDAP directory tree.
- Adding attributes to each branch of the LDAP tree so that the user accounts in each branch are provisioned for the correct services.
- Adding a test user to each branch.
The tool that you use for most of these tasks is Delegated Administrator.
Delegated Administrator consists of server-side components and client-side components. This module explains how to install and configure the server-side components of Delegated Administrator. These components use the Access Manager SDK and must be deployed in the same web container as Access Manager.
This module also describes how to use the client-side command line utility (the commadmin command) to add the email domains, add the LDAP branches, and provision the test users.
This document describes using the Delegated Administrator command line utility, because the command line examples clearly show you the changes that you make to the directory. In a production environment you probably would use the Delegated Administrator console for many of these administration tasks. For the procedures that install and configure the Delegated Administrator console, see Module #8 Delegated Administrator Console on Web Server.
To add more email domains, such as a hosted domain for hostedcorp.com, repeat Step 9 through Step 14, changing the command line arguments for the email domains and LDAP branches you are creating.
Installation and Configuration Summary
Procedure
- Prepare the directory for Messaging Server and Calendar Server.
- On jesDSM1, change directory to the location of the Directory Preparation Tool.
# cd /global/jesDSM1/opt/SUNWcomds/sbin
- Run the Directory Preparation Tool.
# perl comm_dssetup.pl
The script prompts you for configuration parameters.
- Enter the parameter values listed in the following table:
The Directory Preparation Tool adds schema extensions to the directory, including adding the following root suffixes:
Notice that the Directory Preparation Tool operates on the base suffix for the Telco deployment, dc=net,dc=telco,dc=com.
- Install Delegated Administrator software on jesPAM1.
- Configure Delegated Administrator on jesPAM1.
- Run the Delegated Administrator configuration program.
# cd /global/jesPAM1/opt/SUNWcomm/sbin
# ./config-commda -nodisplay- Supply the parameters listed in the following table (notice that this operation creates the o=telcomail.com domain):
- Restart Web Server.
# cd /global/jesPAM1/opt/SUNWwbsvr/https-jesPAM1.net.telco.com
# ./stop
# ./start
- Modify the telcomail.com domain.
Use Delegated Administrator to add object classes and attributes that support Messaging Server and Calendar Server to the telcomail.com domain.
# ./commadmin domain modify -D admin -w password -n net.telco.com
-d o=telcomail.com,dc=net,dc=telco,dc=com -S mail,calWhen prompted, enter the domain's mailhost: jesMCSb.net.telco.com
- Verify the telcomail.com domain.
- Add a user account in the telcomail.com domain.
The following commands also provision the user account for Messaging Server, Calendar Server, and Portal Server.
- Create a user entry for buser0001.
# ./commadmin user create -D admin -w password
-n “o=telcomail.com,dc=net,dc=telco,dc=com”
-d “o=telcomail.com,dc=net,dc=telco,dc=com”-l buser0001
-F user -L buser0001 -W password- Provision buser0001 for mail and calendar services:
# ./commadmin user modify -D admin -w password
-n “o=telcomail.com,dc=net,dc=telco,dc=com”
-d “o=telcomail.com,dc=net,dc=telco,dc=com”-l buser0001
-S mail,cal-S mail,cal means add mail and calendar support for the user.
- Provision the user for the Portal Server SSO adapter service.
# ./commadmin user modify -D admin -w password
-n “o=telcomail.com,dc=net,dc=telco,dc=com”
-d “o=telcomail.com,dc=net,dc=telco,dc=com”-l buser0001
-A +objectclass:sunssoadapterperson- Provision the user for Portal Server Portal Desktop service.
# ./commadmin user modify -D admin -w password
-n “o=telcomail.com,dc=net,dc=telco,dc=com”
-d “o=telcomail.com,dc=net,dc=telco,dc=com”-l buser0001
-A +objectclass:sunportaldesktopperson- Set the mail host for the user to jesMCSb.net.telco.com.
# ./commadmin user modify -D admin -w password
-n “o=telcomail.com,dc=net,dc=telco,dc=com”
-d “o=telcomail.com,dc=net,dc=telco,dc=com”-l buser0001
-A mailhost:jesMCSb.net.telco.com- Provision the user for the Netfile service.
# ./commadmin user modify -D admin -w password
-n “o=telcomail.com,dc=net,dc=telco,dc=com”
-d “o=telcomail.com,dc=net,dc=telco,dc=com”-l buser0001
-A +objectclass:sunportalnetfileservice- Provision the user for the portal gateway access service.
# ./commadmin user modify -D admin -w password
-n “o=telcomail.com,dc=net,dc=telco,dc=com”
-d “o=telcomail.com,dc=net,dc=telco,dc=com”-l buser0001
-A +objectclass:sunportalgatwayaccessservice- Verify buser0001.
- Query the directory for business class users:
# ./commadmin user search -D “admin” -w password
-n “o=telcomail.com,dc=net,dc=telco,dc=com“
-d “o=telcomail.com,dc=net,dc=telco,dc=com“- Confirm the following response:
dn: uid=buser0001,ou=People,o=telcomail.com,dc=net,dc=telco,dc=com
uid: buser0001
mail: buser0001@telcomail.com
mailhost: jesMCSb.net.telco.com
...- Create the telco.net domain.
# ./commadmin domain create -D admin -w password
-n o=telcomail.com,dc=net,dc=telco,dc=com
Enter DNS Domain Name: telco.net
OK- Add Messaging Server support to the telco.net domain.
# ./commadmin domain modify -D admin -w password
-n o=telcomail.com,dc=net,dc=telco,dc=com
-d o=telco.net,dc=net,dc=telco,dc=com, -S mail
Enter domain’s mailhost: jesMSc.net.telco.com- Verify the telco.net domain.
- Add an administrator account for the telco.net domain.
- Create the admin_telco.net account.
# ./commadmin user create -D admin -w password
-n o=telcomail.com,dc=net,dc=telco,dc=com
-d o=telco.net,dc=net,dc=telco,dc=com
-l admin_telco.net -F Default -L Administrator -W password- Add the admin_telco.net account as an administrator for the telco.net domain.
# ./commadmin admin add -D admin -w password
-n o=telcomail.com,dc=net,dc=telco,dc=com
-d o=telco.net,dc=net,dc=telco,dc=com
-l admin_telco.net- Add a user account to the telco.net domain.
The following command uses the admin_telco.net account to create a user account and provision the user account for Messaging Server. Compare this sequence of commands to Step 7, which provisions a business class user account for more services.
- Create a user entry for cuser0001.
# ./commadmin user create -D admin_telco.net -w password
-n o=telco.net,dc=net,dc=telco,dc=com
-d o=telco.net,dc=net,dc=telco,dc=com -l cuser0001
-F user -L cuser0001 -W password- Provision cuser0001 for mail service:
# ./commadmin user modify -D admin_telco.net -w password
-n o=telco.net,dc=net,dc=telco,dc=com
-d o=telcomail.com,dc=net,dc=telco,dc=com-l cuser0001
-l cuser0001 -S mail-S mail means add mail support for the user.
- Set cuser0001’s mailhost to jesMSc.net.telco.com.
# ./commadmin user modify -D admin_telco.net -w password
-n o=telco.net,dc=net,dc=telco,dc=com
-d o=telco.net,dc=net,dc=telco,dc=com -l cuser0001
-A mailhost:jesMSc.net.telco.com- Verify cuser0001.
- Query the directory for consumer class users:
# ./commadmin user search -D admin_telco.net -w password
-n o=telco.net,dc=net,dc=telco,dc=com
-d o=telco.net,dc=net,dc=telco,dc=com- Confirm the following response:
dn: uid=cuser0001,ou=People,o=telco.net,dc=net,dc=telco,dc=com
uid: cuser0001
mail: cuser0001@telco.net
mailhost: jesMSc.net.telco.comModule #5: Business-class Messaging Server and Calendar Server on Sun Cluster Nodes
In module 5 you set up the Messaging Server and Calendar Server instances that support the telcomail.com email domain for business-class users. You install and configure these instances to run on Sun Cluster nodes. The messaging and calendar services thereby become resources managed by Sun Cluster software. The installation and configuration procedure is relatively complex, and requires you to run the Java ES installer three times on each computer. The procedure is divided into the following three parts:
Part A. Install Sun Cluster software and set up the global file system and cluster nodes. This must be done before Messaging Server and Calendar Server are installed.
Part B. Install and configure Messaging Server and Calendar Server. Messaging Server and Calendar Server are installed in the global file system on the logical host that represents the Sun Cluster nodes.
After you install Messaging Server and Calendar Server, you configure them as follows:
- Run the Directory Preparation Tool to extend the LDAP schema to support Messaging Server and Calendar Server configuration. Notice that in the Telco installation, you performed this step in Module 4. For more information, see Module #4: User Management.
- Run the Messaging Server configuration program. Configure the Messaging Server instance to support the telcomail.com email domain.
- Run the Calendar Server configuration program. Configure Calendar Server to use the telcomail.com email domain.
Part C. Install the Sun Cluster agents and configure the Messaging Server and Calendar Server resources. This makes it possible for the Sun Cluster software to manage the Messaging Server and Calendar Server instances.
Installation and Configuration Summary
The installation and configuration procedures are divided into three parts. The procedures are summarized as follows:
Part A: Set Up Sun Cluster Nodes and Global File System
Part B: Install and Configure Messaging Server and Calendar Server
Part C: Configure Sun Cluster Resources
Procedure, Part A: Set Up Sun Cluster Nodes and Global File System
- Install Java ES software on jesMCS1b.
Use the Configure Later option of the Java ES installer.
Select the Sun Cluster core component for installation.
- Prepare system for configuring Sun Cluster software.
Create new file systems on jesMCS1b and mount directories in preparation for configuring Sun Cluster software.
- Create new file systems on jesMCS1b. The following example uses meta devices created using Solaris Volume Manager. d0 is a mirrored, encapsulated system disk and the slice 4 partition will be mounted as a /globaldevices mount point.
# newfs /dev/md/rdsk/d0
# newfs /dev/rdsk/c1t0d0s4- Edit the table of file system defaults (vfstab) to include the new file systems and mount points:
#device device mount FS fsck mount mount
#to mount to fsck point type pass at boot options
# fd - /dev/fd fd - no -
/proc - /proc proc - no -
/dev/dsk/c1t0d0s1 - - swap - no -
/dev/md/dsk/d0 /dev/md/rdsk/d0 / ufs 1 no -
swap - /tmp tmpfs - yes -
/dev/dsk/c1t0d0s4 /dev/rdsk/c1t0d0s4 /globaldevices ufs 1 yes -- Create and mount the directories included in the vfstab in the previous step.
# cd /
# mkdir /globaldevices
# mount /globaldevicesThe /globaldevices mount point is required for configuring Sun Cluster software.
- Configure Sun Cluster software on jesMCS1b.
- Run the Sun Cluster configuration program.
# cd /net/installserver/export/jes4/Solaris_sparc/ Product/sun_cluster/Solaris_10/Tools
# ./scinstallChoose to add jesMCS1b as the first node of a new cluster.
- Enter the configuration parameter values shown in the following table:
- Reboot jesMCS1b.
Sun Cluster software creates cluster metadevices that correspond to each of the disks seen by jesMCS1b.
In addition, it replaces the following jesMCS1b mounted file system
/dev/dsk/c1t0d0s4 mounted on /globaldevices
with
/dev/did/dsk/d2s4 mounted on /global/.devices/node@1
where d2 is the cluster meta device that corresponds to c1t0d0 on jesMCS1b.
- Repeat Step 1 - Step 3 on jesMCS2b.
When running the scinstall program in Step 3, choose to add jesMCS2b as a node in an existing cluster. Sun Cluster software, as in the case of jesMCS1b, creates cluster metadevices that correspond to each of the disks seen by jesMCS2b. However the storage array disks that are dual ported to both jesMCS1b and jesMCS2b are each assigned only a single cluster metadevice, signifying that Sun Cluster software will regard these as replicated devices corresponding to the same logical device.
In addition, it replaces the following jesMCS2b mounted file system
/dev/dsk/c1t0d0s4 mounted on /globaldevices
with
/dev/did/dsk/d27s4 mounted on /global/.devices/node@2
where d27 is the cluster meta device that corresponds to c1t0d0 on jesMCS2b. The scinstall configuration program also configures the private interconnect between jesMCS1b jesMCS2b.
Running the ifconfig command on either node will show the ce1 and ce5 internet adapter in addition to the public internet connection on ce0.
- Complete the configuration of Network Timing Protocol (NTP).
NTP is used to synchronize the time on all cluster nodes. The scinstall configuration program sets up NTP clients for up to 16 cluster nodes. The extra NTP clients can be removed as follows (on both jesMCS1b and jesMCS2b):
- Add a quorum disk to the cluster.
Sun Cluster software uses quorum vote counts to determine when a cluster is viable. Each functioning node or device gets a vote. To be viable, the cluster must have at least one node and one disk storage device functioning. To set this up, you have to add a quorum disk to the cluster.
- Enter the following command on either jesMCS1b or jesMCS2b:
# /usr/cluster/bin/scsetup
- Specify that you want to add a quorum disk.
- The Telco deployment uses d18 as the global device to use for quorum counts. This cluster meta device on the storage array will be used for the Messaging Server store. Note that the quorum count is set to 2 by default because there are two cluster nodes.
- Set up cluster disk meta sets and mirroring.
Execute the following commands on jesMCS1b to set up disk sets that store Messaging Server data (ms_data) and Calendar Server data (cs_data) as mirrored sets.
- Add root to the administrative group.
# vi /etc/group and change sysadmin::14: to sysadmin::14:root.
- Add the following entries in the /etc/hosts file:
192.168.11.7 jesMCS1b.net.telco.com jesMCS1b loghost
192.168.12.5 jesMCSb.net.telco.com jesMCSb
192.168.11.8 jesMCS2b.net.telco.com jesMCS2b- Set up the meta set hosts
# metaset -s ms_data -a -h jesMCS1b jesMCS2b
# metaset -s cs_data -a -h jesMCS1b jesMCS2b- Set up the meta set definitions. In the following example, d18, d19, d20, and d21 are located on storage array A and d22, d23, d24, and d25 are located on storage array B. Two disks on each storage array are used for ms_data and two are used for cs_data.
storage array A:
# metaset -s ms_data -a /dev/did/rdsk/d18 /dev/did/rdsk/d19
# metaset -s cs_data -a /dev/did/rdsk/d20 /dev/did/rdsk/d21storage array B:
# metaset -s ms_data -a /dev/did/rdsk/d22 /dev/did/rdsk/d23
# metaset -s cs_data -a /dev/did/rdsk/d24 /dev/did/rdsk/d25- Set up disk concatenations corresponding to the meta set definitions.
Note that slice 0 is the only partition used on the disks in our setup.
# metainit -s ms_data d71 1 2 /dev/did/rdsk/d18s0 /dev/did/rdsk/d19s0
# metainit -s ms_data d72 1 2 /dev/did/rdsk/d22s0 /dev/did/rdsk/d23s0
# metainit -s cs_data d81 1 2 /dev/did/rdsk/d20s0 /dev/did/rdsk/d21s0
# metainit -s cs_data d82 1 2 /dev/did/rdsk/d24s0 /dev/did/rdsk/d25s0
- Set up mirroring between the disk sets on the two storage arrays.
# metainit -s ms_data d70 -m d71 d72
# metainit -s cs_data d80 -m d81 d82- Set up dual string mediators. In a two-node cluster, with two external storage disk arrays (two strings of disks, hence the name dual string mediators), a quorum mechanism is needed to determine the viability of disk storage in case of failure. Dual string mediators play a role in that mechanism. (Solaris Volume Manager)
# metaset -s ms_data -a -m jesMCS1b jesMCS2b
# metaset -s cs_data -a -m jesMCS1b jesMCS2b- Create new cluster file systems and mount corresponding global directories.
- Create new cluster file systems.
These file systems use the mirrored meta sets created in the previous steps.
# newfs -f 4096 /dev/md/ms_data/rdsk/d70
# newfs -f 4096 /dev/md/cs_data/dsk/d80
- Edit the table of file system defaults (vfstab) on both jesMCS1b and jesMCS2b to include the new file systems and mount points:
/dev/md/ms_data/dsk/d70 /dev/md/ms_data/rdsk/d70 /global/jesMCSb/ms_data ufs 1 yes global
/dev/md/cs_data/dsk/d80 /dev/md/cs_data/rdsk/d80 /global/jesMCSb/cs_data ufs 1 yes global- Create and mount the directories included in the vfstab in the previous step.
# cd /
# mkdir -p /global/jesMCSb/ms_data
# mkdir /global/jesMCSb/cs_data
# chmod 777 /global/jesMCSb/ms_data /global/jesMCSb/cs_data
# mount /global/jesMCSb/ms_data
# mount /global/jesMCSb/cs_data- Create a cluster resource group. The resource group must be associated with a virtual host name and IP address and then brought on line.
- Create a resource group called IMS-RG and make it visible on jesMCS1b and jesMCS2b.
# cd /usr/cluster/bin
# ./scrgadm -a -g IMS-RG -h jesMCS1b jesMCS2b- Identify the resource group with a virtual host name.
# ./scrgadm -a -L -g IMS-RG -l jesMCSb
- Bring the resource group online.
# ./scswitch -Z -g IMS-RG
- Test failover of the cluster resource group.
Procedure, Part B: Install and Configure Messaging Server and Calendar Server
- Disable the Solaris sendmail service on jesMCS1b.
The Solaris sendmail service is a message transfer agent that listens on port 25, the standard SMTP port (see Table 5-3). If not disabled, sendmail would conflict with Messaging Server’s MTA component. Use the following procedure on the Solaris 10 platform:
- Install Java ES software on jesMCS1b.
Use the Configure Later option of the Java ES installer.
- Select the following components:
- Specify that Administration Server will use a remote Directory Server instance.
- Enter the Messaging Server and Calendar Server installation parameter values shown in the following table:
- Configure Messaging Server.
- Modify the /etc/hosts file on jesMCS1b to include the following entries:
192.168.12.5 jesMCSb.net.telco.com jesMCSb
192.168.11.7 jesMCS1b.net.telco.com jesMCS1b loghost
192.168.11.8 jesMCS2b.net.telco.com jesMCS2b- Run the Messaging Server configuration program.
# cd /global/jesMCSb/ms_data/opt/SUNWmsgsr/sbin
# ./configure -nodisplay- Provide the following parameters requested by the configuration program:
- Set configuration parameters and files to the virtual jesMCSb IP address rather than the physical IP address.
- Run the ha_ip_config script to set configure the dispatcher.cnf and job_controller.cnf files for high availability and to set a number of configutil parameters.
# ./ha_ip_config
Provide the following parameters as requested:
Logical IP address: 192.168.12.5
iMS server root: /global/jesMCSb/ms_data/opt/SUNWmsgsr- Modify two additional configutil parameters by hand:
# cd /global/jesMCSb/ms_data/opt/ms_data/SUNWmsgsr/sbin
# ./configutil -o local.hostname -v jesMCSb.net.telco.com
# ./configutil -o local.servername -v jesMCSb.net.telco.com- Configure Messaging Server to support Access Manager single sign-on.
Set the following Messaging Server configutil parameters to enable support for Access Manager’s cookie-based single sign-on when messaging services are accessed in a web browser.
# cd /global/jesMCSb/ms_data/opt/ms_data/SUNWmsgsr/sbin
# ./configutil -o local.webmail.sso.amnamingurl
-v http://jesPAM.net.telco.com/amserver/namingservice# ./configutil -o local.webmail.sso.amcookiename
-v iPlanetDirectoryPro# ./configutil -o local.webmail.sso.amloglevel -v 5
# ./configutil -o local.webmail.sso.singlesignoff -v 1
- Start the Messaging Server
# cd /global/jesMCSb/ms_data/opt/ms_data/SUNWmsgsr/sbin
# ./start-msg- Verify that Messaging Server is properly configured.
- Start the web browser.
- Connect to http://jesMCSb.net.telco.com. Note that the jesMCSb.net.telco.com virtual service must be configured at this point.
- Log in to mail server as user=admin, password=password.
- Send a test email message to Store.Administrator@telcomail.com.
- Check that a new mail arrives in the inbox.
- Configure Calendar Server.
- Run the Calendar Server configuration program on jesMCS1b.
# cd /global/jesMCSb/cs_data/opt/SUNWics5/cal/sbin
# sh ./csconfigurator.sh -nodisplay- Provide the following parameters requested by the configuration program:
- Set configuration parameters and files to the virtual jesMCSb IP address rather than the physical IP address.
Edit the Calendar Server configuration file, /global/jesMCSb/cs_data/etc/opt/SUNWics5/config/ics.conf, as follows:
- Add the following parameters:
local.server.ha.enabled = "yes"
local.server.ha.agent = "SUNWscics"- Rename the service.listenaddr parameter to service.http.listenaddr and then set the parameter to the IP address of the virtual host:
service.http.listenaddr = 192.168.12.5
- Change all parameters that refer to a local host name to the virtual host name:
local.hostname = "jesMCSb"
local.servername = "jesMCSb"
service.ens.host = "jesMCSb"
service.http.calendarhostname = "jesMCSb"- Configure Calendar Server to support Access Manager single sign-on.
Set the following Calendar Server parameters to enable support for Access Manager’s cookie-based single sign-on when calendar services are accessed in a web browser. Set the following parameters in the /global/jesMCSb/cs_data/etc/opt/SUNWics5/config/ics.cnf file:
local.calendar.sso.amnamingurl=”http://jesPAM.net.telco.com/amserver/namingservice“
local.calendar.sso.amcookiename=iPlanetDirectoryPro
local.calendar.sso.logname=am_sso.log
local.calendar.sso.singlesignoff=true
sso.enable = "0"
service.http.allowadminproxy=”yes”
service.http.ipsecurity=”no”
(Setting sso.enable to 0 turns off Calendar Server’s legacy Trusted Circle single sign-on mechanism and permits Access Manager single sign-on. Setting allowadminproxy and ipsecurity enables the Portal Server SSO adapters to operate.)
- Start the Calendar Server.
# cd /global/jesMCSb/cs_data/opt/SUNWics5/cal/sbin
# ./start-cal- Verify that Calendar Server is properly configured.
- Create a Calendar Server user, user group, and directory on jesMCS2b.net.telco.com.
(The configuration program did this automatically on jesMCS1b.)
# groupadd -g 103 icsgroup
# useradd -u 104 -g 103 -d /home/icsuser icsuser
# cd /home
# mkdir icsuser
# chown icsuser icsuserProcedure, Part C: Configure Sun Cluster Resources
- Install Java ES software on jesMCS1b.
Use the Configure Later option of the Java ES installer.
Select the following components:
- Configure the Messaging Server resource.
- Register the Messaging Server cluster agent.
# cd /usr/cluster/bin/
# ./scrgadm -a -t SUNW.imsSUNW.ims is the Messaging Server cluster agent.
- Create a Messaging Server resource and add it to the cluster resource group.
# ./scrgadm -a -j ims-rs -t SUNW.ims -g IMS-RG \
-x IMS_serverroot=/global/jesMCSb/ms_data/opt/SUNWmsgsr \
-y Resource_dependencies=jesMCSbims-rs is the name of the Messaging Server resource.
- Enable the Messaging Server resource.
# ./scswitch -e -j ims-rs
- Test failover of the Messaging Server resource from jesMCS1b to jesMCS2b.
# ./scswitch -z -g IMS-RG -h jesMCS2b
On jesMCS1b, you see the following messages written to the console:
Connecting to watcher ...
shutting down all servers...
Stopping job_controller server 2468 .... done
Stopping dispatcher server 2464 ... done
Stopping sched server 2462 ... done
Stopping http server 2460 ... done
Stopping pop server 2457 ... done
Stopping imap server 2454 ... done
Stopping store server 2451 .... done
Stopping ens server 2450 .... done
stopping watcher process 2443 ... done
Oct 13 08:25:22 jesMCS1b ip: TCP_IOC_ABORT_CONN: local = 129.148.008.109:0, remote = 000.000.000.000:0, start = -2, end = 6
Oct 13 08:25:22 jesMCS1b ip: TCP_IOC_ABORT_CONN: aborted 2 connectionsOn jesMCS2b, you see the following messages written to the console:
Starting the watcher....
Connecting to watcher ...
Launching watcher ...
Oct 13 08:25:42 jesMCS2B SC[SUNW.ims,IMS-RG,ims-rs,ims_svc_start]: Starting the rest of the messaging services....
Connecting to watcher ...
Starting ens server .... 7950
Starting store server .... 7951
checking store server status ..... ready
Starting imap server ...... 7953
Starting pop server .... 7956
Starting http server .... 7959
Starting sched server .... 7961
Starting dispatcher server .... 7963
Starting job_controller server .... 7969- Configure the Calendar Server resource.
- Register the Calendar Server cluster agent.
# cd /usr/cluster/bin/
# ./scrgadm -a -t SUNW.scicsSUNW.scics is the Calendar Server cluster agent.
- Create a Calendar Server resource and add it to the cluster resource group.
# ./scrgadm -a -j scics-rs -t SUNW.scics -g IMS-RG \
-x Confdir_list=/global/jesMCSb/cs_data \
-y Resource_dependencies=jesMCSb -y Port_list=82/tcpscics-rs is the name of the Calendar Server resource.
- Enable the Calendar Server resource.
# ./scswitch -e -j scics-rs
- Check the status of the Sun Cluster resource group.
# ./scstat
The output from this command is displayed and described in Sample User Provisioning Script.
Module #6 Consumer-class Messaging Server on Sun Cluster Nodes
In this module you set up the Messaging Server instances that support the telco.net email domain for consumer-class users. These instances are installed and configured to run on Sun Cluster nodes. The messaging service thereby becomes a resource managed by the Sun Cluster software. The procedure is similar to the procedure for the business-class messaging and calendar services that is described in Module #5: Business-class Messaging Server and Calendar Server on Sun Cluster Nodes. The procedure is relatively complex, and requires you to run the Java ES installer three times on each computer.
Installation and Configuration Summary
The installation and configuration procedures are divided into three parts. The procedures are summarized as follows:
Part A: Basic Sun Cluster Setup
- Repeat the steps in Procedure, Part A: Set Up Sun Cluster Nodes and Global File System.
Part B: Install and Configure Messaging Server
Part C: Configure Sun Cluster Resources
Procedure, Part A: Set Up Sun Cluster Nodes and Global Filesystem
Setting up Sun Cluster nodes and global filesystems on jesMS1c and jesMS2c is almost identical to the procedure for the business class service.
- Repeat Step 1 through Step 10 in Procedure, Part A: Set Up Sun Cluster Nodes and Global File System on jesMS1c and jesMS2c. Modify the hostnames and other parameter whenever it is necessary.
Procedure, Part B: Install and Configure Messaging Server
- Disable the Solaris sendmail service on jesMS1c.
The Solaris sendmail service is a message transfer agent that listens on port 25, the standard SMTP port. If not disabled, sendmail would conflict with Messaging Server’s MTA component. Use the following procedure on the Solaris 10 platform:
- Install Java ES software on jesMS1c.
Use the Configure Later option of the Java ES installer.
- Select the following components:
- Specify that Administration Server will use a remote Directory Server instance.
- Enter the Messaging Server installation parameter values shown in the following table:
- Configure Messaging Server.
- Modify the /etc/hosts file on jesMS1c to include the following entries:
192.168.12.6 jesMSc.net.telco.com jesMSc
192.168.11.9 jesMS1c.net.telco.com jesMS1c loghost
192.168.11.10 jesMS2c.net.telco.com jesMS2c- Run the Messaging Server configuration program.
# cd /global/jesMSc/ms_data/opt/SUNWmsgsr/sbin
# ./configure -nodisplay- Provide the following parameters requested by the configuration program:
- Set configuration parameters and files to use the virtual service IP address jesMSc rather than the physical IP address.
- Run the ha_ip_config script to set configure the dispatcher.cnf and job_controller.cnf files for high availability and to set a number of configutil parameters.
# ./ha_ip_config
Provide the following parameters as requested:
Logical IP address: 192.168.12.6
iMS server root: /global/jesMSc/ms_data/opt/SUNWmsgsr- Modify two additional configutil parameters by hand:
# cd /global/jesMSc/ms_data/opt/ms_data/SUNWmsgsr/sbin
# ./configutil -o local.hostname -v jesMSc.net.telco.com
# ./configutil -o local.servername -v jesMSc.net.telco.com- Configure Messaging Server to support Access Manager single sign-on.
For Messaging Server to support cookie-based single sign-on by way of Access Manager from a browser, the following configutil parameters need to be set.
# cd /global/jesMSc/ms_data/opt/ms_data/SUNWmsgsr/sbin
# ./configutil -o local.webmail.sso.amnamingurl
-v http://jesPAM.net.telco.com/amserver/namingservice# ./configutil -o local.webmail.sso.amcookiename
-v iPlanetDirectoryPro# ./configutil -o local.webmail.sso.amloglevel -v 5
# ./configutil -o local.webmail.sso.singlesignoff -v 1
- Start the Messaging Server
# cd /global/jesMSc/ms_data/opt/ms_data/SUNWmsgsr/sbin
# ./start-msg- Verify that Messaging Server is properly configured.
Procedure, Part C: Configure Sun Cluster Resources
- Install Java ES software on jesMS1c.
Use the Configure Later option of the Java ES installer.
Select the following components:
- Configure the Messaging Server resource.
- Register the Messaging Server cluster agent:
# cd /usr/cluster/bin/
# ./scrgadm -a -t SUNW.imswhere SUNW.ims is the Messaging Server cluster agent.
- Create a Messaging Server resource and add it to the cluster resource group:
# ./scrgadm -a -j ims-rs -t SUNW.ims -g IMS-RG \
-x IMS_serverroot=/global/jesMSc/ms_data/opt/SUNWmsgsr \
-y Resource_dependencies=jesMScwhere ims-rs is the name of the Messaging Server resource.
- Enable the Messaging Server resource.
# ./scswitch -e -j ims-rs
- Test failover of the Messaging Server resource from jesMS1c to jesMS2c.
# ./scswitch -z -g IMS-RG -h jesMS2c
On jesMS1c, you see the following messages written to the console:
Connecting to watcher ...
shutting down all servers...
Stopping job_controller server 2468 .... done
Stopping dispatcher server 2464 ... done
Stopping sched server 2462 ... done
Stopping http server 2460 ... done
Stopping pop server 2457 ... done
Stopping imap server 2454 ... done
Stopping store server 2451 .... done
Stopping ens server 2450 .... done
stopping watcher process 2443 ... done
Oct 13 08:25:22 jesMS1c ip: TCP_IOC_ABORT_CONN: local = 129.148.008.109:0, remote = 000.000.000.000:0, start = -2, end = 6
Oct 13 08:25:22 jesMS1c ip: TCP_IOC_ABORT_CONN: aborted 2 connectionsOn jesMS2c, you see the following messages written to the console:
Starting the watcher....
Connecting to watcher ...
Launching watcher ...
Oct 13 08:25:42 jesMS2c SC[SUNW.ims,IMS-RG,ims-rs,ims_svc_start]: Starting the rest of the messaging services....
Connecting to watcher ...
Starting ens server .... 7950
Starting store server .... 7951
checking store server status ..... ready
Starting imap server ...... 7953
Starting pop server .... 7956
Starting http server .... 7959
Starting sched server .... 7961
Starting dispatcher server .... 7963
Starting job_controller server .... 7969Module #7 Portal Server Secure Remote Access
In this module you install and configure Portal Server Secure Remote Access. You run the Java ES installer twice on each computer. First you install the Portal Server Secure Remote Access core on jesPAM1 and jesPAM2. Then you install the Portal Server Secure Remote Access gateway on jesSRA1 and jesSRA1. The gateway instances on jesSRA1 and jesSRA2 are load-balanced, and appear to the outside world as a single logical service named jesSRA.
Installation and Configuration Summary
The installation and configuration procedures are summarized as follows:
Procedure
- Install Java ES software on jesPAM1.
Use the Configure Now option of the Java ES installer.
- Select the following components:
- Select the following sub-components of Portal Server Secure Remote Access:
- Enter the configuration parameter values shown in the following table:
- Restart the Web Server on jesPAM1.
# cd /global/jesPAM1/opt/SUNWwbsvr/https-jesPAM1.net.telco.com
# ./stop
# ./start- Repeat Step 1 and Step 2 on jesPAM2.
- Install Java ES software on jesSRA1.
Use the Configure Now option of the Java ES installer. Note that you must run the installer in graphical mode, and not in command line mode (the -nodisplay option) when you install Portal Server Secure Remote Access.
- Select the following components:
- Select the following sub-components of Access Manager:
- Select the following sub-components of Portal Server Secure Remote Access:
- Enter the configuration parameter values shown in the following table:
- Set up the gateway configuration parameters.
- Log in to the Access Manager administration console (amconsole):
http://jesPAM.net.telco.com/amconsole
- In the left pane, under Organizations, click telcomail.com.
- Click Services.
- Click Register SRA Services.
- Select Access List and Net file.
- Click Register.
- Confirm that the following services are selected:
- Click the Services tab.
- In the left pane locate the Gateway Service. Click the arrow that follows the name.
- In the right pane (Gateway Profile), click Default Profile.
- Locate the Portal Servers field. Confirm that only the following are listed:
- Locate the URLs to Which User Session Cookie is Forwarded field. Confirm that only the following are listed:
- Select Enable Cookie Management.
- Click Save.
- Select Platform Service.
- Add telcomail.com to the SRA Cookies Domain. The list should include the following:
- Click Save.
- Edit the gateway configuration file on jesSRA1.
The configuration file is /etc/opt/SUNWps/platform.conf.default.
- Modify the following line:
gateway.virtualhost=jesSRA.net.telco.com 192.168.14.4 www.telcomail.com
This enables the load balancer URL www.telcomail.com at 192.168.14.4.
- Add the following line:
gateway.ignoreServerList=true
- Make certain that all entries in platform.conf.default for the portal specify the load balancer’s URL or IP address. For example:
gateway.dsame.agent=http\://jesPAM.net.telco.com\:80/portal/RemoteConfigServlet
portal.server.host=jesPAM.net.telco.com
- Restart the portal server instances on jesPAM1.
# cd /global/jesPAM1/opt/SUNWwbsvr/https-jesPAM1.net.telco.com
# ./stop
# ./start- Start the gateway on jesSRA1.
# cd /global/jesSRA1/opt/SUNWps/bin
# ./gateway -n default stop
# ./gatway -n default start- Verify that the gateway is operating correctly.
- Configure the jesSRA load balancer. For more information, see Configuring the Load Balancers.
- In your web browser, open https://www.telcomail.com.
- Log in as buser0001 (the password is password).
If you succeed, the gateway is operating correctly.
Module #8 Delegated Administrator Console on Web Server
In this module you install and configure the Delegated Administrator console. The Delegated Administrator console must be installed with a web container. The Delegated Administrator console also has a dependency on the Access Manager SDK.
This procedure requires you to run the Java ES installer twice. First, you install Access Manager SDK and Web Server on jesADM. Next, you install the Delegated Administrator console. To complete the procedure, you run the Delegated Administrator configuration program.
Installation and Configuration Summary
The installation and configuration procedures are summarized as follows:
Procedure
- Install Java ES software on jesADM.
Use the Configure Now option of the Java ES installer.
- Select the following components:
- Select the following sub-components of Access Manager:
- Enter the configuration parameter values shown in the following table:
- Start Web Server on jesADM.
# cd /global/jesADM/opt/SUNWwebsvr/https-jesADM.net.telco.com
# ./stop
# ./start- Install Java ES software on jesADM.
Use the Configure Later option of the Java ES installer.
- Configure Delegated Administrator on jesADM.
- Run the Delegated Administrator configuration program:
# cd /global/jesADM/opt/SUNWcomm/sbin
# ./config-commda -nodisplay- Enter the configuration parameter values shown in the following table:
- Restart Web Server on jesADM.
# cd /global/jesADM/opt/SUNWwebsvr/https-jesADM.net.telco.com
# ./stop
# ./start- Verify that Delegated Administrator is operating properly.
Module #9: Load Balanced Messaging Server MTA (Inbound and Outbound)
In this module you install and configure the Messaging Server MTA instances that function as the inbound message relay and outbound message relay. You do not perform any special configuration for these instances to operate correctly with the load balancer. You simply configure the load balancer. For more information, see Configuring the Load Balancers.
The installation and configuration procedures for the MTA inbound and MTA outbound instances are very similar. The one notable difference is that the MTA inbound is configured to interact with the back-end MTA using LMTP protocols, rather than SMTP protocols, while the MTA outbound does not interact with the back-end MTA, and is therefore not configured to use LMTP.
This module is divided into two separate parts. Part A describes installing and configuring the MTA inbound instances. Part B describes installing and configuring the MTA outbound instances.
Installation and Configuration Summary
Part A: Messaging Server MTA Inbound
Part B: Messaging Server MTA Outbound
Procedure, Part A: Messaging Server-MTA Inbound
- Disable the Solaris sendmail service on jesIMR1.
The Solaris sendmail service is a message transfer agent that listens on port 25, the standard SMTP port. If not disabled, sendmail would conflict with the Messaging Server MTA component.
Use the following procedure on the Solaris 10 platform.
- Install Java ES software on jesIMR1.
Use the Configure Later option of the Java ES installer.
- Configure Messaging Server MTA.
- Modify the /etc/hosts file on jesIMR1 to include the following entries:
192.168.14.5 smtp.telcomail.com
192.168.14.9 smtp.telco.net
192.168.13.3 jesIMR1.net.telco.com jesIMR1 loghost
192.168.13.4 jesIMR2.net.telco.com jesIMR2- Run the Messaging Server configuration program.
# cd /global/jesIMR1/opt/SUNWmsgsr/sbin
# ./configure -nodisplay- Provide the following parameters requested by the configuration program:
- Enable the LMTP protocol.
LMTP is a protocol used by Messaging Server MTA components to interact with each other. In the Telco architecture, LMTP is used for communication between the MTA component on jesIMR1 and the MTA component on the back-end messaging stores jesMCSb and jesMSc.
LMPT is lighter and more efficient than the SMTP protocol. Using LMTP eliminates a second user authentication on the backend messaging server where the store is located.
Procedures for enabling LMTP are provided in Enabling LMTP for Messaging Server MTA Interactions.
- Start the Messaging Server MTA on jesIMR1.
# cd /global/jesIMR1/opt/SUNWmsgsr/sbin
# ./start-msg- Verify the operation of Messaging Server MTA.
Operation is verified by opening a telnet session to Messaging Server MTA and then using SMTP to conduct an interactive exchange with the MTA.
- Open a telnet session.
# telnet jesIMR1.net.telco.com 25
Trying 192.168.13.3...
Connected to jesIMR1.
Escape character is ‘^]’
220 jesIMR1.net.telco.com -- Server ESMTP (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))- Conduct conversation with the MTA.
hello jesIMR1
250 jesIMR1.net.telco.com OK, [192.168.13.3].
mail from: <buser0001@telcomail.com>
250 2.5.0 Address Ok.rcpt to: <buser0002@telcomail.com>
250 2.1.5 buser0002@example.com OK.data
354 Enter mail, end with a single ".".
subject:test
test smtp from buser0001 to buser0002
.
250 2.5.0 Ok.quit
221 2.3.0 Bye received. Goodbye.
Connection to jesIMR1 closed by foreign host.- Verify load balancing for Messaging Server MTA inbound.
Having verified that Messaging Server MTA instances are working on jesIMR1 and jesIMR2, you now verify that you can access these instances through the load balancer.
- Turn off the jesIMR2 instance and access the service through the load balancer:
# cd /global/jesIMR2/opt/SUNWmsgsr/sbin
# ./stop-msg
# telnet smtp.telcomail.com 25If this test succeeds then the jesIMR1 instance is working through the load balancer.
- Turn off the jesIMR1 instance and turn on the jesIMR2 instance, and test this condition:
# cd /global/jesIMR1/opt/SUNWmsgsr/sbin
# ./stop-msg
# cd /global/jesIMR2/opt/SUNWmsgsr/sbin
# ./start-msg
# telnet smtp.telcomail.com 25If this test works properly then the jesIMR2 instance is also working through the load balancer.
Procedure, Part B: Messaging Server MTA Outbound
The installation and configuration of Messaging Server MTA outbound is almost identical to that of Messaging Server MTA in bound. The differences are as follows:
- Install and configure the Messaging Server Message Transfer Agent software on jesOMR1.
Repeat Part A, Step 1 - Step 5. Skip Step 4; you do not enable LMTP for the MTA outbound component.
- Install and configure the Messaging Server Message Transfer Agent software on jesOMR2.
Repeat Part A, Step 1 - Step 5. Skip Step 4; you do not enable LMTP for the MTA outbound component.
- Verify load balancing for Messaging Server MTA outbound.
Repeat Part A, Step 6.
Module #10: Load Balanced Messaging Server MMP and MEM
In this module you install and configure Messaging Server MMP and MEM instances. You do not perform any special configuration for these instances to operate correctly with the load balancer. You simply configure the load balancer. For more information, see Configuring the Load Balancers.
The installation and configuration procedure for Messaging Server MMP and MEM is very similar to the procedure for Messaging Server MTA.
Installation and Configuration Summary
Procedure
- Install Java ES software on jesMMP1.
Use the Configure Later option of the Java ES installer.
- Configure Messaging Server on jesMMP1.
- Modify the /etc/hosts file on jesMMP1 to include the following entries:
192.168.13.7 jesMMP1.net.telco.com jesMMP1 loghost
192.168.13.8 jesMMP2.net.telco.com jesMMP2
192.168.14.3 mail.telcomail.com
192.168.14.7 mail.telco.net
192.168.14.8 www.telco.net- Run the Messaging Server configuration program.
# cd /global/jesMMP1/opt/SUNWmsgsr/sbin
# ./configure -nodisplay- Provide the following parameters requested by the configuration program:
- Modify the configuration parameters for Messaging Server (MEM) so that it runs mshttp in proxy mode:
# cd /global/jesMMP1/opt/SUNWmsgsr/sbin
# ./configutil -o local.service.http.proxy -v 1
# ./configutil -o local.service.http.proxy.admin
-v admin_telco.net
# ./configutil -o local.service.http.proxy.adminpass -v password- Start the Messaging Server MMP and MEM on jesMMP1.
# cd /global/jesMMP1/opt/SUNWmsgsr/sbin
# ./start-msg- Verify the operation of Messaging Server jesMMP1.
Operation is verified by opening a telnet session to Messaging Server MMP and then using IMAP to conduct an interactive exchange with the MMP.
- Open a telnet session.
# telnet jesMMP1.net.telco.com 143
Trying 192.168.13.7...
Connected to jesMMP1.net.telco.com.
Escape character is ‘^]’
OK [CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ NAMESPACE UIDPLUS CHILDREN BINARY LANGUAGE XSENDER X-NETSCAPE XSERVERINFO AUTH=PLAIN] Messaging Multiplexor (Sun Java(tm) System Messaging Server 6.2-3.04 (built Jul 15 2005))- Conduct a conversation with the MMP.
a001 login buser0001 password
a001 OK User logged in
a002 noop
a002 OK Completed
a003 Capability
* CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ NAMESPACE UIDPLUS CHILDREN BINARY LANGUAGE XSENDER X-NETSCAPE XSERVERINFO
a003 OK Completed
a004 list "" *
* LIST (\NoInferiors) "/" INBOX
* LIST (\HasNoChildren) "/" Drafts
* LIST (\HasNoChildren) "/" Sent
* LIST (\HasNoChildren) "/" Trash
* LIST (\HasNoChildren) "/" new
a004 OK Completed
a005 select inbox
* FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
* OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \ Seen \*)]
* 1 EXISTS
* 0 RECENT
* OK [UNSEEN 1]
* OK [UIDVALIDITY 1103021473]
* OK [UIDNEXT 2]
a005 OK [READ-WRITE] Completeda006 fetch 1 (body[1] rfc822.size)
* 1 FETCH (FLAGS (\Seen) RFC822.SIZE 989 BODY[1] {52}
buser0002@telcomail.com to buser0001@telcomail.com
)
a006 OK Completed
a007 logout
* BYE LOGOUT received
a007 OK Completed
Connection to jesMMP1 closed by foreign host.- Verify load balancing for Messaging Server MMP.
Having verified that Messaging Server MMP is working on jesMMP1 and jesMMP2, you test access to these instances through the load balancer.
- Turn off the jesMMP2 instance and access the service through the load balancer:
# telnet mail.telcomail.com 143
If this test works properly then the jesMMP1 instance is working through the load balancer.
- Turn off the jesMMP1 instance and turn on the jesMMP2 instance, and retest:
# telnet mail.telconail.com 143
If this test works properly then the jesMMP2 instance is also working through the load balancer.
- Verify load balancing for Messenger Express MEM.
- Verify that the Messenger Express HTTP service is running on jesMMP1.
In your web browser open the following URL:
http://jesMMP1.net.telco.com
Then log in as user cuser0001@telco.net. The password is password.
- Verify that the Messenger Express HTTP service is running on jesMMP2.
In your web browser open the following URL:
http://jesMMP1.net.telco.com
Log in as user cuser0001@telco.net. The password is password.
- Verify that load balancing is working for the public consumer class HTTP service.
In your web browser open the following URL:
http://www.telco.net
Log in as user cuser0001@telco.net. The password is password.