ePeople Teamwork

ePeople Teamwork™ System AdministrationGuide

Version 6.0

ePeople

2 ePeople

Copyright © 1999 - 2004 ePeople, Inc. All rights reserved. ePeople and ePeople Teamwork are trademarks of ePeople, Inc. All other trademarks are the property of their respective owners.

Revision Date: December 2004

ePeople, Inc.

450 National AvenueMountain View, CA 94043

3ePeople

Contents

System Administration Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1About this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

What is ePeople Teamwork? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Recommended configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Low-cost configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3High-availability configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Load balancer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5WebLogic clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5RAID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Database clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

System architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Web layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Application layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Database layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8WebLogic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Ancillary services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Exim and Pop3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Verity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10ChartWorks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10GAIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Directory structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10System accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Deployment process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Network setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Load balancer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13DNS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Database architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Starting/stopping ePeople Teamwork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Running startCluster.pl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15What happens after running startCluster.pl? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Running teamworkctl.pl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Stopping and starting Apache using teamworkctl.pl . . . . . . . . . . . . . . . . . . . . . . . 17Stopping and starting the WebLogic Managed server using teamworkctl.pl . . . 18Stopping and starting ChartWorks using teamworkctl.pl . . . . . . . . . . . . . . . . . . . 19

Starting and stopping ancillary services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Exim/Pop3 (Email) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Verity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21GAIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

ePeople

4 ePeople

Best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22System backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Operating system backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Oracle backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Verity backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Periodic maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Log rotation and clean up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

WebLogic log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Apache log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Verity request indexing and optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Exim maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25GAIM maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Resetting account passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

exim account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26epeople account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26teamwork account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26database user account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Application monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Service monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Exim/Pop3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Verity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28ChartWorks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28GAIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

System monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Network monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Database administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

1ePeople

System Administration Guide

About this document

The purpose of this document is to provide assistance to personnel maintaining the servers, network equipment, and database associated with ePeople Teamwork. This document explains the different services that comprise ePeople Teamwork. It provides general information on the architecture, maintenance, monitoring, database, and troubleshooting of ePeople Teamwork.

The primary audience for this guide is UNIX system administrators, network administrators, and database administrators responsible for maintaining ePeople Teamwork.

Prerequisites

You should be familiar with the following prior to reading this document:

• UNIX/Linux system administration

• TCP/IP networking

• Oracle database administration

• BEA WebLogic

• Apache Web server

• Security

Conventions

This book uses the following typograhic conventions:

What is ePeople Teamwork?

ePeople is a leading provider of business email management solutions for high-value customer relationships in Life Sciences, High Technology, and Engineer-to-order industries. ePeople’s solutions for clinical trial management, collaborative support and team selling, streamline complex processes that demand close coordination of experts, best practices, and knowledge. ePeople solutions are

Italics Glossary terms

Emphasis

Courier Names of Java programming elements, including: object names, method names

Code, in general

Boldface Names of files, directory paths

Emphasis

ePeople

2 ePeople

designed for rapid adoption and integrate with Microsoft® Outlook, Customer Relationship Management (CRM), email, Instant Messenging (IM), and the Web. ePeople customers, including companies such as Cisco Systems, Pria Diagnostics, Cognos, Network Appliance, InstallShield, and Openwave Systems, enjoy significant gains in productivity, responsiveness, and service quality.

Recommended configurations

ePeople recommends that you generally use one of the following two configurations for running ePeople Teamwork:

• Low-cost configuration

– One application server

– Staging server

– One database server

– No load balancer

• High-availability configuration

– Two application servers (Application Server 1 and Application Server 2)

– Staging server

– One database server

– Load balancer

Note Redundant Array of Independent Disks (RAID) technology should be employed on the database server to protect against data loss. Clustering of the database servers can also be used to increase overall reliability.

3ePeople

Low-cost configuration

The following diagram illustrates the low-cost configuration option.

Figure 1: Low-cost configuration

ePeople

4 ePeople

High-availability configuration

The following diagram illustrates the high-availability configuration option.

Figure 2: High-availability configuration

In this configuration, ePeople Teamwork has additional components that allow for increased reliability, scalability, and performance. The high-availability solution has the following additional components:

• Load balancer

• WebLogic clustering

• RAID

• Database clustering

5ePeople

Load balancer

The load balancer provides load sharing, server failover, and session persistence. The load balancer shares traffic between application servers based on pre-set metrics. This ensures that traffic is divided between the available application servers thus increasing overall performance and allowing increased scalability. The load balancer also provides a mechanism for detecting the failure of a given application server, and for redirecting server traffic to an available server. Finally, the load balancer maintains session persistence to a given application server. Ideally, you should use a redundant pair of load balancers.

WebLogic clustering

WebLogic clustering allows for synchronization of session information between application servers. This enables users to be migrated gracefully from one application server to the other without losing the users’ current state.

This combination of WebLogic clustering and a load balancer allow for transparent failover between application servers. This configuration allows application updates to be deployed while the system is running. Load balancing and WebLogic clustering are complimentary services that are required components of a high-availability configuration. The load balancer handles the directing of traffic while WebLogic clustering handles the synchronization of session information.

RAID

RAID provides a mechanism for mirroring and striping data across disks. It should be used on the database to prevent losing critical data. RAID can also be used to increase database disk performance, but its primary function is to prevent the critical loss of data.

Database clustering

For additional redundancy at the database level, a second database server can be added. This secondary server shares the disk subsystem with the primary server in an active/standby configuration. In the event of a failure of the primary server, the secondary server “imports” the hard disks and starts Oracle.

The redundant database server is optional in the high-availability configuration. If you do not have a redundant database server, any significant database failure or maintenance will cause an outage to your application. While the redundant server will not completely eliminate the outage, it can greatly reduce down time.

System architecture

ePeople Teamwork employs a multi-tier architecture consisting of the following three layers:

• Web layer

• Application layer

• Database layer

ePeople

6 ePeople

The Web layer and the application layer reside on the same physical server.

Web layer

The Web layer is serviced by Apache. This layer handles both HTTP and HTTPS traffic. It serves both static content and images, and it also proxies dynamic requests to the application layer.

Application layer

The application layer is handled by WebLogic. The application layer is the core of ePeople Teamwork. It runs all dynamic content, manages the interface to the database, provides replication between application servers, and maintains user sessions.

Database layer

Oracle handles the database layer. The database layer is the main data repository for user session data and application data.

The following diagram illustrates the ePeople Teamwork system architecture for a high-availability configuration.

Note The staging server is not included in the diagram.

7ePeople

Figure 3: ePeople Teamwork system architecture - High availability

ePeople

8 ePeople

Figure 3 displays the components of ePeople Teamwork. At the top of the diagram, you have the load balancer that handles HTTP/HTTPS traffic from the client. The load balancer forwards traffic to the two application servers, Application Server 1 and Application Server 2. Application Server 1 and Application Server 2 contain both the Web layer and the application layer.

The Web layer is handled by Apache, while the application layer is handled by the WebLogic Managed server. WebLogic also has an additional process, the WebLogic Admin Server that handles dissemination of WebLogic configuration to each of the WebLogic Managed servers in the cluster.

The WebLogic Administration Server only runs on one machine in the cluster. For our example, this machine is Application Server 1. Application Server 2 also runs a set of other services that provide additional functions to ePeople Teamwork. These services include:

• Exim/Pop3 (Email)

• Verity (Search)

• ChartWorks (Charting)

• GAIM (Instant Messaging)

The final component of the diagram is the Oracle database. For more information about the Oracle database architecture, see Database architecture on page 14.

Services

There are three core services used by ePeople Teamwork:

• Apache

• WebLogic

• Oracle

Besides these core services, there are several ancillary services providing specialized features associated with the application. These services include:

• Exim

• Pop3

• Verity

• ChartWorks

• GAIM

Apache

Apache is responsible for processing HTTP/HTTPS requests, serving static pages, and acting as an interface to the WebLogic Managed server for dynamic content. Apache listens on both TCP ports 80 and 443 and can be identified in the process table as httpd.

Note While Apache listens on both TCP ports 80 and 443, the Secure Sockets Layer (SSL) session from the client is terminated on the load balancer in the high-availability configuration. This allows the load balancer to inspect the HTTP contents when making forwarding decisions. The load

9ePeople

balancer then creates a second SSL session between itself and the application server. This allows the traffic to be encrypted all the way to the application server.

WebLogic

WebLogic handles most of the processing of the site and runs the dynamic content. WebLogic is divided into two components:

• The WebLogic Managed server runs the applications’ dynamic content and manages connections to the database.

• The Admin server which is responsible for clustering the application servers and the synchronization of session information.

The WebLogic Managed server processes run on both of the application servers. The WebLogic Admin server process runs only on one of the application servers in the cluster.

Oracle

Both of the WebLogic Managed Servers maintain a pool of connections to an Oracle database. This Oracle database maintains a set of data structures associated with ePeople Teamwork. The Oracle connections are created on the standard SQL port (TCP 1521).

Ancillary services

Besides Oracle, WebLogic, and Apache, there are several ancillary services running on Application Server 2 (the application server that does not run the WebLogic Admin Server). These services include:

• Exim (Email)

• Pop3 (Email)

• Verity (Search)

• ChartWorks (Charts)

• GAIM (Instant Messaging)

Exim and Pop3

Exim is used to:

• Send notification updates

• Receive incoming messages if the Resolve Anywhere feature is enabled

Incoming mail messages received by Exim are delivered to the teamwork mailbox. Mail is retrieved from the teamwork mailbox by ePeople Teamwork using the Pop3 facility. The Pop3 server is configured to use the maildir format for improved email processing performance.

ePeople

10 ePeople

Verity

Verity is responsible for handling search services in ePeople Teamwork. Verity is a separate application that can index both request data and external content. Verity can reside on a separate UNIX server, or it can be co-resident on an Application Server. ePeople Teamwork communicates with Verity on TCP port 8991. It uses this TCP port to perform search queries and to obtain search results.

Besides this TCP/IP connection between ePeople Teamwork and Verity, there is also a Verity NFS mount. This NFS mount provides Verity access to request data from ePeople Teamwork. The Application Server running Verity (Application Server 2) contains the /usr/local/teamwork/verity directory. This directory is NFS mounted by Application Server 1. If you run Verity on a separate server, then both Application Servers would NFS mount the /usr/local/teamwork/verity directory. ePeople Teamwork then exports its request data as an .xml file to this NFS mount (or in the case of Application Server 2, to its local directory). Verity then adds this data to its collection and indexes it.

ChartWorks

ChartWorks is the service responsible for providing graphical rendering of certain reports inside of ePeople Teamwork. It runs as three separate processes on Application Server 2. ePeople Teamwork communicates with ChartWorks using TCP/IP on port 8001.

Note ChartWorks is an optional software package. If you decide not to purchase ChartWorks, you can still generate reports, but without any associated charts.

GAIM

The GAIM service provides outbound instant messaging notifications from ePeople Teamwork to AOL. ePeople Teamwork communicates with GAIM on TCP/IP port 7080.

Note GAIM is an optional service.

Directory structure

ePeople Teamwork has two main base directories:

• /usr/local/teamwork/Teamwork5.4 – contains ePeople Teamwork static and dynamic content

• /usr/local/teamwork – contains all of the services associated with running ePeople Teamwork

The /usr/local/teamwork directory contains the following subdirectories:

• apache

• bea

• java

• cws (ChartWorks) - optional

• exim

11ePeople

• verity

• veritybin

• gaim - optional

Each of these subdirectories contains configuration information, executables, and/or libraries.

System accounts

ePeople Teamwork has three system accounts:

• epeople – Main account for ePeople Teamwork. The epeople user runs Apache, WebLogic, and ChartWorks.

• teamwork – Pop3 email account.

• exim – runs Exim email server.

Important The User ID (UID)/Group ID (GID) of the epeople account must be the same between the different application servers. This is required to ensure there are no permission problems using the Verity NFS mount. If Verity is set up on a separate server, the UID/GID of the epeople account on the Verity server should match the UID/GID of the epeople account on both of the application servers.

Table 1: Key directories

Directory Location Directory Contents

/usr/local/teamwork/apache/conf Apache configuration files

/usr/local/teamwork/apache/logs Apache log files

/usr/local/teamwork/bea/logs WebLogic log files

/usr/local/teamwork/exim Exim configuration file (Application Server 2 only)

/usr/local/teamwork/exim/spool/log Exim log file (Application Server 2 only)

/usr/local/teamwork/gaim IM configuration file (Application Server 2 only)

/usr/local/teamwork/verity Verity collection

/usr/local/teamwork/Teamwork5.4 Application content

/home/teamwork/Maildir ePeople Teamwork mail directory

ePeople

12 ePeople

Deployment process

A standard ePeople Teamwork environment consists of two Production Application Servers and one Staging Application Server. The Staging Server allows new code updates to be tested before being deployed to production. The Staging Server also allows configuration changes to ePeople Teamwork to be tested before being migrated to production. See the ePeople Teamwork Configuration Guide for more information about migrating between environments.

After new code has been tested on your Staging Server, it can be deployed to the production environment.

To deploy new code to production:

1. Login to your Staging Application Server as the epeople user.

2. cd to /usr/local/teamwork/utils.

Note Depending on your setup, running the startCluster.pl script will cause a short outage to your application.

3. Deploy the code using the following command:

./startCluster.pl -local -nof5 -nomail prod

4. After the deployment is complete, verify that each of the application servers is correctly running ePeople Teamwork.

Network setup

There are three components to the network setup for the ePeople Teamwork application:

• Firewall

• Load balancer

• DNS

Firewall

Note Firewalls and security are complex topics with many interdependencies, context-specific requirements, and ever changing risks. While ePeople provides general guidance on services required by ePeople Teamwork, the security of your network and computers is the responsibility of your policy, practices, and company employees.

The firewall requirements for ePeople Teamwork depend on the usage model employed. For example, if the application is accessed from the Internet, certain ports will need to be opened in your firewall to allow this access. Also, depending on the strictness of your company security policies and the confidentiality requirements of your information, you can isolate internal users from the application servers, and you can also isolate the database server from the application servers.

In most environments, ePeople Teamwork will reside behind your company's firewall; there won’t be a separate dedicated firewall. Certain ports will need to be opened through this firewall to allow Internet access to the application. These

13ePeople

ports are TCP port 80 (HTTP), TCP port 443 (HTTPS), and TCP port 25 (SMTP). No other inbound services are required, nor should any other inbound services be permitted. It is assumed that outbound TCP sessions are allowed via a TCP-established rule of some form.

In higher security environments, ePeople Teamwork can be isolated from internal users as well as from the Internet; furthermore, the application servers can be isolated from the database. This isolation can be accomplished by placing a multiport firewall in front of the application servers and between the application servers and the database. In this setup, users (both internal and external) can only access HTTP, HTTPS, and SMTP. A separate connection is allowed from the application servers to the database server on TCP port 1521 (SQL). You will also probably need to add certain services to the firewall ruleset for administration purposes (for example, SSH).

Load balancer

A load balancer is required only if you are running ePeople Teamwork with more than one application server.

The load balancer can be an existing piece of equipment that is shared with other applications or a separate device dedicated to ePeople Teamwork.

The load balancer supports three main functions:

• Load balancing – divides traffic between the available application servers in your application cluster, providing a division of the overall load and increasing reliability

• Persistence – ensures that a given session is returned to the server that previously handled the request

• Failover – detects a server or service failure and redirects traffic to an available server

To handle these functions, the load balancer should have the following capabilities:

• Load balance HTTP/HTTPS content between application servers

• Terminate SSL traffic

• Load balance on the basis of HTTP cookies

• Monitor TCP ports and detect failure conditions

The second and third capabilities allow for persistence on the basis of HTTP cookies. HTTP cookie persistence provides a better distribution of traffic between the application servers in the cluster.

Note You can use source-IP based persistence instead of HTTP-cookie persistence. This eliminates the need for terminating the SSL on the load balancer. This method of persistence, however, does not divide traffic evenly. Many users can appear to come from one source-IP address due to either proxy servers or Network Address Translation (NAT). These users will all be bound to the same application server. This can result in a large number of users getting bound to one server while another server(s) is relatively idle. To avoid this problem, terminate SSL on your load balancer and use HTTP cookie persistence.

ePeople

14 ePeople

DNS

ePeople Teamwork requires certain DNS entries in order to operate. You must have a DNS entry for your installation name.

For example, if your installation URL is the following:

http://teamwork.company.com

You must add teamwork.company.com into your DNS. This name should map to the virtual IP address on your load balancer, or to your application server if you are running only a single application server.

Similarly, you will also need a DNS entry for your staging environment. In this example, you would use the following entry:

teamwork.staging.company.com

This entry maps to the IP address of your staging server, or possibly to a virtual IP address on your load balancer depending on your setup.

Besides the DNS entries required for your installations, you will also need a DNS entry for data migrations. Data migration is the process of transferring configuration data from your staging environment to your production environment. The required DNS entry for data migrations is

migration.company.com

The name should map to the IP address of one of your production application servers.

Finally, if you are using the Resolve Anywhere feature, you will need to add Mail Exchange (MX) records. The MX record for production email should map to the application server running Exim and Pop3 (Application Server 2). The MX record for staging email maps to the Staging Application Server. MX records are associated with the installation name. In our example, you would add a MX record for teamwork.company.com and for teamwork.staging.company.com.

For additional reliability, you should add a backup email server as a secondary MX for your production email.

Note Care needs to be taken when adding DNS entries if you are employing Network Address Translation (NAT). In this case, you would have different records in your external DNS servers, then you would have in your internal DNS servers.

Database architecture

The ePeople Teamwork application uses an Oracle 9i R2 Standard Edition database. This database has one application user. The tablespaces for user objects are locally managed with uniform allocation. Furthermore, for better space and extent management, objects have been placed in tablespaces with an appropriate uniform allocation size based on the growth rate of objects. Separate tablespaces have been created for index and Large Object (LOB) data. Due to the potential rapid growth of attachments, there is a tablespace set aside specifically to store file attachments. The undo management is automatic.

15ePeople

Care should be taken to minimize I/O contention based on Oracle's recommendations. This includes, but is not limited to, the specifics of the RAID configuration.

Starting/stopping ePeople Teamwork

There are two methods to start and stop ePeople Teamwork:

• Automatic method using startCluster.pl

The startCluster.pl utility performs a full rolling restart of ePeople Teamwork. startCluster.pl restarts ePeople Teamwork on each of the application servers in the cluster, one at a time. startCluster.pl can be used to both start and re-start ePeople Teamwork.

Note You must run startCluster.pl from the staging server.

• Manual method using teamworkctl.pl

The teamworkctl.pl utility allows you to manually start/stop services (Apache, WebLogic, and/or ChartWorks) on a given application server.

Note Depending on your network configuration, starting/stopping ePeople Teamwork could result in a short down time for your site. To minimize the down time, use the recommended high-availability set up.

Running startCluster.pl

Use the startCluster.pl utility when you want to fully start ePeople Teamwork, for example, under the following circumstances:

• After a restart of both application servers

• When you want to fully restart the ePeople Teamwork application

• When you are deploying new code

To run the startCluster.pl utility:

1. Using the ssh command, login to the staging server as user epeople.


3. Run the following command if you’re not deploying new code:

./startCluster.pl -local -nof5 -nomail -nodeploy prod

This command allows you to fully start the cluster or to fully restart the cluster.

To deploy new code:

Run the following command:

./startCluster.pl -local -nof5 -nomail prod

ePeople

16 ePeople

What happens after running startCluster.pl?

After running startCluster.pl, the following occurs if you’re running in -nodeploy mode:

Application Server 1

1. Apache is shut down.

2. WebLogic Managed server is shut down.

3. WebLogic Managed server is started.

4. Apache is started.

Application Server 2

1. Apache is shut down.

2. WebLogic Managed server is shut down.

3. ChartWorks server is shut down (if applicable).

4. ChartWorks server is started (if applicable).

5. WebLogic Managed server is started.

6. Apache is started.

Running teamworkctl.pl

Use the teamworkctl.pl utility when you want to start and stop individual services (Apache, WebLogic, or ChartWorks) on a given server.

To run teamworkctl.pl:

1. Using the ssh command, login as user epeople on the server that you want to change.


3. Run ./teamworkctl.pl.

After running teamworkctl.pl, a text menu similar to the following displays:

Enter the number of the area you wish to administer and hit enter:

a. Apache Menuc. ChartWorks Menuw. WebLogic Menu

d. siteDown (site maintenance)u. siteUp (normal website)r. Restart WebLogic and Apache

q. Quit this tool

The choice is yours --->

17ePeople

Generally, if a given application server is having problems, you will want to restart the WebLogic Managed Server on this server. However, in order for your load balancer to detect the application server as non-functional, you will also need to stop Apache on this server. Consequently when restarting ePeople Teamwork on a given application server, you generally want to do the following.

1. Stop Apache.

2. Stop WebLogic Managed server.

3. Start WebLogic Managed server.

4. Start Apache.

Using these steps ensures that traffic from clients is no longer forwarded by your load balancer to the given application server.

Note WebLogic and Apache do not restart on boot. For example, you may need to restart Apache or WebLogic after a power outage. You can start WebLogic and Apache using either the startCluster.pl or teamworkctl.pl utilities as previously discussed.

Stopping and starting Apache using teamworkctl.pl

To stop and restart Apache:




q. Quit this tool


1. Select menu option a to go to the Apache sub-menu.

The choice is yours ---> aEnter the number of the action you wish to perform and hit enter:

1. Start Apache (with SSL)2. Stop Apache3. Restart Apache4. Sitedown (Maintenance)5. Siteup (Production)

m. Go to Main Menuq. Quit this tool

2. Stop Apache by choosing menu option 2.

The choice is yours ---> 2teamworkctl.pl: Stopping Apache on linux.../usr/local/teamwork/apache/bin/apachectl stop: httpd stoppedEnter the number of the action you wish to perform and hit enter:

ePeople

18 ePeople

1. Start Apache (with SSL)2. Stop Apache3. Restart Apache

4. Sitedown (Maintenance)5. Siteup (Production)


3. Start Apache by choosing menu option 1.

The choice is yours ---> 1teamworkctl.pl: Starting Apache on linux.../usr/local/teamwork/apache/bin/apachectl startssl: httpd startedEnter the number of the action you wish to perform and hit enter:

1. Start Apache (with SSL)2. Stop Apache3. Restart Apache4. Sitedown (Maintenance)5. Siteup (Production)



Stopping and starting the WebLogic Managed server using teamworkctl.pl

To restart the WebLogic Managed server on a given application server (either application server 1 or application server 2), select the w menu option.

The following sub-menu displays:

The choice is yours ---> w

Enter the number of the action you wish to perform and hit enter:

2. Stop Admin Server3. Restart Admin Server

b. Stop Managed Serverc. Restart Managed Server



Important When restarting the Managed server, stop the Managed server first, and restart it again after it is completely shut down. Select menu option b, and after the Managed server is completely shut down, select menu option a to restart the Managed server.

Note The example shows a server running both an admin server and a Managed server.

19ePeople

The choice is yours ---> bShutdown initiatedThe shutdown sequence has been initiated.teamworkctl.pl: WebLogic has started to shutdown.



a. Start Managed Server


The choice is yours ---> ateamworkctl.pl: Starting WebLogic Managed server...teamworkctl.pl: WebLogic started successfully.teamworkctl.pl: WebLogic Managed server started successfully.



b. Stop Managed Serverc. Restart Managed Server


Stopping and starting ChartWorks using teamworkctl.pl

Note ChartWorks is an optional service. If present, it will run on only one server.

Use the teamworkctl.pl utility to stop and start ChartWorks.

To stop and start ChartWorks:

1. Using the ssh command, login to the application server you want to stop and start.

2. Login as user epeople.


4. Run ./teamworkctl.pl.

After running teamworkctl.pl, a text menu similar to the following displays:




ePeople

20 ePeople

q. Quit this tool


1. Select menu option h to go to the ChartWorks sub-menu.

The choice is yours --->cEnter the number of the action you wish to perform and hit enter:

1. Start ChartWorks2. Stop ChartWorks3. Restart ChartWorks



2. Stop ChartWorks by choosing menu option 2.

The choice is yours --->2Enter the number of the action you wish to perform and hit enter:




3. Start ChartWorks by choosing menu option 1.

The choice is yours --->1Enter the number of the action you wish to perform and hit enter:




Starting and stopping ancillary services

Besides Apache, WebLogic, and ChartWorks, the following services are necessary for running ePeople Teamwork:

• Exim and Pop3

• Verity

• GAIM (optional)

21ePeople

Exim/Pop3 (Email)

Note Exim and the Pop3 service only run on one server in the cluster. This is Application Server 2, the Application Server not running the WebLogic Admin Server.

Use one of the following to start or stop Exim:

• /etc/init.d/exim start

• /etc/init.d/exim stop

Note Run these scripts as the root user.

Use one of the following to start or stop the Pop3 server.

• /etc/init.d/pop3d start

• /etc/init.d/pop3d stop

Note These scripts must be run as the root user.

Verity

Note Verity usually only runs on one Application Server in the cluster. This is generally Application Server 2, the Application Server that is not running the WebLogic Admin Server. It is also possible to run Verity on a separate dedicated server.

Use one of the following to start or stop Verity.

• /etc/init.d/verity start

• /etc/init.d/verity stop


GAIM

Note GAIM is an optional service and will at most run on one server in the cluster. This is generally Application Server 2, the Application Server that is not running the WebLogic Admin Server.

Use one of the following to start or stop GAIM:

• /etc/init.d/gaim start

• /etc/init.d/gaim stop


SecurityNote Firewalls and security are complex topics with many interdependencies,

context-specific requirements, and ever changing risks. While ePeople provides general guidance on services required by ePeople Teamwork, the security of your network and computers is the responsibility of your policy, practices, and company employees.

ePeople

22 ePeople

Best practices

Standard security practices should be employed on the servers and network equipment supporting ePeople Teamwork. Some standard security practices include:

1. Use a firewall between untrusted users and the servers running the application.

2. Limit remotely accessible services to only those services required by the application (including needed management services).

3. Restrict user accounts on the servers to only the appropriate required personnel.

4. Encrypt remote management traffic

5. Restrict physical access to the servers to only the appropriate personnel.

6. Regularly apply patch updates to the operating system and to system services.

7. Monitor the server and network for irregular activities.

8. Monitor security bulletins and news groups for exploits that might affect your system and services. Respond rapidly to significant security risks.

9. Disable all unneeded services on your servers particularly remotely accessible services.

System backupsNote System backup requirements can vary significantly between organizations

depending on such factors as the importance of the data, the tolerance for outages of the user base, and the skills of the personnel involved in administering the systems. While we provide guidance on what content to backup, and on the frequency that this data should be backed up, the personnel and companies running the ePeople Teamwork application are ultimately responsible for insuring that your data is sufficiently backed up.

This discussion assumes the following:

• You have a cluster of at least two application servers.

• You have one staging server.

• You have one database server (and that the database server has some form of data mirroring technique).

Note If you do not meet these requirements, you may need to back up your system more frequently.

Backups for ePeople Teamwork can be divided into three classes:

• Operating system backups

• Oracle backups

• Verity backups

23ePeople

Operating system backups

Perform regular backups on each of the systems comprising ePeople Teamwork. Since most components of the operating system change relatively infrequently, backups can be done at relatively long intervals (for example, once every month). These periodic backups should also be performed on the staging server. If you make frequent changes on the staging server, it is advisable to back up your staging server more frequently. This is especially true since the staging server is the only repository of your configuration data until the data is migrated to production.

Oracle backups

ePeople recommends running the Oracle database in the archivelog mode with a nightly hot backup of the database. These hot backups and their associated archive logs should have an additional copy either stored on tape or on a separate server. For additional reliability, you may also want to export the database on a regular basis.

To validate the reliability of the backup plan, perform a test restore from the backups periodically.

Verity backups

In addition to performing operating system backups, additional backup tasks should be performed to backup Verity software and collections. This is regardless of whether Verity is installed on a separate server or whether Verity runs co-resident on one of the application servers.

The key data to back up on the Verity server is the Verity collection and recommendation engine. Back up the following directory to capture this data:

/usr/local/teamwork/verity

You should back up the /usr/local/teamwork/verity directory on a nightly basis. This directory is physically on only one of your Application Servers. It is a NFS mount on the other Application Server. You should also periodically back up the Verity binaries. The binaries are located in /usr/local/teamwork/veritybin. The Verity binary files should generally be backed up with your operating system backup.

Periodic maintenance

There are some tasks that must be performed on a periodic basis using automated scripts. These periodic maintenance tasks include:

• Log rotation and clean up

• Verity request indexing

• Exim maintenance

• GAIM maintenance

ePeople

24 ePeople

Log rotation and clean up

The two primary sources of log files are WebLogic and Apache. These logs can become quite large and need to be rotated and deleted on a periodic basis.

WebLogic log files

The primary WebLogic log files are stored in the following directory:

• /usr/local/teamwork/bea/logs

WebLogic automatically rolls these files on a periodic basis leaving old logs in these directories. These old log files need to be removed using an automated script.

Apache log files

Apache log files also need to be periodically removed. Apache log files are not automatically rotated so an automated rotation script needs to be run.

The primary Apache log files are located in the following directory:

/usr/local/teamwork/apache/logs

These logs contain data regarding site access and page hits. Consequently, they can be valuable for performing Web-traffic analysis. You should archive these logs on some other server if you want to perform such analysis.

Verity request indexing and optimization

Verity requires certain automated scripts be run at periodic intervals so that newly created or updated requests are correctly indexed. The main Verity script runs every ten minutes, and should be entered into the crontab facility as follows. This script should be setup upon system installation.

0,10,20,30,40,50 * * * * /usr/local/teamwork/verity/scripts/verity_colls_update.sh >> /var/log/verity.log 2>&1

In addition to the Verity indexing script, Verity also needs to optimize the Verity collection and recommendation engine periodically.

Note These Verity scripts will also be installed as part of the Verity installation.

Verity request collection and recommendation optimization is accomplished using the following two crontab entries:

• 5 22 * * * /usr/local/teamwork/verity/scripts/verity_colls_optimize.sh >> /var/log/verity.log 2>&1

• 5 1 * * * /usr/local/teamwork/verity/scripts/verity_re_update.sh >> /var/log/verity.log 2>&1

25ePeople

Finally, the Verity installation automatically rotates the Verity log file. This log file is located at /var/log/verity.log and is rotated by the following crontab entry:

• 5 2 * * * 0 /usr/local/teamwork/verity/scripts/roll_verity_log.sh

Note All of the above scripts must be run as the root user.

These crontab scripts will only be present on the Application Server running Verity. This will generally be Application Server 2. If you are running a dedicated Verity Server, then the crontab scripts will be on this server only.

Exim maintenance

Exim log files need to be periodically rotated and the Exim database should be cleaned on a weekly basis. There are four automated scripts for rotating log files and for cleaning the database.

To rotate Exim log files, run the following crontab script:

# rotate exim's logs1 0 * * * /usr/local/teamwork/exim/bin/exicyclog

To clean up the Exim database, run the following three commands:

# exim's tidydb, once a week in a quiet time15 23 * * 6 /usr/local/teamwork/exim/bin/exim_tidydb –f /usr/local/teamwork/exim/spool retry15 23 * * 6 /usr/local/teamwork/exim/bin/exim_tidydb -f /usr/local/teamwork/exim/spool reject15 23 * * 6 /usr/local/teamwork/exim/bin/exim_tidydb -f /usr/local/teamwork/exim/spool wait-remote_smtp

Note These scripts will be run as user root, and will be set up upon installation.

These Exim crontab scripts will only be present on the Application Server running Exim.

GAIM maintenance

Note The GAIM service is optional. It allows you to receive ePeople Teamwork notifications on an Instant Messaging (IM) client.

The GAIM server needs to be automatically stopped and re-started on a periodic basis. Stopping and re-starting GAIM improves the reliability of the GAIM process.

The following crontab entry will automatically restart GAIM once a night:

# periodically restart gaim0 22 * * * /usr/local/teamwork/sbin/restart_gaim > /dev/null 2>&1

This script will be added as part of the installation. This script will run as the root user.

The GAIM crontab scripts will only be present on the Application Server running GAIM.

ePeople

26 ePeople

Resetting account passwords

There are three system accounts and one database account that are used by ePeople Teamwork:

• exim account

• epeople account

• teamwork account

• database user account

exim account

The exim account is only used for running the Exim email server and should have no password associated with it.

epeople account

The epeople account is the account that runs WebLogic, Apache, and ChartWorks. ePeople Teamwork does not care about the password of this account; consequently, you can freely set this account password as desired. Obviously, good security practices should be followed when setting the account password. While ePeople Teamwork does not care about the epeople account password, you do need to set up an SSH trust relationship between the Staging Server and each of the Production Application Servers. This trust relationship allows user epeople on Staging to access user epeople on each of the Production Application Servers without a password. This allows for the proper operation of the startCluster.pl script, including the deployment of code updates. This trust relationship should be created as part of the installation process.

teamwork account

The teamwork account is the temporary repository of incoming email messages. ePeople Teamwork pops email off of this account using a Pop3 email facility. Since Pop3 requires a password for authentication, ePeople Teamwork must know the Pop3 password.

In order to change the pasword of the teamwork account, you will need to re-run the TWInstall.pl script located in /usr/local/teamwork/utils.

Note This script should be run only on your Staging Server. When running TWInstall.pl, you should accept all of the defaults except for the new teamwork user password. After you have completed the script, you will need to deploy the updated files to production. For testing purposes, you can also update the Staging teamwork user password, and deploy to Staging.

The teamwork user password as specified in the TWInstall.pl script must be the same as the teamwork system password on the Production Application Server running the Pop3 server. This implies that you will need to change the teamwork system password shortly before the deployment of the new ePeople Teamwork files. This also applies to the Staging Server should you decide to update the teamwork password on Staging.

27ePeople

database user account

The database connection also has a separately maintained password that could be updated. In order to update this password, you need to re-run the TWInstall.pl script located in /usr/local/teamwork/utils.

Note This script should be run only on your Staging Server. When running TWInstall.pl, you should accept all of the defaults except for the new database user password. After you have completed the script, you will need to deploy the updated files to Production.

In order to avoid critical problems on your Production environment, you should test this process on Staging before making the changes to Production. In order to test the process on Staging, you would complete the same process of running the TWInstall.pl script, except you would change the database password for the Staging environment. You would then deploy these updated files to the Staging Server (locally).

The database user password as specified in the TWInstall.pl script must be the same as the database user password as specified on the Production Database Server. You need to maintain close coordination between changing the Production Database Server password and the deployment of the updated ePeople Teamwork files. In order to do this, you need to have an outage on your application. You should shut down Apache and both your WebLogic Managed and Admin Servers. You should then change your database password and deploy the new code to Production. This deployment should update the database password as known by ePeople Teamwork and restart the WebLogic processes.

Note This process should be tested and validated on your Staging Server before attempting it on Production.

Monitoring

Effective monitoring of ePeople Teamwork consists of four main areas:

• Application monitoring

• Service monitoring

• System monitoring

• Network monitoring

Application monitoring

Application monitoring allows you to monitor the overall health of ePeople Teamwork. It is intended to give you an aswer as to whether ePeople Teamwork is correctly functioning. Application monitoring is handled using the following diagnostic page:

http://server.company.com/diag/servertest

where server is an Application Server in your cluster.

This servertest page provides a status of the core application and indicates that Apache, WebLogic, and Oracle are up and functioning.

ePeople

28 ePeople

During normal operation, the servertest page gives you the following status message:

alive Server status reports that we are alive

You should monitor this page on a regular basis on each of the application servers. If a failure occurs, an alert should be generated.

You can also monitor the servertest page using the virtual IP address for your installation, for example:

http://teamwork.company.com/diag/servertest

Using your installation URL allows you to differentiate between one server being out of service and the whole application being down.

Service monitoring

While application monitoring does a good job of determining whether Apache, WebLogic, and Oracle are functioning correctly, it does not monitor the ancillary services that are involved in ePeople Teamwork. Separate monitoring should be set up for the following services:

• Exim/Pop3

• Verity

• ChartWorks

• GAIM

Exim/Pop3

Exim is a SMTP mail server. You can monitor Exim by connecting to TCP port 25 and verifying that Exim is responding correctly. The Pop3 server can be monitored by connecting to TCP port 110 and verifying the response.

Verity

Verity can be monitored by connecting to TCP port 8991. This port should respond back with “8991” in the response string. You should also monitor that the Verity NFS directory is correctly mounted on each of the application servers. This ensures that ePeople Teamwork workspace data can be written correctly.

ChartWorks

ChartWorks can be monitored by connecting to TCP port 8001. This port returns an HTML response containing the word ChartWorks.

GAIM

GAIM can be monitored by connecting to TCP port 7080. After connecting to this port, issue the following command:

querynetworks

29ePeople

The querynetworks command should return the names of the networks that are connected. For example:

# telnet gaim-server 7080Connected to gaim-serverEscape character is '^]'.querynetworksConnected Protocols:-AIM/ICQ-MSN-Yahoo^]telnet> quitConnection closed.

The example above shows that you are connected to the following IM networks:

• AIM

• MSN

• Yahoo

Based on this information, you can generate alerts if one or all of your IM networks have failed.

System monitoring

System monitoring monitors the health of the individual systems that comprise ePeople Teamwork. Some items that should be monitored include:

• Disk utilization

• CPU/memory utilization

• Security

Care should be taken to ensure that you have sufficient disk capacity particularly on the Oracle database.

Historical data can also be captured for trend analysis and to assist in hardware upgrade planning.

Network monitoring

Network monitoring ensures that the individual networking devices are functioning correctly. These network devices should be monitored for reliability, performance, and security.

Monitoring network devices can alert you to equipment failures, performance problems, routing/bridging loops, and security incidents.

Database administration

To minimize data loss and downtime in the event of hardware failures or other unforeseen problems, it is essential to have a good backup and disaster recovery plan.

ePeople

30 ePeople

Monitor the following items on a regular basis as part of your database administration:

1. Monitor the alert log and listener logs for error messages.

2. Monitor the tablespaces for available space and add more space when necessary.

3. Check for index fragmentation and rebuild indexes as necessary.

4. Make proper stats available to the optimizer using the Oracle-supplied DBMS_STATS package.

5. Monitor the performance of the database and tune it.

6. Check the new traffic files in the trace dump directories.

7. Upgrade the Oracle version as new patches become available.

Note Before upgrading, you should validate that the specified patch set is supported by ePeople Teamwork.

31ePeople

Index

Aaccount passwords, resetting 26accounts, system 11ancillary services 9Apache

log files 24service 8stopping/starting using teamworkctl.pl 17

applicationlayer 6monitoring 27

CChartWorks 10

monitoring 28stopping/starting using teamworkctl.pl 19

configurationshigh-availability 2, 4low-cost 2, 3recommended 2

conventions 1Ddatabase

administration 29architecture 14clustering 5layer 6

deployment process 12directory structure 10DNS 14Eepeople account 26Exim account 26Exim, maintenance 25Exim/Pop3

monitoring 28stopping/starting 21

Ffirewall 12GGAIM 10

maintenance 25monitoring 28stopping/starting 21

Hhigh-availability configuration 4Lload balancer

about 5network setup 13

log rotation and clean up 24low-cost configuration 3Mmonitoring 27Nnetwork

monitoring 29setting up DNS 14setting up firewall 12setting up load balancer 13setup 12

Ooperating system backups 23Oracle

backups 23service 9

Pperiodic maintenance 23prerequisites for using ePeople Teamwork 1RRAID, about 5Redundant Array of Independent Disks (RAID) 2Ssecurity, best practices 21service monitoring 28services

ancillary 9Apache 8ChartWorks 10core 8Exim and Pop3 9GAIM 10Oracle 9Verity 10WebLogic 9

startCluster.pl 15starting/stopping ePeople Teamwork 15

ePeople

32 ePeople

stopping/starting services 20system

architecture 5backups 22monitoring 29

system accounts 11Tteamwork account 26teamworkctl.pl

running 16VVerity

backups 23monitoring 28request indexing and optimization 24service 10stopping/starting 21

WWeb layer 6WebLogic 9

clustering 5log files 24Managed server, stopping/starting using team-

workctl.pl 18What is ePeople Teamwork? 1

ePeople Teamwork

Documents

Transcript of ePeople Teamwork