XCP Controller Help. Product Version 4.0 Document Version A GA September 30, 2004

Transcription

1 XCP Controller Help Product Version 4.0 Document Version A GA September 30, 2004

2

3 Table Of Contents Overview...1 Welcome to the Jabber IM/XCP Online Help...1 New Features in Jabber IM/XCP Server-to-Server Command Processor...1 Polling Director...1 Single Domain Name Support...2 Web Services...2 Information Broker...2 Namespaces...4 Single XDB...4 Multiple XDBs...4 Schema-Specific Namespaces...4 Logging...7 Router Logging...7 JSM Logging...7 SNMP...7 Component Logging...7 Using the Jabber IM/XCP Controller...8 The System Area...9 The Router Area...10 The Components Area...10 Online Help...11 Router Plugin Configuration...13 Core Router...13 Core Router Configuration...13 Jabber Session Manager...16 Jabber Session Manager Configuration...16 iii

4 XCP Controller Help Rerouting Packets...28 Redirecting Packets...29 XDB FastFile...31 XDB FastFile Configuration...31 Namespace Configuration...34 Changing User Passwords...35 XDB Berkeley...36 XDB Berkeley Configuration...36 XDB Oracle...39 XDB Oracle Configuration...39 Jabberd Logger...43 Jabberd Logger Configuration...43 Component Configuration...45 Connection Manager...45 Connection Manager Configuration...45 JSM Command Processor...53 SMTP Command Processor...62 S2S Command Processor...66 Web Command Processor...79 Text Conferencing...85 Text Conferencing Configuration...85 Conference Room User Roles Message Archiver Message Archiver Configuration Retrieving Message Archiver Data Presence Mirror Presence Mirror Configuration Jabber Directory Suite iv

5 Table Of Contents Jabber Directory Suite Configuration Directory Server Configuration LDAP Database Configuration Jabber User Directory Jabber User Directory Configuration Open Port Open Port Configuration Single Domain Name Support Jabberd Port Configuration Web Services Web Services Configuration Service Configuration Index v

6

7 Overview Welcome to the Jabber IM/XCP Online Help The information contained in this help system is intended for system administrators who are configuring the Jabber IM/XCP server. It provides detailed descriptions of the information that is required during server configuration. The Overview section of the help provides a conceptual overview of the Jabber IM/XCP server, its components, and router plugins. It also provides high-level instructions for using the Jabber IM/XCP Controller. The Router Plugin Configuration section describes the parameters required for configuring each plugin through the Jabber IM/XCP Controller. The Component Configuration section describes the parameters required for configuring each component through the Jabber IM/XCP Controller. Note: For more in-depth information about the Jabber IM/XCP server and its components, see the Jabber IM/XCP 4.0 Getting Started Guide. New Features in Jabber IM/XCP 4.0 Several new features are provided with Jabber IM/XCP 4.0, which greatly increase its extensibility. You can configure these features through the Controller. Server-to-Server Command Processor The new server-to-server command processor (S2SCP) allows you to communicate with servers that are outside the firewall while minimizing the risks of unrestrained access. With Jabber IM/XCP 4.0, you also have more control over how you connect with other XMPP servers. You can log all server connections and track the volume of traffic for each connection; you can also manage black and white lists to limit which servers can connect. Finally, you can set up connections via SSL to protect information flowing between the servers, and you can use SASL for authenticating server connections. Polling Director You can now configure a Connection Manager with the new Polling Director, which uses HTTP to communicate over firewalls using port 80. It handles 1

8 XCP Controller Help polling communication with the Jabber Inc. IM clients, WebClient and Jabber Messenger for J2ME Wireless client. The polling director takes the place of the old mod_webclient and Apache configuration that used to be required to set up WebClient to run over an HTTP polling connection. Single Domain Name Support The new Single Domain Name Support (SDNS) component allows you to deploy a single domain name across a network of Jabber XCP routers and components on different pieces of hardware, even at different locations or with different sub-domain 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. SDNS also enables you to separate your network architecture from end-users, thus providing the additional benefits of performance and reliability. Delivering a single domain name (also known as a single namespace) helps globally-based customers who wish to geographically disperse IT resources obscure their network architecture from users. SDNS is also useful for customers with demanding scalability requirements. Web Services Available to Jabber XCP users, Web Services integrates XCP presence and messaging capabilities into other applications using SOAP-based Web Services APIs. The Web Services APIs include access to the most commonly used commands in the system, including get presence, retrieve and modify roster, send message, and submit to Information Broker. To use the Web Services component, you must have or develop a Web Services application that accesses the XCP services mentioned above. Information Broker Available to Jabber XCP users, the Information Broker extends the server s capability to publish real-time, highly changeable information to exactly those who want to receive the information. It is ideally suited to handle additional presence information, such as location, preferred contact method, and so forth. The Information Broker component, which was built using the JEP-60 protocol specification, is an enabling technology that provides a generic means of publishing information and receiving notifications when that information changes. The flexibility in the way information can be stored 2

9 means it can be deployed to support extended presence and content distribution equally well. Overview To make use of the Information Broker s functionality, you must implement an application that uses it. Such an application might be used to: Broadcast messages for text conferencing Push news contents such as sports scores or stock prices Enforce a subscription model for extended presence Implement extended presence attributes that are popular in wireless communications 3

10 XCP Controller Help Namespaces Namespaces are used to qualify XML element and attribute names so that name conflicts do not occur. Jabber protocol uses both true Uniform Resource Indicator (URI) XML namespaces and a Jabber-unique form of XML namespace. Using the Controller, you can configure which namespaces are handled by each component or plugin on your system. Namespaces are also used in conjunction with Jabber XDBs and in logging. XDB drivers enable the Jabber server to communicate with and store data in different directory services and databases. You can configure multiple XDBs for your Jabber server to handle different types of data. For example, you may want to use existing user accounts set up in your LDAP directory service for authentication and registration, and a Berkeley database for server preferences and vcard information. Single XDB If you have a single XDB, you do not need to add any namespaces. All XDB requests go to this component. Multiple XDBs In a multiple XDB configuration, you must list every namespace under the specific XDB that you want to handle that type of information. Namespaces that are not listed are not handled by the server. You can specify an asterisk (*) in the namespace textbox for one XDB in your configuration, indicating that all namespaces should be associated with that XDB unless they are specified elsewhere. For example, you may specifically list authentication and registration namespaces for XDB FastFile, and place the asterisk in the XDB Oracle namespace configuration. This setup tells the server that Oracle should handle all namespaces except for authentication and registration, which are handled by FastFile. Caution! If you set up XDBs but do not configure namespaces, all namespaces sent from the clients are handled automatically in all XDBs. Schema-Specific Namespaces Both LDAP and Oracle require a schema for storage. Since a schema is necessary, these databases only support those namespaces listed as part of the schema. The following table lists and defines namespaces that are used in the extensible Communications Platform. The last column in this table indicates the XDB component(s) by which the namespace may be handled. If 4

11 Overview you place the namespace in an XDB component that cannot handle it, the namespace is ignored by the Jabber server. Namespace Description Where it can be used schemas/cg.xsd schemas/jds.xsd jabber:iq:auth jabber:iq:register jcp:serverprefs jabber:iq:roster Handles community group requests. Handles JDS requests. Handles authentication requests. Successful authentication results in an IQ type= result response. Errors are returned in the IQ error element. Registers with a server or service and updates or removes a registration. Note: For JDS, this namespace performs a register check but does not allow registration. Handles SMTP integration options. When JDS is installed, this namespace must be handled by JDS. Used by clients to manage their roster, which is stored on the server so that the user can access it from any location. The roster is the authoritative list of subscription information for this account, including the user s nickname and contact list. When the user logs in from any resource, the roster is sent from the server to the client. JDS JDS JDS, Oracle, FastFile, or Berkeley JDS, Oracle, FastFile, or Berkeley JDS, Oracle, FastFile, or Berkeley Oracle, FastFile, or Berkeley 5

12 XCP Controller Help jabber:iq:last jabber:x:offline Provides a standard way to query a Jabber entity about the up-time of a server or service, or the last time that a client was connected to (or active on) a server. In each case, the returned value is a number of seconds. This information can be interpreted by the querying entity according to the following rules: user@server/resource-time since client was last actively used user@server-time since user was last connected server-time since server was last started Stores messages that are sent to users while they are offline. Oracle, FastFile, or Berkeley Oracle, FastFile, or Berkeley vcard-temp Handles vcard data. JDS, Oracle, FastFile, or Berkeley FastFile, Berkeley, Oracle, and JDS are the default database components provided with the extensible Communications Platform. JDS cannot handle any namespaces other than the ones listed above. See also: XDB FastFile Configuration XDB Berkeley Configuration XDB Oracle Configuration 6

13 Overview Logging During server configuration, you can configure these types of logs. Router Logging Using the Controller, you configure router logs in the Jabberd Logger Configuration window. You can configure the namespaces and hostnames for which Jabberd logs packets. You can also configure the Jabberd logger to log to a file, to stderr, and to syslog, and set the severity level for the information that is logged. By default, all components log information to the logs you set up in Jabberd. JSM Logging Using the Controller, you configure JSM logging in the Jabber Session Manager Configuration window. You can configure JSM to log incoming and outgoing packets, session packets, summarized packet data, and presence packets. You can also specify namespaces for which to log iq packets. SNMP With this release of the server, you can configure SNMP for each component and router plugin. Jabber, Inc. has provided a number of counters for gathering data; you can view the information gathered using your SNMP tool. Component Logging By default, each component logs packet delivery information to syslog, file, or stderr (whatever you configure for the Jabberd logger). You can override the default logging service for individual components using the Jabber Logging Library, jlog. Each component configuration window in the Controller has a "Component Logging (Jlog)" section, which allows you to configure filtered syslog and stream loggers for the component to capture information on a more granular level. 7

14 XCP Controller Help Using the Jabber IM/XCP Controller The Controller is a web-based administration console, through which you configure the server's central router, router plugins, and components. Caution! Jabber, Inc. recommends that you use the Controller to configure the 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. The Controller's main window 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. 8

15 Overview The main window is divided into three areas: System, Router, and Components. The System Area The System area contains links that allow you to start and stop the entire system, and to access a summary of your XCP configuration. To start the server, including all components and plug-ins: 9

16 XCP Controller Help Click the Start the System link. The XCP starts, and all associated components and plug-ins are also started. To stop the server, including all components and plug-ins: Click the Stop the System link. The XCP stops, and all associated components and plug-ins are also stopped. To see a summary of your configuration: Click the Summary link. The complete jabber.xml file containing all of your configuration settings displays in the window. Note: 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. 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 Controller is where you add, modify, or remove router plugins. Each of the plugins on your system are listed in the table 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 it from 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. Router plugins include: Core Router XDB FastFile XDB Berkeley XDB Oracle Jabber Session Manager (JSM) Jabberd Logger The Components Area Components are extensions of the Jabber XCP Server that can be started and stopped independent of the server. The Components area on the 10

17 Overview Controller is where you add, modify, start, stop, or remove server components. You add a new component by selecting one from 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.) Note: The WEBCP Open Port component does not provide edit, remove, start, and stop links. This component must not be stopped or modified. The Components area is organized by host. That is, all components installed on a particular host are listed together in the table. Components include: Connection Manager Text Conferencing Message Archiver Presence Mirror Jabber Directory Suite Open Port Single Domain Name Support Information Broker Web Services Online Help Online 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. Each help topic also provides a Full Help System link for opening the entire XCP help system. 11

18

19 Router Plugin Configuration Core Router Core Router Configuration This section defines the configuration parameters specific to the Jabber XCP core router, jabberd. Global Configuration Realm The term that was supplied at the following prompt during core installation: Enter the realm for this router and its components [jabber]: The realm is a unique string used to identify the router and all of its components (i.e., the entire system). This is necessary in case you are using Single Domain Name Support and have multiple routers that need to communicate with each other. For example, an XCP installation in London could have the realm, "london," and an installation in Denver could have the realm, "denver." Changing the realm: It you want to change the realm, you must change it here and in the webcm.xml file (located in $JABBER_HOME/etc). For example, to change the realm from 'jabber' to 'plato' in the web-cm.xml file, change the line: <config xmlns=" config:realm="jabber"> to <config xmlns=" config:realm="plato"> Important: After you have changed the realm in the Controller and in the cm.xml file, you must restart both the server and the Controller. To restart the Controller: 1. At a command prompt, change to the 13

20 XCP Controller Help xcpinstalldir/bin directory. 2. Enter the following command:./runwebcm restart Level of information to log Maximum number of threads for the server Maximum length in bytes of resource per JID The 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. The default log level is info. Select the level of information that you want the XCP server to log. The levels are listed from least severe to most and are described as follows: debug Information from all other log levels in addition to debug data. verbose Every packet that is processed by the server and JSM plus all Error, Warn, and Info data. info Data about socket connections and all JSM logs (packet, session, and message) plus all Error Warn, and Stats log level data. This is the level at which the server logs by default. warn Non-fatal errors such as bounced packets, nonexistent user logging in, invalid recipient for a message, etc., plus all Error log level data. error System-generated errors such as the inability to create listen ports, server configuration errors, failure to create the log files, etc. Enter the maximum number of threads to be instantiated to handle I/O for the Jabber XCP router. These threads handle all traffic from external components. This option is used primarily for performance tuning. The default value of 5 should be adequate in most circumstances. Enter the maximum number of bytes (18 or greater) that your users can specify for the resource portion of their Jabber ID. (You may want to set a maximum resource if you are using a custom client that has such a restriction.) Resources allow users to log on to multiple client sessions using the same Jabber ID. For example, a user can log on as jane@corp.com/one in one location and as jane@corp.com/two in another location; "one" and "two" are the resource portions of 14

21 the Jabber ID. Router Plugin Configuration SNMP Configuration Select this option if you want to configure SNMP for the router. SNMP Enabled This option is set to Yes by default. SNMP Count Errors Select Yes only if you want to enable SNMP error counting. This option takes a great deal of server resource; use it with caution. It is set to No by default. Submit Your Configuration When you have finished configuring the router, click the Submit button. If you want to cancel the configuration, click the Cancel button, not the browser's back button. See also: Full Help System 15

22 XCP Controller Help Jabber Session Manager Jabber Session Manager Configuration The Jabber Session Manager (JSM) controls all sessions on the Jabber Jabber XCP Server. Each time a client connects to the server, a new session is started. That is, there is one session opened for every client logged onto the system. This topic describes each section on the JSM Configuration window: Jabber Session Manager Optional Modules Hostnames Jabber Administrators System Limits System Parameters JSM Features Reroute Packets Stats Jabber Session Manager Agents JSM Logging Redirect to External Components JDS Configuration Roster Configuration Sendmail Configuration Offline SMTP Configuration Mirroring presence Registration Requirements ID Description Runlevel The ID of this plugin. This is a read-only value that is generated by the Controller; the value increments automatically as you add additional JSMs. The default description of this plugin is "Jabber Session Manager." It displays in the Router area on the Jabber XCP Controller's main window when you add a JSM plugin. You can change the description if desired. The description should help you distinguish between JSM plugins if you have more than one installed. The order in which this plugin shuts down. The default runlevel is 40. The runlevel must be an integer value greater than or equal to 0. (Component shutdown is executed in reverse order of the specified runlevel; components with the highest level (typically 70) shut down first.) Caution: Do not change the runlevel unless you know exactly what you are doing and understand the effects that changing it will have. The default runlevel is provided to help 16

23 Router Plugin Configuration Timeout for shutdown the system shut down as smoothly as possible, and is based on other components' dependencies upon this plugin. The number of seconds that the server waits to receive acknowledgement from the component that the shutdown process has completed. Optional Modules This section lets you select (load) individual JSM modules that are used by the Jabber XCP Server to enable specific features. You configure most of these features further down in the JSM Configuration screen. mod_redirect mod_stats mod_jds mod_admin mod_agents mod_disco mod_publish mod_privacy Enables you to redirect packets to external components. Allows system statistics to be logged to the jstats utility. This module is enabled by default. Enables the use of the Jabber Directory Suite. Caution! If you enable mod_jds, you must disable mod_auth_plain, mod_auth_digest, and mod_register. Allows admin functionality like message broadcast. Allows you to configure agents for XCP components. Note: The functions of this module are also handled by mod_disco; mod_agents remains in the software to support backwards compatibility. Important! Do not enable both mod_agents and mod_disco. Allows you to configure static agents (as with mod_agents) and to enable JSM to automatically discover Jabber services and add agents for them (as described in JEP-30). Important! Do not enable both mod_disco and mod_agents. Allows client users to publish items for their Jabber IDs to the XDB. These published items are publicly available. (This is also described in JEP-30). Allows IM users to configure XMPP-compliant privacy lists, which are used as a means of blocking messages from specific users. This feature must be 17

24 XCP Controller Help mod_privacy_legacy mod_sendmail mod_offline_smtp mod_offline mod_presence_bcc mod_auth_plain mod_auth_digest customized within your client software so that users can access it. See the Jabber XCP Developer Guide for more information about privacy lists. Allows the use of older privacy lists that are not XMPP compliant. Allows users to send transcripts of chat and conference room conversations to others via . Note: You must have a Connection Manager configured for SMTP to use the sendmail feature. Allows messages that are sent to offline users to be sent via . Auto-retrieves offline messages and sends them to the XDB. It also fills requests for offline messages as defined in Jep Enables the Presence Mirror to send presence packets to your Oracle database using the Blind Carbon Copy (BCC) feature. Presence information is passed blindly without notifying the user. Each presence packet includes: Jabber ID, a presence (e.g. Away ), and a status message (e.g., Eating lunch ). To retrieve a user s presence, you must access the user s data from the Oracle database using your standard database tools. Enables plaintext authentication. This module is enabled by default. Caution! If you are using JDS or Oracle, disable this option. Enables digest-based authentication, which allows the client and server to perform a cryptographic hash on the password and stream ID, and to compare the results. The hashed value is sent over the connection rather than the plaintext value. This module is enabled by default. Caution! If you are using JDS or Oracle, disable this option. mod_auth_digestmd5 Enables digest-based authentication using an MD5 hash on the password and stream ID. This module is required for use with IMPS Gateway clients, 18

25 Router Plugin Configuration mod_auth_db_plain mod_register mod_vcard versions 2.8 and above. Enables plaintext authentication and is used only with Oracle. Caution! If you are using Oracle, disable mod_auth_plain and mod_auth_digest. You cannot use digest-based authentication with Oracle. Enables users to register with the Jabber XCP Server. This module is enabled by default. Caution! If you are using JDS, disable this option. Enables the use of vcards anywhere on the system. Users can enter vcard information for themselves and can query the vcard information of other users. This module is enabled by default. Hostnames Host Filters Enter the hostnames or IP addresses of the servers for which you want this JSM plugin to handle packets. Separate each hostname or address with a line break. Enter an asterisk (*) in the textbox to enable the component to handle data from any host. Note: Host filters must be hostnames, or IPv4 or IPv6 addresses. Caution: When using SDNS, this field should be left blank. Jabber Administrators In order to use this feature, the mod_admin module must be enabled as described under Optional Modules. Select the Jabber Administrators option if you want to specify Jabber administrators for your XCP system. Jabber administrators can: Unregister users Receive notifications when unregistered users have offline messages, and delete such messages to clean up the system Broadcast messages to all users connected to a specific Connection Manager Receive notification when the XCP license is about to expire 19

26 XCP Controller Help In the text box provided, enter the Jabber ID of each person you want to designate as a Jabber administrator. Separate each Jabber ID with a line break. System Limits Select the System Limits option if you want to set system limits in order to control the usage of your XCP system. Enter the following information: Maximum number of sessions a single Jabber user (Jabber ID) can open at a time Maximum number Jabber users that can be logged into the server at a time System Parameters Enter the maximum number of sessions a Jabber user can have on the server using the same Jabber ID and different resources. Each time a Jabber user logs into the server, a session is created. If the same user logs on from two locations (e.g., at home and at work), that user has two sessions active on the server. By default, users may have an unlimited number of concurrent sessions. You may wish to limit this number to prevent overuse of your Jabber XCP Server. The default setting for this field is , which handles concurrent users. This value is reached using the following method: 1. Multiply the expected number of concurrent users by three. 2. Find the closest prime number above this value. 3. Enter the prime number into this field. Select the System Parameters option if you want to change the default settings for the following parameters: Number of threads to use for processing Jabber tasks Number of worker queues to use for processing Jabber Enter the number of threads that the Jabber XCP Server should create to process Jabber tasks. We recommend that you use the number of CPUs plus 1. The default setting is 3. Creating more threads enables the Jabber XCP Server to process Jabber tasks more quickly, but uses more of your system's processor. We recommend one worker queue for every 10 to 20 users. (Divide the number of expected concurrent users by 20.) This field impacts performance; the 20

27 tasks Closed session cache time (in seconds) User session cache time (in seconds) Timeout for XDB requests in JSM Timeout for IQ requests in JSM Maximum # of XDB requests to allow Resume sockets when # XDB requests drop below SNMP Configuration Router Plugin Configuration more queues you have, the harder your system must work. The default setting is 500. The number of seconds a user's session is cached in memory after he or she logs out. The default setting is 10. Note: The fewer seconds you specify, the more time JSM must spend trying to free memory. The more seconds you specify, the fewer times cleanup occurs. The number of seconds a user's session resources are cached after he or she has logged out from all sessions. The default setting is 120. Note: The fewer seconds you specify, the more time JSM must spend trying to free memory. The more seconds you specify, the fewer times cleanup occurs. Enter the number of seconds to wait before an XDB request that has been sent to the router times out. The default setting is 0 seconds. This setting affects users; the higher the setting, the slower the system runs. Enter the number of seconds to wait before an IQ request that has been sent to the router times out. This item is used only during the discovery of other components, and its setting has no effect on users. The default setting is 30 seconds. Enter the number of XDB requests that can be sent to the JSM from the CM at one time. This is the high-water mark; when the number of XDB requests reaches this number, the JSM stops receiving them from the CM. The default setting is 100 requests. Enter the number of XDB requests that JSM still must handle before accepting them again from the CM. This is the low-water mark. The default setting is 10 requests. Select this option if you want to configure SNMP for the JSM component. SNMP Enabled This option is set to Yes by default. SNMP Count Errors Select Yes only if you want to enable SNMP error counting. This option takes a great deal of server 21

28 XCP Controller Help resource; use it with caution. It is set to No by default. JSM Features Select the JSM Features option if you want to change the default settings for the following server features: Apply Single Domain Name Support semantics to local user lookups Allow roster caching Allow invisible presence Allow restrictive offline Reroute Packets Select Yes if you are using Single Domain Name Support (SDNS) for multiple JSMs. SDNS determines if a particular Jabber ID is a local user when users are spread across multiple domains. This option is set to No by default. Select Yes (the default setting) if you want to cache rosters for online users in the Jabber Session Manager. This option allows users to access their rosters more quickly, but disallows modification of rosters outside of the Jabber system. Select Yes (the default setting) if you want to allow users to set their presence to "Invisible" so that they can be online with the Jabber XCP Server, but show up in their contacts' rosters as offline. Select Yes if you want to prevent the server from offlining bounced messages that are empty. (This setting affects message packets only.) This option is set to No by default. Select the Reroute Packets to External Components option if you want to reroute specific packet types to an external component. Packets rerouted using this method never go through the JSM. To route packets to a different component so that they are also handled by the JSM, see Redirect to External Components. To reroute a packet, click the Go button to access the Reroute a Packet Configuration window. Stats In order to use this feature, the mod_stats module must be enabled as described under Optional Modules. 22

29 Router Plugin Configuration Select the Stats option if you want to set the time interval for capturing server statistics to a flat file. Enter the number of seconds in the textbox. The default setting is 300. Agents In order to use this feature, the mod_agents module must be enabled as described under Optional Modules. Note: Jabber, Inc. recommends that you use mod_disco to handle the discovery of components automatically. Enable mod_agents and configure agents here only if you are using components that do not support the disco protocol. Select the Agent option if you want to add agents for system components. We strongly recommend adding an agent for each component that you install on your Jabber XCP Server. Important! Agents enable information relating to the corresponding component to display in the client interface. For example, if you configure a Text Conferencing component, the TC service agent enables the client to display the Text Conferencing interface to client users. The Jabber Session Manager holds all agent information. When a client queries for available components, the JSM provides this information to the client software, so that the client can display it to the user. To add an agent for a component, select the agent in the drop-down list, and click the Go button. The agents you can add include: LDAP User Directory Agent JUD Agent JDS Community Groups Agent TC Service Agent Send Transcript Agent Generic Agent JSM Logging Incoming message packets Select Yes if you want to log all message packets and file transfer requests received by the Jabber XCP Server. The actual file received during a transfer is not logged. (By default, this option is set to No.) 23

30 XCP Controller Help Outgoing message packets Session packets Summarized packet data Presence packets Namespaces packets Namespace Filters Select Yes if you want to log all message packets and file transfer requests sent by the Jabber XCP Server. The actual file sent during a transfer is not logged. By default, this option is set to No. Select Yes if you want to log information about each user session that occurs on the server. This information includes how long the user has been online, the number of packets in and out of the user's session, and the number of bytes in and out of the user's session. By default, this option is set to No. Select Yes if you want to log a statistical summary of all packets sent/received by the system. By default, this option is set to No. Select Yes if you want to log presence packets. By default, this option is set to No. Note: This setting does not affect the Presence Mirror. Select this option if you want to log IQ packets for specific namespaces. Enter the namespaces for which you want to log IQ packets. For example: jabber:iq:roster jabber:iq:last Separate each namespace with a line break. Redirect to External Components In order to use this feature, the mod_redirect module must be enabled as described under Optional Modules. You may redirect packets to external components as needed. When you "redirect" a packet, it is processed by the JSM like any other packet, but it is redirected to the specified external component by the mod_redirect module. Click the Go button to access the Redirect Configuration window to configure a new redirect instance. When you submit your redirect configuration, you are returned to the JSM Configuration window. JDS Configuration 24

31 Router Plugin Configuration In order to use this feature, the mod_jds module must be enabled as described under Optional Modules. Select the JDS Configuration option to configure how the JSM and the Jabber Directory Suite (JDS) interact. These settings impact the server only if you have installed the JDS component. Digest Authentication Community Groups Roster Configuration When enabled (the default setting), users can log onto the server using digest authentication rather than plaintext authentication. Caution! For digest authentication to work, the LDAP database must be configured to use plaintext authentication. If LDAP uses hashed passwords, you must not enable digest authentication. Digest authentication is more secure than plaintext authentication. When the client connects to the server, the Connection Manager passes a session ID to it. The session ID is SHA-hashed with the client's password and returned to the server. The server authenticates the client based on this value. When enabled (the default setting), users can access community groups through the client software. Select the Roster Configuration option if you want to change the default setting (150) for the maximum number of items a user can have in the roster. This option limits how much space rosters take on your Jabber XCP Server. Roster items include contacts, pending contacts, and any other item that appears in the roster. Sendmail Configuration In order to use this feature, the mod_sendmail module must be enabled as described under Optional Modules. Select the Sendmail Configuration option if you have enabled the use of SMTP by installing an appropriately configured Connection Manager. The sendmail feature allows users to send transcripts of chat and conference room conversations via . If you have not installed SMTP on a Connection Manager, the server ignores these fields. Service ID of the SMTP processor Default reply address for Enter the ID of the SMTP processor that will send the mail. Enter a default address to which any replies should be sent. If the Jabber XCP Server is unable to determine 25

32 XCP Controller Help Offline SMTP Configuration the address of the sender, it automatically plugs in this address. In order to use this feature, the mod_offline_smtp module must be enabled as described under Optional Modules. Select the Offline SMTP Configuration option if you want instant messages received for offline users to be sent to . In order for this functionality to work, you must also have SMTP enabled on a Connection Manager. Service ID of the SMTP processor Default reply address for Mirroring Presence Enter the ID of the SMTP processor that will send the mail. Enter a default address to which any replies should be sent. If the Jabber XCP Server is unable to determine the address of the sender, it automatically plugs in this address. In order to use this feature, the mod_presence_bcc module must be enabled as described under Optional Modules. Select the Mirroring Presence option if you want to specify external components to which a copy of presence packets are sent. This setting impacts the server only if you have installed the Presence Mirror component. The components that should handle BCC (Blind Carbon Copy) packets Registration Requirements Enter the ID and realm (in the format ID.realm) for each component that you want to receive a copy of all presence packets. Separate each component's ID.realm with a line break. If you are using Oracle, you must enable the mod_auth_db_plain module as described under Optional Modules. For everything else, enable the mod_register module. Select the Registration Requirements option if you want to enable your users to create accounts on the XCP server. In this section, you configure the information and prompts that display on the client interfaces to your endusers when they register. Note: If you are using JDS, do not configure the Registration Requirements area. Registration does not work with JDS. Database should When enabled (the default setting), the database 26

33 handle registration Register Fields Registration Message Enable Welcome Messages Submit Your Configuration Router Plugin Configuration handles registration. If you select No, the registration information is sent to the XDB. Select the checkbox for each piece of data that you want to require at registration. Jabber Messenger and WebClient display these fields on their Registration windows. For the most part, these checkboxes are selfexplanatory. The Date field is not defined to be any specific date. You could use it to record the date of account creation, a birthday, or any other date. The Registration Message fields are used by the XCP server to send an instant welcome message to newly created accounts. If you want to change the wording of a message, you must modify your dictionary file. For more information about internationalization, see the "Internationalization" chapter in the XCP Developer's Guide. Type Select Normal, Chat, or Headline for the type of registration message you want sent. (The default setting is Normal.) The Jabber, Inc. clients always use the Chat type, which sends welcome messages in a chat window. You can select another message type if you are using a custom client; for example, a Headline type could be a pop-up message, and a Normal type could be a message sent in a window containing a Reply button. You must define these types as you plan to use them with your custom client. When enabled (the default setting), the server sends a welcome message to users after they register. When you have finished configuring this plugin, click the Submit button. If you want to cancel the configuration, click the Cancel button, not the browser's back button. See also: Full Help System 27

34 XCP Controller Help Rerouting Packets When namespaces are rerouted, they never enter the Jabber Session Manager. As soon as the Jabber XCP Server receives a packet containing namespace data of the specified type, it sends the packet to an external component. In the Reroute a Packet Configuration window, you correlate the namespace that you want to reroute with the external component that should handle packets containing this namespace. Note: If you want the packet to be sent to the Jabber Session Manager and then redirected to an external component, exit this configuration and see the Redirecting Packets topic. For example, you may want to redirect a namespace to an external component, but also have it handled by one of the JSM modules. In this case, you would need to use "redirect" rather than "reroute." Configuration to Reroute a Packet Namespace ID Enter the namespace of the iq packet (e.g., jabber:iq:auth) to reroute. Enter the Jabber ID of the external component. Submit Your Configuration When you have finished configuring the packet reroute click the Submit button. If you want to cancel the configuration, click the Cancel button, not the browser's back button. See also: Full Help System 28

35 Router Plugin Configuration Redirecting Packets The Redirect Packets feature enables you to redirect all packets of a specific type to a component external to the Jabber XCP Server. For example, if you have your own authentication system, you may wish to copy all authentication packets to your system in addition to using the Jabber XCP Server s authentication functionality. In the Redirect Configuration window, you associate packets of a specific type that are generated by a specific event. You also specify the external component to which the specified packets should be sent. Redirect Configuration Event Type JID Select the event that you want to redirect. Events are actions that trigger the client or the Jabber XCP Server to send a packet. When the selected events occur, the Jabber Session Manager will redirect packets generated by them. The default event is "session." See Event Descriptions. Select the packet type that you want to redirect. For example, if you selected "auth" as the event and select "iq" here, all iq packets sent during authentication are redirected. The default type is "iq." See Packet Descriptions. Enter the Jabber ID of the external component. For example, if you want to redirect presence packets to a custom presence component that you configured with the Jabber ID of "presence.example.com", enter "presence.example.com" here. Event Descriptions session offline server deliver Packets sent during login, which is the creation of a new session. Packets sent to users who are offline. Offline users are users who do not have an active session. Packets sent directly to the server; for example, packets processed by the JSM modules mod_stats, mod_time, mod_version, and mod_agents. The first event for packets coming in from another server; the second event for packets coming in from a user on the same server. (The first event for packets coming in from the same server is es_in.) 29

36 XCP Controller Help shutdown auth register reg_cb config stats es_in es_out es_end Packets generated when the server shuts down. IQ packets sent during authentication. Packets generated during registration of a new account by a user. Packets generated when a user registration packet is processed. Packets sent during server start-up. These packets provide configuration information to the Jabber XCP Server. Packets sent periodically that contain server statistics. These packets are usually sent to the Jstats utility. All inbound session packets. All outbound session packets. Packets generated when sessions shut down. Packet Descriptions iq message presence subscription all Packets used during info-query functions. Packets containing standard IM messages. Packets containing presence information. Packets containing subscription information. All packets. Submit your Configuration When you have finished configuring this redirect instance, click the Submit button. If you want to cancel the configuration, click the Cancel button, not the browser's back button. See also: Full Help System 30

37 Router Plugin Configuration XDB FastFile XDB FastFile Configuration The XDB FastFile plugin allows the Jabber XCP Server to connect to and communicate with your FastFile directory service, storing Jabber data in a FastFile flat file. XDB FastFile Plugin ID Description Runlevel Timeout for Shutdown The ID of this plugin. This is a read-only value that is generated by the Controller; the value increments automatically as you add additional FastFile XDBs. The default description of this plugin is "XDB Storage using FastFile." It displays in the Router area on the XCP Controller main window when you add an XDB FastFile plugin. You can change the description if desired. The description should help you distinguish between XDB FastFile plugins if you have more than one installed. The order in which this plugin shuts down. The default runlevel is 20. The runlevel must be an integer value greater than or equal to 0. (Component shutdown is executed in reverse order of the specified runlevel; components with the highest level (typically 70) shut down first.) Caution: Do not change the runlevel unless you know exactly what you are doing and understand the effects that changing it will have. The default runlevel is provided to help the system shut down as smoothly as possible, and is based on other components' dependencies upon this plugin. The number of seconds that the server waits to receive acknowledgement from the component that the shutdown process has completed. XDB This section defines the namespaces and hosts that will be handled by this FastFile XDB. Note: If you are using the Jabber Messenger (JM) Desktop client, version 3.0, you may need to add the namespaces, jabberim:jm_prefs and jabberim:tc_filters in the XDB (Oracle, 31

38 XCP Controller Help FastFile, or Berkeley) where you want to store JM data. These namespaces enable the XCP server to store JM users' preference values and text conference filter information. (You only need to add the jabberim:tc_filters namespace if you are using text conferencing, which requires you to have purchased and licensed the Jabber XCP package.) If the XDB has been configured to handle all namespaces (by placing an asterisk in the Namespace Filters field), you do not need to add the Jabber Messenger namespaces. Namespace Filters Host Filters Configuration The asterisk (*) indicates that this XDB will handle the namespaces that are not handled by another XDB plugin. If you want the XDB to handle specific namespaces only, enter them in the textbox separating each with a line break. All other namespaces will be ignored. Caution! You can specify an asterisk for only one XDB plugin. Enter the hostnames or IP addresses for which you want this XDB instance to handle XDB packets. Separate each hostname or address with a line break. Enter an asterisk (*) in the textbox to enable this XDB instance to handle XDB packets from any host. Note: Host filters must be hostnames, or IPv4 or IPv6 addresses. If you are using FastFile for data storage, you can configure memory caching for specific namespaces. If you choose not to cache, all data is read from disk and written to disk. This configuration decreases the memory footprint, but increases the disk I/O for data retrieval. Full path to the XDB- FastFile spool directory Number of threads to dedicate to FastFile cache Enter the base directory location where Jabber user files will be stored. A default location (xcpinstalldir/var/spool) is provided. Change the path to a different location if needed. Enter the number of threads used by the Jabber XCP Server to process requests from the XDB FastFile plugin. The default setting is 3. Increasing or decreasing this value may adversely affect performance. We recommend that you use the default value. 32

39 Router Plugin Configuration Number of elements allowed in the FastFile cache Number of elements to purge when cache size is reached Configure caching by namespace SNMP Configuration SNMP Enabled SNMP Count Errors Enter the number of XML elements that may be cached in memory for XDB FastFile. Enter the number of XML elements to remove from the cache when the cache size specified above is reached. Select this option and click the Go button to set caching for individual namespaces. Select this option if you want to configure SNMP for the XDB FastFile plugin. This option is set to Yes by default. Select Yes only if you want to enable SNMP error counting. This option takes a great deal of server resource; use it with caution. It is set to No by default. Submit Your Configuration When you have finished configuring this plugin, click the Submit button. If you want to cancel the configuration, click the Cancel button, not the browser's back button. See also: Full Help System Namespace Configuration Changing User Passwords 33

40 XCP Controller Help Namespace Configuration This section lets you add a new namespace to the XDB FastFile configuration, and to enable or disable caching for it. Namespace Enable Caching Namespace Select Yes to enable memory caching for this namespace. Enter the namespace for which you are enabling or disabling caching. Submit Your Configuration When you have finished configuring the namespace, click the Submit button. If you want to cancel the configuration, click the Cancel button, not the browser's back button. See also: Full Help System XDB FastFile Configuration 34

41 Router Plugin Configuration Changing User Passwords If you are using the FastFile directory service to store user authentication information, you can reset a user s password. For example, if your users forget their passwords, you can change them to a default value so that they can access their accounts. If caching is enabled for FastFile, the new password does not take affect until the cache refreshes. To reset a password in FastFile: 1. Change directories to: xcpinstalldir/var/spool/jabber:iq:auth. 2. Open the user s authentication file in a text editor. There is a separate file for each JID that is registered on your server. This file contains all information necessary to authenticate the user on your system. 3. Locate the following lines: <root> <password>password</password> </root> 4. Change the password as needed. 5. Save and close the file. 6. Send the new password to the user. See also: Full Help System XDB FastFile Configuration 35

42 XCP Controller Help XDB Berkeley XDB Berkeley Configuration The XDB Berkeley plugin enables you to store Jabber data in a Berkeley data store. The Berkeley data store is closely integrated with the Jabber XCP server, and does not require you to maintain and administer a separate data server. Before you configure the Berkeley plugin, you must have installed the Berkeley packages when you installed the Jabber XCP Server. If not, you should perform that step now. Further installation information is available in the Jabber IM/XCP Installation Guide. XDB Berkeley Plugin ID Description Runlevel Timeout for Shutdown The ID of this plugin. This is a read-only value that is generated by the Controller; the value increments as you add additional Berkeley XDBs. The default description of this plugin is "XDB Storage using Berkeley." It displays in the Router area on the Controller main window when you add an XDB Berkeley plugin. You can change the description if desired. The description should help you distinguish between XDB Berkeley plugins if you have more than one installed. The order in which this plugin shuts down. The default runlevel is 20. The runlevel must be an integer value greater than or equal to 0. (Component shutdown is executed in reverse order of the specified runlevel; components with the highest level (typically 70) shut down first.) Caution: Do not change the runlevel unless you know exactly what you are doing and understand the effects that changing it will have. The default runlevel is provided to help the system shut down as smoothly as possible, and is based on other components' dependencies upon this plugin. The number of seconds that the server waits to receive acknowledgement from the component that the shutdown process has completed. XDB 36

43 Router Plugin Configuration This section defines the namespaces and hosts that will be handled by the Berkeley XDB. Note: If you are using the Jabber Messenger (JM) Desktop client, version 3.0, you may need to add the namespaces, jabberim:jm_prefs and jabberim:tc_filters in the XDB (Oracle, FastFile, or Berkeley) where you want to store JM data. These namespaces enable the XCP server to store JM users' preference values and text conference filter information. (You only need to add the jabberim:tc_filters namespace if you are using text conferencing, which requires you to have purchased and licensed the Jabber XCP package.) If the XDB has been configured to handle all namespaces (by placing an asterisk in the Namespace Filters field), you do not need to add the Jabber Messenger namespaces. Namespace Filters Host Filters Configuration The asterisk (*) indicates that this XDB will handle the namespaces that are not handled by another XDB plugin. If you want the XDB to handle specific namespaces only, enter them in the textbox separating each with a line break. All other namespaces will be ignored. Caution! You can specify an asterisk for only one XDB plugin. Enter the hostnames or IP addresses for which you want this XDB instance to handle XDB packets. Separate each hostname or address with a line break. Enter an asterisk (*) in the textbox to enable this XDB instance to handle XDB packets from any host. Note: Host filters must be hostnames, or IPv4 or IPv6 addresses. Full path to the XDB- Berkeley spool directory Server SNMP Configuration Enter the full path to the XDB Berkeley spool file. This file is the flat file used by XDB Berkeley to store Jabber information. A default location (xcpinstalldir/var/spool) is provided. Change the location if needed. Enter the name of an RPC server that handles all database calls only if your Berkeley database is configured for RPC access. This field is blank by default, which means that you will be accessing a local Berkeley database. Select this option if you want to configure SNMP for 37

44 XCP Controller Help the XDB Berkeley plugin. SNMP Enabled This option is set to Yes by default. SNMP Count Errors Select Yes only if you want to enable SNMP error counting. This option takes a great deal of server resource; use it with caution. It is set to No by default. Submit Your Configuration When you have finished configuring this plugin, click the Submit button. If you want to cancel the configuration, click the Cancel button, not the browser's back button. See also: Full Help System 38

45 Router Plugin Configuration XDB Oracle XDB Oracle Configuration The XDB Oracle plugin enables the Jabber XCP Server to store and retrieve data using an Oracle database. You may want to use Oracle to store registration data, account data, or any other Jabber namespaces. Additional Configuration Instructions In addition to providing the information in the XDB Oracle Configuration screen, you must do the following in the Jabber Session Manager Configuration screen: Enable the mod_auth_db_plain module, and disable the mod_auth_plain and mod_auth_digest modules. Enable Registration Requirements, and select Yes for the option, "Database should handle registration." XDB Oracle Plugin ID Description Runlevel The ID of this plugin. This is a read-only value that is generated by the Controller; the value increments as you add additional Oracle XDBs. The default description of this plugin is "XDB Storage using Oracle." It displays in the Router area on the Controller main window when you add an XDB Oracle plugin. You can change the description if desired. The description should help you distinguish between XDB FastFile plugins if you have more than one installed. The order in which this plugin shuts down. The default runlevel is 20. The runlevel must be an integer value greater than or equal to 0. (Component shutdown is executed in reverse order of the specified runlevel; components with the highest level (typically 70) shut down first.) Caution: Do not change the runlevel unless you know exactly what you are doing and understand the effects that changing it will have. The default runlevel is provided to help the system shut down as smoothly as possible, and is based 39

46 XCP Controller Help Timeout for shutdown on other components' dependencies upon this plugin. The number of seconds that the server waits to receive acknowledgement from the component that the shutdown process has completed. The default setting is 120. XDB This section defines the namespaces and hosts that will be handled by the Oracle XDB. Note: If you are using the Jabber Messenger (JM) Desktop client, version 3.0, you may need to add the namespaces, jabberim:jm_prefs and jabberim:tc_filters in the XDB (Oracle, FastFile, or Berkeley) where you want to store JM data. These namespaces enable the XCP server to store JM users' preference values and text conference filter information. (You only need to add the jabberim:tc_filters namespace if you are using text conferencing, which requires you to have purchased and licensed the Jabber XCP package.) If the XDB has been configured to handle all namespaces (by placing an asterisk in the Namespace Filters field), you do not need to add the Jabber Messenger namespaces. Namespace Filters Host Filters XDB Oracle Configuration The asterisk (*) indicates that this Oracle XDB will handle all namespaces. If you want the XDB to handle specific namespaces only, enter them in the textbox separating each with a line break. All other namespaces will be ignored. Note: Oracle can now handle any namespace, including those that are non-standard. Caution! You can specify an asterisk for only one XDB plugin. Enter the hostnames or IP addresses for which you want this XDB Oracle instance to handle XDB packets. Separate each hostname or address with a line break. Enter an asterisk (*) in the textbox to enable this XDB Oracle instance to handle XDB packets from any host. Note: Host filters must be hostnames, or IPv4 or IPv6 addresses. Number of threads to Enter the number of threads used by the Jabber XCP Server to process requests from the Oracle plugin. 40

47 Router Plugin Configuration dedicate to Oracle tasks Increasing or decreasing this value may adversely affect performance. We recommend that you use the default value of 7. Oracle server Unique Server ID Oracle database resource Oracle user Oracle user's password Timeout in seconds after which the Oracle server is considered disconnected Frequency in seconds to refresh connection to the Oracle server Interval in seconds to wait between reconnect attempts to the Oracle server The ID of this Oracle server. This is a read-only value that is generated by the Controller; the value increments automatically as you add additional Oracle databases. Enter the database alias, or ORACLE_SID. Enter the account name to use when connecting to the Oracle server. This account name should be the same one you used when running the Oracle SQL scripts at installation (cr_jabber_user.sql or cr_sql_user_ro.sql). Enter the password for the user account indicated above. If no activity occurs between the Oracle server and the Jabber XCP Server for this number of seconds, the connection is considered disconnected. This value should be at least 20 seconds greater than the refresh value (below). The Jabber XCP Server refreshes its connection to the Oracle server at this interval. This interval should be at least 20 seconds less than the timeout value (above). You should also take into consideration any firewall(s) between the Jabber XCP Server and the Oracle server when determining this value, and set it to at least 20 seconds less than the firewall timeout. If the Oracle server becomes unavailable, the Jabber XCP Server attempts to reconnect to it at this interval. It will continue attempting to reconnect until the Oracle server returns. Register Fields When you install XDB Oracle and associate an Oracle server with the Jabber XCP Server, you need to indicate how the Jabber registration values map to your Oracle database. For example, if you require the Jabber registration field " ", you must specify where in the Oracle database that value should be stored. 41

48 XCP Controller Help Registration values are configured in the Registration section of the Jabber Session Manager configuration window. If you are using Oracle, you need to map each selected registration value to a valid Oracle value. Note: Before mapping these values, you may want to return to the JSM configuration window and make a list of all of the enabled registration values. Select the checkboxes next to the registration fields that you selected during JSM configuration. Enter the corresponding Oracle column names in the text fields provided. SNMP Configuration Select this option if you want to configure SNMP for the XDB Oracle plugin. SNMP Enabled SNMP Count Errors vcard Mapping File This option is set to Yes by default. Select Yes only if you want to enable SNMP error counting. This option takes a great deal of server resource; use it with caution. It is set to No by default. Full path to the vcard mapping file Enter the full path to the vcard mapping file (vcard_oracle.xml). All mapping between vcard values and Oracle values occurs within this file. Directions for configuring the vcard mapping file are available in the Jabber IM/XCP Installation Guide. vcard mapping cannot be accomplished through the Controller. Submit Your Configuration When you have finished configuring this plugin, click the Submit button. If you want to cancel the configuration, click the Cancel button, not the browser's back button. See also: Full Help System 42

49 Router Plugin Configuration Jabberd Logger Jabberd Logger Configuration The Jabber XCP Server uses syslog as the default logging service to capture information from both external components and the central router, jabberd. Syslog may be run locally or remotely and does not require any additional hardware or software. The server is configured by default to log statistical messages generated by the JSM component. You can log statistics data to a file or export it to external components. Caution! Statistics data is not available if the log's verbosity level is set below "info". Jabberd Logger ID Description The ID of this plugin. This is a read-only value that is generated by the Controller; the value increments as you add additional Jabberd Logger plugins. The default description of this plugin is "Jabber Logger." It displays in the Router area on the Controller main window when you add a logger plugin. You can change the description if desired. The description should help you distinguish between logger plugins if you have more than one installed. Log nss Host Filters Select the namespaces that you want this logger to log. This field should always contain an asterisk (*). The asterisk enables this logger to log data from any host. Configuration Select a logger from the drop-down list, and click the Go button to open the configuration window for the selected logger. Loggers you can configure include: File Logger Standard Error Logger 43

50 XCP Controller Help Syslog Logger Log Level Submit Your Configuration When you have finished configuring this plugin, click the Submit button. If you want to cancel the configuration, click the Cancel button, not the browser's back button. See also: Full Help System 44

51 Component Configuration Connection Manager Connection Manager Configuration The Connection Manager (CM) component enables IM clients and servers to connect to the Jabber XCP Server. You can configure multiple instances of the Connection Manager to increase the number of connections your server can handle and to enable communication over different protocols. Connection Manager ID Description Runlevel Timeout for shutdown 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 CM components. The default description of this component is "Connection Manager." It displays in the Components area on the Controller main window when you add a Connection Manager. You can change the description if desired. The description should help you distinguish between CM components if you have more than one installed. The order in which this component shuts down. The default runlevel is 50. The runlevel must be an integer value greater than or equal to 0. (Component shutdown is executed in reverse order of the specified runlevel; components with the highest level (typically 70) shut down first.) Caution: Do not change the runlevel unless you know exactly what you are doing and understand the effects that changing it will have. The default runlevel is provided to help the system shut down as smoothly as possible, and is based on this component's dependencies upon other components. The number of seconds that the server waits to receive acknowledgement from the component that the shutdown process has completed. The default is 240 seconds. Router Connection Information Connection Type With an accept connection type (the default setting), the router opens a specific port and listens on that 45

52 XCP Controller Help Component IP Port Password Buffer size in bytes for outgoing data Buffer size in bytes for incoming data Number of packets buffered when component is down Keep-alive interval in seconds port for a connection from the component. By default, the router uses the accept method to listen for connections from all components. With a connect connection type, the router connects to the component. If you selected an accept connection type, enter the IP address or FQDN on which the router listens for the component. By default, this field contains the IP address of the system on which the router is installed. If you selected a connect connection type, enter the IP address or hostname of the system on which the component is installed. If you selected an accept connection type, enter the port on which the router listens for the component s connection. The router allows only a single connection over this port at a time; therefore, multiple versions of the component cannot connect over the same port. The port is set to 7301 by default. If you selected a connect connection type, enter the port that the component uses for communications. Enter the password that the router uses to authenticate the component. A default is provided if the command configuration is used. You can change this value as needed. Enter the number of bytes the router should buffer when it sends information to the component. You may want to modify this element when working on performance enhancements. The default is set to bytes. Enter the number of bytes the router should buffer when it receives information from the component. You may want to modify this element when working on performance enhancements. The default is set to bytes. Enter the number of incoming packets the router should buffer when the component is down. The default is set to 512 packets. Enter the number of seconds after which the router sends a keep-alive to the component. The keep-alive helps prevent firewalls from dropping an unused 46

53 Component Configuration Log delivery of packets to this component Bounce error packets to stderr Maximum interval in seconds to wait before restarting component Maximum number of times to restart component Interval in seconds at which to reset this value to 1 second connection to the component. If this option is set to 0 or left empty, keep-alives are disabled. Select Yes (the default setting) if you want the data that the router delivers to the component to be logged. The information is logged to the logger(s) you set up during Jabberd Logger configuration (syslog, file, or stderr). Socket-level logging happens only at the debug level. The information is logged using the default namespace, jcs:log:default. Select Yes (the default setting) if you want the router to send warnings to stderr when the component is not available. Enter the maximum number of seconds after which the router tries to restart the component. The default is set to 300 seconds. If the component goes down, the router tries to restart it after 1 second. If the component is not running yet and the command option is being used, the router multiplies the wait time by 1.5, and retires after the longer time. Once the maximum time interval that you specify in this field is reached, the router continues to retry after waiting this amount of time. Enter the total number of restarts allowed. The default setting, -1, means unlimited. Note: If you want to be able to kill the component from the command line and prevent it from starting again automatically, you must set this number to something other than -1. For example, if you set it to 1, the component will not restart once you have killed it; if you set it to 2, the component will only restart once, and so on. The number of seconds that the component has been up and running, after which to set the restart time back to 1 second. Command Select the Command option if you want the component to be started by the router. This option is enabled by default. 47

54 XCP Controller Help Path to Binary Command The directory path to the shell that launches the component. You can change the default setting (/bin/sh) if needed. Enter the command that you want to use to start the component. Caution: Do not use the -B argument with this component. Since jabberd is already a daemon process, its children must not be daemons. Do not escape XML characters in the Controller's interface. For example, if you were writing the command configuration manually, you would need to write the string "exec 2>&1" as "exec 2>&1". However, in the Controller, you should enter the literal string and let the software perform the necessary escaping when it converts the form input into XML. Hostnames Host Filters Enter the hostnames or IP addresses for which you want this CM component to handle packets. Separate each hostname or address with a line break. Enter an asterisk (*) in the textbox to enable the component to handle data from any hosts that are not specified in another XDB host filter. Note: Host filters must be hostnames, or IPv4 or IPv6 addresses. If an IP address is used, the packet address must also use this IP address. Connection Manager Configuration Maximum number of sockets for connecting clients Maximum size of the threadpool Enter the maximum number of sockets for the CM across all client and SMTP connections. This number does not include the sockets used by the processors to connect to the central router (jabberd). The default setting is Enter the number of threads used by the client and SMTP connections. This does not include the threads used to talk to the central router (jabberd). The default setting is 5. Command Processors 48

55 Component Configuration You can add one or both of the following command processors, depending on what you are configuring this particular CM to do: The JSM command processor is used to connect the Jabber XCP Server to Jabber Inc.'s IM clients (Jabber Messenger and WebClient). The SMTP command processor is used to connect the Jabber XCP Server to an external server for the delivery of offline messages via . The S2S command processor is used to connect two Jabber XCP Servers. Note: Usually, an S2S command processor is configured in its own CM. The Web command processor is used to connect specific functions of the Jabber XCP Server to custom-build components. Select the desired command processor in the drop-down list, and click the Go button to access the configuration window for that command processor. When you submit your command processor configuration, you are returned to the Connection Manager Configuration window. SNMP Configuration Select the SNMP Configuration option if you want to configure SNMP for the CM component. SNMP Enabled SNMP Count Errors Component Logging This option is set to Yes by default. Select Yes only if you want to enable SNMP error counting. This option takes a great deal of server resource; use it with caution. It is set to No by default. Select the Component Logging (Jlog) option to configure filtered level loggers that log messages to syslog and to a stream (stderr or stdout). You can enable either or both the syslog and stream loggers. Caution! When a component is daemonized, logging to stderr or stdout does not work; for example, if you start a component from the command line using the -B flag, it is daemonized. These loggers log messages that are at or above the selected severity level, and drop messages that are below the 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. Filtered Syslog Logger 49

56 XCP Controller Help Select the Filtered Syslog Logger option if you want to log information to syslog. The syslog logger logs messages that meet the Level Filter criteria. Level Pipe file Facility Identity Formatter Select a severity level from the pull-down list. ("INFO" is the default setting.) The levels are listed from least severe to most. The less severe the level, the more verbose the log. DEBUG - Information from all other log levels in addition to debug data. VERBOSE - Every packet that is processed by the server and JSM plus all Error, Warn, and Info data. INFO - Data about socket connections and all JSM logs (packet, session, and message) plus all Error Warn, and Stats log level data. This is the level at which the server logs by default. WARNING - Non-fatal errors such as bounced packets, nonexistent user logging in, invalid recipient for a message, etc., plus all Error log level data. ERROR - System-generated errors such as the inability to create listen ports, server configuration errors, failure to create the log files, etc. Enter the full path to a pipe file for this component; we suggest naming the file /var/tmp/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. Select the facility that you want to use from the drop-down list. The default facility is "LOG_DAEMON." Note: Facilities are defined on the syslog(3) manpage. Enter a term that identifies where the log information is coming from. The identity is displayed in syslog next to the associated data. The default identity is "XCP." You can change this value as needed. Enter the formatters for the information that you want to log. A default format of %d [%l] %s: %m is provided. Filtered Stream Logger 50

57 Component Configuration Select the Filtered Stream Logger option if you want to log information to stderr or to stdout. The stream logger logs messages that meet the Level Filter criteria to the specified output stream. Level Pipe file Stream Formatter Select a severity level from the pull-down list. The levels are listed from least severe to most. The less severe the level, the more verbose the log. DEBUG - Information from all other log levels in addition to debug data. VERBOSE - Every packet that is processed by the server and JSM plus all Error, Warn, and Info data. INFO - Data about socket connections and all JSM logs (packet, session, and message) plus all Error Warn, and Stats log level data. This is the level at which the server logs by default. WARNING - Non-fatal errors such as bounced packets, nonexistent user logging in, invalid recipient for a message, etc., plus all Error log level data. ERROR - System-generated errors such as the inability to create listen ports, server configuration errors, failure to create the log files, etc. Enter the full path to a pipe file for this component; we suggest naming the file /var/tmp/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. Select stderr or stdout from the drop-down list. Stderr is the default setting. Enter the formatters for the information that you want to log. A default format of %d [%l] %s: %m is provided. Add a new Custom Logger Click the Go button to access the Custom Logger Configuration screen, in which you can specify the library and library entry point function for a custom logger. Submit Your Configuration 51

58 XCP Controller Help When you have finished configuring this component, click the Submit button. If you want to cancel the configuration, click the Cancel button, not the browser's back button. See also: Full Help System JSM Command Processor Configuration SMTP Command Processor Configuration S2S Command Processor Configuration Web Command Processor Configuration Connection Manager Overview 52

59 Component Configuration JSM Command Processor JSM Command Processor Configuration The JSM command processor (JSMCP) handles the translation and transfer of data between IM clients and the router (jabberd). JSM Command Processor ID The Jabber ID of this command processor. This is a readonly value that is generated by the Controller; the value increments automatically as you add additional JSMCPs. Director Configuration Select a director in the pull-down list and click the Go button to access its configuration window. Your choices include: XMPP director handles communications with Jabber Inc.'s IM clients, Jabber Messenger 3.0 for Windows and WebClient. Polling director uses HTTP to communicate over firewalls using port 80. It handles communication with Jabber Messenger 3.0 for Windows, WebClient, and Jabber Messenger for J2ME Wireless client. Router Connection Information Connection Type Component IP Port With an accept connection type (the default setting), the router opens a specific port and listens on that port for a connection from the component. By default, the router listens for connections from all components. With a connect connection type, the router connects to the component. If you selected an accept connection type, enter the IP address or FQDN on which the router listens for the command processor. By default, this field contains the IP address of the system on which the router is installed. If you selected a connect connection type, enter the IP address or hostname of the system on which the CM is installed. If you selected an accept connection type, enter the port on which the router listens for the command processor's connection. The router allows only a single connection 53

60 XCP Controller Help Password over this port at a time; therefore, multiple versions of the command processor cannot connect over the same port. The port is set to 7303 by default. If you selected a connect connection type, enter the port that the command processor uses for communications. Enter the password used by the server to authenticate the command processor. Client Locks Select the client-locks option and click the Go button to access the Client Configuration window in which you can configure client locking between this JSM command processor and a Jabber client. You can add multiple client locks. Broadcast enable-broadcast Select Yes (the default setting) if you want to allow the router to send broadcast messages to all online users connected through this CM. Hosts to Track Enter the hostnames or IP addresses of any transports; for example, msn.jabber.com. This enables clients to receive notifications when the transports become available or unavailable. Submit Your Configuration When you have finished configuring this JSM command processor, click the Submit button. If you want to cancel the configuration, click the Cancel button, not the browser's back button. See also: Full Help System 54

61 Component Configuration XMPP Director Configuration The XMPP director handles communication with Jabber Inc.'s IM clients, Jabber Messenger and WebClient. XMPP Director ID The Jabber ID of this director. This is a read-only value that is generated by the Controller; the value increments automatically as you add additional directors. Listening Connection for the TCP Socket IP address of external channel Port SSL Settings Enter the IP address of the external channel on which this director listens for connections from the IM clients. By default, this is set to the IP address of the system on which jabberd is installed. Enter the port number on which this director listens for connections from the IM clients. The default setting is Note: If you enable SSL Listen Mode, use port Select this option to configure secure socket layer settings to enable this director to establish a secure connection with the server. Note: For the purposes of this configuration, SSL is accessed via Start TLS. ssl-mode Select the desired mode from the pull-down list. The choices are: Full path to SSL key file listen SSL listening mode. To use SSL, clients must connect to the server over port tls Enables TLS (transport layer security). Clients that support TLS can connect to the server securely over Clients that do not support TLS can still connect to the server. tls-required The same as the tls option, except that the client must support TLS. Clients that do not support TLS cannot connect to the server. Note: Tls mode does not require a secure connection. Enter the full path to the location of the private key that is used to establish a secure server connection. The 55

62 XCP Controller Help Full path to SSL cert file Full path to root CA cert file Keepalive default location is set to xcpinstalldir/certs/key.pem. Enter the full path to the location of the default certificate file. The default location is set to xcpinstalldir/certs/key.pem. This is the same location as the key; however, it is a different file if you work with a certificate authority to acquire a certified key. Note: You must create your own certified key in order to secure the system. Enter the path to the CA cert with which to verify incoming client certificates. Verify depth Enter the maximum depth for the certificate chain verification to allow for incoming client connections. The default setting is 10. Enable weak ciphers Select Yes if you want to allow SSL connections to use cryptographically weak ciphers. The default setting is No. Select the keepalive option if you want to configure a keep-alive interval for the XMPP director. interval Limit Enter the number of seconds after which a keep-alive is sent to the director. The keep-alive helps prevent firewalls from dropping an unused connection to the director. If this option is set to 0, keep-alives are disabled. The default setting is 60 seconds. Select the limit option if you want to configure limits for the amount of data that can be sent or received by each connection, and for the number of connections that this director can accept. karma Select this option if you want to configure the number of bytes that can be sent or received per second by each connection. The smaller the limit (karma size threshold), the easier it is for a user to be penalized. Once a user reaches the karma limit and is penalized, everything further sent by the client is queued at the OS level, and the Jabber XCP Server does not accept any data from the client until the penalty phase passes. The penalty phase is on a timer. Enable this option only if you need to control the amount of data that is sent or received. 56

63 Component Configuration read-bytes Enter the number of bytes per second to read from the client; -1 disables the option. The default setting is write-bytes Enter the number of bytes per second to write to the client; -1 disables it. The default setting is connection-limits Select this option if you want to configure the number of new connections per second that will be accepted by this director. max Enter the maximum number of sockets the director accepts; -1 disables the option. The default setting is 500. max per slice Enter the maximum number of connections that can occur per time slice. max per ip Enter the maximum number of connections the director accepts from a single IP address. The default setting, - 1, disables the option. Time slice (secs) Enter the number of seconds per time slice. max packet bytes Token Authentication Mapping Enter the maximum size of a packet (in bytes) that this director can accept. Limiting the packet size helps reduce bandwidth issues that can occur when huge packets are sent through the router. Note: The packet size is not exact. The Jabber XCP Server supports token-based authentication mechanisms. If you have a custom token authentication mechanism installed on your server, select the tokenauth mappings option and click the Go button to access the Mapping Configuration window in which you can configure token-based authentication for this director. Please contact Jabber, Inc.'s Professional Services for more information about adding custom components. SASL Settings SASL (Simple Authentication and Security Layer) is a method for adding authentication support to connection-based protocols. Select the SASL Settings option if you want to enable this feature for the XMPP director. Note: Refer to your Cyrus SASL documentation for information about setting up a SASL database. This is done apart from the Controller. 57

64 XCP Controller Help Application Name SASL Realm max auth tries This setting should always be 'xmpp'. Enter the hostname that is specified in your server-side SASL configuration (unless you have an unusual SASL configuration). Enter the number of authentication attempts that you want the system to make. The default setting is 1. Submit Your Configuration Click the Submit button when you have finished configuring the XMPP director. If you want to cancel the configuration, click the Cancel button, not the browser's back button. See also: Full Help System 58

65 Component Configuration Polling Director Configuration The Polling director handles communication with Jabber Inc.'s IM clients, WebClient, and Jabber Messenger for J2ME Wireless client. The Polling director uses HTTP to communicate over firewalls using port 80. Note: The Polling director takes the place of the old mod_webclient and Apache configuration that used to be required for setting up WebClient to run over an HTTP polling connection. Polling Director ID The Jabber ID of this director. This is a read-only value that is generated by the Controller; the value increments automatically as you add additional directors. Listening Connection for the TCP Socket IP address of external channel Port SSL Settings Enter the IP address of the external channel on which this director listens for connections from the IM clients. By default, this is set to the IP address of the system on which jabberd is installed. Enter the port number on which this director listens for connections from the IM clients. The default setting is 80. Select this option to configure secure socket layer settings to enable this director to establish a secure connection with the server. Note: For the purposes of this configuration, TLS is SSL (however, SSL is not TLS). ssl-mode Select the desired mode from the pull-down list. The choices are: listen SSL listening mode. To use SSL, clients must connect to the server over port tls Enables TLS (transport layer security). Clients that support TLS can connect to the server securely over Clients that do not support TLS can still connect to the server. tls-required The same as the tls option, except that the client must support TLS. Clients that do 59

66 XCP Controller Help Full path to SSL key file Full path to SSL cert file Full path to root CA cert file Limit not support TLS cannot connect to the server. Note: Neither listen nor tls mode requires a secure connection. Enter the full path to the location of the private key that is used to establish a secure server connection. The default location is set to xcpinstalldir/certs/key.pem. Enter the full path to the location of the default certificate file. The default location is set to xcpinstalldir/certs/key.pem. This is the same location as the key; however, it is a different file if you work with a certificate authority to acquire a certified key. Note: You must create your own certified key in order to secure the system. Enter the path to the CA cert with which to verify incoming client certificates. Verify depth Enter the maximum depth for the certificate chain verification to allow for incoming client connections. The default setting is 10. Enable weak ciphers Select Yes if you want to allow SSL connections to use cryptographically weak ciphers. The default setting is No. max packet bytes Enter the maximum size of a packet (in bytes) that this director can accept. Limiting the packet size helps reduce bandwidth issues that can occur when huge packets are sent through the router. Note: The packet size is not exact. Miscellaneous Settings socket write timeout session timeout seconds file root directory Enter the number of seconds allowed for the socket to write data before timing out. Enter the number of seconds after which the server terminates the session if the client has not sent a poll request. Enter the root directory on the Jabber XCP Server that contains the files that are served up to WebClient. SASL Settings 60

67 Component Configuration SASL (Simple Authentication and Security Layer) is a method for adding authentication support to connection-based protocols. Select the SASL Settings option if you want to enable this feature for the Polling director. Note: Refer to your Cyrus SASL documentation for information about setting up a SASL database. This is done apart from the Controller. Application Name This setting should always be xmpp. SASL Realm max auth tries Submit Your Configuration Enter the hostname that is specified in your server-side SASL configuration (unless you have an unusual SASL configuration). Enter the number of authentication attempts that you want the system to make. The default setting is 1. Click the Submit button when you have finished configuring the XMPP director. If you want to cancel the configuration, click the Cancel button, not the browser's back button. See also: Full Help System 61

68 XCP Controller Help SMTP Command Processor SMTP Command Processor Configuration The SMTP command processor enables the redirection of offline messages to an server. Offline messages are messages that are sent to a client while the client is offline. Additional Configuration Instructions In addition to providing the information in the SMTP Command Processor Configuration screen, you must do the following: In the Jabber Session Manager Configuration screen: o Enable the mod_sendmail and mod_offline_smtp modules. o Configure the Send Transcript agent unless you enabled the mod_disco module, in which case the agent is created automatically. From the Controller's main window, add an Open Port component and name it SMTPCP-n (the ID of this SMTP command processor, where 'n' is 1 for the first SMTPCP and '2' for the second, etc). SMTP Command Processor and Director SMTP Command Processor id The Jabber ID of this command processor. This is a read-only value that is generated by the Controller; the value increments automatically as you add additional SMTP command processors. SMTP Director id The Jabber ID of this director. This is a read-only value that is generated by the Controller. smarthost This section contains the parameters required for connecting to the smarthost and converting Jabber messages to SMTP s. Each director instance uses a single SMTP smarthost. host Enter the IP or FQDN of the smarthost. port Enter the port number used to connect to the smarthost. 62

69 Component Configuration The default setting is 25. domain Enter the domain that the XCP system uses when connecting to the smarthost. Your smarthost must be configured to accept relay mail from this domain. max-retries Enter the number of times the directory attempts to connect to the smarthost before giving up. The default setting is 5. SSL Settings Select this option to configure secure socket layer settings to establish a secure CM connection. Note: For the purposes of this configuration, SSL is accessed via Start TLS. ssl-mode Select the desired mode from the pull-down list. The choices are: Full path to SSL key file Full path to SSL cert file Full path to root CA cert file listen SSL listening mode. To use SSL, clients must connect to the server over port tls Enables TLS (transport layer security). Clients that support TLS can connect to the server securely over Clients that do not support TLS can still connect to the server. tls-required The same as the tls option, except that the client must support TLS. Clients that do not support TLS cannot connect to the server. Note: Tls mode does not require a secure connection. Enter the full path to the location of the private key that is used to establish a secure server connection. The default location is set to xcpinstalldir/certs/key.pem. Enter the full path to the location of the default certificate file. The default location is set to xcpinstalldir/certs/key.pem. This is the same location as the key; however, it is a different file if you work with a certificate authority to acquire a certified key. Note: You must create your own certified key in order to secure the system. Enter the path to the CA cert with which to verify incoming client certificates. Verify depth Enter the maximum depth for the certificate chain verification to allow for incoming client connections. The default setting is 10. Enable weak- Select Yes if you want to allow SSL connections to use 63

70 XCP Controller Help auth subject prebody ciphers cryptographically weak ciphers. The default setting is No. Select this option to configure SMTP authentication credentials with the Jabber XCP Server. username Enter the username for authenticating with the SMTP server. password Enter the password used for authenticating with the SMTP server. Enter the subject of the messages. This subject displays in the 's subject line. You can configure it using the %FROMJID% variable as shown in the following example: This is an offline message from %FROMJID%. The system automatically replaces the %FROMJID% variable with the Jabber ID of the message's sender. Enter a header for the messages. The header is prefixed onto the message body. You can configure it using the %FROMJID% variable as shown in the following example: This message was forwarded from %FROMJID% by the Jabber server. postbody pooled-connscount The system automatically replaces the %FROMJID% variable with the Jabber ID of the message's sender. Enter a footer for the message. The footer is appended to the message body. You can configure it using the %FROMJID% variable as shown in the following example: This message was sent to you by %FROMJID%. The system automatically replaces the %FROMJID% variable with the Jabber ID of the message's sender. Enter the number of simultaneous connections that can be made to the smarthost. SMTP Headers SMTP headers are used to stamp outgoing messages. If you want to configure a header, select this option, and click the Go button. 64

71 Component Configuration Router Connection Information Connection Type With an accept connection type (the default setting), the router opens a specific port and listens on that port for a connection from the component. By default, the router listens for connections from all components. With a connect connection type, the router connects to the component. Component IP If you selected an accept connection type, enter the IP address or FQDN on which the router listens for the command processor. By default, this field contains the IP address of the system on which the router is installed. Port Password Submit Your Configuration If you selected a connect connection type, enter the IP address or hostname of the system on which the CM is installed. If you selected an accept connection type, enter the port on which the router listens for the command processor's connection. The router allows only a single connection over this port at a time; therefore, multiple versions of the command processor cannot connect over the same port. The port is set to 7321 by default. If you selected a connect connection type, enter the port that the command processor uses for communications. Enter the password that the server uses to authenticate the command processor. When you have finished configuring this command processor, click the Submit button. If you want to cancel the configuration, click the Cancel button, not the browser's back button. See also: Full Help System Connection Manager Overview Connection Manager Configuration JSM Command Processor Configuration 65

72 XCP Controller Help S2S Command Processor S2S Command Processor Configuration The Server-to-Server (S2S) command processor has replaced the old Server Connection Manager (SCM) component. It enables Jabber XCP Servers to communicate with each other across domains, and supports the Jabber dialback protocol, which determines whether or not to trust a connection from another server. Additional features include the ability to: Blacklist IP addresses and hostnames to prevent unwanted server connections. Configure connections to expire automatically. Enforce connection lifetimes to ensure fair use of server-to-server delivery. Adjust the number of threads to manage performance, limit the maximum number of sockets used to manage resources and usage, and control the number of inbound/outbound bytes per second to manage resources and usage. Deliver messages with automatic retry if the remote server is unavailable. Each message delivery is attempted three times before the message bounces back to the sender. Additional Configuration Instructions The S2S command processor should be configured in its own Connection Manager. You must also configure an S2S open port component, which will enable the S2S CM to connect to the router. The S2SCP's ID must be used as the ID of the open port component. Furthermore, the Component IP, Port, and Password that you specify for this S2SCP must be used in the corresponding configuration in the open port. Director Configuration Select a director from the pull-down list and click the Go button to access the configuration screen for that director. Your choices include: 66

73 Component Configuration XMPP Incoming Server director handles incoming packets being sent to the router from remote servers. XMPP Outgoing Server director handles outgoing packets being sent from the router to remote servers. S2SCP Configuration Router Connection Information Connection Type Configure the S2SCP with a connection of type connect. With this type of connection, the router connects to the component. Component IP Port Password Dialback Secret Note: You must configure a connection of type accept for the Open Port component. With this type of connection, the router opens a specific port and listens on that port for a connection from the component. If you selected an accept connection type, enter the IP address or FQDN on which the router listens for the component. By default, this field contains the IP address of the system on which the router is installed. If you selected a connect connection type, enter the IP address or hostname of the system on which the component is installed. If you selected an accept connection type, enter the port on which the router listens for the component s connection. The router allows only a single connection over this port at a time; therefore, multiple versions of the component cannot connect over the same port. The port is set to 7301 by default. If you selected a connect connection type, enter the port that the component uses for communications. Enter the password that the router uses to authenticate the component. A default is provided. You can change this value as needed. Enter the password used to prove the authenticity of another server. All S2S control processors for a single XCP system must have the same dialback secret. Authorized Outgoing 'From' Addresses 67

74 XCP Controller Help Outgoing 'from' addresses are hosts or IP addresses within your organization from which outgoing packets may be sent. Outgoing 'from' addresses are normally paired with incoming 'to' addresses. Default behavior Hosts IPs Select the default behavior of your system for handling outgoing 'from' addresses, either allow or deny. The hosts and IP addresses listed below are exceptions to the default behavior. For example, if you set the default behavior to allow, the specified hosts and IPs are not allowed to send outgoing packets. If you set the default behavior to deny, the specified hosts and IPs are allowed to send outgoing packets. Enter the hostnames for which you want to apply the opposite of the default behavior. Enter the IP addresses for which you want to apply the opposite of the default behavior. Authorized Outgoing 'To' Addresses Outgoing 'to' addresses are hosts or IP addresses to which people or entities in your organization may send outgoing packets. Outgoing 'to' addresses are normally paired with incoming 'from' addresses. Default behavior Hosts IPs Select the default behavior of your system for handling outgoing 'to' addresses, either allow or deny. The hosts and IP addresses listed below are exceptions to the default behavior. For example, if you set the default behavior to allow, outgoing packets are not allowed to be sent to the specified hosts and IPs. If you set the default behavior to deny, outgoing packets can be sent to the specified hosts and IPs. Enter the hostnames for which you want to apply the opposite of the default behavior. Enter the IP addresses for which you want to apply the opposite of the default behavior. Authorized Incoming 'From' Addresses Incoming 'from' addresses are hosts or IP addresses from which people or entities in your organization may receive incoming packets. Incoming 'from' addresses are normally paired with outgoing 'to' addresses. Default behavior Select the default behavior of your system for handling incoming 'from' addresses, either allow or deny. The hosts and IP addresses listed below are exceptions to the default behavior. For example, if 68

75 Component Configuration Hosts IPs you set the default behavior to allow, the specified hosts and IPs are not allowed to send incoming packets. If you set the default behavior to deny, the specified hosts and IPs are allowed to send incoming packets. Enter the hostnames for which you want to apply the opposite of the default behavior. Enter the IP addresses for which you want to apply the opposite of the default behavior. Authorized Incoming 'To' Addresses Incoming 'to' addresses are hosts or IP addresses in your organization that cannot receive incoming packets. Incoming 'to' addresses are usually paired with outgoing 'from' addresses. Default behavior Hosts IPs Select the default behavior of your system for handling incoming 'to' addresses, either allow or deny. The hosts and IP addresses listed below are exceptions to the default behavior. For example, if you set the default behavior to allow, the specified hosts and IPs are not allowed to receive incoming packets. If you set the default behavior to deny, the specified hosts and IPs are allowed to receive incoming packets. Enter the hostnames for which you want to apply the opposite of the default behavior. Enter the IP addresses for which you want to apply the opposite of the default behavior. Connection Settings Number of connection attempts for outgoing connections Connection Attempt Delay (seconds) Enter the number of times to try making an outbound connection. The default setting is 1. Enter the number of seconds to wait between connection attempts. The default setting is 60. IP Addresses to Prevent Loopback Connections IP Addresses Enter the address of any S2S Command Processor that listens for incoming packets. Invalid DNS Hostname Cache 69

76 XCP Controller Help Timeout for Failed Outgoing cache (seconds) The S2S Command Processor caches invalid DNS hostnames that it encounters to prevent itself from looking up the same invalid names over and over. Enter the number of seconds after which the cache table is cleared. This table must be cleared periodically to prevent DOS attacks and to prevent a temporarily-unresolvable hostname from becoming permanently unresolvable. The default setting is 1800 seconds. Outgoing Connection Attempt Rules Click the Go button to access the Rule Configuration screen where you define rules that specify the order and DNS lookup properties for each outbound director. Important! You must configure three specific rules in the Rule Configuration screen. These rules are described on the help page for the screen. S2S Administrators Administrator Jabber IDs Which users can discover/view s2s connections Enter the Jabber IDs of those you want to enable to query the S2S Command Processor. Select which users can query the S2S Command Processor for a list of connected hosts. The default setting is 'admins'. Submit Your Configuration When you have finished configuring this component, click the Submit button. If you want to cancel the configuration, click the Cancel button, not the browser's back button. See also: Full Help System 70

77 Component Configuration Outgoing Connection Rule Configuration The S2S Control Processor contains rules that specify the order and DNS lookup properties for each outbound director. Each rule specifies the ID of the director that should attempt the connection, and the DNS SRV lookup or port to use for the connection. Each time a new outbound connection is required, the S2SCP goes through the rules asking the specified director to attempt the outgoing connection. If a director successfully establishes a connection, then that director will always handle stanzas bound for that host. Otherwise, the S2SCP asks the next director (using the rules defined) to attempt an outbound connection for the new host. For example, the S2SCP may be configured to try XMPP first for all outbound connections, and SIMPLE second, etc. Rule Director ID DNS SRV lookup to use Port to use instead of DNS SRV lookup The ID of the director for which you are configuring the rule. The default setting is xmppsoutd-1. Enter _xmpp-server._tcp or _jabber._tcp. The port to use if the DNS SRV lookups do not work. Enter Note: If you use a port other than 5269, you must create a DNS SRV record and match this port setting in it. Important: Every Jabber XCP Server must have the following three rules: Director ID DNS SRV lookup Port xmppsoutd-1 xmppsoutd-1 _xmpp-server._tcp _jabber._tcp xmppsoutd Submit Your Configuration When you have finished configuring this component, click the Submit button. If you want to cancel the configuration, click the Cancel button, not the browser's back button. See also: 71

78 XCP Controller Help Full Help System 72

79 Component Configuration XMPP Incoming Server Director Configuration This section configures the XMPP incoming director, which handles packets being sent to the router from remote servers. XMPP Incoming Server Director ID The Jabber ID of this director. This is a read-only value that is generated by the Controller; the value increments automatically as you add additional directors. Listening Connection for the TCP Socket IP address of external channel Port SSL Settings Enter the IP address of the external channel on which this director listens for connections from the IM clients. By default, this is set to the IP address of the system on which jabberd is installed. Enter the port number on which this director listens for connections from the IM clients. The default setting is Select this option to configure secure socket layer settings to enable this director to establish a secure connection with the server. Note: For the purposes of this configuration, SSL is accessed via Start TLS. ssl-mode Select the desired mode from the pull-down list. The choices are: Full path to SSL key file listen - Do not select this option. Listen should never be used with S2S. tls Enables TLS (transport layer security). Servers that support TLS can connect to the server securely over Servers that do not support TLS can still connect to the server. tls-required Connecting servers must support TLS. Servers that do not support TLS cannot connect to the server. Note: Tls mode does not require a secure connection. Enter the full path to the location of the private key that is used to establish a secure server connection. The 73

80 XCP Controller Help Full path to SSL cert file Full path to root CA cert file Keepalive default location is set to xcpinstalldir/certs/key.pem. Enter the full path to the location of the default certificate file. The default location is set to xcpinstalldir/certs/key.pem. This is the same location as the key; however, it is a different file if you work with a certificate authority to acquire a certified key. Note: You must create your own certified key in order to secure the system. Enter the path to the CA cert with which to verify incoming client certificates. Verify-depth Enter the maximum depth for the certificate chain verification to allow for incoming client connections. The default setting is 10. Enable-weakciphers Select Yes if you want to allow SSL connections to use cryptographically weak ciphers. The default setting is No, in which case strong ciphers are used. Select the keepalive option if you want to configure a keep-alive interval for this director. interval Limit Enter the number of seconds after which a keep-alive is sent to the director. The keep-alive helps prevent firewalls from dropping an unused connection to the director. If this option is set to 0, keep-alives are disabled. The default setting is 60 seconds. Select the limit option if you want to configure limits for the amount of data that can be sent or received by each connection, and for the number of connections that this director can accept. karma Select this option if you want to configure the number of bytes that can be sent or received per second by each connection. The smaller the limit (karma size threshold), the easier it is for a user to be penalized. Once a connection reaches the karma limit and is penalized, everything further sent by the server is queued at the OS level, and the Jabber XCP Server does not accept any data from the server until the penalty phase passes. The penalty phase is on a timer. Enable this option only if you need to control the amount of data that is sent or received. 74

81 Component Configuration read-bytes Enter the number of bytes per second to read from the server; -1 disables the option. The default setting is write-bytes Enter the number of bytes per second to write to the server; -1 disables it. The default setting is connection-limits Select this option if you want to configure the number of new connections per second that will be accepted by this director. max Enter the maximum number of sockets the director accepts; -1 disables the option. The default setting is 500. max-per-slice Enter the maximum number of connections that can occur per time slice. max-per-ip Enter the maximum number of connections that can occur per IP address, regardless of how much time has elapsed. Time slice (secs) Enter the number of seconds per time slice. max packet bytes Enter the maximum size of a packet (in bytes) that this director can accept. Limiting the packet size helps reduce bandwidth issues that can occur when huge packets are sent through the router. Dialback Authentication Note: The packet size limiting is not exact, but rather a rough guide. Enable dialback authentication Select Yes (the default setting) if you want to use the dialback protocol for authentication. SASL Settings SASL (Simple Authentication and Security Layer) is a method for adding authentication support to connection-based protocols. Select the SASL Settings option if you want to enable this feature for the director. Note: Refer to your Cyrus SASL documentation for information about setting up a SASL database. This is done apart from the Controller. SASL Realm SASL Hostname Enter the hostname that is specified in your server-side SASL configuration (unless you have an unusual SASL configuration). Enter the hostname that is specified in your server-side 75

82 XCP Controller Help Enable External Auth External Auth ID SASL configuration. Select Yes if you want to authenticate using an SSL certification. To do this, you must enable SSL, require TLS, and have a validating cert for the root CA. No is the default setting. Enter your ID when doing an external authentication. If this field is left blank, this value defaults to the common name (cn) in the cert. Submit Your Configuration Click the Submit button when you have finished configuring the director. If you want to cancel the configuration, click the Cancel button, not the browser's back button. See also: Full Help System 76

83 Component Configuration XMPP Outgoing Server Director Configuration This section configures the XMPP outgoing director, which handles packets being sent from the router to remote servers. XMPP Outgoing Server Director ID Threads to use for establishing outgoing connections Enable XMPP Dialback Authentication Timeout for dialback authentication (secs) Timeout for idle connections (secs) The Jabber ID of this director. This is a readonly value that is generated by the Controller; the value increments automatically as you add additional directors. Enter the number of threads to use for DNS lookups. Select Yes if you want to enable dialback authentication for this XMPP server. No is the default setting. Enter the number of seconds to wait for dialback results before dropping the connection. Enter the number of seconds to keep the S2S connection when this director has not sent anything through the connection. SASL Authentication Credentials Click the Go button to access the SASL Settings Configuration screen. SSL Settings SSL Settings Select this option to configure secure socket layer settings to enable this director to establish a secure connection with the server. Note: For the purposes of this configuration, SSL is accessed via Start TLS. ssl-mode Select the desired mode from the pull-down list. The choices are: listen Do not select this option. Listen should never be used with S2S. tls Enables TLS (transport layer security). 77

84 XCP Controller Help Full path to SSL key file Full path to SSL cert file Full path to root CA cert file Servers that support TLS can connect to the server securely over Servers that do not support TLS can still connect to the server. tls-required Connecting servers must support TLS. Servers that do not support TLS cannot connect to the server. Note: Tls mode does not require a secure connection. Enter the full path to the location of the private key that is used to establish a secure server connection. The default location is set to xcpinstalldir/certs/key.pem. Enter the full path to the location of the default certificate file. The default location is set to xcpinstalldir/certs/key.pem. This is the same location as the key; however, it is a different file if you work with a certificate authority to acquire a certified key. Note: You must create your own certified key in order to secure the system. Enter the path to the CA cert with which to verify incoming client certificates. Verify-depth Enter the maximum depth for the certificate chain verification to allow for incoming client connections. The default setting is 10. Enable-weakciphers Submit Your Configuration Select Yes if you want to allow SSL connections to use cryptographically weak ciphers. The default setting is No, in which case strong ciphers are used. Click the Submit button when you have finished configuring the director. If you want to cancel the configuration, click the Cancel button, not the browser's back button. See also: Full Help System 78

85 Component Configuration Web Command Processor Web Command Processor Configuration The Web command processor handles HTTP requests; it translates and transfers data between clients and the Jabber XCP router (jabberd) over the Web. Customers who purchase the Web Services package will be able to install the Web Services component as part of the Jabber XCP Server and to configure the WebCP and the Web Services Handler. Additional Configuration Instructions The Web Command Processor should be configured in its own Connection Manager. You must also configure a Web Services open port component. The port number you specify for the open port must match the port specified in the Web Services Handler. Director Configuration Click the Go button to access the HTTP Director Configuration screen. The HTTP Director receives HTTP requests from clients and calls the command processor to process them. WebCP Configuration Click the Go button to access the Web Services Handler Configuration screen in which you associate an HTTP URI path with a handler. Currently, only one path per handler is supported. Submit Your Configuration Click the Submit button when you have finished configuring this command processor. If you want to cancel the configuration, click the Cancel button, not the browser's back button. See also: Full Help System 79

86 XCP Controller Help HTTP Director Configuration The HTTP director receives SOAP-over-HTTP requests from Web Services applications and passes these requests to the Web Command Processor. Listening Connection for the TCP Socket IP address of external channel Port SSL Settings Enter the IP address of the external channel on which this director listens for incoming SOAP requests. By default, this is set to the IP address of the system on which jabberd is installed. Enter the port number on which this director listens for incoming SOAP requests. The default setting is Select this option to configure secure socket layer settings to enable this director to establish a secure connection with the server. Note: For the purposes of this configuration, SSL is accessed via Start TLS. ssl-mode Select the desired mode from the pull-down list. The choices are: Full path to SSL key file Full path to SSL cert file listen SSL listening mode. tls Enables TLS (transport layer security). Clients that support TLS can connect to the server securely over Clients that do not support TLS can still connect to the server. tls-required The same as the tls option, except that the client must support TLS. Clients that do not support TLS cannot connect to the server. Note: Neither listen nor tls mode requires a secure connection. Enter the full path to the location of the private key that is used to establish a secure server connection. The default location is set to xcpinstalldir/certs/key.pem. Enter the full path to the location of the default certificate file. The default location is set to xcpinstalldir/certs/key.pem. This is the same location as the key; however, it is a different file if you work with a certificate authority to acquire a certified key. Note: You must create your own certified key in order to secure the system. 80

87 Full path to root CA cert file Limit Component Configuration Enter the full path to the CA cert with which to verify incoming client certificates. Verify depth Enter the maximum depth for the certificate chain verification to allow for incoming client connections. The default setting is 10. Enable weak ciphers Select Yes if you want to allow SSL connections to use cryptographically weak ciphers. The default setting is No. Select the limit option if you want to configure limits for the amount of data that can be sent or received by each connection, and for the number of connections that this director can accept. karma Select this option if you want to configure the number of bytes that can be sent or received per second by each connection. The smaller the limit (karma size threshold), the easier it is for a user to be penalized. Once a user reaches the karma limit and is penalized, everything further sent by the client is queued at the OS level, and the Jabber XCP Server does not accept any data from the client until the penalty phase passes. The penalty phase is on a timer. Enable this option only if you need to control the amount of data that is sent or received. read-bytes Enter the number of bytes per second to read from the client; -1 disables the option. The default setting is write-bytes Enter the number of bytes per second to write to the client; -1 disables it. The default setting is connection-limits Select this option if you want to configure the number of new connections per second that will be accepted by this director. max Enter the maximum number of sockets the director accepts; -1 disables the option. The default setting is 500. max per slice Enter the maximum number of connections that can occur per time slice. max per ip Enter the maximum number of connections the director accepts from a single IP address. The default setting, - 81

88 XCP Controller Help 1, disables the option. Time slice (secs) Enter the number of seconds per time slice. Submit Your Configuration Click the Submit button when you have finished configuring the HTTP director. If you want to cancel the configuration, click the Cancel button, not the browser's back button. 82

89 Component Configuration Web Services Handler Configuration The Web Services handler configures a URI (Uniform Resource Indicator) path, over which messages are sent from Web Services applications to the handler via HTTP. The handler performs HTTP basic authentication and, if passed, forwards the message to the Web Services component. The type of handler you configure depends on what protocol is running over HTTP. The handler handles that protocol; for example, SOAP. Note: Currently, only one path per handler is supported. HTTP URI Paths Handled Path Path to file containing admin password FQDN of Web Services Component Time slice (in seconds) for logging Enter the HTTP URI path that this handler will handle. For example, for the URI '/soap' is the path. Enter the full path to the file that contains the Web Services administrator's password. Enter the fully qualified domain name of the Web Services component; for example, webservices.example.com. Note: This value must match the hostname specified for the Web Services component in the Web Services Configuration screen. Enter the number of seconds after which log information is written. The default setting is 60. Router Connection Information This section configures the parameters necessary for this handler to communicate with the Jabber XCP router, jabberd. Connection Type Component IP With an accept connection type (the default setting), the router opens a specific port and listens on that port for a connection from the component. By default, the router listens for connections from all components. With a connect connection type, the router connects to the component. If you selected an accept connection type, enter the IP address or FQDN on which the router listens for the handler. 83

90 XCP Controller Help Port Password (By default, this field contains the IP address of the system on which the router is installed.) If you selected a connect connection type, enter the IP address or hostname of the system on which the handler is installed. If you selected an accept connection type, enter the port on which the router listens for the components connection. The router allows only a single connection over this port at a time; therefore, multiple versions of the component cannot connect over the same port. (The port is set to 7336 by default. If you change the port, make sure it matches the port specified in the Web Services open port component.) If you selected a connect connection type, enter the port that the handler uses for communications. Enter the password that the router uses to authenticate the component. A default is provided. You can change this value as needed. Submit Your Configuration Click the Submit button when you have finished configuring this component. If you want to cancel the configuration, click the Cancel button, not the browser's back button. See also: Full Help System 84

91 Component Configuration Text Conferencing Text Conferencing Configuration The Text Conferencing (TC) component allows Jabber users to chat in online conference rooms. Besides chatting, users can accomplish a number of different tasks including finding and joining existing rooms, creating new rooms, managing members and options of the rooms they create, entering and exiting rooms, and inviting others to rooms. In this section, you configure the TC component's connection to the router, host filters, logging, and various other settings. You also configure a number of "gears," which control the behavior of advanced text conferencing features. If you do not change the settings, default values are used. Additional Configuration Instructions The Text Conferencing component must have an agent configured for it so that the clients can display the Text Conferencing interface. Agents are configured in the JSM Configuration screen. If you enable the mod_disco module in the JSM configuration, JSM will discover the Text Conferencing component and configure an agent for it automatically. However, if you choose to enable mod_agents instead, you must add the Text Conferencing agent in the Agents section of the JSM configuration. (You should configure agents only for older components that are not compliant with the disco protocol.) The TC component must be enabled and configured both on the Jabber server and on the Jabber clients, WebClient and Jabber Messenger. For information on configuring the clients, refer to the respective client administration guides. Text Conferencing ID Description 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 TC components. The default description of this component is "Text conferencing." It displays in the Components area on the Controller main window when you add a Text Conferencing 85

92 XCP Controller Help Runlevel Timeout for shutdown component. You can change the description if desired. The description should help you distinguish between TC components if you have more than one installed. The order in which this component shuts down. The default runlevel is 70. The runlevel must be an integer value greater than or equal to 0. (Component shutdown is executed in reverse order of the specified runlevel; components with the highest level (typically 70) shut down first.) Caution: Do not change the runlevel unless you know exactly what you are doing and understand the effects that changing it will have. The default runlevel is provided to help the system shut down as smoothly as possible, and is based on this component's dependencies upon other components. The number of seconds that the server waits to receive acknowledgement from the component that the shutdown process has completed. The default is 120 seconds. Router Connection Information Connection Type Component IP Port With an accept connection type (the default setting), the router opens a specific port and listens on that port for a connection from the component. By default, the router uses the accept method to listen for connections from all components. With a connect connection type, the router connects to the component. If you selected an accept connection type, enter the IP address or FQDN on which the router listens for the component. (By default, this field contains the IP address of the system on which the router is installed.) If you selected a connect connection type, enter the IP address or hostname of the system on which the component is installed. If you selected an accept connection type, enter the port on which the router listens for the components connection. The router allows only a single connection over this port at a time; therefore, multiple versions of the component cannot connect over the same port. (The port is set to 7350 by default.) If you selected a connect connection type, enter the 86

93 Component Configuration Password Buffer size in bytes for outgoing data Buffer size in bytes for incoming data Number of packets buffered when component is down Keep-alive interval in seconds Log delivery of packets to this component Bounce error packets to stderr Maximum interval in seconds to wait before restarting component port that the component uses for communications. Enter the password that the router uses to authenticate the component. A default is provided if the command configuration is used. You can change this value as needed. Enter the number of bytes the router should buffer when it sends information to the component. You may want to modify this element when working on performance enhancements. The default is set to bytes. Enter the number of bytes the router should buffer when it receives information from the component. You may want to modify this element when working on performance enhancements. The default is set to bytes. Enter the number of incoming packets the router should buffer when the component is down. The default is set to 512 packets. Enter the number of seconds after which the router sends a keep-alive to the component. The keep-alive helps prevent firewalls from dropping an unused connection to the component. If this option is set to 0 or left empty, keep-alives are disabled. Select Yes (the default setting) if you want the data that the router delivers to the component to be logged. The information is logged to the logger(s) you set up during Jabberd Logger configuration (syslog, file, or stderr). Socket-level logging happens only at the debug level. The information is logged using the default namespace, jcs:log:default. Select Yes (the default setting) if you want the router to send warnings to stderr when the component is not available. Enter the maximum number of seconds after which the router tries to restart the component. The default is set to 300 seconds. If the component goes down, the router tries to restart it after 1 second. If the component is not running yet and the command option is being used, the router multiplies the wait time by 1.5, and retires 87

94 XCP Controller Help Maximum number of times to restart component Interval in seconds at which to reset this value to 1 second after the longer time. Once the maximum time interval that you specify in this field is reached, the router continues to retry after waiting this amount of time. Enter the total number of restarts allowed. The default setting, -1, means unlimited. Note: If you want to be able to kill the component from the command line and prevent it from starting again automatically, you must set this number to something other than -1. For example, if you set it to 1, the component will not restart once you have killed it; if you set it to 2, the component will only restart once, and so on. The number of seconds that the component has been up and running, after which to set the restart time back to 1 second. Command Select the Command option if you want the component to be started by the router. This option is enabled by default. Path to the shell that launches the component Command Hostnames The directory path to the shell that launches the component. You can change the default setting (/bin/sh) if needed. Enter the command that you want to use to start the component. Caution: Do not use the -B argument with this component. Since jabberd is already a daemon process, its children must not be daemons. Do not escape XML characters in the Controller's interface. For example, if you were writing the command configuration manually, you would need to write the string "exec 2>&1" as "exec 2>&1". However, in the Controller, you should enter the literal string and let the software perform the necessary escaping when it converts the form input into XML. Host Filters Enter the hostnames or IP addresses for which you want the TC component to handle packets. Separate each 88

95 hostname or address with a line break. Component Configuration Enter an asterisk (*) in the textbox to enable the component to handle data from any hosts that are not specified in another XDB host filter. Note: Host filters must be hostnames, or IPv4 or IPv6 addresses. If an IP address is used, the packet address must also use this IP address. TC Configuration Number of threads to dedicate to TC tasks Number of managed queues to dedicate to TC tasks Enter the number of database update threads that you want the TC component to use. The default setting is 5. Enter the number of queues that you want the TC component to use. This number reflects how many expected rooms there will be on a system divided by 20. The recommendation is one queue for every 20 rooms. The default setting is 50. SNMP Configuration Select this option if you want to configure SNMP for the TC component. SNMP Enabled SNMP Count Errors Component Logging (Jlog) SNMP is enabled by default. Select Yes only if you want to enable SNMP error counting. This option takes a great deal of server resource; use it with caution. It is set to No by default. Select the Component Logging (Jlog) option to configure filtered level loggers that log messages to syslog and to a stream (stderr or stdout). You can enable either or both the syslog and stream loggers. Caution! When a component is daemonized, logging to stderr or stdout does not work; for example, if you start a component from the command line using the -B flag, it is daemonized. These loggers log messages that are at or above the selected severity level, and drop messages that are below the 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. Filtered Syslog Logger 89

96 XCP Controller Help Select the Filtered Syslog Logger option if you want to log information to syslog. The syslog logger logs messages that meet the Level Filter criteria. Level Pipe file Facility Identity Formatter Select a severity level from the pull-down list. ("INFO" is the default setting.) The levels are listed from least severe to most. The less severe the level, the more verbose the log. DEBUG - Information from all other log levels in addition to debug data. VERBOSE - Every packet that is processed by the server and JSM plus all Error, Warn, and Info data. INFO - Data about socket connections and all JSM logs (packet, session, and message) plus all Error Warn, and Stats log level data. This is the level at which the server logs by default. WARNING - Non-fatal errors such as bounced packets, nonexistent user logging in, invalid recipient for a message, etc., plus all Error log level data. ERROR - System-generated errors such as the inability to create listen ports, server configuration errors, failure to create the log files, etc. Enter the full path to a pipe file for this component; we suggest naming the file /var/tmp/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. Select the facility that you want to use from the drop-down list. The default facility is "LOG_DAEMON." Note: Facilities are defined on the syslog(3) manpage. Enter a term that identifies where the log information is coming from. The identity is displayed in syslog next to the associated data. The default identity is "XCP." You can change this value as needed. Enter the formatters for the information that you want to log. A default format of %d [%l] %s: %m is provided. Filtered Stream Logger 90

97 Component Configuration Select the Filtered Stream Logger option if you want to log information to stderr or to stdout. The stream logger logs messages that meet the Level Filter criteria to the specified output stream. Level Pipe file Stream Formatter Select a severity level from the pull-down list. The levels are listed from least severe to most. The less severe the level, the more verbose the log. DEBUG - Information from all other log levels in addition to debug data. VERBOSE - Every packet that is processed by the server and JSM plus all Error, Warn, and Info data. INFO - Data about socket connections and all JSM logs (packet, session, and message) plus all Error Warn, and Stats log level data. This is the level at which the server logs by default. WARNING - Non-fatal errors such as bounced packets, nonexistent user logging in, invalid recipient for a message, etc., plus all Error log level data. ERROR - System-generated errors such as the inability to create listen ports, server configuration errors, failure to create the log files, etc. Enter the full path to a pipe file for this component; we suggest naming the file /var/tmp/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. Select stderr or stdout from the drop-down list. Stderr is the default setting. Enter the formatters for the information that you want to log. A default format of %d [%l] %s: %m is provided. Add a new Custom Logger Click the Go button to access the Custom Logger Configuration screen, in which you can specify the library and library entry point function for a custom logger. Advanced TC Features 91

98 XCP Controller Help This section describes the TC "gears," which control the default settings and behavior of the text conferencing features on your system. Persistent Gear Note: If you want to use persistent conference rooms, you must have Oracle or PostgreSQL installed. Select the Persistent Gear option if you want to configure persistent conference rooms for your TC system. Persistent rooms remain in existence on your system even after all users have left the room. Library load Datasource Name Database User Name Database User's Password Database Type Number of connections to the database Time in seconds between database connection heartbeats Select PostgresGear or OracleGear, depending on which database you are using. Important! If you select PostgresGear, you must add the line, "MaxVarcharSize=4000" to the datasource definition used by Text Conferencing in the.odbc.ini file. Note: See the Jabber IM/XCP Installation Guide for information on setting up Oracle and PostgreSQL. The library entry point function. For the PostgreSQL database, this is the name of the TC datasource as specified in the.odbc.ini file. For Oracle, the datasource is specified in the ORACLE_SID environment variable. Enter the username used to connect to the database. Enter the password used to connect to the database. Select the type of database you are using from the pull-down list. The choices are postrgresqlodbc and oracle-oci. Enter the number of connections that you want the TC component to use for processing requests. The default setting is 5 connections. Enter the number of seconds after which the database connection should refresh. If there is no firewall between the TC component and the database, set this interval to '0' to disable periodic refresh attempts. The default setting is 60 seconds. 92

99 Component Configuration Heartbeat SQL Is database debug logging enabled Archive all room joins and exits? Restrict persistent room creation to tcadmins only? What is the maximum number of persistent rooms allowed? How many messages display in the room by default? Can room owners change this setting when configuring a room? Each database connection is monitored for the last time it was used. If an interval larger than "Time in seconds between database connection heartbeats" has passed, the "Heartbeat SQL" command is sent to the database to make sure the database connection is still functioning. If the connection has failed for any reason (firewalls, timeouts, network failures, etc.), the connection is reestablished. "Heartbeat SQL" is set to "default," which is 60 seconds. When set to "default," the database connection selects a database system-specific SQL command to test the validity of the connection. Caution: Do not change this value without first consulting Jabber, Inc. support. Select Yes to log database debug information. No is the default setting. Database logging uses jabberd's logging facility. The jabberd logging must be set to DEBUG for database logging to occur. Select Yes if you want to archive all instances of users joining and exiting rooms in the database. No is the default setting. Select Yes (the default setting) if you want only TC administrators to be able to create persistent rooms. If you select No, all users can create persistent rooms. Enter the maximum number of persistent conference rooms that can exist on your TC system. The default setting is 200 rooms. Enter the default number of previous messages that should display in a room. Select Yes if you want to enable room owners to change the number of messages displayed in the rooms they create. The default setting is No. Room Gear 93

100 XCP Controller Help The Room Gear controls the total number of conference rooms (including both ad hoc and persistent) that can exist on your TC system. Custom library load How many rooms can exist on your system? Member Gear Leave this field blank unless you want to use a custom Room gear. The library entry point function. Enter the maximum number of conference rooms that can exist on your TC system. Select the Member Gear option if you want to configure rules for membership in text conference rooms. The Member Gear controls aspects of TC room membership such as whether members of members-only rooms can invite others to the room, and whether membership in a room is restricted or open. Custom library load Are rooms for members only by default? Can room owners change this setting when configuring a room? Can anyone other than room moderators invite others to a members-only room? Can room owners change this setting when configuring a room? Can users add themselves to rooms as members? Can room owners change this setting when configuring a room? Leave this field blank unless you want to use a custom Member gear. The library entry point function. Select Yes only if you want all rooms that are created to be for members only by default. The default setting is No. Select Yes (the default setting) if you want to let room owners choose whether the rooms they create are for members only. Select Yes (the default setting) if you want moderators to be the only ones who can invite others to members-only rooms. If you select No, any user can do this. Select Yes if you want to let room owners choose who can invite others to a room. The default setting is No. Select Yes (the default setting) if you want to let users add themselves to conference rooms as members. Select Yes (the default setting) if you want to let room owners decide if users can add themselves to the rooms they (the owners) create. 94

101 Component Configuration Presence Gear The Presence Gear controls how room users' presence is handled in TC rooms. For example, it controls whether rooms can contain anonymous users (users whose presence is indicated only by nicknames). It also controls whether unavailable users display in a room, and whether users of older Jabber software versions (1.0 protocol) can participate in TC rooms. Custom library load Should members and administrators who are not in a room still be visible in the room? Can room owners change this setting when configuring a room? Should rooms be backwards-compatible with older clients? Can room owners change this setting when configuring a room? Should rooms be anonymous by default? Can room owners change this setting when configuring a room? Occupancy Gear Leave this field blank unless you want to use a custom Presence gear. The library entry point function. Select Yes (the default setting) if you want conference room members and administrators who are currently not in a room to be visible, displaying a presence indicator of unavailable. Select Yes (the default setting) if you want to let room owners enable or disable "unavailable" presence indicators for the rooms they create. Select Yes (the default setting) if you want to allow users of older clients (group chat 1.0 protocol) to participate in TC rooms. Select Yes (the default setting) if you want to let room owners enable or disable backward compatibility for the rooms they create. Select Yes (the default setting) if you want to make all TC rooms anonymous by default. Anonymous rooms allow users to participate using nicknames; other users in the room cannot see anonymous users' Jabber IDs. Select Yes (the default setting) if you want to let room owners enable or disable anonymity for the rooms they create. Select the Occupancy Gear option if you want to configure room occupancy limits. The Occupancy Gear lets you restrict the number of users who can be in any given TC room at one time. You can also use this gear to allow room owners to configure the maximum number of users who may be in the rooms they create. 95

102 XCP Controller Help Custom library load How many users can be in a room at one time? How many hidden users can be in a room? What is the default maximum occupancy for a room? Can room owners change this setting when configuring a room? Leave this field blank unless you want to use a custom Occupancy gear. The library entry point function. Enter the maximum number of users who can be in any given conference room on your TC system at one time. The default setting is 50 people. Enter the maximum number of hidden occupants who can be in any given conference room on your system. The default setting is 25. Hidden occupants are those who are filtering on a room but are not in the room. The number of hidden occupants in a room is included in the total number of room occupants. Enter the default maximum number of users who can be in a conference room. This number is displayed as the default in the Room Options window in the clients' TC interface. The default setting is 50. Select Yes if you want to let room owners specify the maximum number of users who can be in a room at one time. The default setting is No. Invite Gear The Invite Gear controls who can invite other users to a conference room. Custom library load What is the lowest participation level a user can have to invite others to the room? Leave this field blank unless you want to use a custom Invite gear. The library entry point function. Select the default privilege level that users must have to invite others to a room. The choices are: Visitor - a room user who has no voice in the room (cannot chat in the room). Participant - a room user who has voice (can chat in the room). (This option is selected by default.) Moderator - a room user who has voice, can kick other users, and can grant and revoke voice from other users. 96

103 Component Configuration Can room owners change this setting when configuring a room? Select Yes (the default setting) if you want to allow room owners to choose the privilege level that users must have to invite others to a room. Password Gear Select the Password Gear option if you want to enable room owners to password-protect the rooms they create. (This option is enabled by default.) Custom library load Message Gear Leave this field blank unless you want to use a custom Password gear. The library entry point function. The Message Gear controls who can change the subject in a TC room and who can send private messages in the room. Custom library load What is the lowest participation level a user can have to change a room's subject? Can room owners change this setting when configuring a room? What is the lowest participation level a user can have to send a private message from within the room? Leave this field blank unless you want to use a custom Message gear. The library entry point function. Select the default privilege level that users must have to change the subject in a room. The choices are: Visitor - a room user who has no voice in the room (cannot chat in the room). Participant - a room user who has voice (can chat in the room). Moderator - a room user who has voice, can kick other users, and can grant and revoke voice from other users. (This option is selected by default.) Select Yes (the default setting) if you want to allow room owners to choose the privilege level that users must have to change the subject in a room. Select the default privilege level that users must have to send private messages to others in a room. The choices are: Visitor - a room user who has no voice in the room (cannot chat in the room). (This option is 97

104 XCP Controller Help Can room owners change this setting when configuring a room? selected by default.) Participant - a room user who has voice (can chat in the room). Moderator - a room user who has voice, can kick other users, and can grant and revoke voice from other users. Select Yes if you want to allow room owners to choose the privilege level that users must have to send private messages to others in a room. The default setting is No. Moderation Gear Select the Moderation Gear option if you want to allow conference rooms to have moderators. This option is enabled by default. Custom library load Are rooms moderated by default? Can room owners change this setting when configuring a room? History Gear Leave this field blank unless you want to use a custom Moderation gear. The library entry point function. Select Yes if you want to allow rooms to have moderators by default. The default setting is No. Select Yes (the default setting) if you want to let room owners enable or disable moderation for the rooms they create. Select the History Gear option if you want to configure message history rules. The History Gear lets you set the maximum number of previous messages that are displayed in a TC room. This option is enabled by default. Custom library load What is the maximum number of previous messages that can display in a room? How many previous messages display in a room by default? Leave this field blank unless you want to use a custom History gear. The library entry point function. Enter the maximum number of messages that can display in the message history for any room on your system. The default setting is 100 messages. Enter the number of messages that appear in the message history of a room by default. The default setting is 15 messages. 98

105 Component Configuration Can room owners change this setting when configuring a room? Select Yes if you want to let room owners set the number of messages that appear in the message history for the rooms they create. Room owners cannot set a number larger than the one you configured above. The default setting is No. Log Gear Select the Log Gear option if you want to enable logging in HTML format for conference room transcripts. Note: The log gear is typically not used for enterprise-grade archiving; see Message Archiver Configuration. Library load File location where room messages are logged Base URL where users can view room logs Buffer size to use when writing to the logs Sysadmin Gear This is a read-only field containing "LogGear." The library entry point function. Enter the directory path of the file where messages are logged. Caution: Do not include the log filename in the directory path. Enter the URL at which users can view the room logs. Enter the size in megabytes of the buffer you want to use for writing logs. Select the Sysadmin Gear option if you want to use TC administrators in your TC system. TC administrators have the same privileges as room owners for all rooms on the system. This option is enabled by default. Custom library load Administrators Submit Your Configuration Leave this field blank unless you want to use a custom Sysadmin gear. The library entry point function. Click the Go button to access the Add an Admin Configuration screen where you can add a TC administrator. 99

106 XCP Controller Help Click the Submit button when you have finished configuring this component. If you want to cancel the configuration, click the Cancel button, not the browser's back button. See also: Full Help System Conference Room User Roles 100

107 Component Configuration Conference Room User Roles The privileges that users have when participating in conference rooms depend on their roles in the room. These roles are listed below, and the privileges associated with them are provided in the table. Visitor a room user who has no voice in the room (cannot chat or send private messages). Participant a room user who has voice (can chat and send private messages). Moderator a room user who has voice, can kick other users, and can grant and revoke voice from other users. The following table describes the privileges associated with the room user roles: Privilege Visitor Participant Moderator Enter the room Yes Yes Yes Receive messages from others in the room Change availability status in the room Yes Yes Yes Yes Yes Yes Change nickname in the room Yes Yes Yes Send private messages to others in the room Yes* Yes Yes Invite other users to the room Yes* Yes* Yes Send messages to everyone in the room No Yes Yes Change the room's subject No Yes* Yes Kick participants and visitors from the room No No Yes Grant voice No No Yes Revoke voice form room participants No No Yes * This is the default setting, but configuration settings may further restrict this privilege. See also: 101

108 XCP Controller Help Full Help System 102

109 Component Configuration Message Archiver Message Archiver Configuration The Message Archiver stores all inbound and outbound messages to a PostgreSQL or an Oracle database where they can be indexed and searched. It also logs file transfer requests, although it does not log the actual transferred files. Shutting down the Message Archiver may require several minutes. This is especially true if there is a queue of messages waiting to be stored in the database. The Message Archiver attempts to ensure that all messages are written before the system shuts down. To check whether it is still storing pending messages after you have shut it down, look to see if the archiver threads are still busy. If the threads are running, the Message Archiver is still working. Additional Configuration Instructions In addition to providing the information in the Message Archiver Configuration screen, you must do the following in the Jabber Session Manager Configuration screen: Enable JSM Logging and select Yes for both Incoming and Outgoing message packets. Message Archiver ID Description Runlevel 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 Message Archiver. The default description of this component is "Oracle Message Archiver." It displays in the Components area on the XCP Controller main window when you add a Message Archiver. You can change the description if desired. The description should help you distinguish between Message Archiver components if you have more than one installed. The order in which this component shuts down. The default runlevel is 30. The runlevel must be an integer value greater than or equal to 0. (Component shutdown is executed in 103

110 XCP Controller Help Timeout for shutdown reverse order of the specified runlevel; components with the highest level (typically 70) shut down first.) Caution: Do not change the runlevel unless you know exactly what you are doing and understand the effects that changing it will have. The default runlevel is provided to help the system shut down as smoothly as possible, and is based on this component's dependencies upon other components. The number of seconds that the server waits to receive acknowledgement from the component that the shutdown process has completed. Router Connection Information Connection Type Component IP Port Password Buffer size in bytes With an accept connection type (the default setting), the router opens a specific port and listens on that port for a connection from the component. By default, the router uses the accept method to listen for connections from all components. With a connect connection type, the router connects to the component. If you selected an accept connection type, enter the IP address or FQDN on which the router listens for the component. (By default, this field contains the IP address of the system on which the router is installed.) If you selected a connect connection type, enter the IP address or hostname of the system on which the component is installed. If you selected an accept connection type, enter the port on which the router listens for the component s connection. The router allows only a single connection over this port at a time; therefore, multiple versions of the component cannot connect over the same port. (The port is set to 7371 by default.) If you selected a connect connection type, enter the port that the component uses for communications. Enter the password that the router uses to authenticate the component. A default is provided if the command configuration is used. You can change this value as needed. Enter the number of bytes the router should buffer 104

111 Component Configuration for outgoing data Buffer size in bytes for incoming data Number of packets buffered when component is down Keep-alive interval in seconds Log delivery of packets to this component Bounce error packets to stderr Maximum interval in seconds to wait before restarting component Maximum number of times to restart component when it sends information to the component. You may want to modify this element when working on performance enhancements. The default is set to bytes. Enter the number of bytes the router should buffer when it receives information from the component. You may want to modify this element when working on performance enhancements. The default is set to bytes. Enter the number of incoming packets the router should buffer when the component is down. The default is set to 512 packets. Enter the number of seconds after which the router sends a keep-alive to the component. The keep-alive helps prevent firewalls from dropping an unused connection to the component. If this option is set to 0 or left empty, keep-alives are disabled. Select Yes (the default setting) if you want the data that the router delivers to the component to be logged. The information is logged to the logger(s) you set up during Jabberd Logger configuration (syslog, file, or stderr). Socket-level logging happens only at the debug level. The information is logged using the default namespace, jcs:log:default. Select Yes (the default setting) if you want the router to send warnings to stderr when the component is not available. Enter the maximum number of seconds after which the router tries to restart the component. The default is set to 300 seconds. If the component goes down, the router tries to restart it after 1 second. If the component is not running yet and the command option is being used, the router multiplies the wait time by 1.5, and retires after the longer time. Once the maximum time interval that you specify in this field is reached, the router continues to retry after waiting this amount of time. Enter the total number of restarts allowed. The default setting, -1, means unlimited. 105

112 XCP Controller Help Interval in seconds at which to reset this value to 1 second Note: If you want to be able to kill the component from the command line and prevent it from starting again automatically, you must set this number to something other than -1. For example, if you set it to 1, the component will not restart once you have killed it; if you set it to 2, the component will only restart once, and so on. The number of seconds that the component has been up and running, after which to set the restart time back to 1 second. Command Select the Command option if you want the component to be started by the router. This option is enabled by default. Path to Binary Command Log The directory path to the shell that launches the component. You can change the default setting (/bin/sh) if needed. Enter the command that you want to use to start the component. Caution: Do not use the -B argument with this component. Since jabberd is already a daemon process, its children must not be daemons. Do not escape XML characters in the Controller's interface. For example, if you were writing the command configuration manually, you would need to write the string "exec 2>&1" as "exec 2>&1". However, in the Controller, you should enter the literal string and let the software perform the necessary escaping when it converts the form input into XML. nss Host Filters Select the namespaces for which you want data to be logged by this Message Archiver. All namespaces not selected here are ignored by the Message Archiver. Enter the hostnames or IP addresses for which you want this Message Archiver to handle packets. Separate each hostname or address with a line break. Enter an asterisk (*) in the textbox to enable the component to handle data from any hosts that are not specified in 106

113 another XDB host filter. Component Configuration Note: Host filters must be hostnames, or IPv4 or IPv6 addresses. If an IP address is used, the packet address must also use this IP address. Message Archiver Configuration In this section, you configure database settings, SNMP, and filtered logging for the component. Database Setup Datasource Name Database User Name Database User's Password Database Type Number of connections to the database Time in seconds between database connection heartbeats Heartbeat SQL For the PostgreSQL database, this is the name of the component's datasource as specified in the.odbc.ini file. For Oracle, the datasource is specified in the ORACLE_SID environment variable. Enter the username used to connect to the database. Enter the password used to connect to the database. Select the type of database you are using from the pull-down list. The choices are postgresql-odbc and oracle-oci. Important! If you select postgresql-odbc, you must add the line, "MaxVarcharSize=4000" to the datasource definition used by the Message Archiver in the.odbc.ini file. Enter the number of connections that you want the component to use for processing requests. The default setting is 5 connections. Enter the number of seconds after which the database connection should refresh. If there is no firewall between the component and the database, set this interval to '0' to disable periodic refresh attempts. The default setting is 60 seconds. Each database connection is monitored for the last time it was used. If an interval larger than "Time in seconds between database connection heartbeats" has passed, the "Heartbeat SQL" command is sent to the database to make sure the database connection is still functioning. If the connection has failed for any reason (firewalls, timeouts, network 107

114 XCP Controller Help Is database debug logging enabled failures, etc.), the connection is reestablished. "Heartbeat SQL" is set to "default," which is 60 seconds. When set to "default," the database connection selects a database system-specific SQL command to test the validity of the connection. Caution: Do not change this value without first consulting Jabber, Inc. support. Select Yes to log database debug information. No is the default setting. Database logging uses jabberd's logging facility. The jabberd logging must be set to DEBUG for database logging to occur. SNMP Configuration Select this option if you want to configure SNMP for the Message Archiver. SNMP Enabled This option is set to Yes by default. SNMP Count Errors Select Yes only if you want to enable SNMP error counting. This option takes a great deal of server resource; use it with caution. It is set to No by default. Component Logging (Jlog) Select the Component Logging (Jlog) option to configure filtered level loggers that log messages to syslog and to a stream (stderr or stdout). You can enable either or both the syslog and stream loggers. Caution! When a component is daemonized, logging to stderr or stdout does not work; for example, if you start a component from the command line using the -B flag, it is daemonized. These loggers log messages that are at or above the selected severity level, and drop messages that are below the 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. Filtered Syslog Logger Select the Filtered Syslog Logger option if you want to log information to syslog. The syslog logger logs messages that meet the Level Filter criteria. Level Select a severity level from the pull-down list. ("INFO" is the default setting.) The levels are listed from least severe to most. The less severe the level, the more verbose the log. DEBUG - Information from all other log levels in addition to 108

115 Component Configuration Pipe file Facility Identity Formatter debug data. VERBOSE - Every packet that is processed by the server and JSM plus all Error, Warn, and Info data. INFO - Data about socket connections and all JSM logs (packet, session, and message) plus all Error Warn, and Stats log level data. This is the level at which the server logs by default. WARNING - Non-fatal errors such as bounced packets, nonexistent user logging in, invalid recipient for a message, etc., plus all Error log level data. ERROR - System-generated errors such as the inability to create listen ports, server configuration errors, failure to create the log files, etc. Enter the full path to a pipe file for this component; we suggest naming the file /var/tmp/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. Select the facility that you want to use from the drop-down list. The default facility is "LOG_DAEMON." Note: Facilities are defined on the syslog(3) manpage. Enter a term that identifies where the log information is coming from. The identity is displayed in syslog next to the associated data. The default identity is "XCP." You can change this value as needed. Enter the formatters for the information that you want to log. A default format of %d [%l] %s: %m is provided. Filtered Stream Logger Select the Filtered Stream Logger option if you want to log information to stderr or to stdout. The stream logger logs messages that meet the Level Filter criteria to the specified output stream. Level Select a severity level from the pull-down list. The levels are listed from least severe to most. The less severe the level, the more verbose the log. DEBUG - Information from all other log levels in addition to 109

116 XCP Controller Help Pipe file Stream Formatter debug data. VERBOSE - Every packet that is processed by the server and JSM plus all Error, Warn, and Info data. INFO - Data about socket connections and all JSM logs (packet, session, and message) plus all Error Warn, and Stats log level data. This is the level at which the server logs by default. WARNING - Non-fatal errors such as bounced packets, nonexistent user logging in, invalid recipient for a message, etc., plus all Error log level data. ERROR - System-generated errors such as the inability to create listen ports, server configuration errors, failure to create the log files, etc. Enter the full path to a pipe file for this component; we suggest naming the file /var/tmp/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. Select stderr or stdout from the drop-down list. Stderr is the default setting. Enter the formatters for the information that you want to log. A default format of %d [%l] %s: %m is provided. Add a new Custom Logger Click the Go button to access the Custom Logger Configuration screen, in which you can specify the library and library entry point function for a custom logger. Submit Your Configuration When you have finished configuring this component, click the Submit button. If you want to cancel the configuration, click the Cancel button, not the browser's back button. See also: Full Help System Retrieving Message Archiver Data 110

117 Component Configuration 111

118 XCP Controller Help Retrieving Message Archiver Data This information is provided to help you retrieve data stored by the Message Archiver. You can use database views to access information that has been stored in the Message Archiver. You can access the message archive either directly through the "jm" table, or through the "message_threads" and "conversations" views. The descriptions of the table and view are provided below. Incoming and Outgoing Messages The following information pertaining to incoming and outgoing messages is stored in the jm table: to_jid from_jid subject thread_id sent_date msg_type direction body_len Stores the Jabber ID of the person who is receiving the message. This field cannot be left blank. Stores the Jabber ID of the person from whom the message was sent. This field cannot be left blank. Stores the subject line of the message, if available. Stores the thread ID of the message, if available. Stores the date on which the Jabber server received the message. This field cannot be left blank. Stores the type of the message. C indicates that the message is a Chat, while G indicates that it is a Group message. Jabber protocol supports additional message types. These types are indicated with an N for normal. Stores an indicator that tells where the message was generated. I indicates inbound messages, while O indicates outbound messages. Stores the number of characters in the message s body. The system uses this field to determine whether to store the text of the message in body_text or body_string. body_text If the length (body_len) is greater than 4000 characters, the text of the message body is stored in body_text. body_string If the length (body_len) is less than or equal to 4000, the text of the message body is stored in body_string. 112

119 message_len Component Configuration The message fields store the entire XML packet of the message. Custom clients may include things that are not in the body s text. This captures everything, even if it cannot be indexed. It stores the number of characters in the message. The system uses this field to determine whether to store the text of the message in message_text or message_string. message_text If the length (message_len) is greater than 4000 characters, the text of the entire message is stored in message_text. message_string File Transfer Requests If the length (message_len) is less than or equal to 4000, the text of the entire message is stored in message_string. File transfer requests are also stored in the jm table with the following differences: subject thread_jid sent_date body_len body_text body_string message_len Stores the URL of the message, if available. Stores the thread ID of the message, if available. Stores the date on which the Jabber server received the message. This field cannot be left blank. Stores the number of characters in the message body. The system uses this field to determine whether to store the text of the message in body_text or body_string. If the length (body_len) is greater than 4000 characters, the text of the message is stored in body_text. If the length (body_len) is less than or equal to 4000, the text of the message is stored in body_string. The message fields store the entire XML packet of the message. Custom clients may include things that are not in the body s text. This captures everything, even if it cannot be indexed. It stores the number of characters in the message. The system uses this field to determine whether to store the text of the message in message_text or message_string. message_text If the length (message_len) is greater than 4000 characters, the text of the message is stored in message_text. 113

120 XCP Controller Help message_string If the length (message_len) is less than or equal to 4000, the text of the message is stored in message_string. message_threads View thread_id to_jid from_jid sent_date Stores the thread ID of the message, if available. Stores the Jabber ID of the person who is receiving the message. This field cannot be left blank. Stores the Jabber ID of the person from whom the message was sent. This field cannot be left blank. Stores the date on which the Jabber server received the message. This field cannot be left blank. conversations View thread_id from_jid to_jid sent_date msg_type subject body_len body_text body_string Stores the thread ID of the message, if available. Stores the Jabber ID of the person from whom the message was sent. This field cannot be left blank. Stores the Jabber ID of the person who is receiving the message. This field cannot be left blank. Stores the date on which the Jabber server received the message. This field cannot be left blank. Stores the type of the message. C indicates that the message is a Chat, while G indicates that it is a Group message. Jabber protocol supports additional message types. These types are indicated with an N for normal. Stores the URL of the message, if available. Stores the number of characters in the message. The system uses this field to determine whether to store the text of the message in body_text or body_string. If the length (body_len) is greater than 4000 characters, the text of the message is stored in body_text. If the length (body_len) is less than or equal to 4000, the text of the message is stored in body_string. Retrieving Specific Conversations 114

121 Component Configuration You can retrieve specific conversations from the message archive through the provided views. For example, you can retrieve conversations involving a particular user within a specific date range using the following SQL statements: SELECT thread_id, sent_date FROM message_threads WHERE to_jid LIKE 'userjid%' OR from_jid LIKE 'userjid%' AND sent_date >= TO_DATE('start_date') AND sent_date <= TO_DATE('end_date') ORDER BY sent_date; SELECT sent_date, from_jid, to_jid, msg_type, subject, body_text, body_string FROM conversations WHERE thread_id=[*thread_id from previous*] ORDER BY sent_date; Either body_text or body_string contains the message bodies, depending on the length of the messages. If the message body was greater than 4000 characters in length, it is stored in body_text; otherwise it is in body_string. Whichever of these two fields is not used is set to null. The entire message packet in raw form is stored in message_string or message_text field of the jm table. See also: Full Help System 115

122 XCP Controller Help Presence Mirror Presence Mirror Configuration The Presence Mirror enables you to store the current presence of all users on the system in a PostgreSQL or an Oracle database. The Jabber XCP Server sends presence updates to Jabber IM users on a regular basis. For example, when a user updates her presence to away -- at lunch, all contacts in that user s roster receive a presence packet updating their rosters to show her as away -- at lunch. The Presence Mirror stores a copy of all the presence packets in your database. Presence packets are sent to the database using the Blind Carbon Copy feature. Presence information is passed blindly without notifying the user. Each presence packet includes: Jabber ID, a presence, e.g. Away, and a status message, e.g., Eating lunch. To retrieve a user s presence from the database, you must access the user s data using your standard database tools. Additional Configuration Instructions In addition to providing the information in the Presence Mirror Configuration screen, you must do the following in the Jabber Session Manager Configuration screen: Enable the mod_presence_bcc module. Enable Mirroring Presence and enter the name of the component(s) that you want to handle blind carbon copy (BCC). Presence Mirror ID Description 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 Presence Mirrors. The default description of this component is "Oracle Presence Mirror." It displays in the Components area on the Controller main window when you add a Presence Mirror. You can change the description if desired. The description should help you distinguish between Presence Mirror 116

123 Component Configuration Runlevel Timeout for shutdown components if you have more than one installed. The order in which this component shuts down. The default runlevel is 30. The runlevel must be an integer value greater than or equal to 0. (Component shutdown is executed in reverse order of the specified runlevel; components with the highest level (typically 70) shut down first.) Caution: Do not change the runlevel unless you know exactly what you are doing and understand the effects that changing it will have. The default runlevel is provided to help the system shut down as smoothly as possible, and is based on this component's dependencies upon other components. The number of seconds that the server waits to receive acknowledgement from the component that the shutdown process has completed. Router Connection Information Connection Type Component IP Port Password With an accept connection type (the default setting), the router opens a specific port and listens on that port for a connection from the component. By default, the router uses the accept method to listen for connections from all components. With a connect connection type, the router connects to the component. If you selected an accept connection type, enter the IP address or FQDN on which the router listens for the component. (By default, this field contains the IP address of the system on which the router is installed.) If you selected a connect connection type, enter the IP address or hostname of the system on which the component is installed. If you selected an accept connection type, enter the port on which the router listens for the component s connection. The router allows only a single connection over this port at a time; therefore, multiple versions of the component cannot connect over the same port. (The port is set to 7372 by default.) If you selected a connect connection type, enter the port that the component uses for communications. Enter the password that the router uses to 117

124 XCP Controller Help Buffer size in bytes for outgoing data Buffer size in bytes for incoming data Number of packets buffered when component is down Keep-alive interval in seconds Log delivery of packets to this component Bounce error packets to stderr Maximum interval in seconds to wait before restarting component authenticate the component. A default is provided if the command configuration is used. You can change this value as needed. Enter the number of bytes the router should buffer when it sends information to the component. You may want to modify this element when working on performance enhancements. The default is set to bytes. Enter the number of bytes the router should buffer when it receives information from the component. You may want to modify this element when working on performance enhancements. The default is set to bytes. Enter the number of incoming packets the router should buffer when the component is down. The default is set to 512 packets. Enter the number of seconds after which the router sends a keep-alive to the component. The keep-alive helps prevent firewalls from dropping an unused connection to the component. If this option is set to 0 or left empty, keep-alives are disabled. Select Yes (the default setting) if you want the data that the router delivers to the component to be logged. The information is logged to the logger(s) you set up during Jabberd Logger configuration (syslog, file, or stderr). Socket-level logging happens only at the debug level. The information is logged using the default namespace, jcs:log:default. Select Yes (the default setting) if you want the router to send warnings to stderr when the component is not available. Enter the maximum number of seconds after which the router tries to restart the component. The default is set to 300 seconds. If the component goes down, the router tries to restart it after 1 second. If the component is not running yet and the command option is being used, the router multiplies the wait time by 1.5, and retires after the longer time. Once the maximum time interval that you specify in this field is reached, the router continues to retry after waiting this amount of 118

125 Component Configuration Maximum number of times to restart component Interval in seconds at which to reset this value to 1 second time. Enter the total number of restarts allowed. The default setting, -1, means unlimited. Note: If you want to be able to kill the component from the command line and prevent it from starting again automatically, you must set this number to something other than -1. For example, if you set it to 1, the component will not restart once you have killed it; if you set it to 2, the component will only restart once, and so on. The number of seconds that the component has been up and running, after which to set the restart time back to 1 second. Command Select the Command option if you want the component to be started by the router. This option is enabled by default. Path to Binary Command Hostnames The directory path to the shell that launches the component. You can change the default setting (/bin/sh) if needed. Enter the command that you want to use to start the component. Caution: Do not use the -B argument with this component. Since jabberd is already a daemon process, its children must not be daemons. Do not escape XML characters in the Controller's interface. For example, if you were writing the command configuration manually, you would need to write the string "exec 2>&1" as "exec 2>&1". However, in the Controller, you should enter the literal string and let the software perform the necessary escaping when it converts the form input into XML. Host Filters Enter the hostnames or IP addresses for which you want this Presence Mirror to handle packets. Separate each hostname or address with a line break. Enter an asterisk (*) in the textbox to enable the component to handle data from any hosts that are not specified in 119

126 XCP Controller Help another XDB host filter. Note: Host filters must be hostnames, or IPv4 or IPv6 addresses. If an IP address is used, the packet address must also use this IP address. Presence Mirror Configuration In this section, you configure database settings, SNMP, and filtered logging for the component. Database Setup Datasource Name Database User Name Database User's Password Database Type Number of connections to the database Time in seconds between database connection heartbeats Heartbeat SQL For the PostgreSQL database, this is the name of the component's datasource as specified in the.odbc.ini file. For Oracle, the datasource is specified in the ORACLE_SID environment variable. Enter the username used to connect to the database. Enter the password used to connect to the database. Select the type of database you are using from the pull-down list. The choices are postgresql-odbc and oracle-oci. Important! If you select postgresql-odbc, you must add the line, "MaxVarcharSize=4000" to the datasource definition used by the Presence Mirror in the.odbc.ini file. Enter the number of connections that you want the component to use for processing requests. The default setting is 5 connections. Enter the number of seconds after which the database connection should refresh. If there is no firewall between the component and the database, set this interval to '0' to disable periodic refresh attempts. The default setting is 60 seconds. Each database connection is monitored for the last time it was used. If an interval larger than "Time in seconds between database connection heartbeats" has passed, the "Heartbeat SQL" command is sent to the database to make sure the database connection is still functioning. If the connection has failed for any reason (firewalls, timeouts, network 120

127 Component Configuration Is database debug logging enabled failures, etc.), the connection is reestablished. "Heartbeat SQL" is set to "default," which is 60 seconds. When set to "default," the database connection selects a database system-specific SQL command to test the validity of the connection. Caution: Do not change this value without first consulting Jabber, Inc. support. Select Yes to log database debug information. No is the default setting. Database logging uses jabberd's logging facility. The jabberd logging must be set to DEBUG for database logging to occur. SNMP Configuration Select this option if you want to configure SNMP for the Presence Mirror component. SNMP Enabled SNMP Count Errors Component Logging (Jlog) This option is set to Yes by default. Select Yes only if you want to enable SNMP error counting. This option takes a great deal of server resource; use it with caution. It is set to No by default. Select the Component Logging (Jlog) option to configure filtered level loggers that log messages to syslog and to a stream (stderr or stdout). You can enable either or both the syslog and stream loggers. Caution! When a component is daemonized, logging to stderr or stdout does not work; for example, if you start a component from the command line using the -B flag, it is daemonized. These loggers log messages that are at or above the selected severity level, and drop messages that are below the 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. Filtered Syslog Logger Select the Filtered Syslog Logger option if you want to log information to syslog. The syslog logger logs messages that meet the Level Filter criteria. Level Select a severity level from the pull-down list. ("INFO" is the default setting.) The levels are listed from least severe to most. The less severe the level, the more verbose the log. 121

128 XCP Controller Help Pipe file Facility Identity Formatter DEBUG - Information from all other log levels in addition to debug data. VERBOSE - Every packet that is processed by the server and JSM plus all Error, Warn, and Info data. INFO - Data about socket connections and all JSM logs (packet, session, and message) plus all Error Warn, and Stats log level data. This is the level at which the server logs by default. WARNING - Non-fatal errors such as bounced packets, nonexistent user logging in, invalid recipient for a message, etc., plus all Error log level data. ERROR - System-generated errors such as the inability to create listen ports, server configuration errors, failure to create the log files, etc. Enter the full path to a pipe file for this component; we suggest naming the file /var/tmp/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. Select the facility that you want to use from the drop-down list. The default facility is "LOG_DAEMON." Note: Facilities are defined on the syslog(3) manpage. Enter a term that identifies where the log information is coming from. The identity is displayed in syslog next to the associated data. The default identity is "XCP." You can change this value as needed. Enter the formatters for the information that you want to log. A default format of %d [%l] %s: %m is provided. Filtered Stream Logger Select the Filtered Stream Logger option if you want to log information to stderr or to stdout. The stream logger logs messages that meet the Level Filter criteria to the specified output stream. Level Select a severity level from the pull-down list. The levels are listed from least severe to most. The less severe the level, the more verbose the log. 122

129 Component Configuration Pipe file Stream Formatter DEBUG - Information from all other log levels in addition to debug data. VERBOSE - Every packet that is processed by the server and JSM plus all Error, Warn, and Info data. INFO - Data about socket connections and all JSM logs (packet, session, and message) plus all Error Warn, and Stats log level data. This is the level at which the server logs by default. WARNING - Non-fatal errors such as bounced packets, nonexistent user logging in, invalid recipient for a message, etc., plus all Error log level data. ERROR - System-generated errors such as the inability to create listen ports, server configuration errors, failure to create the log files, etc. Enter the full path to a pipe file for this component; we suggest naming the file /var/tmp/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. Select stderr or stdout from the drop-down list. Stderr is the default setting. Enter the formatters for the information that you want to log. A default format of %d [%l] %s: %m is provided. Add a new Custom Logger Click the Go button to access the Custom Logger Configuration screen, in which you can specify the library and library entry point function for a custom logger. Submit Your Configuration When you have finished configuring this component, click the Submit button. If you want to cancel the configuration, click the Cancel button, not the browser's back button. See also: Full Help System 123

130 XCP Controller Help 124

131 Component Configuration Jabber Directory Suite Jabber Directory Suite Configuration The Jabber Directory Suite (JDS) provides integration between the XCP server and your LDAP directory service. The current JDS release supports integration with the directory services Sun ONE, IBM Directory Services, Microsoft Active Directory 2000/2003, and OpenLDAP. The LDAP service can be used to store and search user registration, authentication, and vcard information. JDS also enables you to organize users on your Jabber XCP Server into Community Groups. Community groups are collections of Jabber users created by the LDAP administrator to group like users together; for example, you can create a separate community group for each department within an organization. JDS allows you to configure your directory service to store the data from one Jabber server in one LDAP directory service, or to configure multiple LDAP services and distribute information across them. Additional Configuration Instructions In addition to providing the information in the Jabber Directory Suite Configuration screen, you must do the following in the Jabber Session Manager Configuration screen: Enable the mod_jds module and disable all of the other "mod_auth" modules (plain, digest, and db_plain). JDS requires the JDS Community Group agent and/or the LDAP Search agent, depending on how you plan to use JDS. You can enable the mod_disco module, which creates these agents for you automatically. If you choose not to enable mod_disco, you must configure the agents manually. Enable JDS Configuration and select Yes for one or both options. Jabber Directory Suite ID The Jabber ID of this component. This is a read-only value that is generated by the Controller; the value increments 125

132 XCP Controller Help Description Runlevel Timeout for shutdown automatically as you add additional JDS components. The default description of this component is "Jabber Directory Server." It displays in the Components area on the XCP Controller main window when you add a Jabber Directory Suite component. You can change the description if desired. The description should help you distinguish between JDS components if you have more than one installed. The order in which this component shuts down. The default runlevel is 20. The runlevel must be an integer value greater than or equal to 0. (Component shutdown is executed in reverse order of the specified runlevel; components with the highest level (typically 70) shut down first.) Caution: Do not change the runlevel unless you know exactly what you are doing and understand the effects that changing it will have. The default runlevel is provided to help the system shut down as smoothly as possible, and is based on this component's dependencies upon other components. The number of seconds that the server waits to receive acknowledgement from the component that the shutdown process has completed. The default is 20 seconds. Router Connection Information Connection Type Component IP Port With an accept connection type (the default setting), the router opens a specific port and listens on that port for a connection from the component. By default, the router uses the accept method to listen for connections from all components. With a connect connection type, the router connects to the component. If you selected an accept connection type, enter the IP address or FQDN on which the router listens for the component. By default, this field contains the IP address of the system on which the router is installed. If you selected a connect connection type, enter the IP address or hostname of the system on which the component is installed. If you selected an accept connection type, enter the port on which the router listens for the component s 126

133 Component Configuration Password Buffer size in bytes for outgoing data Buffer size in bytes for incoming data Number of packets buffered when component is down Keep-alive interval in seconds Log delivery of packets to this component Bounce error packets to stderr Maximum interval in seconds to wait connection. The router allows only a single connection over this port at a time; therefore, multiple versions of the component cannot connect over the same port. The port is set to 7340 by default. If you selected a connect connection type, enter the port that the component uses for communications. Enter the password that the router uses to authenticate the component. A default is provided if the command configuration is used. You can change this value as needed. Enter the number of bytes the router should buffer when it sends information to the component. You may want to modify this element when working on performance enhancements. The default is set to bytes. Enter the number of bytes the router should buffer when it receives information from the component. You may want to modify this element when working on performance enhancements. The default is set to bytes. Enter the number of incoming packets the router should buffer when the component is down. The default is set to 512 packets. Enter the number of seconds after which the router sends a keep-alive to the component. The keep-alive helps prevent firewalls from dropping an unused connection to the component. If this option is set to 0 or left empty, keep-alives are disabled. Select Yes (the default setting) if you want the data that the router delivers to the component to be logged. The information is logged to the logger(s) you set up during Jabberd Logger configuration (syslog, file, or stderr). Socket-level logging happens only at the debug level. The information is logged using the default namespace, jcs:log:default. Select Yes (the default setting) if you want the router to send warnings to stderr when the component is not available. Enter the maximum number of seconds after which the router tries to restart the component. The default 127

134 XCP Controller Help before restarting component Maximum number of times to restart component Interval in seconds at which to reset this value to 1 second is set to 300 seconds. If the component goes down, the router tries to restart it after 1 second. If the component is not running yet and the command option is being used, the router multiplies the wait time by 1.5, and retires after the longer time. Once the maximum time interval that you specify in this field is reached, the router continues to retry after waiting this amount of time. Enter the total number of restarts allowed. The default setting, -1, means unlimited. Note: If you want to be able to kill the component from the command line and prevent it from starting again automatically, you must set this number to something other than -1. For example, if you set it to 1, the component will not restart once you have killed it; if you set it to 2, the component will only restart once, and so on. The number of seconds that the component has been up and running, after which to set the restart time back to 1 second. Command Select the Command option if you want the component to be started by the router. This option is enabled by default. Path to Binary Command The directory path to the shell that launches the component. You can change the default setting (/bin/sh) if needed. Enter the command that you want to use to start the component. Caution: Do not use the -B argument with this component. Since jabberd is already a daemon process, its children must not be daemons. Do not escape XML characters in the Controller's interface. For example, if you were writing the command configuration manually, you would need to write the string "exec 2>&1" as "exec 2>&1". However, in the Controller, you should enter the literal string and let the software perform the necessary escaping when it converts the form input into XML. 128

135 Component Configuration XDB This section configures what types of XDB packets will be processed by this JDS component: Namespace Filters Host Filters Hostnames Enter the namespaces that you want this JDS XDB to handle. Enter the hostnames or IP addresses for which you want this JDS component to handle the specified namespaces. Separate each hostname or address with a line break. Enter an asterisk (*) in the textbox to enable the component to handle data from any hosts that are not specified in another XDB host filter. Note: Host filters must be hostnames, or IPv4 or IPv6 addresses. If an IP address is used, the packet address must also use this IP address. Host Filters Enter the hostnames or IP addresses for which you want this JDS component to handle non-xdb packets. Separate each hostname or address with a line break. If you have configured the LDAP Search agent, include its name in this box as well. Note: Host filters must be hostnames, or IPv4 or IPv6 addresses. If an IP address is used, the packet address must also use this IP address. JDS Configuration Component Logging (Jlog) Select the Component Logging (Jlog) option to configure filtered level loggers that log messages to syslog and to a stream (stderr or stdout). You can enable either or both the syslog and stream loggers. Caution! When a component is daemonized, logging to stderr or stdout does not work; for example, if you start a component from the command line using the -B flag, it is daemonized. These loggers log messages that are at or above the selected severity level, and drop messages that are below the 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. 129

136 XCP Controller Help Filtered Syslog Logger Select the Filtered Syslog Logger option if you want to log information to syslog. The syslog logger logs messages that meet the Level Filter criteria. Level Pipe file Facility Identity Formatter Select a severity level from the pull-down list. ("INFO" is the default setting.) The levels are listed from least severe to most. The less severe the level, the more verbose the log. DEBUG - Information from all other log levels in addition to debug data. VERBOSE - Every packet that is processed by the server and JSM plus all Error, Warn, and Info data. INFO - Data about socket connections and all JSM logs (packet, session, and message) plus all Error Warn, and Stats log level data. This is the level at which the server logs by default. WARNING - Non-fatal errors such as bounced packets, nonexistent user logging in, invalid recipient for a message, etc., plus all Error log level data. ERROR - System-generated errors such as the inability to create listen ports, server configuration errors, failure to create the log files, etc. Enter the full path to a pipe file for this component; we suggest naming the file /var/tmp/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. Select the facility that you want to use from the drop-down list. The default facility is "LOG_DAEMON." Note: Facilities are defined on the syslog(3) manpage. Enter a term that identifies where the log information is coming from. The identity is displayed in syslog next to the associated data. The default identity is "XCP." You can change this value as needed. Enter the formatters for the information that you want to log. A default format of %d [%l] %s: %m is provided. Filtered Stream Logger 130

137 Component Configuration Select the Filtered Stream Logger option if you want to log information to stderr or to stdout. The stream logger logs messages that meet the Level Filter criteria to the specified output stream. Level Pipe file Stream Formatter Select a severity level from the pull-down list. The levels are listed from least severe to most. The less severe the level, the more verbose the log. DEBUG - Information from all other log levels in addition to debug data. VERBOSE - Every packet that is processed by the server and JSM plus all Error, Warn, and Info data. INFO - Data about socket connections and all JSM logs (packet, session, and message) plus all Error Warn, and Stats log level data. This is the level at which the server logs by default. WARNING - Non-fatal errors such as bounced packets, nonexistent user logging in, invalid recipient for a message, etc., plus all Error log level data. ERROR - System-generated errors such as the inability to create listen ports, server configuration errors, failure to create the log files, etc. Enter the full path to a pipe file for this component; we suggest naming the file /var/tmp/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. Select stderr or stdout from the drop-down list. Stderr is the default setting. Enter the formatters for the information that you want to log. A default format of %d [%l] %s: %m is provided. Add a new Custom Logger Click the Go button to access the Custom Logger Configuration screen, in which you can specify the library and library entry point function for a custom logger. Driver 131

138 XCP Controller Help Currently, 'ldap' is the only driver available. LDAP LDAP Directory Servers LDAP Databases Click the Go button to configure an LDAP directory server. Click the Go button to configure an LDAP database. SNMP Configuration Select this option if you want to configure SNMP for the JDS component. SNMP Enabled SNMP Count Errors Submit Your Configuration This option is set to Yes by default. Select Yes only if you want to enable SNMP error counting. This option takes a great deal of server resource; use it with caution. It is set to No by default. When you have finished configuring this component, click the Submit button. If you want to cancel the configuration, click the Cancel button, not the browser's back button. See also: Full Help System Directory Server Configuration LDAP Database Configuration 132

139 Component Configuration Directory Server Configuration In this section, you configure the communication between JDS and your LDAP directory service. Directory Server Enter the following information: Unique server ID Directory server hostname Directory server port Read-only SSL via TLS Timeout in seconds to wait for the directory server to process requests Frequency in seconds to refresh connection to directory server Interval in seconds to wait between reconnect attempts to directory server Enter a unique identifier for this LDAP server. This value is used to map the LDAP server to the LDAP database. Enter the hostname or IP address of the LDAP server. Enter the port number of the LDAP server. The default setting is 389. Select Yes (the default setting) if you want only read operations to be performed on the LDAP server. Note: A setting of Yes disables community group subscriptions. This option is used typically in master/slave configurations where the slave is a read-only copy of the master. Select Yes (the default setting) if you want the LDAP server connection to use starttls. Note: The XCP server supports TLS, not LDAPS. Enter the number of seconds that JDS waits for a single request to the LDAP server to be processed. Enter the number of seconds that elapse before JDS refreshes its connections to the LDAP server. Enter the number of seconds that elapse before the JDS tries to reconnect to the LDAP server if a lost connection is detected. 133

140 XCP Controller Help Directory Server user Password for directory service user Enter the distinguished name of the administration account for the LDAP server. Enter the password of the administration account for the LDAP server. Submit Your Configuration When you have finished configuring this directory server, click the Submit button. If you want to cancel the configuration, click the Cancel button, not the browser's back button. See also: Full Help System Jabber Directory Suite Configuration LDAP Database Configuration 134

141 Component Configuration LDAP Database Configuration On the Database Configuration screen, you enter information about your LDAP schema; JDS then uses this information to build Jabber IDs. You also configure the JDS commands that you want to use. Host Filters Enter the hostnames that will be processed by this database; for example, yourcorp.com. Separate each hostname with a line break. Directory Server You must configure to which directory server(s) this LDAP database applies. Click the Go button to access the Directory Server Configuration window. Jabber ID Creation The following information defines how Jabber IDs will be created from attributes in your LDAP schema: LDAP object class to users Base context for this LDAP class LDAP attribute to use for the Jabber display name Full JID attribute Static User JID Enter the LDAP object class that represents a user; for example, inetorgperson. Enter the top level of the LDAP tree that contains user entries. Enter the LDAP attribute used to display each user's name in the Jabber client interfaces; for example, cn. Select this option if your schema contains an attribute that can be used as the full Jabber ID. Attribute Enter the name of the attribute to use as the Jabber ID; for example, jabberid. Select this option if your schema contains a host attribute that can be used for all Jabber IDs. User Attribute Enter the name of the user attribute; for example, uid. User Host JID Host Enter the hostname; for example, example.com. Select this option if user Jabber IDs must be constructed from two separate LDAP attributes. User Attribute Enter the name of the user attribute; for example, 135

142 XCP Controller Help Active uid. Host Attribute Enter the name of the attribute that contains the hostname. Command Definitions Select this option if your schema contains an attribute that indicates whether or not Jabber users are valid. Type Select positive (the default setting) if the value you specify in the Value field must be in your LDAP schema for the user to be considered a valid Jabber user. If you select negative, the value you specify must not be in your LDAP schema. Attribute Enter the name of the LDAP attribute that contains the value that ensures a user is a valid Jabber user; for example, jabberactive. Value Enter the value that the LDAP attribute must or must not contain for a user to be a valid Jabber user; for example, true. Select the Command Definitions option if you want to configure the loadable commands supported by JDS. SDNS Command The SDNS (Single Domain Name Support) command allows you to use LDAP attributes to map users and hosts to subdomain names and/or to map global domains to subdomains when no user is provided. lib load Mapping for user/host Jids Leave this field blank unless you want to use a custom SDNS command. The library entry point function. Select this option if you want to map user-host Jabber IDs. The host name to map Enter the host name of the global domain being mapped; for example; yourcorp.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. In this case, if the JID jane@yourcorp.com must be rewritten as jane@denver.yourcorp.com the jabberhost attribute should contain denver.yourcorp.com. 136

143 Mapping for Host Jids Component Configuration Select this option if you want to map host-only Jabber IDs. The host name to map Enter the host name of the global domain being mapped; for example; yourcorp.com. LDAP object class to use for host lookups Base LDAP context for the lookup The LDAP entry containing the host key value The LDAP entry attribute containing the host map value Authentication Commands Enter the LDAP object class that contains the domain that is used to rewrite users' Jabber IDs. Enter the top level of the LDAP sub-tree that contains this particular host entry. Enter the LDAP attribute that contains the hostname (e.g., yourcorp.com) that you want to map. Enter the LDAP attribute that contains the domain that will be used to rewrite users' Jabber IDs; for example, jabberhost. In this case, if the JID must be rewritten as the jabberhost attribute should contain denver.yourcorp.com. The Jabber XCP Server supports SHA-1 digest authentication in addition to plain-text authentication. You can select only one or the other. authplain Digest Authentication Select this option to enable plain-text authentication. lib Leave this field blank unless you want to use a custom authplain command. load The library entry point function. Packet Type The type of packet this command processes. Select this option to enable digest-based authentication. Digest authentication allows the client and server to perform a cryptographic hash on the password and stream ID, and to compare the results. The hashed value is sent over the connection rather than the plain-text value that would be sent for the authplain command. lib Leave this field blank unless you want to use a custom Digest Authentication command. load The library entry point function. Packet Type The type of packet this command processes. 137

144 XCP Controller Help Register Check Command Select the registercheck command option to verify that each user has an active, registered account with the system. lib load Packet Type Community Groups Command Leave this field blank unless you want to use a custom registercheck command. The library entry point function. The type of packet this command processes. Select the Community Groups command option to enable community groups. lib load Packet Type LDAP object class to use for the Community Group Base context for this LDAP class LDAP attribute to use for the Group's display name Describe the relationship between users and groups Enter the attribute that indicates the relationship Relation Attribute Subscription Cache Leave this field blank unless you want to use a custom Community Groups command. The library entry point function. Type of packet this command processes. Enter the name of the object class used for group entries in your LDAP schema; for example, groupofuniquenames. Enter the top level of the LDAP sub-tree that contains group entries; for example, ou=groups, o=jabber.com. Enter the name of the group attribute to use for displaying group names in the client interfaces; for example, cn. Select container (the default setting) if users are added to group entries. Select noncontainer if groups are added to user entries. Enter the attribute that associates the user with the group (such as member) or the attribute that associates the group with the user (such as ou). Enter container or noncontainer. Enter the group attribute used to create the subscriber list for groups; for example, jabbercgsubscriber. Select this option to configure subscription caching, which improves efficiency when community groups are enabled. 138

145 Component Configuration Interval in seconds between purges of obsolete cache entries Seconds that a cache entry may exist before becoming obsolete Enter the number of seconds between purges of obsolete cache entries. Enter the number of seconds that a cache entry can remain in the cache until it becomes obsolete. LDAP Search Command Select the ldapsearch command option to enable users to search your LDAP directory for other Jabber users. lib load Packet Type Search Attributes What is the minimum number of non-wildcard (*) characters that need to be provided? Offline SMTP Leave this field blank unless you want to use a custom ldapsearch command. The library entry point function. The type of packet this command processes. The default value is 0, which allows wild-card searches without any restrictions. If you want to allow wild-card searches with restrictions, enter a positive value. The positive value must equal the number of non-wild-card characters that are required in addition to the asterisk. For example, if you enter 3, a wild-card search must include at least 3 non-wild-card characters; i.e., a*bc, abc*. In this case, a search query for a* will fail. Enter a negative value to prevent the use of wild cards in LDAP searches. Click the Go button to access the Attribute Configuration window, in which you can add LDAP search attributes. Client users will be able to search the LDAP directory using these attributes. Select the Offline SMTP option to enable the delivery of offline messages to an server. lib load Packet Type vcard Leave this field blank unless you want to use a custom Offline SMTP command. The library entry point function. The type of packet this command processes. 139

146 XCP Controller Help Select the vcard option to enable users to enter vcard information for themselves and to query the vcard information of other users. lib load Packet Type Full path to the vcard mapping file Submit Your Configuration Leave this field blank unless you want to use a custom vcard command. The library entry point function. The type of packet this command processes. Enter the full path to the vcard mapping file, vcard_ldap.xml; for example, xcpinstalldir/etc/vcard_ldap.xml. When you have finished configuring this database, click the Submit button. If you want to cancel the configuration, click the Cancel button, not the browser's back button. See also: Full Help System Jabber Directory Suite Configuration Directory Server Configuration 140

147 Component Configuration Jabber User Directory Jabber User Directory Configuration The Jabber User Directory (JUD) component creates a directory of all users who register on your server. Your Jabber users can search for other users by first name, last name, nickname, and address. The JUD component requires the use of either a PostgreSQL or Oracle database. Note: Configuring the JUD is not necessary if you have set up ldapsearch via JDS. Additional Configuration Instructions The JUD component must have an agent configured for it so that client users can search the Jabber User Directory for other Jabber users. If you enable the mod_disco module in the Jabber Session Manager Configuration, JSM will discover the JUD component and configure an agent for it automatically. However, if you choose to enable the mod_agents module instead, you must add the JUD agent in the Agents section of the Jabber Session Manager Configuration screen. As an external component, the JUD component can run on a separate machine from the Jabber XCP Server so that any degradation of performance or reliability does not affect the performance of the server. Note: Enabling JUD for use with the Jabber Messenger client requires some configuration in the client s configuration file, feature.xml. See the Jabber Messenger Administration Guide for instructions on enabling the appropriate tags in the feature.xml file. Jabber User Directory ID Description 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 JUD components. The default description of this component is "Jabber User Directory." It displays in the Components area on the Controller main window when you add a Jabber User Directory component. You can change the description if desired. The description 141

148 XCP Controller Help Runlevel Timeout for shutdown should help you distinguish between JUD components if you have more than one installed. The order in which this component shuts down. The default runlevel is 70. The runlevel must be an integer value greater than or equal to 0. (Component shutdown is executed in reverse order of the specified runlevel; components with the highest level (typically 70) shut down first.) Caution: Do not change the runlevel unless you know exactly what you are doing and understand the effects that changing it will have. The default runlevel is provided to help the system shut down as smoothly as possible, and is based on this component's dependencies upon other components. The number of seconds that the server waits to receive acknowledgement from the component that the shutdown process has completed. The default is 30 seconds. Router Connection Information Connection Type Component IP Port With an accept connection type (the default setting), the router opens a specific port and listens on that port for a connection from the component. By default, the router uses the accept method to listen for connections from all components. With a connect connection type, the router connects to the component. If you selected an accept connection type, enter the IP address or FQDN on which the router listens for the component. (By default, this field contains the IP address of the system on which the router is installed.) If you selected a connect connection type, enter the IP address or hostname of the system on which the component is installed. If you selected an accept connection type, enter the port on which the router listens for the component s connection. The router allows only a single connection over this port at a time; therefore, multiple versions of the component cannot connect over the same port. (The port is set to 7352 by default.) If you selected a connect connection type, enter the port that the component uses for communications. 142

149 Component Configuration Password Buffer size in bytes for outgoing data Buffer size in bytes for incoming data Number of packets buffered when component is down Keep-alive interval in seconds Log delivery of packets to this component Bounce error packets to stderr Maximum interval in seconds to wait before restarting component Enter the password that the router uses to authenticate the component. A default is provided if the command configuration is used. You can change this value as needed. Enter the number of bytes the router should buffer when it sends information to the component. You may want to modify this element when working on performance enhancements. The default is set to bytes. Enter the number of bytes the router should buffer when it receives information from the component. You may want to modify this element when working on performance enhancements. The default is set to bytes. Enter the number of incoming packets the router should buffer when the component is down. The default is set to 512 packets. Enter the number of seconds after which the router sends a keep-alive to the component. The keep-alive helps prevent firewalls from dropping an unused connection to the component. If this option is set to 0 or left empty, keep-alives are disabled. Select Yes (the default setting) if you want the data that the router delivers to the component to be logged. The information is logged to the logger(s) you set up during Jabberd Logger configuration (syslog, file, or stderr). Socket-level logging happens only at the debug level. The information is logged using the default namespace, jcs:log:default. Select Yes (the default setting) if you want the router to send warnings to stderr when the component is not available. Enter the maximum number of seconds after which the router tries to restart the component. The default is set to 300 seconds. If the component goes down, the router tries to restart it after 1 second. If the component is not running yet and the command option is being used, the router multiplies the wait time by 1.5, and retires after the longer time. Once the maximum time 143

150 XCP Controller Help Maximum number of times to restart component Interval in seconds at which to reset this value to 1 second interval that you specify in this field is reached, the router continues to retry after waiting this amount of time. Enter the total number of restarts allowed. The default setting, -1, means unlimited. Note: If you want to be able to kill the component from the command line and prevent it from starting again automatically, you must set this number to something other than -1. For example, if you set it to 1, the component will not restart once you have killed it; if you set it to 2, the component will only restart once, and so on. The number of seconds that the component has been up and running, after which to set the restart time back to 1 second. Command Select the Command option if you want the component to be started by the router. This option is enabled by default. Path to Binary Command Hostnames The directory path to the shell that launches the component. You can change the default setting (/bin/sh) if needed. The command that starts the component. You can change the default setting if needed. Caution: Do not use the -B argument with this component. Since jabberd is already a daemon process, its children must not be daemons. Do not escape XML characters in the Controller's interface. For example, if you were writing the command configuration manually, you would need to write the string "exec 2>&1" as "exec 2>&1". However, in the Controller, you should enter the literal string and let the software perform the necessary escaping when it converts the form input into XML. Host Filters Enter the hostnames or IP addresses for which you want this JUD component to handle packets. Separate each hostname or address with a line break. 144

151 Component Configuration Enter an asterisk (*) in the textbox to enable the component to handle data from any hosts that are not specified in another XDB host filter. Note: Host filters must be hostnames, or IPv4 or IPv6 addresses. If an IP address is used, the packet address must also use this IP address. Jabber User Directory Configuration In this section, you configure the database settings, SNMP, and filtered logging for the component. Database Setup The JUD component requires that either PostgreSQL or Oracle be installed. You must apply the JUD schema to the database so that it can store JUD data. See the XCP Installation Guide for information on setting up PostgreSQL and Oracle. Datasource Name Database User Name Database User's Password Database Type Number of connections to the database Time in seconds between database connection heartbeats For the PostgreSQL database, this is the name of the JUD datasource as specified in the.odbc.ini file. For Oracle, the datasource is specified in the ORACLE_SID environment variable. Enter the username used to connect to the database. Enter the password used to connect to the database. Select the type of database you are using from the pull-down list. The choices are postgresql-odbc and oracle-oci. Important! If you select postgresql-odbc, you must add the line, "MaxVarcharSize=4000" to the datasource definition used by the JUD in the.odbc.ini file. Enter the number of connections that you want the JUD component to use for processing requests. The default setting is 5 connections. Enter the number of seconds after which the database connection should refresh. If there is no firewall between the JUD component and the database, set this interval to '0' to disable periodic refresh attempts. The default setting is 60 seconds. 145

152 XCP Controller Help Heartbeat SQL Is database debug logging enabled Each database connection is monitored for the last time it was used. If an interval larger than "Time in seconds between database connection heartbeats" has passed, the "Heartbeat SQL" command is sent to the database to make sure the database connection is still functioning. If the connection has failed for any reason (firewalls, timeouts, network failures, etc.), the connection is reestablished. "Heartbeat SQL" is set to "default," which is 60 seconds. When set to "default," the database connection selects a database system-specific SQL command to test the validity of the connection. Caution: Do not change this value without first consulting Jabber, Inc. support. Select Yes to log database debug information. No is the default setting. Database logging uses jabberd's logging facility. The jabberd logging must be set to DEBUG for database logging to occur. User Registration Allow users to register with JUD What is the minimum number of non-wildcard (%) characters that need to be provided? Select Yes (the default setting) if you want to enable users to register with the Jabber User Directory. Enter the minimum number non-wildcard characters that a user must enter when searching the user directory. The default setting is 1. SNMP Configuration Select this option if you want to configure SNMP for the JUD component. SNMP Enabled SNMP Count Errors Component Logging (Jlog) This option is set to Yes by default. Select Yes only if you want to enable SNMP error counting. This option takes a great deal of server resource; use it with caution. It is set to No by default. 146

153 Component Configuration Select the Component Logging (Jlog) option to configure filtered level loggers that log messages to syslog and to a stream (stderr or stdout). You can enable either or both the syslog and stream loggers. Caution! When a component is daemonized, logging to stderr or stdout does not work; for example, if you start a component from the command line using the -B flag, it is daemonized. These loggers log messages that are at or above the selected severity level, and drop messages that are below the 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. Filtered Syslog Logger Select the Filtered Syslog Logger option if you want to log information to syslog. The syslog logger logs messages that meet the Level Filter criteria. Level Pipe file Select a severity level from the pull-down list. ("INFO" is the default setting.) The levels are listed from least severe to most. The less severe the level, the more verbose the log. DEBUG - Information from all other log levels in addition to debug data. VERBOSE - Every packet that is processed by the server and JSM plus all Error, Warn, and Info data. INFO - Data about socket connections and all JSM logs (packet, session, and message) plus all Error Warn, and Stats log level data. This is the level at which the server logs by default. WARNING - Non-fatal errors such as bounced packets, nonexistent user logging in, invalid recipient for a message, etc., plus all Error log level data. ERROR - System-generated errors such as the inability to create listen ports, server configuration errors, failure to create the log files, etc. Enter the full path to a pipe file for this component; we suggest naming the file /var/tmp/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. 147

154 XCP Controller Help Facility Identity Formatter Select the facility that you want to use from the drop-down list. The default facility is "LOG_DAEMON." Note: Facilities are defined on the syslog(3) manpage. Enter a term that identifies where the log information is coming from. The identity is displayed in syslog next to the associated data. The default identity is "XCP." You can change this value as needed. Enter the formatters for the information that you want to log. A default format of %d [%l] %s: %m is provided. Filtered Stream Logger Select the Filtered Stream Logger option if you want to log information to stderr or to stdout. The stream logger logs messages that meet the Level Filter criteria to the specified output stream. Level Pipe file Select a severity level from the pull-down list. The levels are listed from least severe to most. The less severe the level, the more verbose the log. DEBUG - Information from all other log levels in addition to debug data. VERBOSE - Every packet that is processed by the server and JSM plus all Error, Warn, and Info data. INFO - Data about socket connections and all JSM logs (packet, session, and message) plus all Error Warn, and Stats log level data. This is the level at which the server logs by default. WARNING - Non-fatal errors such as bounced packets, nonexistent user logging in, invalid recipient for a message, etc., plus all Error log level data. ERROR - System-generated errors such as the inability to create listen ports, server configuration errors, failure to create the log files, etc. Enter the full path to a pipe file for this component; we suggest naming the file /var/tmp/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. 148

155 Component Configuration Stream Formatter Select stderr or stdout from the drop-down list. Stderr is the default setting. Enter the formatters for the information that you want to log. A default format of %d [%l] %s: %m is provided. Add a new Custom Logger Click the Go button to access the Custom Logger Configuration screen, in which you can specify the library and library entry point function for a custom logger. Submit Your Configuration When you have finished configuring this component, click the Submit button. If you want to cancel the configuration, click the Cancel button, not the browser's back button. See also: Full Help System 149

156 XCP Controller Help Open Port Open Port Configuration The Open Port component allows you to configure a custom component or a component used for testing purposes. Open Port ID Description Runlevel Timeout for Shutdown The Jabber ID of this component. This is a read-only value that you provide before entering the open port configuration screen. Important! This value must match the ID of the component for which you are creating the open port. The description of the component displays in the Components area on the Controller main window when you add an Open Port component. You can change the description if desired. The description should help you distinguish between Open Port components if you have more than one installed. The order in which this component shuts down. The runlevel for an open port component depends on the purpose of the open port. For a generic open port, the default runlevel is 70, which shuts the component down first. Open port components for a CM, such as the default JSMCP and WEBCP components should be set to 60 (one level higher than the CM runlevel) so that they will shutdown before the CM. The default run level for an S2S Open Port is 30. The runlevel must be an integer value greater than or equal to 0. Component shutdown is executed in reverse order of the specified runlevel; components with the highest level (typically 70) shut down first. Caution: Do not change the runlevel for the default open port components unless you know exactly what you are doing and understand the effects that changing them will have. The default runlevel is provided to help the system shut down as smoothly as possible, and is based on this component's dependencies upon other components. The number of seconds that the server waits to receive acknowledgement from the component that the shutdown process has completed. 150

157 Component Configuration Router Connection Information Connection Type Component IP Port Password Buffer size in bytes for outgoing data Buffer size in bytes for incoming data Number of packets With an accept connection type (the default setting), the router opens a specific port and listens on that port for a connection from the component. By default, the router uses the accept method to listen for connections from all components. With a connect connection type, the router connects to the component. If you selected an accept connection type, enter the IP address or FQDN on which the router listens for the component. If you selected a connect connection type, enter the IP address or hostname of the system on which the component is installed. If you selected an accept connection type, enter the port on which the router listens for the component s connection. The router allows only a single connection over this port at a time; therefore, multiple versions of the component cannot connect over the same port. If you selected a connect connection type, enter the port that the component uses for communications. Note: If you are configuring a Web Services open port, the port number here must match the port specified for the Web Services handler. Enter the password that the router uses to authenticate the component. A default is provided if the command configuration is used. You can change this value as needed. Enter the number of bytes the router should buffer when it sends information to the component. You may want to modify this element when working on performance enhancements. The default is set to bytes. Enter the number of bytes the router should buffer when it receives information from the component. You may want to modify this element when working on performance enhancements. The default is set to bytes. Enter the number of incoming packets the router 151

158 XCP Controller Help buffered when component is down Keep-alive interval in seconds Log delivery of packets to this component Bounce error packets to stderr Maximum interval in seconds to wait before restarting component Maximum number of times to restart component Interval in seconds at which to reset this value to 1 second should buffer when the component is down. The default is set to 512 packets. Enter the number of seconds after which the router sends a keep-alive to the component. The keep-alive helps prevent firewalls from dropping an unused connection to the component. If this option is set to 0 or left empty, keep-alives are disabled. Select Yes (the default setting) if you want the data that the router delivers to the component to be logged. The information is logged to the logger(s) you set up during Jabberd Logger configuration (syslog, file, or stderr). Socket-level logging happens only at the debug level. The information is logged using the default namespace, jcs:log:default. Select Yes (the default setting) if you want the router to send warnings to stderr when the component is not available. Enter the maximum number of seconds after which the router tries to restart the component. The default is set to 300 seconds. If the component goes down, the router tries to restart it after 1 second. If the component is not running yet and the command option is being used, the router multiplies the wait time by 1.5, and retires after the longer time. Once the maximum time interval that you specify in this field is reached, the router continues to retry after waiting this amount of time. Enter the total number of restarts allowed. The default setting, -1, means unlimited. Note: If you want to be able to kill the component from the command line and prevent it from starting again automatically, you must set this number to something other than -1. For example, if you set it to 1, the component will not restart once you have killed it; if you set it to 2, the component will only restart once, and so on. The number of seconds that the component has been up and running, after which to set the restart time back to 1 second. 152

159 Component Configuration Command Select the Command option if you want the component to be started by the router. Path to Binary Command Service Component The directory path to the shell that launches the component. You can change the default setting (/bin/sh) if needed. Enter the command that you want to use to start the component. Caution: Do not use the -B argument with this component. Since jabberd is already a daemon process, its children must not be daemons. Do not escape XML characters in the Controller's interface. For example, if you were writing the command configuration manually, you would need to write the string "exec 2>&1" as "exec 2>&1". However, in the Controller, you should enter the literal string and let the software perform the necessary escaping when it converts the form input into XML. Select the Service Component option if you want the component to receive packets other than 'log' or 'xdb.' This component is enabled by default. Host Filters XDB Enter the hostnames or IP addresses for which you want this Open Port component to handle packets. Separate each hostname or address with a line break. Enter an asterisk (*) in the textbox to enable the component to handle data from any hosts that are not specified in another XDB host filter. Note: Host filters must be hostnames, or IPv4 or IPv6 addresses. If an IP address is used, the packet address must also use this IP address. Select the XDB option if you want to set this component up to receive XDB packets. Namespace Filters Enter an asterisk (*) to indicates that this XDB will handle the namespaces that are not handled by another XDB plugin. If you want the XDB to handle specific namespaces only, enter them in the textbox separating each with a line break. All other namespaces will be 153

160 XCP Controller Help Host Filters ignored. Caution! You can specify an asterisk for only one XDB plugin. Enter the hostnames for which you want this XDB instance to handle XDB packets. Separate each hostname with a line break. Enter an asterisk (*) in the textbox to enable this XDB instance to handle XDB packets from any host. Log Select the Log option if you want to set this component up to receive log packets. nss Host Filters Open Port Configuration Leave the namespaces for which you want data to be logged by this component. Remove those that you do not wish to use. Note: You can delete or modify any of the namespaces in the list, and you can add namespaces at the bottom of the list if desired. Enter the hostnames for which you want this Open Port component to handle packets. Separate each hostname with a line break. Enter an asterisk (*) in the textbox to enable the component to handle data from any host. By default, the OpenPort Config field contains an empty <config/> element in the open-port namespace. Do not change the top-level configuration element. You can add any additional XML configuration for the open port; for example, a configuration for SNMP. When you add an element, the string "xmlns=" is added inside the tag. Adding additional XML is helpful when you are creating an open port for a custom component that does not have a.jig or an.xsd file. Submit Your Configuration When you have finished configuring this component, click the Submit button. If you want to cancel the configuration, click the Cancel button, not the browser's back button. See also: 154

161 Component Configuration Full Help System 155

162 XCP Controller Help Single Domain Name Support Jabberd Port Configuration The Jabberd port is used to connect two Jabber XCP routers when like components connected to those routers need to communicate. 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 a Jabberd port on both routers. The Jabberd port on router A must specify host filters (in the form ID.realm) for the TC components on router B. Likewise, the Jabberd port on router B must specify the host filters for the TC components on router A. This configuration enables two-way communication between the TC components on both routers. The components that you can configure to communicate using a Jabberd port include: JSM Information Broker Text Conferencing Example Configuration In the following figure, router A is installed on a Redhat box and, during installation, was given the realm "redhat." Router B is installed on a Solaris box and was given the realm "solaris." The TC components on router A have the IDs, tc-1 and tc-2, and the TC components on router B have the IDs, tc-1, tc-2, and tc-3. The SDNS component is configured on router B in order to facilitate the communication between the TC components (it must be installed on only one of the two connecting routers). 156

163 Component Configuration The process for enabling the TC components illustrated in the previous figure to communicate by configuring a Jabberd port on each system is described below. On both Jabber XCP routers: 1. Add a Jabberd port component. 2. In the Jabberd Port Configuration screen, supply all necessary router information. Note: If you configure the Jabberd port on router A to have a connection type of accept, you must configure the Jabberd port on router B to have a connection type of connect and vice versa. 3. Enable the Service Component option. 4. In the Host Filters list: On router A, enter the ID and realm of each TC component installed on router B as follows: tc-1.solaris tc-2.solaris tc-3.solaris On router B, enter the ID and realm of each TC component installed on router A as follows: tc-1.redhat tc-2.redhat 5. Submit the Jabberd port's configuration. 157