Tigase Server

Possible values: user1@domain,user2@domain2

Specifies a list of administrator accounts. Possible values: list of admin accounts: 'user1@domain,user2@domain2'

Possible values: mysql|pgsql|ldap|drupal|tigase-auth|tigase-custom|class name

Specifies authentication repository, where 'db-type' can be one of possible values: mysql, pgsql, drupal, wp, tigase-auth and tigase-custom (if omitted: 'user-db' is used in versions up to 5.0 and 'tigase-custom' is the new default value starting from version 5.1 ) or the class name. For SQL database this is normally: tigase.db.jdbc.JDBCRepository.

Possible values: db connection-uri

'connection-uri' is a full resource uri for user repository data source. (If omitted 'user-db-uri' settings are used.)

Possible values: class implementing AuthRepository

Allows to specify an implementation for per-domain AuthRepository implementation. This is used only if the implementation provided by a default Tigase server package is not sufficient in the particular deployment. The implementation provides a DB (AuthRepository to be more specific) connection pool where each connection (AuthRepository) handles data for a different DNS domain (VHost). This allows for database (user data) sharding to improve the system performance and better balance the load.

Possible values: class implementing AuthRepository

Allows to specify an implementation for the authentication repository connection pool. This is used only if the implementation provided by a default Tigase server package is not sufficient in the particular deployment. The implementation provides a DB (AuthRepository to be more specific) connection pool to improve the data access performance. The repository pool can offer data caching for improved performance or any other features necessary.

Possible values: comma separated list of domains

This property allows to set a list of domains to be bound to the external component connection. Let's say we have a Tigase instance with only MUC and PubSub components loaded and we want to connect this instance to the main server via external component protocol. Using --external property we can define a domain (maybe muc.devel.tigase.org), password, TCP/IP port, remote host address, connection type, etc.... This would make one of our component (MUC) visible on the remote server.
To make visible the second component (PubSub) we would need to open another connection with the domain name (pubsub.devel.tigase.org) for the another component. Of course the second connection is redundant as all communication could go through a single connection. This is what this property is used. In our example with 2 components you can just put the 'pubsub.devel.tigase.org' domain as a value to this property and it will bind the second domain to a single connection on top of the domain...

Possible values: true|false

The property globally disables Bosh keep-alive support for the Tigase server. It causes the Bosh connection manager to force closed HTTP connection each time data is sent to the Bosh client. To continue communication the client must open a new HTTP connection.

This setting is rarely required on some installations where the client cannot control/disable keep-alive Bosh connections and keep-alive does not work correctly for some reason.

Possible values: path to a file on the filesystem

The property allows you to specify a path to a text file with additional HTTP headers which will be sent to a Bosh client with each request. This gives some extra flexibility for Bosh clients running on some systems with special requirements for the HTTP headers and some additional settings.

By default a file distributed with the installation contains following content:

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Content-Type
Access-Control-Max-Age: 86400

Possible values: class implementing ComponentRepository

This property allows to set class controlling cluster connections repository. The cluster connections repository is responsible for discovering cluster nodes which are part of the installation. Tigase in cluster mode establishes TCP/IP connections between cluster nodes to allow for user communication and exchanging cluster state metadata.

From the Tigase XMPP Server 5.2.0 the server supports cluster auto-configuration so no action, configuring or any maintenance action is required to add a new cluster node.
As everything in the Tigase it is also a pluggable system so it is possible to implement/add new ways to synchronize information about cluster nodes on the system. Currently following cluster connection repositories are implemented:

1. ClConSQLRepository a default implementation which synchronizes cluster nodes information through SQL database. By default it uses the same database as the main Tigase DB, that is the UserRepository...

Possible values: path to a file on the filesystem

The property allows to control the cross domain access policy for Silverlight based web applications. The cross domain policy is controlled via XML file which contains the policy and rules.

By default Tigase is distributed with an example policy file which allows for full access from all sources to the whole installation. This is generally correct for most Bosh server installations. The configuration through the property and the XML file allows for a very easy and flexible modification of the policy on your installation.

Possible values: true|false

The property is used to open active connections to all nodes listed in the '--cluster-nodes' configuration property. This property should be used only on the node which is added to the live cluster at later time. Normally this new cluster node is not listed in configuration of the existing cluster nodes. This is why they can not open connections the new node. The new node opens connection to all existing nodes instead. False is the default value and you can skip this option if you want to have it switched off.

Possible values: true|false

The property is used to switch cluster mode on. The default value is 'false' so you can normally skip the parameter if you don't want the server to run in the cluster mode. You can run the server in the cluster mode even if there is only one node running. The performance impact is insignificant and you have the opportunity to connect mode cluster nodes at any time without restarting the server.

Possible values: a comma separated list of hostnames

The property is used to specify a list of cluster nodes running on your installation.
The node is a full DNS name of the machine running the node. Please note the proper DNS configuration is critical for the cluster to work correctly. Make sure the 'hostname' command returns a full DNS name on each cluster node. Nodes don't have to be in the same network although good network connectivity is also a critical element for an effective cluster performance.

--cluster-nodes=host-a.domain.com:pass:port,host-b.domain.com:pass:port,host-c.domain.com:pass:port

Possible values: comma separated list of traffic limits settings

The property is used to specify traffic limit of non-user connections, that is s2s, external components and other high traffic server connections. Meaning of the property and values encoded are in the same way as for the --cm-traffic-throttling property.

Possible values: comma separated list of traffic limits settings

The property allows you to limit traffic on user connections. These limits are applied to each user connection and if a limit is exceeded then a specified action is applied.
The property value is a comma separated list of traffic limits settings. For example the first part: xmpp:2500:0:disc specifies traffic limits for XMPP data to 2,500 packets allowed within last minute either sent to or received from a user and unlimited (0) total traffic on the user connection, in case any limit is exceeded the action is to disconnect the user.

• [xmpp|bin] traffic type, xmpp - XMPP traffic, that is limits refer to a number of XMPP packets transmitted, bin - binary traffic, that is limits refer to a number of bytes transmitted.
• 2500 maximum traffic allowed within 1 minute. 0 means unlimited, or no limits.
• 0 maximum traffic allowed for the life span of the connection. 0 means unlimited or no limits.
...

Possible values: comma separate list of TCP/IP port numbers

The property is used to set ports list for a connection manager. 'cmpname' is a component name of the connection manager you want to change ports numbers for. 'list of ports' is a comma separated list of ports numbers. For example for the server to server connection manager named s2s the property would like like the example below:

--s2s-ports=5269,5270,5271

Possible values: class name

Property is used to load an extra component to the server. Normally this parameter is used if you want to load a component which is not included in the 'config-type' you use. You can, of course, load more than just one component using parameters: '--comp-class-2', '--comp-class-3' and so on.... Let's say you want to load the MUC component and the class name for the component is: 'tigase.muc.MUCService'. The line in the properties file should look like:

--comp-class-1 = tigase.muc.MUCComponent

Possible values: XMPP localnode string

The property is used to assign name 'name' to the non-standard component which is loaded by the server. It is normally used when you want to load component which is not loaded by the 'config-type' you use. Together with '--comp-class-1' it allows you to load any extra component to your server configuration. Of course you can load more than just one component. Just use '--comp-name-2', '--comp-name-3' and so on... Let's say you want to load the MUC component. You can then put give it a name: 'muc' and the setting would look like:

--comp-name-1 = muc

Possible values: path to a file on the filesystem

The property allows to set path to a file with cross domain access policy for flash based clients. This is a standard XML file which is sent to the flash client upon request.

A default file distributed with the Tigase installation allows for full access for all. This is good enough for most use cases but it can be changed by simply editing the file.

Possible values: comma separated list of Tigase's package names

This property is used to turn on debugs log for selected tigase package. For example if you want to turn debug logs on for package: tigase.server then you have to put parameter: '--debug server'. If you have any problems with your server the best way to get help from me is to generate configuration with '--debug = server' and run the server. Then from the logs/tigase-console.log log file I can get all information I need to give you a help. More details about server logging and adjusting logging level is described in article Debugging Tigase.

Possible values: comma separated list of java packages or classes

The property is used to turn debugging on for any package not necessarily within tigase packages.

Possible values: ALL|LOCAL|OWN|BLOCK|LIST

The property is a global settings for setting communication filtering for vhosts. This function is kind of extension of the same property which could be set on a single user level. However, in many cases it is desired to control users communication not on per user-level but on the domain level. Domain filtering (communication filtering) allows you to specify with whom users can communicate for a particular domain. It allows to restrict communication for a selected domains or for the entire installation. A default value ALL that users for the domain (by default for all domains) are allowed to communicate with any user on any other domain. Other possible values are:

1. ALL a default value allowing users to communicate with anybody on any other domain, including external servers.
2. LOCAL allows users to communicate with all users on the same installation on any domain. It only blocks communication with external servers.
3. ...

Possible values: external connection definition string

Deprecated in favor of '--external'. Support for this property is no longer maintained, please update your installation for the new way to connect external components.
The property creates a connection over external component protocol - XEP-0114. The connection can be made to/from any XEP-0114 application: IM transort, MUC, PubSub and others. It is also possible to separate Tigase internal components onto separate instances connected via XEP-0114 connections. Possible values: connection string 'localdomain,remotedomain,port,passwd,(plain|ssl),(accept|connect),routing'
Note: It is also possible to generate configuration for many external components. To do so use '--ext-comp_1 parameters', '--ext-comp_2 parameters' and so on...

Possible values: a class name implementing tigase.db.comp.ComponentRepository

This can be used when '--external' is used to connect external components. The component responsible for maintaining external components connections can be reconfigured at run-time and can store configuration in a separate place, configuration file, database or any other data source. This property specifies implementation for this data source.
The property sets a class managing the component repository. There are 3 available now and you can implement and use your own. The 3 available are:
'tigase.server.ext.CompConfigRepository' which reads settings for external components from configuration only. It works well with ad-hoc commands, you can add, remove and update external component settings but your changes are not saved to any permanent storage.
'tigase.server.ext.CompDBRepository' which reads settings for external components from configuration and from database. As a database backend it uses UserRepository. It works well with ad-hoc commands and your...

Possible values: external domains parameters list

The property defines parameters for external component connections.
The component is loaded the same way as all other Tigase components. In your init.properties file you need to add 2 lines:

--comp-name-1 = ext
--comp-class-1 = tigase.server.ext.ComponentProtocol

--external = muc1.devel.tigase.org:passwd1,muc2.devel.tigase.org:passwd2

Possible values: integer number

The property set internal queues maximum size to a specified value. By default the Tigase sets the queue size depending on the maximum available memory to the Tigase server process. It set's 1000 for each 100MB memory assigned for JVM. This is enough for most use cases. If you have, however extremely busy service with Pubsub or MUC component generating huge number of packets (presence or messages) this size should be equal or bigger to the maximum expected number of packets generated by the component in a single request. Otherwise the Tigase may drop packets which it is unable to process.

Possible values: list of monitoring protocols with port numbers

The property activates monitoring interfaces through selected protocols on selected TCP/IP port numbers. For more details please refer to the monitoring guide for details.

Possible values: network buffer size as integer

The property sets the network buffer for high traffic connections like s2s or connections between cluster nodes. The default is 64k and is optimal for medium traffic websites. If your cluster installation can not cope with traffic between nodes try to increase this number.

Possible values: network buffer size as integer

The property sets the network buffer for standard (usually c2s) connections, default value is 2k and is optimal for most of cases.

Possible values: a list of port numbers with throttling thresholds as integer

The property allows you to limit how many new users' connection per second the server accepts on a particular port. Connections established within the limit are processed normally, all others are simply disconnected. This allows you to avoid server overload in case there is a huge number of users trying to connect at the same time. Mostly this happens after the server restart.
The property value is a list of comma separated port settings. Each port setting is formatted in a following way: PORT_NO:LIMIT_VAL

Possible values: true|false

The property can be used to switch to non-priority queues usage in the Tigase server (value set to 'true'). Using non-priority queues prevents packets reordering. By default the Tigase uses priority queues which means that packets with highest priority may take over packets with lower priority (presence updates) which may result in packets arriving out of order.
This may happen however only for packets of different types. That is, messages may take over presence packets, however, one message never takes over another message for the same user. Therefore, out of order packets delivery is not an issue for most cases.

Possible values: class name extending tigase.util.PriorityQueueAbstract

The property sets the Tigase internal queue implementation. You can choose between already available and ready to use or you can create own queue implementation and let the Tigase load it instead of the default one.
Currently following queue implementations are available:

1. tigase.util.PriorityQueueRelaxed - specialized priority queue designed to efficiently handle very high load and prevent packets loss for higher priority queues. This means that sometimes, under the system overload packets may arrive out of order in cases when they could have been dropped. Packets loss (drops) can typically happen for the lowest priority packets (presences) under a very high load.
2. tigase.util.PriorityQueueStrict - specialized priority queue designed to efficiently handle very high load but prefers packet loss over packet reordering. It is suitable for systems with a very high load where the packets order is the critical to proper system functioning. It means that...

Possible values: Class extending tigase.xmpp.impl.roster.RosterAbstract

This property allows you to specify a different RosterAbstract implementation. This might be useful for a customized roster storage, or extended roster content or in some cases for some custom logic for certain roster elements.

Possible values: true|false

Property activates a workaround for a bug in EJabberd in it's s2s implementation. EJabberd does not send dialback in stream features after TLS handshaking even if the dialback is expected/needed. This results in unusable connection as EJabberd does not accept any packets on this connection either. The workaround is enabled by default right now until EJabberd version without the bug is popular enough. A disadvantage of the workaround is that dialback is always performed even if the SSL certificate is fully trusted and in theory dialback could be avoided.

Possible values: ascii string

The property is a global settings for s2s secrets to generate dialback keys on the Tigase installation. By default it is null, which means the secret is automatically generated for each s2s connection and handshaking.

This is a global property which is overridden by settings for particular vhost.

A default settings for all virtual hosts for which the configuration is not defined. This settings is useful mostly for installations with many virtual hosts listed in the init.property file for which there is no individual settings specified. It allows to configure a default values for all of them, instead of having to provide individual configuration for each vhost.

It is also applied as a default value for all new vhosts added at run-time.

Possible values: comma separated list of domains

The property disables TLS handshaking for s2s connections to selected remote domains. Unfortunately some servers (certain versions of Openfire - [1] or [2]) have problems with TLS handshaking over s2s which prevents establishing usable connection. This completely blocks any communication to these servers. As a workaround you can disable TLS for these domains to get communication back.

Possible values: path to a directory on the filesystem

The property sets the directory where all administrator scripts for ad-hoc command are stored.

Possible values: comma separated list of plugins IDs

The property allows to specify a list of plugins which should be loaded or disabled on the server. Normally you don't have to specify this. Server loads default list of plugins automatically. The default list contains all available plugins. Sometimes however you might want to load only some plugins. Typical use case is when user accounts are managed on your third-party system the Tigase server is integrated with. Then you might not want to allow users to register new accounts via XMPP service. You can then load a list of plugins without the user registration plugin. Another case when you usually have to use this option is when you have your own plugins which replace function of the Tigase default plugins like vCard, roster management, and so on....
To prevent the plugin from loading add '-' before its ID, to load the plugin add '+' (which is optional). For example, following settings would switch user registration off, while adding a new plugin: 'your-plugin':...

Possible values: default|custom:NN

The property allows you to fine-tune the SM plugins (processors) thread pool. With the default settings every plugin gets his own thread pool. This guarantees the best performance and optimal resource usage. The downside of this setting is that packets can arrive out of order if they are processed within a different thread pools.
If you really need or want to preserve the order for packets processed by different plugins then the solution is to use the 'custom' thread pool. In such a case packets processed by all plugins are handled within a single thread pool. This guarantees that the packets are processed and delivered in the exact order they arrive. The number after the colon ':' specifies the thread pool size.
What about fine-tuning then? Yes, there is an option to fine tune this even further. Let's say you want most of the plugins to be executed within a single thread pool to preserve packet ordering for them, but some, selected plugins can/should execute within...

Possible values: location of SSL certificates directory on the filesystem

The option allows you to specify location where SSL certificates are stored. Meaning of this property depends on the SSL container class implementation. By default it just points to the directory where the server SSL certificates are stored in files in PEM format.

Possible values: a class implementing tigase.io.SSLContectContainerIfc

The property allows you to specify a class implementing storage for SSL/TLS certificates. The class presented in the example to this description allows for loading certificates from PEM files which is a common storage used on many systems.

Possible values: DNS domain name

The property allows you to specify a default alias/domain name for certificate. It is mostly used to load certificate for unknown domain name during SSL negotiation. Unlike in TLS protocol, where the domain name is known at the handshaking time, for SSL domain name is not known, therefore, the server does not know which certificate to use. Specifying domain name in this property allows you to use certificate for specific domain in such case. This property value is also sometimes used if there is no certificate for one of virtual domains and the container does not automatically generate a self-signed certificate, then it can use the default one.

Possible values: SIZE-NUM,INTERVAL_NUM

The Tigase XMPP Server can store server statistics internally for a given period of time. This allows you to connect to a running system and collect all the server metrics along with historic data which are stored on the server.

This is very useful when something happens on your production system you can connect and see when exactly this happened and what other metrics looked around this time.

Possible values: simple|libidn|empty

The property sets the stringprep processor for all JIDs handled by the Tigase server. The default 'simple' implementation uses regular expressions to parse and check the user JID. It does not fulfils the RFC-3920 requirements but also puts much less stress on the server CPU, hence impact on the performance is very low.
Other possible values are:
'libidn' - provides full stringprep processing exactly as described in the RFC-3920. It requires lots of CPU power and significantly impacts performance.
'empty' - doesn't do anything to JIDs. JIDs are accepted in the form they are received. No impact on the performance and doesn't use any CPU. Suitable for use in automated systems where JIDs are generated by some algorithm, hence there is no way incorrect JIDs may enter the system.

Possible values: true|false|empty-string

This property sets the server for a test mode, which means that all loggings are turned off, message offline storage is off and possibly some other changes to the system configuration are being made.
The idea behind this mode is to test the Tigase XMPP Server with minimal performance impact from environment such as hard drive, database and others...

Possible values: name of class implementing tigase.conf.ConfigRepositoryIfc

This property is a parameter which allows loading different configuration storage engines. The default one stores configuration in memory only. Other possible are: tigase.conf.ConfigXMLRepository which keeps configuration in the old XML file and tigase.conf.ConfigSQLRepository which stores configuration in SQL database. Please note, in all cases the init.properties file can still be read and works the same way - provides an initial settings for the Tigase startup time.

Possible values: DB connection URI string

This property is a parameter which allows to provide database connection string for configuration storage engines which keep server settings in database.

Possible values: true|false

Workaround for TLS/SSL bug in new JDK7 using native library for keys generation and connection encryption used with new version of nss library.
This caused number of problems with Tigase installed on system with JDK7 and the new library, such as hanging connections, or broken SSL/TLS. There was a short information on our wiki page. Our earlier suggestion was to avoid using either JDK7 or the problematic native library. Now we have a proper fix/workaround which allows you to run Tigase with JDK7.

• http://stackoverflow.com/q/10687200/427545
• http://bugs.sun.com/bugdatabase/view_bug.do;jsessionid=b509d9cb5d8164d90e6731f5fc44?bug_id=6928796

Possible values: comma separated list of user bare JIDs

The property allows to specify a list of accounts which are considered as trusted, thus can perform some specific actions on the server. They can execute some commands, send a broadcast message, set MOTD and so on. The configuration is similar to '--adimins' setting.

Possible values: UserRepository implementation class name or predefined string

The property allows to specify UserRepository implementation - a storage where all users' data are located. Users' data include contact list (roster), privacy lists, vCards, and similar. Everything except user authentication information. The implementation can be defined by one of possible values: mysql, pgsql, xml or the class name. For SQL database this is normally: tigase.db.jdbc.JDBCRepository.

Possible values: Database connection URI

The property specify database connection string - 'connection-uri', where 'connection-uri' is a full resource uri for user repository data source. If you skip this parameter default value is used depending on database type you selected:

• jdbc:mysql://localhost/tigase?user=root&password=mypass
• jdbc:postgresql://localhost/tigase?user=tigase
• user-repository.xml

Possible values: Name of class implementing UserRepository

The property allows specify an implementation for per-domain UserRepository implementation. This is used only if the implementation provided by a default Tigase server package is not sufficient in the particular deployment. The implementation provides a DB (UserRepository to be more specific) connection pool where each connection (UserRepository) handles data for a different DNS domain (VHost). This allows for database (user data) sharding to improve the system performance and better balance the load.

Possible values: Name of class implementing UserRepository

The property allows to specify an implementation for the repository connection pool. This is used only if the implementation provided by a default Tigase server package is not sufficient in the particular deployment. The implementation provides a DB (UserRepository to be more specific) connection pool to improve the data access performance. The repository pool can offer data caching for improved performance or any other features necessary.

Possible values: Number of db connections as integer

The property allows to set the database connections pool size for the UserRepository.

Possible values: true|false

The property specifies whether anonymous user login is allowed for the installation for all vhosts.

Possible values: integer number

The property specifies how many user accounts can be registered on the installations for all vhosts.
0 - zero means unlimited and this is a default. Otherwise greater than zero value specifies accounts number limit.

Possible values: valid JID

This is a global property for message forwarding for the installation. This property is normally specified on the vhost configuration level, however if you want to forward all messages on your installation and you have many virtual domains this property allows to set message forwarding for all of them. A valid JID must be specified as the forwarding destination. Also a message forwarding plugin must be loaded and activated on the installation for the message forwarding to work.

Possible values: valid JID

This is a global property for presence forwarding function for the installation. All user status presences will be forwarded to given XMPP address which can be a component or any other XMPP entity. If the destination entity is a bot connected via c2s connection it probably should be addressed via full JID (with resource part) or the standard XMPP presence processing would refuse to deliver presences from users who are not in the contact list.

Possible values: true|false

This is a global property which allows you to switch on/off user registration on the installation. Setting this property to false does not disable registration plugin on the server. You can enable registration for selected domains in the domain configuration settings.

Possible values: true|false

The property is a global settings to switch on/off TLS required mode on the Tigase installation. Setting this property to false does not turn TLS off. The TLS is still available on the server but as an option and this is the client's decision whether to use encryption or not. If the property is set to true the server will not allow for user authentication or sending any other user data before TLS handshaking is completed.

Possible values: comma separated list of domains

The property allows to set a list of virtual domains served by the installation. This is just a list of virtual domains loaded at the startup time. Domains can be added, removed, disabled or updated at runtime. All the actual domain metadata are stored in the database. Some metadata for vhosts can be also provided in the init.properties configuration file using this property. Domain is separated with ':' from its metadata. For boolean values '-' in front of the parameter means the feature is off. '+' or nothing means it is on. If a parameter requires some additional settings it is provided in form: param=val
Here is an example:

--virt-hosts=domain1:-anon:register:-tls-required:s2s-secret=s2spasswd:\
  domain-filter=LOCAL:max-users=1000,domain2,domain3

Possible values: --gen-config-def|--gen-config-all|--gen-config-sm|--gen-config-cs|--gen-config-comp

Probably the only such a property not starting with double hyphen. It sets the server type and determines what components are included in the generated XML file. Possible values are listed below:

• '--gen-config-all' - creating configuration file with all available components. That is: session manager, client-to-server connection manager, server-to-server connection manager, one external component connection manager, stanza sender and stanza receiver.
• '--gen-config-def' - creating default configuration file. That is configuration which is most likely needed for a typical installation. Components included in configuration are: session manager, client-to-server connection manager and server-to-server connection manager.
• '--gen-config-sm' - creating configuration for instance with session manager and external component only. This is useful for distributed installation where you want to have session...