Configuration Server Properties

access.control.configuration

<configurationfile>

This property shows where the configuration to the access contrl system in the configuration server is found.

Example:
./cfg/usi-server-security.xml

In this example the configuration server uses the specified XML file. This configurations file contains the users and groups who have access to all or part of the PortalProtect management GUI.

See chapter 4. Administration of users.

access.controller

<java class>

This class is an implementation of AccessControlList which defines the format which the access control system uses.
Example:

dk.itp.security.accesscontrol.AccessControlListXMLImpl
In this example an XML implementation is used.

remote.servers

<host> [<,|;> <host> […] ]

This property defines the servers, hostnames, which the configuration server will accept connections from. If a servers hostname or IP address is not defined in this property the configurations server will close the connection.
This will ensure that servers can not be applied, without being defined beforehand.

IMPORTANT: Note that this entry can be configured on other types of servers that accept connections from remote clients too, including the session controller and the log server.

Example:
server1,server2

In this example the configuration server will only accept connections from server1 and server2. All other server connections will be refused.

configuration.remote.servers

<host> [<,|;> <host> […] ]

Functions much like remote.servers, but it restricts access to a configuration entry so this particular configuration can only be read by one of the hosts listed here.
Note that this entry can be set on any kind of server configuration, and when a client/agent (e.g. a dispatcher) wants to retrieve this configuration, it must be on the approved list in order to do so.

If the entry is not present, or empty no restrictions are set on who are able to read which configuration entry.

Example:
dispatcher1,dispatcher3

cluster.server

<master|slave>

A configuration server can run in a cluster which can handle fail-over. A cluster conmprises of a master server and a set of slave servers.

The master configuration server, which normally is the same machine which is host for the management GUI console, propagates changes in the configuration to all connected slave configuration servers. Similarly all slave configuration servers will propagate their changes on to the master configuration server.

If a change is made in the master configuration server, this will be propagated to the connected slave servers. Each slave configuration server works locally as a standalone configurations server with its own configurations file. A slave configuration server can just like a master, operate alone and be host for all PortalProtect servers in the system.

If a change is made in a slave configuration server, this will propagate the change to the master server who will propagate the change out to the other slave servers. The slave configuration server will receive an event about the change. The single configuration server can react on these events, for example, if it already knows the event the configurations server will ignore this.

There will normally be just one master server in an installation and there can be 0 or more slave configurations.

Example:
<master>
In this example the server will be the master server.

<slave>
In this example the server will be the slave server.

cluster.server.master

<host:port> or <protocol:host:port> where protocol is tcp, nio, nios or local

This property defines the connection to the master configurations server. This property must correspond to the master configurations servers host name and server.port.

This property has no effect if the configuration server is defined as <master>.

Example:
cluster.server.master=configserver1:21233 - In this example the configurations server will connect to the master configurations server on port 21233.
cluster.server.master=nio://configserver1:21233 – Same as above, but connects using NIO sockets which are nonblocking IO using fewer server threads.
cluster.server.master=local://21233 - Same as above, but does not use tcp/ip and instead local JVM connections – the master then has to exist in the same JVM and be loaded by the same classloader.

peer.server.address

<ip address> - DEPRECATED – use statistics.server.listenurls instead

This IP address is the network interface which the program must listen for connections from the statistics server on. This parameter is interesting in configurations where the server has more than one network interfaces.

The IP address 0.0.0.0 implies that the server must listen for all interfaces.

Example:
0.0.0.0
Here the server will listen on all available network interfaces.
Security for attacks from the outside is low when when all network interfaces are being listened to.

Example:
10.23.13.110.
Here the server will listen for the specified interface. It will therefore not be possible to access the server from other network interfaces.
Security for attacks from the outside with this configuration will be higher.

Example:
127.0.0.1
Here the server will listen on the loopback interface. No external machines can connect to the server.
Security for attacks from the outside with this configuration is high.

peer.server.port

<port> - - DEPRECATED – use statistics.server.listenurls instead

This property specifies the port which among others the statistics server connects on.
At this point in time it is only the statistics server which uses this connection. The statistics server must XXXestableXXX be configured to connect to this port.

Example:
21111
In this example the configurations server listens on port 21111.

statistics.server.listenurls

protocol://hostname:port

If not using statistics.server.listenurls, where the statistics server connects to the configserver, you can get the configserver to connect to the statisticsserver instead - this is done by setting this property - the corresponding statistics.server.listenurls setting must then be defined in the statistics server.

The statistic server works closely with the configuration servers. A configuration server receives at definite intervals statistics from each of the servers which are connected to it. The configuration server stores the collected statistics in a buffer. When a statistics server gathers statistics from a configurations server, this buffer is emptied. The statistics server handles the data, by grouping the measurements in time slots.

Note that the measurements are received asynchronously. Therefore the statistics can be changed in the past also. A server which has been disconnected can have collected statistics over time. When the connection is re-established the statistic server will receive the statistics and group this information also back in time.

The protocol, if specified can be either nio, nios, tcp, tcps or local –see the description of the config server's server.listenurls for detailed info on the differences. If no protocol is specified, tcp:// is assumed.

Example:
tcp://localhost:21111
local://21111
nios://localhost:21111

In this example the statistic server connects to the configuration server localhost:21111 and collects gathered statistics from here.

server.address

<IP or hostname> - DEPRECATED – use server.listenurls instead.

The IP address is the network interface which the program must listen on. Interesting for configurations where the server has many network interfaces.

IP address 0.0.0.0 implies that the server listens for all network interfaces.

Example
0.0.0.0
Here the server will listen on all available network interfaces.
Security for attacks from the outside is low when when all network interfaces are being listened to.

Example:
10.23.13.110.
Here the server will listen for the specified interface. It will therefore not be possible to access the server from other network interfaces.
Security for attacks from the outside with this configuration will be higher.

Example:
127.0.0.1

Here the server will listen on the loopback interface. No external machines can connect to the server.
Security for attacks from the outside with this configuration is high.

server.port

<port> - DEPRECATED – use server.listenurls instead.

This property contains the port which the configurations server listens on. This corresponds to the port in config.servers or in ptserver.properties which the PortalProtect agent uses.

Example:
21233

server.listenurls

<URL list> - defaults to tcp://{server.port} where {server.port} is the value of the server.port property.

List of URLs to listen for connections from configuration clients – The URLs have the following format:

tcp://[hostname:]port – TCP/IP blocking sockets – requires 2 java threads per connection.
nio://[hostname:]port – TCP/IP nonblocking (java nio) sockets – does not require any extra threads.
local://port – Local queue-based connection, requires 1 thread per connection, only works in the same JVM, but much faster than using sockets.
nios://[hostname]:port[?params] – Like NIO, but with SSL encryption

For nios connections, the following parameters can be specified;
keystore – Filename of keystore – default is /ptskeystore
keystorepassword - Password for keystore
keystoretype – Type of keystore, default is JKS
enabledciphersuites – List of enabled cipher suites, if not specified, the Java default ones are used.

Note that this list of URLs replaces the older server.port and server.address properties – this provides a more flexible way to support multiple communication protocols, and listen on multiple interfaces simultaneously.
If this property is not specified, it will default to tcp:// protocol and the port number from the server.port setting to remain backward compatible.

Examples:
server.listenurls=tcp://21233 – Listens on port 21233, using TCP blocking sockets
server.listenurls=nio://10.0.0.1:21233;local://21233 – Listen on the specified IP address and port, using nonblocking sockets, and also listens for local connections from components in the same JVM on port 21233.

statistics.server

<name of statistics server>

This property gives the name of the statistic server. This is used by the configuration server to collect information from the statistic server and show the information in the PortalProtect management GUI.

The name must correspond to the name in the statistic server physical name in the configuration.

Example:
statisticsserver1

telnetd

<enable|disable>

This property enables or disables the built-in telnet server in the PortalProtect configuration server.
Noite that this is not supported.
The telnet server supports a series of commands. The syntax can be found by writing help on the command line after logon.

Example:
<enable>
In this example the telnet server is active. In the following example it is assumed that the telnet port telnetd.listenport is 23. The Telnet server can be reached by writing:
telnet <configserver> 23
Where <configserver> is the host name or IP address of the configurations server (the same as the administrations GUI server)
Afterwards one must log in as administrator in order to call the functions in the telnet server.

<disable>
In this example the telnet server is disabled.

telnetd.listenport

<port>

This property specifies the telnet servers port.

Example:
2323
In this example the telnet server listens on port 2323 if telnetd is <enable>
The telnet server can be called by writing:
telnet <configserver> 2323
And then log in as administrator.

telnetd.timeout

<time in seconds>

This property specifies the number of seconds before an inactive telnet session times out. When a session times out, the user is logged out and the session is terminated.

Example:
60
In this example the telnet session will be terminated after 60 seconds.

dashboard.type

Type of dashboard to show.

If not defined no dashboard will be available.

Simple: Shows a simple dashboard using the servers status pages

dashboard.layout

Layout for the configures dashboard

This property is dashboard specific:

Simple dashboard: Supports grid, gridtop, gridbottom, sidebyside and ontop. Default value is "grid". The different values will result in layouts like shown below.

dashboard.showheaders

Setting this vaule to "true" will result in the dashboard to show headers of each server before the actual data.

For the simple dashboard this will be shown in the top of each frame with server name, command and property.

dashboard.X.server

The servername for the X'th dashboard

X is a numeric value from 1 through the number of supported servers for the current dashboard type. The server should exist in the configuration or an error will be shown in the dashboard.

dashboard.X.command

The command for the X'th dashboard (Simple dashboard only)

This property is used in the simple dashboard. It conforms to the command used to show dashboard content. Currently the values "general" and "details" are supported. Default value is "general"

X is a numeric value from 1 through the number of supported servers for the current dashboard type and should match a server entry.

dashboard.X.property

The property for the X'th dashboard (Simple dashboard only)

This property is used in the simple dashboard. It conforms to the property link used to show dashboard content in conjunction with the "details" command. This is sent to the server where it is treated like a status link. And example value is "routetable" for configuration servers which shows the routing table and status of connected agents. Default value is empty/null..

X is a numeric value from 1 through the number of supported servers for the current dashboard type and should match a server entry.

dashboard.X.refresh

The refresh timeer for the X'th dashboard

This property is used in all dashboards. It is a number in seconds that defines hwo often the dashboard should refresh the data from the configured server. Default value is "30"

X is a numeric value from 1 through the number of supported servers for the current dashboard type and should match a server entry.

customMenuItems

<semicolon separated list of name,url>

If any custom menu items are defined, they will be slow below the list of servers. This can be used to add additional functionality to the administration console, e.g. you can add additional administration pages, jsp pages or similar.

ExampleView audit log,viewaudit.jsp;WAS Admin,/ibm/console

list.log.directories

<semicolon separated list of directories,aliases>

Directories and their aliases listed here will be shown in the details for the config server and if they can be reached through the management console application the files in those directores can be downloaded through the administration console. If no alias is defined the log directory is shown as is.

If several configuration servers exists and only one is used for administration console access UNC paths can be used instead of direct paths. This will allow the administration console to access the directories and files. If UNC paths are used that cannot be accessed regular network path timeout for the host platform is controlling how long it takes to show the directory list.

Example:
./logs,PP core logs;/var/logs,Server logs;c:\temp

In this example three log directories are shown. PP Core logs (using ./logs), Server logs (using /var/logs) and c:\temp