jabber xcp configuration...

Jabber XCP Configuration GuideProduct Version: Jabber XCP 5.0

Document Version: A

January 2006

1899 Wynkoop Street, Suite 600

Denver, CO 80202

303-308-3231

DisclaimersCopyright 2006 Jabber, Inc.

The information contained in this document is proprietary to Jabber, Inc. This information is considered confidential and is not to be disclosed to any outside parties without the express written consent of Jabber, Inc.

This document is provided for informational purposes only, and the information herein is subject to change without notice. Jabber, Inc. does not provide any warranties covering and specifically disclaims any liability in connection with this document.

TrademarksJABBER® and the light bulb logo are either trademarks or registered trademarks of Jabber, Inc.

All other trademarks are the property of their respective owners.

Page ii Jabber XCP 5.0 Configuration Guide

Table of Contents

Chapter 1. Overview of the Jabber XCP Server .............................................. 7XCP 5.0 Architecture 8

Component Descriptions 9Router Plugin Descriptions 11

New Functionality in XCP 5.0 11Advanced File Transfer 11Master Accept Port 12Clusters and Dynamic Routing 13Router-to-Router Connection Component 14

The Jabber XCP Controller 15Configuration Views 16Areas on the Main Screen 17Online Help 19

Configuration Guidelines 19Optimal Network Configuration 19Firewall Considerations 20Hardware Considerations 21

Chapter 2. Logging............................................................................................ 23Setting the Log Level for Router-Generated Packets 24Jabberd Logger Configuration 26

Selecting Namespaces 27Specifying Host Filters 28Configuring Loggers and Log Levels 29Formatting Logs 31

JSM Logging 32Packet Logs 34Session Logs 34Message Logs 35

Message Archiver Logging 35Statistics Logging 37Component Logging (Jlog) 39

Jabber XCP 5.0 Configuration Guide Page iii

Configuring the Filtered Syslog Logger 40Configuring the Filtered Stream Logger 41Adding a New Custom Logger 42

Chapter 3. Advanced File Transfer ................................................................ 43Configuring the Advanced File Transfer Handler 44Configuring an Open Port 49

Chapter 4. External Command Interface and WebEx ................................. 51Before You Configure the WebEx Command 51Configuring the WebEx Command 52

Chapter 5. SNMP.............................................................................................. 55Net-snmp Agent 55MIBs 56Counters 56

Counters Available for All Components 56Command Manager Counters 56Connection Manager Counters 57File Transfer Proxy Counters 57JSM Counters 57Router Counters 58Server-to-Server Counters 58Waitlist Counters 58Web Services Counters 59

Enabling SNMP 59

Chapter 6. Single Domain Name Support...................................................... 61Overview 61

Which Components to Use with SDNS 62Choosing a Mapping Algorithm 63

Configuring SDNS in Geographically Dispersed Installations 65Example – Configuring SDNS for Text Conferencing 66Example – Configuring SDNS for JSM and Information Broker 70

Configuring SDNS in Local Installations 77Configuring SDNS for LDAP 78

Chapter 7. WebServices................................................................................... 81Configuring Web Services 81

Add a Web Services Component 82Configure a Web Services Connection Manager 83Add Web Services as a Jabber Administrator 86Configure a Web Services Administrator 87

Service-Specific Configurations 88Broadcast Messages 88Offline Messaging 90

Page iv Jabber XCP 5.0 Configuration Guide

Information Broker 91Invoking Services from a SOAP-over-HTTP Client 91Web Services Definition Language Files 92

Chapter 8. Active Directory Authentication................................................... 93Add a Jabber Directory Suite Component 93Configure a Directory Server 95Configure an LDAP Database 96Configure JSM to use JDS 99

Chapter 9. HTTP Polling Connections.......................................................... 101

Appendix A. Connection Manager Overview............................................... 105Core Components 106Default Jabber XCP Configuration 107Polling XMPP over HTTP 109SMTP CM for Offline E-mail Redirection 110Web Services CM 111Server-to-Server CM 112

Jabber XCP 5.0 Configuration Guide Page v

Page vi Jabber XCP 5.0 Configuration Guide

Chapter 1. Overview of the Jabber XCP Server

Jabber Inc.’s new release of the Extensible Communications Platform (XCP) server (version 5.0) contains a number of new features and components. This chapter provides a high-level diagram of the Jabber XCP 5.0 architecture, and an overview of each new feature in addition to information about configuration, namespaces, and logging.

The following sections are provided:

• XCP 5.0 Architecture• New Functionality in XCP 5.0• The Jabber XCP Controller• Configuration Guidelines

Jabber XCP 5.0 Configuration Guide Chapter 1. Overview of the Jabber XCP Server

XCP 5.0 Architecture

XCP 5.0 ArchitectureFigure 1 illustrates the architecture of the Jabber XCP server, release 5.0. It includes the new dynamic routing and Advanced File Transfer features and the new LCS and AIM gateways.

Figure 1. XCP 5.0 Architectural Overview

Clients

Connection Manager

XMPP Client, Server

HTTP Config,Poll,SOAP

UserDirectory

External Servers

Connectors

DataSources

ClientXMPP

S2SXMPP

SMTP

OfflineE-mail

SMS,WAP,IMPS

WebClient JabberMessenger

Polling XMPP

AdminConsole

SDKs(C++, Java)

HTTP

(To All)SNMPAgent

AgentX

Web ServicesPresence

Messaging

Custom

CustomDynamicRouting

JDSAuth

Search

CG

Vcard

ECIWebEx

Custom

InfoBrokerDatabase

Memory Advanced FileTransfer

Basic FileTransfer

SDNSAlgorithm

AuthZ,Modify,Filter

TCMUC

Persistent

Custom/ECR

Jabber Session ManagerOffline

Auth (Z,N)

Disco

Presence

Roster

Mirror

ECR Archive Router

ConfigManager

ComponentPresence

SQL

LD

Chapter 1. Overview of the Jabber XCP Server Jabber XCP 5.0 Configuration Guide


Component DescriptionsComponents are extensions of the Jabber XCP server that can be started and stopped independent of the router, jabberd. For example, you can start and stop the Text Conferencing component without bringing down the router (although your users will lose text conferencing capability if you do). The Components area in the Jabber XCP Controller is where you add, modify, and remove external server components. You can also start and stop individual components from this area.

After you install the Jabber XCP server, you must add the components that you want to make available to your users. If desired, you can use the server’s SDNS feature to install multiple copies of the same component to distribute it across hosts and to increase your system performance and reliability.

The components are described as follows:

• Connection Manager (CM) – Enables clients and other servers to connect to the Jabber XCP server. You can configure multiple connection managers to enable different types of connections or to scale the system to accept more connections.

• External Command Interface (ECI) – Integrates with the WebEx service. It allows Jabber client users to create WebEx meetings and to send meeting invitations to contacts. The component also allows you to add your own custom JEP-0050 Ad-Hoc Commands.

• File Transfer Proxy – The File Transfer Proxy component allows you to enable server-based file transfer capabilities via a JEP-65: SOCKS5 Bytestreams proxy. The component acts as a SOCKS5 proxy server, and allows byte streams to be transferred between two Jabber clients.

• Information Broker – Provides the capability for customers to create applications through which users can publish, subscribe to, and access information that is organized by meaningful categories.

• Jabber Directory Suite (JDS) – Provides an interface between the Jabber server and version 3-compliant LDAP or ADS directory services. It handles authentication, and enables the retrieval of vCard information and the use of Community Groups.

• Jabber User Directory (JUD) – A searchable directory to which users on the server can subscribe. You can use it to create a searchable directory of all users on your Jabber server. (The JUD is commonly used for a directory when JDS with LDAP is not being used.)



• Java External Command Interface (JECI) – The Java External Command Interface (JECI) component performs the same function as the ECI component, but allows custom commands to be written in Java. As with ECI, theses commands must comply with JEP-50: Ad-Hoc Commands.

• Message Archiver – Logs all messages sent to and from the server, including basic IM, text conferences, and broadcast messages. You must have a supported database (Oracle, PostgreSQL, or MS SQL) to use this feature.

• Open Port – Allows you to configure a custom component with a non-validated configuration or a component that is used for testing purposes. It also allows you to associate a host filter with a component that connects to the multi-accept port.

• Presence Mirror – Enables the storage of user presence information in a database on a near real-time basis. You must have a supported database (Oracle, PostgreSQL, or MS SQL) to use this feature.

• Router-to-Router – Allows a connection between two routers that are not in the same cluster or subnet. This component must be configured on the router that is initiating the connection. Its configuration simply requires the IP address, Port, and Password of the router to which it is connecting.

• Single Domain Name Support (SDNS) – Provides a means of distributing the load for a single Jabber domain over multiple components. For example, if you want the users connected to routers A and B to participate in text conference rooms on either router, you must configure an SDNS component on both routers. The components that you can configure for SDNS include JSM, Information Broker, and Text Conferencing.

• Text Conferencing (TC) – Enables Jabber users to participate in online conference rooms. It provides the ability to load core gears, which control the behavior of text conferencing on your system. It also permits the storage of persistent conference rooms on the server; to use persistent rooms, you must have one of the supported databases (Oracle, PostgreSQL, or MS SQL). You can use the Text Conferencing SDK to write your own custom gears to expand the functionality of text conferencing in your environment (see the Text Conferencing SDK Tutorial for more information).

• Wait List Service – Specified in JEP-130: Waiting Lists, this component allows Jabber IM users to place a contact on a waiting list by specifying information about the contact (such as a telephone number or an email address) and to be notified when that contact creates an IM account.

• Web Services – Provides the capability for customers to create applications and custom components that can use Messaging, Router/Presence, and Information Broker services.


New Functionality in XCP 5.0

Router Plugin DescriptionsRouter plugins are extensions of the Jabber XCP server that always load within the jabberd process. You cannot start and stop plugins independently of the server. You can add, configure, and remove plugins as desired in the Router area of the Jabber XCP Controller.

Router plugins include the following:

• Core Router – Contains configuration parameters specific to the Jabber XCP core router, jabberd. Unlike the other plugins, you cannot add a new core router or remove the existing core router.

• Jabber Session Manager (JSM) – Handles real-time messaging functionality; contains state information about every client that sends a packet through jabberd.

• Jabberd Logger – Logs packets that are sent to and from the plugins to a file, to syslog, and to stderr.

New Functionality in XCP 5.0Several new features have been added to the Jabber XCP 5.0 server. The include Advanced File Transfer, the router’s Master Accept Port, and Clusters and Dynamic Routing.

Advanced File TransferThe Advanced File Transfer (AFT) handler uses HTTP to upload and download files that are being transferred. When a user uploads a file for transfer, it is placed in a staging area and scanned for viruses, content, etc. If the scan is successful, the file is archived, and a URL from which the file can be downloaded is sent to the user who uploaded the file. The user then sends the URL to other users who want to download the file. When a user downloads the file, a copy of the file is sent from the archive to the user. All file transfer transactions are recorded in an Oracle, PostgreSQL, or MS SQL database.

Scanning the files that are uploaded is an optional, although recommended step. This option is configurable in the Advanced File Transfer Handler’s configuration screen.



Master Accept PortThe Global Settings configuration for the core router now includes a Master Accept Port option, as shown in Figure 2. You can enable this option to allow all XCP components to connect to the router using the same port. The port is a configurable option, which you select during XCP installation. By default, it is set to 7400.

Figure 2. Master Accept Port configuration

Figure 4 illustrates the use of Master Accept Port 7400. The router accepts connections on port 7400 from all components. During XCP configuration, the use of the Master Accept Port removes the necessity of specifying router connection information separately for each component that connects to the router.

If, however, you want to configure a component so that the router connects to it, each component’s configuration screen gives you the Router Outbound Connection Information option as shown below. This option is disabled by default in the component configuration screens, and you must enable and configure it if you want the router to connect to the component.

Figure 3. Router Outbound Connection

As shown in Figure 4, components located outside the firewall use other ports for communicating with the router, and are configured with the Router Outbound Connection Information, since the router must connect to them for security reasons.



Figure 4. Master Accept Port illustration

Clusters and Dynamic RoutingXCP 5.0 allows you to install a number of XCP routers that are on the same subnet into the same group, or cluster. You are asked to name a router’s cluster during installation. Routers that are in the same cluster are able to discover each other (using MDNS) and all of their respective components and plugins.

Web CM

HTTPTranscoder

Family

Web CommandProcessor

Presence MirrorComponent

Router(jabberd)

Message ArchiverComponent

Jabber UserDirectory

Component

Text ConferencingComponent

JSM CM

S2S CM

Firewall

XMPPTranscoder

Family

JSMCommandProcessor

XMPPTranscoder

Family

S2S CommandProcessor

Jabber SessionManager Plugin

Master acceptport 7400

7400

7301 (connect)

7310 (connect)

Remote XMPP Server

File TransferProxy Component

7358 (connect)

file






For example, let’s say that four routers have been installed in the same cluster, MainCluster (as illustrated in Figure 5). Each router knows about the other routers because they belong to the same cluster. When the Text Conferencing component on Router 4 comes online, Router 4 sends the component’s presence to all of the other routers, and the routing table on each router is dynamically updated. Therefore, if one of the routers goes down, another route can be found.

To make things more interesting, SDNS is being used on each router to spread the conferencing load across the four TC components. Through the dynamic routing feature, all ports that are necessary for SDNS communication between these components are dynamically configured for you. You no longer need to laboriously configure the Jabberd Port as was required in the previous release.

Figure 5. Cluster and Dynamic Routing illustration

Router-to-Router Connection ComponentThe Router-to-Router Connection component allows a connection between two routers that are not in the same cluster. This component must be configured on the router that is initiating the connection.

TextConferencing

TC-1.r1

TextConferencing

TC-1.r3

TextConferencing

TC-1.r4

SDNSconf.jabber.com

SDNSconf.jabber.com

SDNSconf.jabber.com

Router1realm=r1

SDNSconf.jabber.com

TextConferencing

TC-1.r2

Router2realm=r2

Router3realm=r3

Router4realm=r4

MainCluster


The Jabber XCP Controller

The Jabber XCP ControllerThe Jabber XCP Controller is a web-based administration console through which you configure the server’s central router, router plugins, and components. The Controller’s main screen is shown below; it provides information about the core Jabber XCP server, and all plugins and components installed on the server. You can start and stop the server and its components from this location. You can also view an XML summary of your server configuration. The main screen is divided into four areas: Configuration View, System, Router, and Components.

Caution: Jabber, Inc. recommends that you use the Controller to configure the Jabber XCP server rather than attempting to edit the XML configuration files manually. If you edit the files manually, your configuration could easily become compromised. Furthermore, if you hand-edit a component’s XML file, you cannot use the Controller later to edit the component’s configuration.

Figure 6. Jabber XCP Controller main screen



Configuration ViewsThe Jabber XCP Controller offers three modes of configuration, called “Configuration views”: Basic, Intermediate, and Advanced. The following figure shows the “Configuration view” drop-down menu, which is located in the top right corner of every Controller screen. When you select a particular view, it remains in effect on all screens until you change it.

Figure 7. Configuration views

The Basic configuration view uses default values for the most part, and displays the fewest configuration options. Configuring your system using this mode enables you to get your Jabber XCP system up and running in the shortest amount of time.

The Intermediate configuration view provides all of the options that are available in the Basic view in addition to some other options, such as those used for hostname and command configurations, and for logging. It also includes many of the options for components that are installed with the Jabber XCP Developer Extensions. The components whose configurations require you to use at least the Intermediate view include:

• Information Broker• Message Archiver• Presence Mirror• Wait List Service• Web Services

Finally, the Advanced configuration view provides all of the Controller’s configuration options, including those used for detailed router configuration. This view is also required for configuring the Single Domain Name Support (SDNS) and Router-to-Router components, two of the server’s most advanced features. The Advanced configuration view also lets you configure options such as buffer sizes, thread counts, run levels, and custom loggers. These options require a more advanced level of XCP server knowledge and can be used for fine tuning your XCP system.



Areas on the Main ScreenThe areas on the Controller’s main screen are described in the following sections.

The System Area

The System area contains a Summary link that lets you display the complete jabber.xml file containing your configuration settings, a Cluster link that allows you to access all of the Controllers for this cluster, and a Stop the System link that allows you to stop the Jabber XCP system. It also provides a Window Help link that displays a help topic for the Controller’s main screen, and a Full Help System link that opens the entire online help system.

If you have modified the configuration of a plugin or component, you must restart the system before the changes take effect and before they display in the Summary.

Figure 8. System area on Controller’s main screen

To stop the server, click the Stop the System link. The XCP server stops, and all associated components and plugins also stop. The following screen displays:

Figure 9. Restart the server link

To restart the server, click the start the server now link.

Click view all of the controllers to access the screen from which you can access all of the Controllers in the current cluster.



The Router Area

Router plugins are extensions to the server’s core router, jabberd, and always start and stop with the system. The Router area of the Jabber XCP Controller is where you add, modify, or remove router plugins.

Figure 10. Router area on Controller’s main screen

Each plugin on your system is listed in the Router area. You will always find a “Core Router” plugin in the table. The core router cannot be removed from the server. As you add other plugins, they are listed in the table as well.

You add a new plugin by selecting one in the pull-down list and clicking the Go button to access its configuration window. You can also modify an existing plugin’s configuration by clicking the corresponding Edit link, or remove a plugin (except for the core router) by clicking its Remove link.

The Components Area

Components are extensions of the Jabber XCP server that can be started and stopped independent of the server. The Components area, shown in the following figure, is where you add, modify, start, stop, or remove server components.

Figure 11. Components area on Controller’s main screen

You add a new component by selecting one in the pull-down list and clicking the Go button to access its configuration window. You can start and stop individual components if needed by clicking the Start and Stop links. You can also modify an existing component’s configuration by clicking the corresponding Edit link, or remove a stopped component by clicking its Remove link. (You must stop a component before you can remove it.)

The Components area is organized by host. That is, all components installed on a particular host are listed together in the table.


Configuration Guidelines

Online HelpOnline help is provided for each configuration window through a Help link; the help topic that displays contains detailed descriptions of the parameters required for configuring the plugin or component.

Configuration GuidelinesWhen you install Jabber XCP, a default connection manager with a Web command processor is installed on your system to give you access to the Jabber XCP Controller through a Web browser. You must use the Controller to modify the default configurations for the Jabber XCP system components and plugins, and to add, remove or reconfigure the components and plugins associated with your system.

A configuration manager, which is part of the jabberd, handles the validation, storage and retrieval of configuration data for the router and all of its components. All component configuration information is stored with the configuration manager.

We recommend that you use the Jabber XCP Controller to configure and to make all necessary modifications to your Jabber XCP system. The Controller ensures that all parameters are configured properly and that all parts of the system work together correctly.

Optimal Network ConfigurationIn order to run an efficient and secure Jabber deployment, it is important to correctly configure your network for integration with the Jabber XCP server. Here are several principles to keep in mind when deploying a Jabber system:

• In general, a Jabber XCP server should be treated similarly to any other major piece of infrastructure, such as a web server or e-mail server.

• If your Jabber deployment is intended solely for internal use within your organization, it should not be exposed outside your organization’s firewall.



• If your Jabber deployment is accessed by both internal and external users, you may need to open selected ports in your firewall (see below). You may even want to run two Jabber servers: one within the firewall (for internal users) and one outside the firewall (for external users), with server-to-server communication set up between them.

• Jabber uses persistent TCP sockets between clients and the server, as well as from one server to another. Therefore, make sure that any firewalls have appropriate time-outs so that connections are not lost unnecessarily.

• When you are configuring your Jabber server, use a static IP address and not DHCP.

Firewall ConsiderationsThe optimum firewall configuration for your deployment depends on your organization’s requirements and security policies. If your Jabber server accepts TCP connections only from users within your organization’s firewall, you do not need to open any additional ports. In certain situations (for example, if your organization has employees who telecommute), you may want to use the standard Jabber client port 5222 with TLS so that users outside the firewall can make incoming connections to your server. In addition, if you would like users of your server to communicate with users of an external server, you must open the standard Jabber server port 5269 to enable server-to-server connections.

A more complex configuration would have one server behind the firewall for internal users, one server outside the firewall for external users, and a trusted server-to-server channel between the two servers over port 5269 (with “white listing” at the firewall level to open server-to-server communications over port 5269 only between these two machines).

By default, components are configured to use the accept (or passive) connection type. With this connection type, the server listens for a connection from the component. This connection is considered passive because the server waits passively for the component to connect to it. Conversely, if you select the connect (or active) connection type when you configure the component, the server actively connects to the component.

To avoid firewall interference with a connection, you should also set a keep-alive interval when you configure the component. The keep-alive helps prevent firewalls from dropping an unused connection to the component.



Hardware ConsiderationsFor a base-level deployment (up to 5,000 users), it is usually sufficient to run both the core server and a connection manager (CM) on one machine. Somewhat larger, “scale 1” deployments (up to 20,000 users) will probably want to add several machines, each running its own CM to complement the machine running the core server. A separate machine running external components such as Text Conferencing may also be desirable, though not strictly necessary. Larger, “scale 2” deployments (more than 20,000 users) may need to take advantage of Jabber servers in multiple locations and implement specialized features for high availability. For assistance regarding large deployments, we recommend that you discuss your requirements with representatives from Jabber, Inc.


Chapter 2. Logging

The Jabber XCP server provides a number of different logging options. By default, the server’s core router, jabberd, is configured to log JSM and router data to syslog at the ‘info’ log level. You can change this default level as needed (as described in “Setting the Log Level for Router-Generated Packets”). Any level that you choose logs data at that level in addition to all the levels above it. For example, when the log level is set to ‘info’, data is logged at the ‘warn’ and ‘error’ levels as well.

The current jabberd log level is recorded in the jabber.loglevel file, which is located in $JABBER_HOME/var/tmp. This file is updated any time someone changes the log level and restarts the server.

If you require more logging than what occurs by default, you can configure the server to log statistics and other types of JSM data, and to use file and stderr loggers in addition to syslog. You can also configure syslog and stream loggers for each component.

Logging is an intermediate, and sometimes advanced, feature in the XCP Controller. When you configure Logging, make sure you are using the Controller’s Intermediate or Advanced configuration view.

The following sections are provided in this chapter:

• Setting the Log Level for Router-Generated Packets• Jabberd Logger Configuration• JSM Logging• Message Archiver Logging• Statistics Logging• Component Logging (Jlog)

Jabber XCP 5.0 Configuration Guide Chapter 2. Logging

Setting the Log Level for Router-Generated Packets

Setting the Log Level for Router-Generated PacketsThe log level specifies the severity of the data that is logged and determines the amount of data that the server records; the lower the severity level, the more verbose the log (see Table 1 for descriptions of severity levels). The core router is configured by default to log packets at the info level and above, which means that log packets are generated only for data that comes into the router at the ‘info’, ‘warn’, and ‘error’ levels.

The log level that is set for the core router is the level at which the server starts. If needed, you can temporarily change the level during runtime; however, the default level is restored when you restart the server.

Red Hat sets its syslog level to *.info by default. If you prefer to see other log levels, you must change the syslog configuration on your RedHat system. You should syslog default to a value that is greater than or equal to the XCP log level that you plan to use.

Log levels are described in Table 1 and are listed in the order of decreasing severity. For example, the ‘warn’ log level is less severe than the ‘error’ log level. The lower the severity level, the higher the log’s level of verbosity.

Table 1. Log severity levels

The log level must be set to ‘info’ or higher for the Jabber Session Manager (JSM) log types (message, packet, and session) to function properly. In addition, statistics data is not available if the log’s verbosity level is set below ‘info’.

Severity Level Information logged...

error System-generated errors such as the inability to create listen ports, server configuration errors, failure to create the log files, etc.

warn All ‘error’ level data plus non-fatal errors such as bounced packets, nonexistent user logging in, invalid recipient for a message, etc.

info All ‘error’ and ‘warn’ level data plus information about socket connections and all JSM logs (packet, session, and message)

verbose All ‘error’, warn’, and ‘info’ level data plus every packet that is processed by the server and JSM.

debug All log-level data plus debug data.

Chapter 2. Logging Jabber XCP 5.0 Configuration Guide

Setting the Log Level for Router-Generated Packets

To change the router’s default log level

1. In the Router area on the Controller’s main screen, click the Edit link for the Core Router.

2. In the Global Settings Configuration screen, expand the drop-down list beside Level of information to log, and select the desired level.

3. Scroll to the bottom of the screen and click Submit to save your configuration.

To view the current log level

Enter the following command from the jabberInstallDir/bin directory: ./runjabber loglevel check

To increase the log’s verbosity level while the server is running

1. Enter the following command from the jabberInstallDir/bin directory to increase the log level by one increment (for example, from ‘warn’ to ‘info’).

./runjabber loglevel increase

2. Repeat the command for each desired level increase.

To decrease the log’s verbosity level while the server is running

1. Enter the following command from the jabberInstallDir/bin directory to decrease the log level by one increment (for example, from ‘info’ to ‘warn’).

./runjabber loglevel decrease

2. Repeat the command for each desired level decrease.


Jabberd Logger Configuration

Jabberd Logger ConfigurationThe Jabberd Logger receives packets that are generated by the core router (jabberd), by JSM, and by any other plugin, and logs them to syslog, file, and/or stderr. The Jabberd Logger that is installed by default is configured to capture information generated in the generic namespace, jcs:log:default, and to log the information to syslog. You can edit the default logger, or you can add new ones. In the Jabberd Logger Configuration screen, you can select the namespaces for other types of information that you want to log, and you can specify the names of the hosts from which you want to log the information. You can also select the types of loggers that you want to use, and the log level(s) used to log the information.

You can configure multiple Jabberd Loggers depending on how specific you want to your logging to be. For example, if you want to log presence and session packets for host alpha.example.com to a file logger, and message packets for host beta.example.com to syslog, you would need to configure two Jabberd Loggers to handle the logging.

To add a Jabberd Logger

1. In the Router area on the Controller’s main screen, select Jabberd Logger from the drop down list and click Go.

The Jabberd Logger Configuration screen opens as shown in the following figure.



2. Read the following sections for instructions on configuring the Jabberd Logger.

Selecting NamespacesNamespaces are used to capture specific types of log packets that are generated by JSM (mod_log) or the core router, jabberd. When these packets are generated, they are sent to the Jabberd Logger. If they match the namespaces that are in the Namespace Filters list in the Jabberd Logger Configuration screen, the Jabberd Logger logs the information to the configured log types (syslog, file, or stderr).

To select the namespaces for the data you want to log

Simply delete the namespaces that you do not want to use from the Namespace Filters list. You can enter other namespaces, but you must have a custom logger that handles them.



The namespaces that Jabber, Inc. provides for logging are described in the following table.

Specifying Host FiltersIn the Host Filters text box, you can specify the names of hosts from which you want to log the selected packet types. For jcs:log:default packets, you should leave the asterisk (*), which will log packets in that namespace from all hosts. However, for other namespace filters you can either use the asterisk to indicate that you want to log these packet types from all hosts, or you can list specific hosts only.

Namespace This log captures...

jcs:log:default Information from the router and from JSM. This namespace is selected by default.

jcs:stats:jsm System statistic information. You must select this namespace if you plan to enable Statistics logging in the JSM configuration.

jcs:mod_log:session Information about each user session that occurs on the server. You must select this namespace if you plan to enable session packet logging in the JSM configuration.

jcs:mod_log:message:in Incoming messages and file transfer requests as they are received by the server. You must select this namespace if you plan to enable incoming message logging in the JSM configuration, and you want the Jabberd Logger to handle the logging.

Note: If you prefer to use Message Archiver rather than the Jabberd Logger to handle message packets, you do not have to select the message namespaces here (see “Message Archiver Logging” on page 35).

jcs:mod_log:message:out Outgoing messages and file transfer requests as they are sent by the server. You must select this namespace if you plan to enable outgoing message logging in the JSM configuration, and you want the Jabberd Logger to handle the logging.

jcs:mod_log:packet:in Information about packets going into JSM.

Note: Logging incoming and outgoing packets is not recommended because of the massive load it places on the router. This type of logging is usually reserved for debugging purposes.

jcs:mod_log:packet:out Information about packets coming out of JSM.

jcs:mod_log:presence Information about client users’ presence. You must select this namespace if you plan to enable presence packet logging in the JSM configuration.



Configuring Loggers and Log LevelsIn addition to the Syslog logger, which is enabled by default, you can configure a file logger and a standard error logger. In addition, you can select one or more log levels at which to log the information to these log types.

Syslog Logger The Syslog logger is enabled by default when you install the server. This logger logs information from the router, and from JSM and other plugins to syslog. Syslog refers to the logging daemon used to log messages generated by your operating system components. Syslog also provides log rotation based on file age and size. It can be run locally or remotely and does not require any additional hardware or software.

To configure the Syslog logger

1. Under Configuration on the Jabberd Logger Configuration screen, select the Details link beside the Syslog Logger. The Syslog Logger Configuration screen displays. (If you prefer, you can add a new Syslog logger rather than modifying the existing one.)

2. Configure the Syslog logger using the online help as needed for field descriptions.

3. Click Submit to save your configuration.



File Logger The File Logger lets you specify the name and location of a log file and various parameters for the information that you want to log to it.

To configure the File logger

1. Under Configuration on the Jabberd Logger Configuration screen, select File Logger from the drop-down list, and click Go. The File Logger Configuration screen displays.

2. Configure the File logger using the online help as needed for field descriptions.


Standard Error Logger

The Standard Error Logger lets you format information that is logged to stderr.

To configure the Standard Error logger

1. Under Configuration on the Jabberd Logger Configuration screen, select Standard Error Logger from the drop-down list, and click Go. The Standard Error Logger Configuration screen displays.

2. Enter the log formatters for the type of information that you want logged. (See “Formatting Logs” on page 31 for more information.)




Log Levels You can select one or more log levels, which pertain to all of the loggers configured in this particular instance of the Jabberd Logger plugin.

To select one or more log levels

1. Under Configuration on the Jabberd Logger Configuration screen, select Standard Log Levels from the drop-down list, and click Go. The Log Levels Configuration screen displays.

2. Select one or more log levels in the list (hold down the CTRL key to select more than one). The logs you have selected for this particular Jabberd Logger configuration will each log at these levels.


Formatting LogsYou can modify how log information is formatted using a number of attribute codes.

To format a log

Add any or all of the attribute codes listed in the table below in a logger’s Format textbox to capture the desired data in your log.

Format Tag Description

%h The point in the code where the log message was generated. In general, this information is useful in debugging the server. It is usually not useful when used with message and session logs.

%i The thread number inside the server that generates the log message; used for debugging.

%s The information being logged.

%d The Greenwich Mean Time and date when the log message was generated.


JSM Logging

JSM LoggingIf you want to log message, session, and presence packets in addition to the JSM-generated packets logged by the server by default, you can configure this logging in the Jabber Session Manager Configuration screen.

To configure JSM logging

1. In the Router area on the Controller’s main screen, click the Edit link for the Jabber Session Manager.

2. In the Jabber Session Manager Configuration screen, scroll down to the JSM Logging section, and click the checkbox to enable it. (The Advanced configuration view is shown in the following figure.)

In the Controller’s Intermediate view, you can enable the logging of incoming and outgoing message packets. In the Advanced view, you can additionally enable the logging of session and presence packets, and of summarized packets.

3. Select Yes beside any of the packets that you want to log. Use the online help as needed to complete the logging configuration.

4. Click Submit to save your configuration. You are returned to the Controller’s main screen.

%t The log level of the message; for example, none, error, info, warn, verbose, debug. This attribute does not work with message, packet, or session logs.

Format Tag Description


JSM Logging

5. Edit the Jabberd Logger plugin.

6. In the Jabberd Logger Configuration screen, select the namespaces in the Namespace Filters list that correspond to the packet types you selected for JSM logging. (Hold down the CTRL key to select multiple namespaces.) Packets generated by JSM in these namespaces will be logged to the loggers that you have configured for the Jabberd Logger. The namespaces correspond to the packets in the JSM Configuration screen as follows:


8. Restart your system.

The following sections describe packet, session, and message logs.

Jabberd Logger namespaces JSM packet types

jcs:mod_log:session Session Packets

jcs:mod_log:message:in Incoming message packets

jcs:mod_log:message:out Outgoing message packets

jcs:mod_log:packet:in Summarized packet data

jcs:mod_log:packet:out Summarized packet data

jcs:mod_log:presence Presence packets


JSM Logging

Packet LogsPacket logs contain two types of data: non-IQ packets and IQ packets. A non-IQ packet records whether the packet contained an IQ packet (designated by ‘i’), presence information (designated by ‘p’), or subscription information (designated by ‘s’). Non-IQ packet information resembles the following:

An IQ packet contains all of the information that is saved for the non-IQ packet. It also includes a numeric sub-type for the packet and the namespace from which the data came. Numeric sub-types include: 5 for ‘get’; 6 for ‘set’, and 7 for ‘result’. IQ packet log information resembles the following:

Session LogsSession logs contain information about each user session that occurs on the server. When the user logs off or is disconnected, the server logs the timestamp of when the session ended, the number of seconds the session lasted, and the full Jabber ID of the user associated with the session (for example, user@host/resource). It also records the number of packets sent and received.

The session log provides information only after a session has ended, and therefore does not provide information about a user’s session while that user is logged in.

<log time='20020128T18:16:32'>p [email protected]/resource [email protected]/0.8.5 98</log>

log date and time'p' indicates presence data

JID from which the packet was sent

JID to which the packet was sent Size of the packet in bytes

<log time='20020128T18:16:32'>i [email protected]/resource - 101 5 jabber:iq:roster</log>

The JID to which the packet was sent. A dash indicates that the packet went to the server.

'i' indicates an IQ packet log

IQ packet namespace

Size of the packet in bytes

‘5’ indicates a 'get' sub-type


Message Archiver Logging

Session log information resembles the following:

Message LogsMessage logs contain all messages. You may want to use the message log feature to archive your message traffic. You may archive traffic through the server by writing the message logs to a file and backing them up outside of the server.

Message log information resembles the following:

Message Archiver LoggingYou can send all inbound and outbound message packets to the Message Archiver component for logging instead of, or in addition to, the Jabberd Logger. Message Archiver handles the message packets and stores them in PostgresSQL or in Oracle. (If you do not select the message namespaces in the Jabberd Logger configuration, message packets will be logged only through Message Archiver as long as you have configured a Message Archiver component.)

<log time='20030528T18:19:26'>174 1 5 [email protected]/resource</log>

The time and date the user logged out

Length of session in seconds

Number of packets received

Number of packets sent

JID whose session is recorded here

<log time='20030628T18:18:52'><message to='[email protected]' type='chat' from='[email protected]/resource'><body>How was the game?</body></message></log>

The time and date the message was sent

The entire message


Message Archiver Logging

To log message packets through Message Archiver

1. In the Components area on the Controller’s main screen, select Message Archiver in the drop-down list, and click Go to add a Message Archiver component.

2. Configure the Message Archiver component using the online help as needed.

3. In the Log area, select one or both namespaces in the Namespace Filters list depending on which message packets you want to log.

4. If you want to log message packets from specific hosts only, enter their hostnames or IP addresses in the Host Filters text box. The asterisk (*) is used to log message packets from every host.


6. Edit the JSM plugin.

7. In the Jabber Session Manager Configuration screen, scroll down to the JSM Logging section, and select the checkbox to enable the feature.


Statistics Logging

8. Select Yes for one or both message packet options. The packets you enable here should match the namespaces you selected in the Message Archiver configuration.



Statistics LoggingStatistics logging captures server statistics and logs the data to the log types that are configured for the Jabberd Logger. Statistics logging is turned off by default when you install the XCP server; however, you can enable it in the JSM configuration and set the time interval for capturing data.

Server statistics data includes the number of:

• Users who are currently online• Successful logins in the last time-slice interval• Successful logins since server startup• Failed logins since server startup• Offline messages stored in the last time-slice interval• Total messages since server startup• Presence packets since server startup• IQ packets since server startup

Statistics data also includes information about:

• The length of time, in seconds, that the server has been running• The average message size in the last time-slice interval• The number of messages in the last time-slice interval

To enable server statistics logging

1. In the Router area on the Controller’s main screen, click the Edit link for the Logger plugin.


Statistics Logging

2. In the Jabberd Logger Configuration screen, select the jcs:stats:jsm namespace in the list of Namespace Filters. (If you want the jcs:log:default namespace to remain selected, hold down the CTRL key when you select the jcs:stats:jsm namespace.)


4. In the Router area on the Controller’s main screen, click the Edit link for the Jabber Session Manager.

5. In the Jabber Session Manager Configuration screen, scroll down to the Stats section and click the checkbox to enable the option.

6. If needed, change the number of seconds that elapse before each capture of server statistics.

7. Scroll to the bottom of the Jabber Session Manager Configuration screen, and click Submit to save your configuration.


Component Logging (Jlog)

Component Logging (Jlog)All XCP components can log to the Jabber Logging Library, Jlog. Each component configuration screen has a Component Logging (Jlog) section, in which you can configure Syslog and stream loggers that filter the information based on the selected log level. The information that is logged varies by component.

The Syslog and stream loggers log information that is generated at or above the selected severity level and drops messages that are below that level. For example, if you select the warning level, warning and error messages are logged, and messages at the debug, verbose, and info levels are dropped.

When a component is daemonized, logging to stderr or stdout is disabled; if you start a component from the command line using the -P flag, it is daemonized.

To enable component logging, you must select the checkboxes beside Component Logging (Jlog) and Logger as shown below. Then you must select one or both logger types and configure them as needed.



Configuring the Filtered Syslog LoggerThe Filtered Syslog Logger logs component information to syslog at the selected level.

To configure the Filtered Syslog Logger

1. Click the checkbox next to Filtered Syslog Logger to enable the options.

2. Select a severity level from the drop-down list.

3. Enter the full path to a pipe file for this component. We suggest naming the file $JABBER_HOME/var/log/comp-id (where comp-id is the unique identifier of the component). If the pipe file does not already exist on your system, it will be created.

You can send the file a pipe command of U (up) or D (down) to increase or decrease the amount of data being logged from the component. For example, if your log level is set to ‘verbose’ and you send a pipe command of D, the log’s level of verbosity is decreased to ‘info’.

You can also use the echo C > pipe_file command to create an entry in syslog indicating the current log level for the component. For pipe_file, enter the full or relative path (including the pipe file’s name) to the location of the component’s pipe file.

4. Select the facility that you want to use from the drop-down list. (Facilities are defined on the syslog(3) manpage.)

5. Enter a term that identifies where the log information is coming from. The identity is displayed in syslog next to the associated data. You can change the default value as needed.

6. Enter the formatters for the information that you want to log. (See “Formatting Logs” on page 31.)

7. When you have finished configuring the loggers, click Submit to save your configuration.




Configuring the Filtered Stream LoggerThe Filtered Stream Logger logs information to stdout or to stderr at the selected level.

To configure the Filtered Stream Logger

1. Click the checkbox next to Filtered Syslog Logger to enable the options.

2. Select a severity level from the drop-down list.

3. Enter the full path to a pipe file for this component. We suggest naming the file $JABBER_HOME/var/log/comp-id (where comp-id is the unique identifier of the component). If the pipe file does not already exist on your system, it will be created. (For more information about the pipe file, see Step 3 in the previous section.)

4. Select stderr or stdout from the drop-down list.

5. Enter the formatters for the information that you want to log. (See “Formatting Logs” on page 31.)

6. When you have finished configuring the loggers, click Submit to save your configuration.




Adding a New Custom LoggerIf you have created a custom logger for logging component information using the libjcore library, you can add it to your XCP server configuration. The custom logger option is available only in the Controller’s Advanced configuration view.

To add a custom logger

1. Click Go beside Add a new custom logger. The Custom Logger Configuration screen displays.

2. In the Custom library field, enter the library used for this logger.

3. In the Load field, enter the library entry point function.




Chapter 3. Advanced File Transfer

Advanced File Transfer (AFT) is a new feature that allows users to transfer files via HTTP. It stores transaction information associated with each file transfer in an Oracle, a PostgreSQL, or an MS SQL database. AFT is used mainly by customers who want to monitor, archive, and log their users’ file transfer activities say, for example, to comply with SEC laws. This feature is more robust than the File Transfer Proxy component that was included beginning in XCP 4.x, and can be used in place of it.

The AFT feature allows users to transfer files via HTTP. When a user uploads a file for transfer, it is placed in a staging area and scanned. If the scan is successful, the file is archived, and a URL from which the file can be downloaded is sent to the user who uploaded the file. This user sends the URL to other users who can then download the file. When a user downloads the file, a copy of the file is sent from the archive to the user, and the transaction is recorded in the database.

The Advanced File Transfer feature is installed using a package that is separate from the XCP server software. After you install it, you configure the feature in a Connection Manager as a handler for the Web Command Processor.

Instructions for installing the Advanced File Transfer handler are provided in the Jabber XCP 5.0 Installation Guide.


• Configuring the Advanced File Transfer Handler• Configuring an Open Port

Jabber XCP 5.0 Configuration Guide Chapter 3. Advanced File Transfer

Configuring the Advanced File Transfer Handler

Configuring the Advanced File Transfer HandlerYou configure the Advanced File Transfer Handler as part of the Web Command Processor (WebCP) within a Connection Manager (CM). Although you can add the AFT Handler to an existing CM that is configured with a WebCP, we recommend that you configure the handler in its own CM so that the CM can be dedicated exclusively to transferring files.

To configure the Advanced File Transfer Handler

1. Make sure you are using the Controller’s Intermediate or Advanced configuration view.

2. In the Components area on the Controller’s main screen, click Go to add a new Connection Manager.

3. In the Connection Manager Configuration screen, use the online help as needed to configure the Connection Manager.

4. In the Connection Manager Configuration area, select Web Command Processor in the drop-down list, and click Go.

If you already have a Web Command Processor, click the Details link next to its name to edit it rather than adding a

new one.

Chapter 3. Advanced File Transfer Jabber XCP 5.0 Configuration Guide


5. Add an HTTP director, and use the online help as needed to complete its configuration.

If you are editing an existing WebCP that already has an HTTP director, you do not have to add another director.

6. In the WEBCP Configuration area on the Web Command Processor Configuration screen, click Go to add an Advanced File Transfer Handler.

7. The upper portion of the Advanced File Transfer Handler Configuration screen is shown in the following figure using the Controller’s Advanced configuration view. Change the configuration parameters as needed using the descriptions provided in the following table.

The parameters are described as follows:

Parameter Description

Connection Type With a connect connection type, the router connects to the handler.

With an accept connection type, the router opens a specific port and listens on that port for a connection from the handler. By default, the router uses the accept method to listen for connections from all components.



8. A database is required for the Advanced File Transfer handler. If you configured a database for the Core Router in the Global Settings Configuration screen, you do not have to configure one here. However, if you did not configure a global database or want to use a different database for AFT, select the Database Setup option and configure the parameters.

Component IP For a connect connection type, enter the IP address or hostname of the system on which the AFT handler’s CM is installed.

For an accept connection type, enter the IP address or FQDN on which the router listens for the AFT handler.

Port For a connect connection type, enter the port that the handler uses for communications.

For an accept connection type, enter the port on which the router listens for the handler’s connection. The router allows only a single connection over this port at a time; therefore, multiple versions of the handler cannot connect over the same port.

Password Enter the password that the router uses to authenticate the component.

Number of threads to use for HTTP file transfers

Enter the number of threads that you want the AFT handler to use for processing HTTP file transfers.

HTTP URI Paths Handled

This option displays only in the Controller’s Advanced configuration view.

The HTTP URI Path is simply a prefix that the WebCP uses to determine what handler to use for a particular HTTP request. The default path for this handler is /files.





9. Configure the following parameters.



Datasource name For the PostgreSQL database, this is the name of the datasource as specified in the .odbc.ini file. For Oracle, the datasource is specified in the ORACLE_SID environment variable or in the tsnames.ora file.

Database user name Enter the username used to connect to the database.

Database user’s password

Enter the password used to connect to the database.

Confirm password Enter the password again to confirm it.

Database type Select the type of database you are using from the pull-down list.

Important! If you select postgresql-odbc, you must add the line, “MaxVarcharSize=4000” to the datasource definition in the .odbc.ini file.

Number of connections to the database

Enter the number of connections that you want this handler to use for processing requests.

Time in seconds between database connection heartbeats

Enter the number of seconds after which the database connection should refresh. Do not set this value to 0 without contacting Jabber support.

Is database debug logging enabled?

This option displays only in the Controller’s Advanced configuration view.

Select Yes to log database debug information.

Database logging uses jabberd’s logging facility. The Jabberd logger must be set to DEBUG for database logging to occur.


Maximum file size (in bytes)

Enter the maximum-size file that can be transferred. ‘0’ means the file size is unlimited (the OS maximum file size, which is typically 4 GB).



10. Select the scanning program option if you want to scan all files that are uploaded for transfer. Enter the absolute path to the scanning program; for example, /usr/bin/clamscan.

If you choose not to enable a scanning program, uploaded files are sent directly to the archive directory. Click Submit to save your configuration.

For the Windows XCP server, 16-bit scanning applications are not supported. Only 32-bit scanning applications are supported.

Host name This is the host filter of the AFT handler. The default host filter simply adds “aft.” onto the beginning of the XCP server’s host name.

Important! This host name must be specified in the Host Filter text field in the AFT’s Open Port configuration.

Base URL of Advanced File Transfer handler

This is the URL that clients will use to connect to the AFT handler. The host portion of this URL must be resolvable in DNS.

Important! You must make sure that the HTTP director’s port number is appended onto the end of this URL; for example:http://aft.corp.example.com:7335

7335 is the default setting. If this is incorrect, you must change it.

Absolute path of the staging directory

Enter the absolute path to the directory in which uploaded files will be staged temporarily while they are being scanned. This directory must already exist, and should be located on the same machine on which the AFT CM is installed.

Absolute path of the archive directory

Enter the absolute path to the directory in which files that are successfully scanned will be archived. This directory must already exist and should be located on the same machine on which the AFT CM is installed.



Configuring an Open Port

Configuring an Open PortIn addition to providing the information in the Advanced File Transfer Handler Configuration screen, you must configure an Open Port component to enable the AFT Handler to connect to the router.

To configure the open port

1. In the Components area on the Controller’s main screen, select OpenPort from the drop-down list, and click Go.

2. When prompted for an ID for the open port, enter the ID of the AFT Handler and click OK; for example, cm-2_webcp-1_aft-1.

3. In the OpenPort Configuration screen, change the description to something like AFT Open Port.

4. The open port must use a connection type that is opposite the one specified for the AFT Handler. By default, the AFT Handler’s connection type is set to connect, and the open port’s connection type is set to accept (using the Master Accept Port configure for the core router).

If you need to change the open port’s connection type to connect, select the Router Outbound Connection Information option, and specify the same component IP, port, and password that you used for the AFT handler.


Configuring an Open Port

5. In the open port’s Hostnames for this Component text field, enter the AFT handler’s hostname; for example, aft.corp.example.com.

6. Click Submit to save your configuration. Click Submit in the Web Command Processor and Connection Manager screens as well.



Chapter 4. External Command Interface and WebEx

The External Command Interface (ECI) component integrates with the WebEx application. It allows Jabber client users to create WebEx meetings and to send meeting invitations to contacts. The component also allows you to add your own custom commands. For example, you could create a command to allow users to request vacation time or to enter timecard information, or even to perform user administration. Commands that you create must comply with JEP-0050, Ad-Hoc Commands.

Before You Configure the WebEx CommandBefore you can configure the WebEx command, you must have the following in place:

• You must be provisioned by WebEx

• You must have received the following information from WebEx: Hostname prefix, WebEx PID, Site ID, Default meeting type

• Port 443 must be open on your firewall, since the WebEx command makes an outbound connection to https://<host_prefix>/webex.com:443

Jabber XCP 5.0 Configuration Guide Chapter 4. External Command Interface and WebEx

Configuring the WebEx Command

Configuring the WebEx CommandThis section describes how to configure the WebEx command in the External Command Interface component.

To configure the WebEx Command

1. In the Components area on the Controller’s main screen, select External Command Interface from the drop-down list, and click Go.

The External Command Interface Configuration screen is shown in the following figure in the Basic configuration view.

Chapter 4. External Command Interface and WebEx Jabber XCP 5.0 Configuration Guide


The parameters available in the Basic view are sufficient for enabling the WebEx command in your environment. If you want to change Intermediate or Advanced configuration settings, use the online help provided in the Controller for parameter descriptions.

2. Configure the Basic parameters using the descriptions provided in the following table:


ID The Jabber ID of this component. This is a read-only value that is generated by the Controller; the value increments automatically as you add additional ECI components.

Description The description displays in the Components area on the Controller main window when you add an ECI component.

You can change the description if desired. It should help you distinguish between ECI components if you have more than one installed.

Router Outbound Connection Information

Select this option only if you want the router to connect to the component. For example, if the component is running outside your firewall, this option allows the XCP router to connect to the component safely rather than introducing security risks by having the component connect to it.

By default, components connect to the router using the Master Accept Port that is configured for the Core Router.

Component IP Enter the IP address or hostname of the system on which the component is installed.

Port Enter the port that the component uses for communications.

WebEx Collaboration Command

Select this option to configure the WebEx command.

The WebEx collaboration command sends two jabber:x:data forms to the user. The first form requests the user’s WebEx username and password, and the second form requests the meeting topic and the list of Jabber IDs of those to invite to the meeting.

Node Enter a unique identifier for this command; for example, WebEx.

The following options require information that you receive from WebEx.

Hostname prefix Enter the host prefix used to access the WebEx server.

The WebEx command makes an outbound connection to https://<host_prefix>/webex.com:443.

WebEx PID Enter your WebEx partner ID.

Jabber XCP 5.0 Configuration Guide Chapter 4. External Command Interface and WebEx



4. Restart the system.

Site ID Enter your site ID.

Default Meeting Type

Enter the numeric code that denotes the meeting type. The default value is ‘3’, which indicates WebEx Meeting Center Pro.


Chapter 4. External Command Interface and WebEx Jabber XCP 5.0 Configuration Guide

Chapter 5. SNMP

The Simple Network Management Protocol (SNMP) is the de facto standard for internetwork management. Jabber, Inc. has implemented SNMP functionality into its Extensible Communications Platform server software so that you can use standard SNMP monitoring tools to monitor the server. Through the XCP Controller, you can enable or disable the use of SNMP individually for each server component and router plugin, including the core router.

Net-snmp AgentTo use SNMP with the Jabber XCP Server, you must install net-snmp-5.0.9, an open source product. The net-snmp agent must be installed on each system on which an SNMP-enabled Jabber component or plugin is running. Depending on which version of the SNMP daemon you install, it will listen on a specific Named Pipe for agentx communications. For example:/var/agentx/master

Note: A Named Pipe is a local socket to which Jabber components connect in order to pass information to the SNMP server. The SNMP server then passes the information to your remote SNMP console application.

By default, our components use /var/agentx/master as the expected location for agentx queries. We recommend that you verify that this Named Pipe has read/write permissions set for the Jabber user (that is, for the user as whom you run the Jabber XCP server). Our components write information to it.

Jabber XCP 5.0 Configuration Guide Chapter 5. SNMP

MIBs

If your daemon listens on a different Named Pipe, you need to export the JABBER_AGENTX variable. For example:export JABBER_AGENTX=/var/snmp/agentx

MIBsManagement Information Bases (MIBs), which define the properties of the Jabber XCP components, are included with the Jabber XCP installation in the xcpInstallDir/support directory. You can plug these MIBs into your SNMP tool to view the collected data.

CountersThe following counters are supported by Jabber Inc.’s SNMP implementation.

Counters Available for All Components• Component ID• Number of bytes into the component• Number of bytes out of the component• Number of packets into the component• Number of packets out of the component• Number of packets dropped by the component• Number of error packets received by the component• Number of error packets generated by the component• Component version

Command Manager Counters• Table of all Jabber Command Managers on this host• A single row in the Command Managers table• Index value into the table• PID of the process running this CommandMgr• Table of all commands handled by this CommandMgr• A single row in the commands table

Chapter 5. SNMP Jabber XCP 5.0 Configuration Guide

Counters

• Index value into the table• Command node identifier• Total number of successful commands• Total number of failed commands• Total number of timed-out commands

Connection Manager Counters• Component ID• Table of all directors connected to this CM• Total number of connected sockets• Total number of sockets reaped/closed

File Transfer Proxy Counters• File Transfer Proxy transaction vectors• Number of files transferred• Number of files failed/rejected• Number of bytes transferred

JSM Counters• Component ID• Number of message stanzas received by this component• Number of message stanzas sent by this component• Number of presence stanzas received by this component• Number of presence stanzas sent by this component• Number of IQ stanzas received by this component• Number of IQ stanzas sent by this component• Current number of IM sessions being managed by this component• Current number of users online being managed by this component• Number of messages sent to offline storage by this component• Total number of successful sessions created by this component• Total number of failed attempts to create a session


Counters

Router Counters• Router ID• Number of connected components• Number of normal packets• Number of xdb packets• Number of log packets• Number of route packets• Id and port for connected component• Component ID• Remote host that runs this component• Port that is used by this component• Type of component (Service, log, xdb, etc.)• List of hosts for which this service gets packets• List of xdb namespaces to which this service responds• List of log namespaces to which this service responds

Server-to-Server Counters• Number of connected incoming domains• Number of connected outgoing domains• Table of all server-to-server connection statistics• Hostname of connected server• Date connection was established• Number of packets sent/received on this connection• Time of last packet sent/received• Type of S2S Director - in/out• Text Conferencing Counters• ID for this component• Total number of all types of rooms• Total number of adHoc rooms• Total number of persistent rooms• Total number of rooms created• Total number of deleted rooms

Waitlist Counters• Waitlist transaction information• Table of waitlist transactions• A single row of transaction columns


Enabling SNMP

• Index value into the table• Number of successful transactions• Number of failed transactions• Number of currently pending transactions• Number of inbound viral marketing requests• Number of outbound viral marketing requests

Web Services Counters• ID for this component• Total number requests

Enabling SNMPAs stated previously, you can use the XCP Controller to enable or disable the use of SNMP individually for each component and router plugin, including the core router. The following figure shows the area in the component and plugin configuration screens in which you enable SNMP.

To enable SNMP for a component or plugin:

1. In the configuration screen, scroll down to SNMP Configuration and click the checkbox next to it to enable the options. The Enable SNMP option is enabled by default.

2. Select Yes for Count Errors only if you want to enable SNMP error counting. This option takes a great deal of server resource; use it with caution.



Enabling SNMP


Chapter 6. Single Domain Name Support

This chapter provides instructions for configuring the Single Domain Name Support (SDNS) component, one of the XCP server’s most advanced features.

The following sections are provided in this chapter:

• Overview• Configuring SDNS in Geographically Dispersed Installations• Configuring SDNS in Local Installations• Configuring SDNS for LDAP

OverviewSingle Domain Name Support (SDNS) provides a method of distributing the load for a single domain over multiple, equivalent components (for example, multiple JSM components). The SDNS component accomplishes this by allowing you to deploy a single domain name across a network of XCP routers and components on different pieces of hardware, even at different locations or with different subdomain names. SDNS allows two components with equivalent capabilities to act side by side, thereby reducing performance bottlenecks and increasing the number of concurrent users that are supported on each system.

Delivering a single domain name (also known as a single namespace) helps globally-based customers who want to disperse IT resources geographically or to obscure their network architecture from users. SDNS is also useful for customers with demanding scalability requirements.

Jabber XCP 5.0 Configuration Guide Chapter 6. Single Domain Name Support

Overview

For example, using SDNS with two JSMs, the global domain, example.com, may be broken down into multiple subdomains using the JSMs’ hostnames (for example, denver.example.com and london.example.com). The SDNS component uses the JSMs’ id.realms (for example, jsm-1.denver and jsm-1.london) to map the correct subdomain within the global domain. The mapping between global domain and subdomain can be maintained in LDAP (using the SDNS Command) or in an RDBMS, and replicated across all sites. It may also be determined using a hashing algorithm. The SDNS component manages all packets bound for the global domain and rewrites the addresses on each stanza so that the router can redirect it to the appropriate subdomain. All rewriting is transparent to the user.

If you are using an LDAP database, you must configure the SDNS command in the Jabber Directory Suite rather than configuring an SDNS component. To configure the SDNS command, follow the instructions in “Configuring SDNS for LDAP” on page 78.

Which Components to Use with SDNSThe Jabber XCP components that make the most effective use of SDNS are JSM, Text Conferencing, and Information Broker. When you use SDNS to “front” for one or more of these components, you can configure an SDNS component on each router for each component. If you are configuring SDNS for geographically dispersed locations, you must also configure a Router-to-Router Connection component on the router that is establishing the outgoing connection.

SDNS is limited with regards to disco searches. When multiple, equivalent components are configured for SDNS, only one of the components will be searched when a disco request is received. For example, when multiple Text Conferencing components are configured for SDNS and a user searches for existing conference rooms, only one of the TC components will be searched. Likewise, for Information Broker, when a user searches for existing categories, only one of the Information Broker components will be searched.

Chapter 6. Single Domain Name Support Jabber XCP 5.0 Configuration Guide

Overview

Choosing a Mapping AlgorithmWhen you configure the SDNS component, you can choose between the database mapping algorithm and the modulo mapping algorithm (or you can write your own) to store the mapping between subdomains and the global domain in a supported database.

Modulo mapping algorithm

The Modulo Mapping Algorithm algorithmically determines the mapping between the global domain and subdomains, and is particularly effective if your scalability needs are high. This algorithm is faster than the database mapping algorithm; however, it provides less control over where stanzas are rerouted. The modulo mapping algorithm uses the mathematical function “modulo” to map to the correct subdomain within the global domain by hashing the user/host Jabber ID and using the integral hash value modulo the number of components.

Figure 12 shows the Modulo Mapping Algorithm section in the SDNS Configuration screen.

Figure 12. Modulo Mapping Algorithm configuration

The database mapping

algorithm

The database mapping algorithm is recommended for geographically distributed setups, and is used most effectively for JSM when users must be mapped to different locations, such as Denver and London. This algorithm is not as fast as the modulo mapping algorithm, but it provides finer control over where stanzas are rerouted.

Figure 13 shows the Database Mapping Algorithm section in the SDNS Configuration screen. SDNS will use the global database set up in the Core Router configuration if do not configure the Database Setup option shown in the figure. If you prefer to use a database other than the one that is configured globally, you can configure another one here.


Overview

Figure 13. Database Mapping Algorithm configuration

If you select the database mapping algorithm, you must insert mapping information (JID and MAPPED_HOST) into the SDNS_MAP table in your database.

If you have multiple SDNS components that use the database mapping algorithm, you must have a separate SDNS_MAP table for each component. This means that you must create a separate database (if you are using Oracle) or a separate tablespace (if you are using PostgreSQL) for each SDNS component. Figure 14 illustrates this.


Configuring SDNS in Geographically Dispersed Installations

DaData

InfoDat

Data

B

sB

Figure 14. Multiple SDNS components and SDNS_MAP tables

Configuring SDNS in Geographically Dispersed InstallationsThis section provides two example SDNS configurations for the hypothetical company, example.com, which has one XCP installation in Denver and another in London. During installation, the realm for the Denver router was specified as “denver”; likewise, the London router was given the realm, “london”. The configuration of SDNS for a remote deployment of this type requires you to:

• Configure an SDNS component on each router for every component being fronted by SDNS. For example, if you are using SDNS for JSM and for Information Broker, you must have two SDNS components on each router: one for JSM and one for Information Broker. (This scenario is described in “Example – Configuring SDNS for JSM and Information Broker” on page 70.)

• Configure a Router-to-Router Connection component on the router that is establishing the outbound connection.

Text Conferencing SDNSDatasource Name=PostgresDatabase User Name=TCDB

Text Conferencing SDNSDatasource Name=Oracle

Database User Name=TCDB

JSM SDNStasource Name=Oraclebase User Name=JSMDB

Each database/tablespace has its own

SDNS_MAP table.

rmation Broker SDNSasource Name=Oraclebase User Name=IBDB

jabberdrealm=denver

JSM SDNSDatasource Name=Postgres

Database User Name=JSMD

Information Broker SDNSDatasource Name=PostgreDatabase User Name=IBD

denver.example.com london.example.com

Database:TCDB

Database:JSMDB

Database:IBDB

Tablespace:TCDB

Tablespace:JSMDB

Tablespace:IBDB

Oracledatabases

PostgreSQLtablespaces

jabberdrealm=london

Router-to-Router

connection



Example – Configuring SDNS for Text ConferencingFigure 15 illustrates how SDNS is being used for Text Conferencing in the company, example.com. The SDNS components and the Router-to-Router Connection are facilitating communication between the Text Conferencing components on the two routers, thus allowing users in both Denver and London to participate in conference rooms created on either router without having to know on which physical server a conference room is located. As you can see, for this configuration, each router must have a TC component and an SDNS component. The Router-to-Router Connection component is configured on the Denver router, which has established the outbound connection.

In this example, we’ll use the Modulo Mapping Algorithm when we configure the SDNS components. An example of using the Database Algorithm is provided in “Configuring SDNS for JSM” on page 72.

Figure 15. Example SDNS configuration for Text Conferencing

SDNStc-1.denvertc-1.london

Text Conferencingtc-1.denver

jabberdrealm=denver

jabberdrealm=london

SDNStc-1.denvertc-1.london

Router-to-RouterConnection

conference.example.com conference.example.com

Text Conferencingtc-1.london

[email protected]/denver

Denver London

Connection Mgr

jsmcp.london

Connection Mgr

jsmcp.denver

Denver establishedoutgoing connection

[email protected]/london



Configuring the Text

Conferencing component

In order to work correctly, the Text Conferencing configuration must not contain any hostnames. (This is true for the TC components on both routers.) The hostname that would ordinarily be entered in the TC configuration is, instead, entered in the SDNS Configuration screen.

To configure the TC component

1. In the Components area on the Controller’s main screen, click the Edit link beside the tc component.

2. In the Text Conferencing Configuration screen, scroll down to the Hostnames for this Component area, and remove the hostname from the text field as shown in the following figure.




Configuring the SDNS

component

The SDNS components on both routers must be configured using the Text Conferencing hostnames and the id.realms of the Text Conferencing components in both locations.

You must use the Controller’s Advanced configuration view to configure the SDNS component.

To configure the SDNS component

1. In the Components area on the Controller’s main screen, select Single Domain Name Support in the drop-down list and click Go.

2. In the Single Domain Name Support Configuration screen, scroll down to the Hostnames for this Component area. By default, the text field contains the hostname of the XCP server.

3. Enter the TC hostname in the text field; for example, conference.example.com.

4. Scroll down to the Single Domain Name Support Configuration area. You can choose either the Modulo Mapping Algorithm or the Database Mapping Algorithm. In this example, we’ll use the Modulo Mapping Algorithm.

5. Click the Modulo Mapping Algorithm radio button to enable the feature.

6. In the Components text field, enter the id.realms of the TC components on each router; for example, tc-1.denver and tc-1.london.




Configuring a Router-to-

Router Connection

Finally, to establish communication between the Denver and London routers, you must configure a Router-to-Router Connection component on the router that is making the outbound connection. In this example, we’ll configure the component on the Denver router.

To configure the Router-to-Router Connection on the Denver router

1. In the Components are on the Controller’s main screen, select Router-to-Router Connection in the drop-down list, and click Go.

2. In the Router-to-Router Connection Configuration screen, do the following:

- Change to the Controller’s Advanced configuration view (you should already be using that view from configuring SDNS).

- For Component IP, enter the London router’s IP address.

- For Port, enter the port specified for the London router’s Master Accept Port.



- For Password, enter the password specified for the London router’s Master Accept Port.


Example – Configuring SDNS for JSM and Information BrokerThis example provide a slightly more complex scenario in which SDNS is being configured for both JSM and Information Broker in the company, example.com. The following figure illustrates the use of SDNS to distribute the load across two JSMs. It also illustrates the use of SDNS to facilitate communication between the Information Broker components on the two routers, allowing users in both Denver and London to create, publish to, and subscribe to nodes within categories on either router. As you can see, for this configuration, each router must have a JSM, an Information Broker component, and two SDNS components. A Router-to-Router Connection component must be configured on the router that is establishing the outbound connection: in this example, Denver.



Figure 16. SDNS Configuration for JSM and Information Broker

Configuring JSM In order to work correctly with SDNS, the Jabber Session Manager configurations on both routers must not contain any hostnames. The hostname that would ordinarily be entered in the JSM configuration is, instead, entered in the SDNS configuration.

To configure the JSM plugins

1. In the Router area on the Controller’s main screen, click the Edit link beside Jabber Session Manager.

2. In the Jabber Session Manager Configuration screen, scroll down to the Hostnames for this Component area and remove the hostname from the text field as shown in the following figure.

SDNSinfo-broker-1.denverinfo-broker-1.london

Information Brokerinfo-broker-1.denver

jabberdrealm=denver

jabberdrealm=london

SDNSinfo-broker-1.denverinfo-broker-1.london

SDNSjsm-1.denverjsm-1.london

JSMjsm-1.denver

JSMjsm-1.london

SDNSjsm-1.denverjsm-1.london

Open PortID=London

Connection Mgr

info-broker.example.com info-broker.example.com

jsmcp.denver

Connection Mgr

jsmcp.london

Information Brokerinfo-broker-1.london

example.com example.com

[email protected]/denver

[email protected]/london

Denver London

Denver establishedoutbound connection



3. Scroll down to the JSM Features area, and select Yes beside Apply Single Domain Name Support semantics to local user lookups.


5. Repeat this procedure for the JSM plugin on the other router.

Configuring SDNS for JSM

You must configure an SDNS component on each router for the corresponding JSM plugins. In this example, the SDNS components are configured using the database mapping algorithm. This algorithm is used most effectively for JSM when users are being mapped to different locations.

To configure SDNS components for JSM

1. In the Components area of the Controller’s main screen, select Single Domain Name Support from the drop-down list, and click Go.In the Single Domain Name Support Configuration screen, scroll down to the Hostnames for this Component area. In the text box, enter the JSM hostname; for example; example.com.

2. Scroll down to the Single Domain Name Support Configuration area, and click the radio button above Database Mapping Algorithm to enable the option. Do the following:

- Under Algorithm Input Generator, make sure that standard_algo_input is selected in the Load drop-down list.



- If you want to use a database other than the database configured in the Core Router configuration, select the Database Setup option. Configure the settings using the online help as needed.

You must use the sdns_util program (located in $JABBER_HOME/support) to insert users’ Jabber IDs and Mapped_Hosts into your database.

3. In the Default Mapping for lookup failure text field, enter the id.realm of the component to which you want to direct host-only Jabber IDs. The component that you specify here is the “catch-all” component to which users, conference rooms, or nodes are directed when they are not listed in the SDNS_MAP table in your database. For example, if you specify tc-2.denver here, all of the conference rooms that are not listed in your SDNS_MAP table will be directed to the Text Conferencing component, tc-2.denver.

Since all unresolved database lookups will be directed to the “catch-all” host, you might consider using a more powerful machine for the host.


5. Repeat this procedure for the SDNS component on the other router.



Configuring Information

Broker

The Information Broker configurations on both routers must contain no hostnames. The hostname that would ordinarily be entered in the Information Broker configuration is, instead, entered in the SDNS configuration.

To configure the Information Broker components

1. In the Component area on the Controller’s main screen, click the Edit link beside Information Broker.

2. In the Information Broker Configuration screen, scroll down to the Hostnames for this Component area, and remove the hostname from the text field.


4. Repeat this procedure for the Information Broker component on the other router.

Configuring SDNS for

Information Broker

You must configure an SDNS component on each router for the corresponding Information Broker components. In this example, the Modulo Mapping Algorithm in the SDNS configuration is used.

To configure SDNS Components for Information Broker

1. In the Components area of the Controller’s main screen, select Single Domain Name Support from the drop-down list, and click Go.



2. In the Single Domain Name Support Configuration screen, scroll down to the Hostnames for this Component area. In the text box, enter the Information Broker hostname; for example; info-broker.example.com.

3. Scroll down to the Single Domain Name Support Configuration area, and click the radio button above Modulo Mapping Algorithm to enable the option. Do the following:

- Under Algorithm Input Generator, select infobroker_algo_input in the Load drop-down list.

- In the Components text box, enter the id.realms of the Information Broker components that are configured on each router; for example:

info-broker-1.denver info-broker-1.london

These id.realms must be entered in the same order in each cooperating SDNS component’s configuration.


5. Repeat this procedure for the SDNS component on the other router.



Configuring a Router-to-

Router Connection

Finally, you must configure a Router-to-Router Connection component on the router that is making the outbound connection. In this example, we’ll configure the component on the Denver router.

To configure the Router-to-Router Connection on the Denver router

1. In the Components are on the Controller’s main screen, select Router-to-Router Connection in the drop-down list, and click Go.

2. In the Router-to-Router Connection Configuration screen, do the following:

- Change to the Controller’s Advanced configuration view (you should already be using that view from configuring SDNS).

- For Component IP, enter the London router’s IP address.

- For Port, enter the port specified for the London router’s Master Accept Port.

- For Password, enter the password specified for the London router’s Master Accept Port.



Configuring SDNS in Local Installations

Configuring SDNS in Local InstallationsA “local installation” is one in which multiple routers are installed within the same physical subnet and share the same cluster. Jabber XCP’s new dynamic routing feature enables all components within the installation, regardless of which router they are installed on, to discover each other automatically.

To use SDNS in this scenario, you must still configure an SDNS component on each router for each component that is using SDNS. The only difference in this configuration and the geographically distributed configuration is that a Router-to-Router Connection component is not required for the routers to communicate.

For example, let’s say that a local configuration has two routers (as shown in Figure 17), and that both routers have a TC component. You want users connected to either router to be able to use TC rooms that exist across the entire installation. You must configure an SDNS component for TC on each router. Through dynamic routing, each router becomes aware of the new SDNS component on the other, and updates its routing table accordingly. TC users connected to either router are now able to see and use TC rooms configured on both routers without being aware of which router the rooms are on.

Figure 17. SDNS in a Local Installation

SDNS-1.R1 SDNS-1.R2

R1 R2

TC-1.R2TC-1.R1

This connectionhappens automatically

Same physicalsubnet

Same cluster


Configuring SDNS for LDAP

Configuring SDNS for LDAPIf you are using an LDAP database, you must configure the SDNS command within your Jabber Directory Suite (JDS) component rather than configuring an SDNS component as described in the previous sections in this chapter. The SDNS command allows you to use LDAP attributes to map users and hosts to subdomain names, and to map global domains to subdomains when no user is provided. In almost all cases, the SDNS command sends users to different JSMs. When you configure the SDNS command, the JDS, in effect, becomes your SDNS component.

This method is especially effective for configuring SDNS in geographically distributed setups, and is typically applied against JSM.

To configure SDNS for LDAP

1. In the Components area on the Controller’s main screen, select Jabber Directory Suite in the pull-down list, and click Go.

2. Configure the JDS component using the Controller’s online help.

3. Under Databases, click Go to add an LDAP database. This is where you will configure the SDNS command.

4. Configure your LDAP database using the online help.



5. In the JDS Command Definitions area on the Database Configuration screen, click the checkbox beside Single Domain Name Support (SDNS) to enable the command.

6. Enter the required information as described in the following table:

7. When you have finished configuring the LDAP database, click Submit to save your configuration. You are returned to the Jabber Directory Suite Configuration screen.

8. When you have finished configuring the Jabber Directory Suite, click Submit. You are returned to the Controller’s main screen.

9. Since the SDNS feature is applied to JSM when you configure it through JDS, you must modify the JSM plugin in the same way it is modified when the SDNS component is used (see “Configuring JSM” on page 71).

In the Router area on the Controller’s main screen, click the Edit link beside Jabber Session Manager.

Text field Description

Custom Library Leave this field blank unless you want to use a custom SDNS command.

The host name to map Enter the server name of the global domain being mapped; for example; example.com.

The LDAP entry attribute containing the host map value

Enter the LDAP attribute that contains the domain used to rewrite users’ Jabber IDs; for example, jabberHost. For example, if the Jabber ID [email protected] must be rewritten as [email protected] the jabberHost attribute should contain denver.example.com.

The component ID to use when rewriting host-only addresses

Enter the id.realm of the authoritative responder to requests that contain only a server name without a userid; for example, disco requests.

Since this command is used mainly to send users to different JSMs, an example id.realm is jsm-1.jabber.



10. In the Jabber Session Manager Configuration screen, scroll down to the Hostnames for this Component area, and remove any hostnames from the text field.

11. Scroll down to the JSM Features area, and select Yes beside Apply Single Domain Name Support semantics to local user lookups.


13. Restart the XCP server.


Chapter 7. WebServices

This chapter describes how to configure the Web Services package to allow custom-built applications and components to access Jabber XCP services, including messaging, roster/presence, and Information Broker. (Installation instructions are provided in the “Special Features” chapter in the Jabber XCP Installation Guide.


• Configuring Web Services• Service-Specific Configurations• Invoking Services from a SOAP-over-HTTP Client• Web Services Definition Language Files

Configuring Web ServicesYou must configure Web Services through the Jabber XCP Controller, which is the Web-based interface used to configure the Jabber XCP server’s components and plugins. Instructions for starting the Jabber XCP Controller are provided in the “Standard Operations” chapter in the Jabber XCP 5.0 Installation Guide.

Online help is provided with the Jabber XCP Controller. Use the help to answer any questions you may have regarding text field and option definitions.

Jabber XCP 5.0 Configuration Guide Chapter 7. WebServices

Configuring Web Services

Add a Web Services ComponentThe Web Services component specifies which Jabber XCP services are available to the Web Services application.

To add a Web Services component to your Jabber XCP configuration:

1. Change to the Controller’s Intermediate or Advanced configuration view.

2. In the Components area on the Controller’s main screen, select Web Services from the pull-down list and click the Go button.

3. In the Web Services Configuration screen, configure the Web Services component using the Controller’s online help if necessary. (The first Web Services component that you add will have web-services-1 for its ID.)

4. In the Services section (shown below), click the Go button to add a Web service.

The Service Configuration screen displays.

Chapter 7. WebServices Jabber XCP 5.0 Configuration Guide

Configuring Web

5. In the Service Configuration screen, enter one of the following namespaces in the Namespace for this service field depending on the service you want to make available:

- http://jabber.com/webservices/Messaging- http://jabber.com/webservices/RosterPresence- http://jabber.com/webservices/InfoBroker

These namespaces are built into the WebServices API and are the only ones currently supported. Do not modify them.

6. Leave the Service library field blank unless you are using a custom library.

7. In the Service load function field, enter the server function that loads the service; depending on the namespace you entered in step 5, the function is one of following:

- ws_messaging- ws_rosterpresence- ws_infobroker

8. Submit the service configuration. You are returned to the Web Services Configuration screen.

9. From the Web Services Configuration screen, add more services as needed.

10. Submit the Web Services component’s configuration.

Configure a Web Services Connection ManagerIn order to facilitate high performance for Web Services, we recommend that you configure a separate CM for each Web Services component that you add to the Jabber XCP configuration. (In other words, do not add a the Web Command Processor to an existing CM.) The CM for Web Services must be configured with a Web Command Processor, an HTTP director, and a SOAPHandler, which translates SOAP-over-HTTP requests into SOAP-over-XMPP and vice versa.

To add and configure a Web Services Connection Manager:

1. In the Components area on the Controller’s main screen, select Connection Manager from the pull-down list and click the Go button. The Connection Manager Configuration screen displays.

2. Configure the CM’s settings using the Controller’s online help if needed.

You can change the default port number if necessary.



3. In the Add a New Command Processor section, select Web Services Command Processor in the drop-down list, and click the Go button.

You must be in the Controller’s Advanced configuration mode to configure a Web Services Command Processor.

The first Web Command processor that you add will have an ID of cm-2_webcp-1 as shown here:

4. In the Director Configuration area, click the Go button to add an HTTP director. The configuration screen is shown in the following figure.


Configuring Web

5. Configure the director’s settings using the online help if needed.

The default port number of the director’s external channel is 7335 (this implements an HTTP server on port 7335 to serve incoming SOAP requests). You can change the port number if necessary.

6. Submit the director’s configuration. You are returned to the WebCP Configuration screen.

7. In the Handlers area on the WebCP Configuration screen, click Go to add a Web Services Handler. The configuration screen is shown below. The Web Services Handler enables the WebCP to talk to the Jabber XCP router, jabberd.



8. In the Web Services Handler Configuration screen, enter the path, /soap. This path is referenced in the WSDL.

9. Submit your configuration both in this screen and in the WebCP Configuration screen.

Add Web Services as a Jabber AdministratorYou must add the ID and realm of the Web Services component as a Jabber administrator in the Jabber Session Manager (JSM) plugin.

The default realm is “jabber.” To see the realm for the current Jabber XCP installation, click the Edit link beside the Core Router in the Plugins area on the Jabber XCP Controller’s main screen. The realm is the second entry under “Global Settings.”

To edit the JSM configuration:

1. In the Router area on the Controller’s main screen, click the Edit link beside the JSM plugin to edit the configuration.

2. In the Jabber Session Manager Configuration screen, add the ID and realm of the Web Services component (for example, web-services-1.jabber) as a Jabber administrator as shown in the following figure.


Configuring Web

3. Submit your configuration changes.

Configure a Web Services AdministratorThe Web Services component must be able to authorize requests coming in from the Web Services Handler. For this to happen, the Web Services Handler must be added as an administrator in the Web Services configuration.

To configure the Web Services administrator:

1. In the Components area on the Controller’s main screen, click the Edit link beside the Web Services component.

2. In the Web Services Configuration screen, add the ID and realm of the Web Services Handler (for example, cm-2_webcp-1_websvch-1.denver) as an administrator as shown in the following figure.

3. Submit your configuration.


Service-Specific Configurations

Service-Specific ConfigurationsThis section describes extra steps that you must take to configure broadcast messages, offline messages, and the Information Broker service.

Broadcast MessagesThe broadcast message function is part of the Messaging service. To enable this function, you must modify the JSM Command Processor’s configuration.

To enable broadcast messages:

1. In the Components area on the Jabber XCP Controller’s main screen, click the Edit link beside the CM component that has a JSM Command Processor. (The CM component that is installed by default with the Jabber XCP server contains a JSM Command Processor.)

If multiple CM components have JSM Command Processors, you must follows these steps for each one.

2. In the Add a new command processor section click the Details link beside the name of the JSM command processor.


Service-Specific

The JSM Command Processor Configuration screen displays as shown below:

3. In the lower portion of the JSM Command Processor Configuration screen, select Yes beside the Enable Broadcast option.



Service-Specific Configurations

Offline MessagingTo enable offline messaging to work correctly with Web Services, the mod_offline_pop module in the JSM configuration must be enabled. The module is enabled by default, and is required for JEP-0013 functionality. Do not change this setting without first consulting Jabber, Inc. support.

To verify that the mod_offline_pop module is enabled:

1. In the Router area on the Controller’s main screen, click the Edit link beside the JSM plugin.

2. In the JSM Configuration screen, under Optional modules, ensure that the checkbox beside mod_offline_pop is enabled as shown below:

3. If you made any changes, click the Submit button at the bottom of the screen to save the configuration.


Invoking Services

Information BrokerThe Information Broker service can create a node and publish information to a node on behalf of a user. To use this service, you must have an Information Broker component in your Jabber XCP server configuration.

To configure the Information Broker for Web Services:

1. In the Components area on the Controller’s main screen, click the Edit link beside the Information Broker component.

2. In the Information Broker Configuration screen, scroll down to the Information Broker Administrators area.

3. In the Admin(s) field, enter the ID and realm of the Web Services component (for example, web-services-1.denver).

4. Submit your configuration changes.

Invoking Services from a SOAP-over-HTTP ClientTo invoke Web services from a SOAP-over-HTTP client, the user sends a SOAP-over-HTTP message to the WebCP SOAPHandler; for example, http://user:[email protected]:7336/soap. User and password must match the username and password that were specified for Web Services during the package’s installation. The username and password are stored in $JABBER_HOME/etc/.websvc_passwd.

You can modify the password if needed by using the admin password command to access the websvc_passwd file.

The WebCP SOAPHandler performs HTTP basic authentication on the message and, if passed, forwards the message to the Web Services component.


Web Services Definition Language Files

Web Services Definition Language FilesThree Web Service Definition Language (WSDL) files are provided with the Web Services package installation. The WSDL files provide all of the information that a client development environment needs in order to generate the framework to invoke the services. The files are located at:

• $JABBER_HOME/htdocs/wsdl/web-services/Messaging.wsdl• $JABBER_HOME/htdocs/wsdl/web-services/RosterPresence.wsdl• $JABBER_HOME/htdocs/wsdl/web-services/InfoBroker.wsdl

Assuming that the controller application is running and listening on port 7300, you can access these files via HTTP by pointing your browser to, for example: https://server.com:7300/wsdl/web-services/Messaging.wsdl

If you have trouble accessing the files through your browser, make sure that you have permissions to access them.


Chapter 8. Active Directory Authentication

This chapter provides instructions for configuring JDS for authentication and user search using Active Directory. The process does not involve extending your ADS schema.

The following tasks are involved:

• Add a Jabber Directory Suite Component• Configure a Directory Server• Configure an LDAP Database• Configure JSM to use JDS

Add a Jabber Directory Suite Component1. On the Jabber XCP Controller’s main screen, in the Components area, select

Jabber Directory Suite from the pull-down list, and click the Go button.

The Jabber Directory Suite Configuration screen displays.

Jabber XCP 5.0 Configuration Guide Chapter 8. Active Directory Authentication

Add a Jabber Directory Suite Component

2. In the Jabber Directory Suite Configuration screen, scroll down to the XDB Filters section, and select all of the namespace filters with the exception of jcp:serverprefs.

3. In the next section, “Hostnames for this Component,” enter ldapsearch.yourJabberServerName.com in the “Host Filters” text box. This configures JDS to accept user search requests.

4. Scroll down until you see the LDAP area, and click Go beside “Add a Directory Server.”

The Directory Server Configuration screen displays.

Chapter 8. Active Directory Authentication Jabber XCP 5.0 Configuration Guide

Configure a Di-

Configure a Directory ServerIn the Directory Server Configuration screen, you configure the connection to your Active Directory server.

1. Using the online help for field descriptions, enter the required information.

Note: The Directory server hostname is probably your Global Catalog (GC) server, but could differ based on your setup of AD. The Directory Server user is the DN of an administrator account or other account that has read access to the authentication information in AD. The GC port is 3268.

2. Click the Submit button to submit your configuration. You are returned to the Jabber Directory Suite Configuration screen.

3. Scroll to the bottom of the screen, and click the Go button beside “Databases” in the LDAP section. The Database Configuration screen opens.


Configure an LDAP Database

Configure an LDAP DatabaseThis section describes the information required to configure your LDAP database. In the Database Configuration screen:

1. In the “Host Filters” text field, enter an asterisk (*) as shown below.

2. Beside “Add a new server,” click the Go button. The Server Configuration screen opens.

3. In the Server Configuration screen, enter the ID of the directory server that you created (see page 95). If you used the default value when you configured the directory server, its ID is “server-1” as shown below.

4. Click the Submit button to save your server configuration. You are returned to the Database Configuration screen.

5. On the Database Configuration screen scroll to the “Jabber User Configuration” section.


Configure an

This section specifies your ADS setup. The values you must enter are described as follows:

6. Next you must define how JDS will build your JIDs. Under “Select exactly one of the following options,” select “Static User JID.”

The values you must enter are described as follows:

7. Scroll down to the “JDS Command Definitions” section. Make sure that the “Authentication” option is checked, then select “Plain-Text Authentication.” You do not need to enter a custom library.

Option Description

LDAP object class for users This value is probably going to be ‘User.’

Base context for this LDAP class

Enter the following:cn=users,dc=server,dc=domain,dc=com

Replace server, domain, and com with the correct values from your AD setup.

LDAP attribute to use for the Jabber display name

The common attribute used is displayName.

Option Description

User Attribute Enter the following:sAMAccountName

Host Enter the hostname of your Jabber server; for example: jabber.example.com


Configure an LDAP Database

8. Select “Register Check” so that JDS can validate Jabber users. Again, you do not need to enter a custom library.

9. Select “ldapSearch command” so that Jabber users can search for other user accounts. (This is not the same thing as vCard information.)

10. Click the Go button, and add the LDAP attributes in the Searchable LDAP Attribute Configuration screen. Click Submit when you have finished.

The LDAP attributes in Active Directory for email, first name, and last name are “mail,” “givenName, and “sn” respectively. Do not enter spaces in the descriptions.

11. You have now configured all of the JDS subcomponents. Click the Submit button on the Database Configuration screen, and then the Submit button on the “Jabber Directory Suite Configuration” screen. If you see any errors, correct them and try again to submit the new JDS component.

On the Jabber XCP Controller’s main screen, you should see a new JDS component with a red “Stopped” banner next to it. You must now restart the system.

12. On the Controller’s main screen, click the Stop the System link, then on the next screen, click start the server now. You should be returned to the Controller’s main screen and see a green “Running” banner next to the JDS component. (If it is stopped, check syslog for errors.)


Configure JSM to

Configure JSM to use JDSNow that JDS is up and running, you must configure the JSM plugin to use JDS.

1. On the Controller’s main screen, click the Edit link beside “jsm” in the Router area to display the Jabber Session Manager Configuration screen.

2. In the “Optional modules” section, check “mod_jds.” Uncheck “mod_auth_plain,” “mod_auth_digest,” and “mod_register.” This enables JDS for authentication and turns off the default authentication.

3. Scroll down to the “JDS Configuration” option, and click the checkbox to enable it. Set both “Digest Configuration” and “Community Groups” options to “no.”


Configure JSM to use JDS

4. Scroll down to the “Registration Requirements” option and clear the checkbox to disable it, since your users are already registered in Active Dirctory.

5. Click the Submit button to save your changes.

6. From the Controller’s main screen, restart the server.

7. Test the new configuration by logging into the Jabber XCP server with the Jabber Messenger client, specifying a username and password for a valid AD account. If the login fails, check the JDS component configuration, syslog, and LDAP logs for more detail.


Chapter 9. HTTP Polling Connections

This chapter provides instructions for configuring an HTTP Polling Connection Manager for your XCP server. HTTP polling connections enable you to use Jabber Inc.’s WebClient and other HTTP clients. This type of connection allows users to access your XCP server without requiring any changes to network or firewall settings.

The process for configuring an HTTP polling connection involves adding a new Connection Manager (CM) to your XCP server. This CM must be configured with a JSM Command Processor and an HTTP Polling director. In this chapter, we set the director’s port to 8080. If you want the director ro listen on port 80 or 443, you must start the CM as root.

Figure 18 illustrates the CM that WebClient uses to connect to the Jabber XCP server using Polling XMPP over HTTP. The figure also shows the CMs used by the XCP Controller and by the Jabber Messenger client.

Jabber XCP 5.0 Configuration Guide Chapter 9. HTTP Polling Connections

Figure 18. HTTP Polling CM configuration

To configure an HTTP Polling connection

1. Change to the XCP Controller’s Intermediate configuration view. (This view is required to configure the Polling Director.)

2. In the Components area on the Controller’s main screen, click Go to add a new Connection Manager.

3. In the Connection Manager Configuration screen, change the Description to Polling CM.

Connection Manager

Pol

ling

Dire

ctor Polling Gaffer

PollingTranscoder

JSMCP

Connection Manager

HTT

PD

irect

or HTTP Gaffer

HTTPTranscoder

WebCP

HTTP

Connection Manager

XMPP

Dire

ctor XMPP Gaffer

XMPPTranscoder

JSMCP

Router


Polling XMPPover HTTP

Client XMPP

XCP ControllerWeb Interface

Chapter 9. HTTP Polling Connections Jabber XCP 5.0 Configuration Guide

4. Under Add a New Command Processor, click Go to add a JSM Command Processor.

5. In the JSM Command Processor Configuration screen, select Polling Director in the pull-down list, and click Go.

6. In the Polling Director Configuration screen, do the following:

- Change the Port to 8080. (If you want to use port 80 or 443, you must start the CM as root.)

- Click the checkbox beside SSL Settings if you want to enable SSL.

Caution! The XCP server does not support private keys for SSL certificates that have pass phrases. If you have a pass phrase or encrypt your private key, your private key/public certificate pair will not load into XCP.

- Click Submit to save your configuration. You are returned to the JSM Command Processor Configuration screen.

Jabber XCP 5.0 Configuration Guide Chapter 9. HTTP Polling Connections

7. Click Submit in the JSM Command Processor Configuration screen. You are returned to the Connection Manager Configuration screen.

8. In the Connection Manager Configuration screen, perform any additional configuration if needed, then click Submit to save your configuration.

No additional configuration is required. You can submit the CM using its remaining default settings if desired.

Chapter 9. HTTP Polling Connections Jabber XCP 5.0 Configuration Guide

Appendix A. Connection Manager Overview

The Connection Manager (CM) enables IM clients and external servers to connect to the Jabber XCP server. You can configure multiple instances of the CM to increase the number of connections your server can handle and to enable communication over different protocols. For example, you might set up a CM on one server that handles SMTP connections to redirect offline messages to an e-mail server (offline messages are messages that are sent to a client while the client is offline). Additionally, you can set up another CM to handle XMPP connections from IM clients (such as Jabber Messenger and WebClient). You can install multiple connection managers on the same server, or you can install them on separate servers if desired.


• Core Components• Default Jabber XCP Configuration• Polling XMPP over HTTP• SMTP CM for Offline E-mail Redirection• Web Services CM• Server-to-Server CM

Jabber XCP 5.0 Configuration Guide

Core Components

Core ComponentsThe following figure illustrates the core components of the Connection Manager.

As shown here, the CM is composed of a “transcoder family” (made up of a director, gaffer, and transcoder) and a command processor (CP). The director guides the interaction between the gaffer and the transcoder. The gaffer receives data over a socket from a client, and converts the protocol, if necessary, so that the transcoder can understand it. The transcoder converts the data into a form that the CP can understand and sends it to the CP; the CP then sends the data to the central router, which sends it on to its final destination.

The command processor and the transcoder family also handle the entire process in the reverse order. Data being sent from the router to a client is received and interpreted by the command processor, which sends it to the transcoder family. The transcoder family translates the data into packets that the client can understand, then sends the information to the client.

Jabber, Inc. recommends that you configure a separate CM to handle each different communication task rather than configuring one CM to do everything. The reasons for this include:

• Scalability – Each CM has a maximum number of connections that it can handle. For example, the client CM can handle only 10,000 concurrent client connections. Your system can handle more client connections if you add additional client CMs.

10,000 connections is a practical limit. There is nothing preventing you from configuring more; however, more connections may cause performance to suffer.

• Different communication protocols – Jabber, Inc. recommends that you configure a separate CM to handle each communication protocol that you plan to use. For example, if you want to configure an SMTP CM that handles communications with wireless clients, add a CM strictly for this purpose rather than adding another JSM command processor to the default client CM.


Default Jabber XCP Configuration

• Redundancy – Configuring separate CMs also helps to ensure that you experience as few communication problems as possible. If the system on which one CM is installed fails, other systems can pick up the slack.

The remainder of this section provides illustrations of the Connection Managers that you can configure with the current release of the Jabber XCP server software. If you are using the WebClient, you can configure a CM that handles HTTP polling connections. You can also configure CMs that handle the SMPP and SMTP protocols for wireless client and mail server connections respectively.

Default Jabber XCP ConfigurationThe Jabber XCP configuration shown in the following figure is installed by default with the Jabber XCP server. This configuration includes two CMs: one to handle the basic client (Jabber Messenger and WebClient) communications over an XMPP connection, and the other to handle input from the Jabber XCP Controller’s web interface over an HTTP connection. The basic configuration also includes the Text Conferencing component.


Default Jabber XCP Configuration

Figure 19. Default Jabber XCP server CM configuration

XMPPTranscoder

Family

JSM CommandProcessor

HTTPTranscoder

Family

Web CommandProcessor

Router (jabberd)


Jabber MessengerWebClient

ConfigManager

TextConferencingComponent

HTTP

XMPP


Polling XMPP over HTTP

Polling XMPP over HTTPThe following figure adds an illustration of the CM that WebClient uses to connect to the Jabber XCP server using Polling XMPP over HTTP. You can configure a polling director for the JSM Command Processor, which uses HTTP to communicate over firewalls using port 80.

Figure 20. HTTP Polling CM configuration

Connection Manager

Pol

ling

Dire

ctor Polling Gaffer

PollingTranscoder

JSMCP

Connection Manager

HTT

PD

irect

or HTTP Gaffer

HTTPTranscoder

WebCP

HTTP

Connection Manager

XMPP

Dire

ctor XMPP Gaffer

XMPPTranscoder

JSMCP

Router


Polling XMPPover HTTP

Client XMPP



SMTP CM for Offline E-mail Redirection

SMTP CM for Offline E-mail RedirectionThe following figure adds an illustration of yet another CM that handles SMTP connections to redirect offline messages to an e-mail server (offline messages are messages that are sent to a client while the client is offline). This configuration uses an SMTP transcoder family and an SMTP command processor.

Figure 21. SMTP CM configuration

Connection ManagerSM

TPD

irect

or SMTP Gaffer

HTTP

Connection Manager

HTT

PD

irect

or

HTTP Gaffer

HTTPTranscoder

WebCP

XMPP

Connection Manager

XMPP

Dire

ctor XMPP Gaffer

XMPPTranscoder

JSMCP

SMTPTranscoder

SMTPCPRouter

JabberMessenger

WebClient


SMTP

Server forOffline e-mail


Web Services CM

Web Services CMThe Web Services Connection Manager is configured with a Web Command Processor (WebCP), which has a SOAPHandler. The WebCP SOAPHandler is used when Web Services applications send SOAP-over-HTTP requests to the Jabber XCP server. It provides the ability to map a URL to a dynamically-loaded handler. The SOAPHandler is responsible for taking the SOAP-over-HTTP request, authenticating it, and translating it into SOAP over XMPP so that it can be routed to the Web Services Component. When a response comes in from the Web Services component, the WebCP SOAPHandler translates it back into SOAP over HTTP, and writes the result back to the requesting application.

Figure 22. Web Services CM with WebCP and SOAPHandler

Connection Manager

HTTP DirectorFamily

Web ServicesOpen Port

Component

WebCP

SOAP overHTTP

Web ServicesApplication

SOAPHandler

SOAP overXMPP

HTT

PD

irect

or HTTP Gaffer

HTTPTranscoder

WebCP

HTTP

Router Web ServicesComponent


Server-to-Server CM

Server-to-Server CMThe server-to-server CM (S2SCM) is configured with an S2S Command Processor (S2SCP). The S2SCP can be configured with an XMPP Incoming Director and an XMPP Outgoing Director for XMPP server-to-server communications. These directors allow you to black- and white-list specific hosts both internal and external to your environment. The Incoming director handles incoming packets being sent to the router from remote servers; the Outgoing director handles packets being sent from the router to remote servers.

The S2SCP can also be configured with a SIMPLE Server Director, which establishes connections with remote SIP connectors and Lotus IM servers. The SIMPLE Gateway requires a separate license and installation.

Figure 23. Server-to-server CM

S2S Connection Manager

S2S Command Processor

XMPPIncoming Dir.

XMPPOutgoing Dir.

XM

PP

InTr

ansc

oder

XMP

P O

utTr

ansc

oder

SIMPLE ServerDirector

SIM

PLE

Tran

scod

er

Internet

Router

Remote XMPPServer

Remote LotusIM Server

SIPConnector


Index

AAdvanced File Transfer

overview of 11advanced file transfer 43

configuring an open port 49configuring the handler 44

architectureXCP 5.0 8

Cclusters

overview of 13component

descriptions of 9logging 39

componentsRouter-to-Router Connection 14

configurationguidelines 19views in the Controller 16

Connection Managercomponent description 9

ControllerComponent area on main screen 18configuration views 16how to use 15online help 19Router area on main screen 18System area on main screen 17

Core Routerdescription of 11

counters for SNMP 56custom logger 42

Ddatabase mapping algorithm 63debug log level 24dynamic routing

overview of 13

Eerror log level 24External Command Interface

component description 9configuring 52WebEx command 51

Ffile logger

configuring 30File Transfer Proxy

component description 9filtered stream logger 41filtered syslog logger 40firewall considerations 20formatting logs 31

Hhardware considerations 21host filters

Jabberd Logger 28

Iinfo log level 24Information Broker

component description 9configuring for SDNS 70, 74

IQ packets 34

JJabber Directory Suite

component description 9Jabber Logging Library 39Jabber Session Manager

description of 11Jabber User Directory

component description 9Jabberd Logger

adding 26configuration 26configuring a file logger 30configuring a standard error logger 30configuring a syslog logger 29configuring log levels 31description of 11formatting logs 31host filters 28namespaces 27

Java external Command Interfacecomponent description 10

Jlog 39configuring the filtered stream logger 41configuring the filtered syslog logger 40


JSMconfiguring for SDNS 70, 71

JSM loggingmessage logs 35packet logs 34session logs 34

LLDAP

configuring SDNS command 78log level

setting 24setting for router-generated packets 24severity levels 24

log levelsconfiguring 31debug 24descriptions of 24error 24info 24verbose 24warn 24

logging 23adding a Jabberd Logger 26adding new custom logger 42changing default logging level 25changing the router’s default log level 25component 39configuring a file logger 30configuring log levels 31decreasing verbosity during runtime 25filtered stream logger 41filtered syslog logger 40formatting a stderr log 30formatting logs 31increasing verbosity during runtime 25JSM message logs 35JSM packet logs 34JSM session logs 34log levels 24Message Archiver 35selecting namespaces for Jabberd Logger 27setting the default log level 24statistics 37viewing the current log level 25

Mmapping algorithms

choosing 63Master Accept Port

overview of 12Message Archiver

component description 10Message Archiver logging 35message logs 35MIBs 56modulo mapping algorithm 63

Nnamespaces

selecting in Jabberd Logger 27net-snmp agent 55network configuration suggestions 19non-IQ packets 34

Oonline help 19Open Port

component description 10Open Port component

configuring for advanced file transfer 49

Ppacket logs 34Presence Mirror

component description 10

Rrouter

changing the default log level 25decreasing log verbosity during runtime 25increasing log verbosity during runtime 25viewing the current log level 25

router plugin descriptions 11Router-to-Router Connection

configuring for JSM and Information Broker in SDNS setup 76

configuring for Text Conferencing in SDNS setup 69

Router-to-Router Connection componentoverview of 14


SSDNS. See Single Domain Name Supportserver statistics logging 37session logs 34severity levels for logging 24Single Domain Name Support

choosing a mapping algorithm 63component description 10configuring for Information Broker 74configuring for JSM 72configuring for LDAP 78configuring in geographically dispersed

installations 65database mapping algorithm 63example of configuring for JSM and

Information Broker 70example of configuring for Text Conferencing

66modulo mapping algorithm 63overview 61which components to use 62

SNMP 55counters 56enabling 59MIBs 56net-snmp agent 55the net-snmp agent 55

statistics logging 37stderr logger

configuring 30stream logger 41syslog logger

configuring 29

TText Conferencing

component description 10configuring with SDNS 66

Vverbose log level 24

WWait List Service

component description 10warn log level 24Web Services

component description 10WebEx integration 51

XXCP

architecture 8


jabber xcp configuration...

Documents