.TH jabber.xml 5 "15 Mar 2005" "@VERSION@" "jabberd14 project".SH NAMEjabber.xml \- jabberd daemon configuration file.SH SYNOPSISThe jabber daemon jabberd is configured by an XML configuration file. Bydefault jabberd will read \fI@sysconfdir@/jabber.xml\fR. The \fB-c\fRcommand line option can be used to specify an alternate configuration file..SH "FILE FORMAT"The configuration file has to be a valid XML document preferably in theUTF-8 charset (ASCII is valid subset of UTF-8)..TP.B <jabber/>This is the root element of the configuration file..TP.B <service/>This element is an immediate child element of the <jabber/> root element.It defines a general purpose component in the jabber daemon. The jabber daemonwill route all stanzas to this component that have a domain part in thedestination JID that equals the id attribute or any defined additionaldomains this component is responsible for using the <host/> child element.An implementation or relation to an other process is defined using one of thefollowing child elements: <accept/>, <connect/>, <dynamic/>, <exec/>, <load/>,<null/>. Any child elements in own namespaces are ignored by the corejabberd and can be used by components to store their own configuration..TP.B <xdb/>This element is an immediate child element of the <jabber/> root element.It defines a component in the jabber daemon, that is responsible for XMLdata storage. This components internal address is defined by the idattribute. The <host/> child elements define for which domains this storagecomponent is managing the data. An empty <host/> element defines, that itis responsible for all components. With the <ns/> child element you canlimit the responsibility to XML chunks in a given set of namespaces. Youcan then for example define one storage component that handles rosters andan other that handles offline message storage.An implementation or relation to an other process is defined using on of thefollowing child elements: <accept/>, <connect/>, <dynamic/>, <exec/>, <load/>,<null/>. Any child elements in own namespaces are ignored by the core jabberdand can be used by components to store their own configuration..TP.B <log/>This element is an immediate child element of the <jabber/> root element.It defines a component in the jabber daemon, that acts as a logging sink.This components internal address is defined by the id attribute. The <host/>child elements define for which domains this logging sink is logging messages.An empty <host/> element defines, that it is responsible for all components.With the <logtype/> child element you can select the types of messages, thatare handled by this component.Where to write the logging information is defined with one of the followingchild elements: <file/>, <stderr/>, <stdout/>, <to/>.With the <format/> child element you define the format of the logged message..TP.B <io/>This element is an immediate child element of the <jabber/> root element.In this section of the configuration file you can define different settingsthat are related to the network I/O layer. This includes bandwidth limitations(using the <karma/> element), assigning X.509 certificates to sockets (usingthe <ssl/> element), and to limit access to the server to specific IP addressranges (using the <allow/> and <deny/> elements)..TP.B <pidfile/>This element specifies to which file the server should write its process ID.If this file already exists when the server is started, it will fail. Youhave to remove stale pidfiles before starting the server yourself. If youomit this element, the server will not write nor check any pidfile..TP.B <debug/>This element contains configuration settings controlling the output ofdebugging messages. These settings can be changed at server runtime, theserver will reread them on receiving a SIGHUP signal..TPThe following elements are used inside the <service/>, <xdb/>, and <log/>elements, that are defining components. They are used to provide the jabberdprocess with information where it can find the component's implementation..TP.B <load/>This element can be used inside any component definition. It specifies, thatthe implementation of the component can be found inside a shared object. Anychild element of this element defines a shared object file and a method inthis object. jabberd will load the shared object files which locationsare defined in the cdata elements inside the child elements, the names of theelements are defining the functions that have to be called. An optionalmain attribute in the <load/> element define the main function in a component,that has to be used to initialize it..TP.B <accept/>This element defines, that jabberd will wait for an incoming connection usingthe jabber:component:accept protocol defined in JEP-0114. With this it ispossible to run components in their own process, even on different hostsand connect it to the main jabberd routing process. On the other end of theconnection there can be an instance of jabberd again that uses a sectionwith <connect/> to initiate the connection, but there are libraries in manyprogramming languages available, that implement JEP-0114 as well.Inside this element you have to provide an <ip/> element, that defines theIPv4 or IPv6 address to listen on, a <port/> element that defines on whichport the server will listen for the connection, and a <secret/> element, thatdefines a shared secret to authenticate the other peer..TP.B <connect/>This element is the opposite of the <accept/> element. Jabberd will try toconnect to an implementation of the jabber:component:accept protocol definedin JEP-0114.Inside this element you have to provide an <ip/> element, that defines theIPv4 or IPv6 address where to connect to, a <port/> element, that definesthe destination port, and a <secret/> element, that defines a shared secretto authenticate to the other peer..TP.B <dynamic/>This element defines a directory where components reside. Incoming packets arerouted to the components based on the node or resource part of the JabberID.The files in this directory can be shared objects or executables. This israrely used and badly tested..TP.B <exec/>This element is used to start an external component. Instead of using a TCPsocket to communicate with it, the jabberd process will execute the componentand communicate with it using pipes on stdin and stdout..TP.B <file/>This element can only be used inside a <log/> section. It is used to specifythat log messages should be appended to a text file..TP.B <null/>This element specifies an empty component. Everything that is sent to a JabberIDwith the domain part of this component is silently discarded. It can be usedto drop stanzas directed to entities on the Jabber network, that havedisappeared (e.g. update.jabber.org)..TP.B <stderr/>This element can only be used inside a <log/> section. It is used to specifythat log messages should be written to the standard error output stream..TP.B <stdout/>This element is used to define, that the jabberd process is communicatingwith the process, that is implementing the component. It is the oppositeof <exec/>. A process that is started by <exec/> in an other process canuse <stdout/> to implement the other end of the connecting pipe..TP.B <syslog/>This element can only be used inside a <log/> section. It is used to specifythat log messages should be written to the syslog..TP.B <to/>This element can only be used inside a <log/> section. It is used toreformat log packets as messages and resend them to an entity with thegiven JabberID. The JabberID is given as cdata child element..TP.B <unsubscribe/>This element can only be used inside a <service/> section. It is usedto bounce messages and iq queries and send unsubscribes to presences, thatare received. It is intended to be used as a replacement for transports,that are removed from a server. It will remove the roster items of thistransport from the users' rosters..SH AUTHORJabber Software Foundation