Mikeh: /* jabberd Command-Line Switches */

2006-09-13T19:06:15Z

jabberd Command-Line Switches

←Older revision		Revision as of 19:06, 13 September 2006
Line 444:		Line 444:

	{\|<br>		{\|<br>
-		+	Command-line switches -
-	\|+ Command-line switches -	+
	! Switch !! Relating to !! Description		! Switch !! Relating to !! Description
	\|-		\|-
	\| -c \|\| Alternate configuration \|\| Use this to specify an alternative configuration file if you don't want to use jabber.xml.		\| -c \|\| Alternate configuration \|\| Use this to specify an alternative configuration file if you don't want to use jabber.xml.
	\|-		\|-
-	\| -D \|\| Debugging info \|\| Specifying this switch will cause (a large	+	\| -D \|\| Debugging info \|\| Specifying this switch will cause (a large amount of) debugging information to be sent to STDERR.
-	\| amount of) debugging information to be sent to STDERR.	+
	\|-		\|-
	\| -h \|\| Hostname \|\| The hostname of the Jabber server.		\| -h \|\| Hostname \|\| The hostname of the Jabber server.
Line 457:		Line 455:
	\| -H \|\| Home folder \|\| Used to specify "home" folder or directory.		\| -H \|\| Home folder \|\| Used to specify "home" folder or directory.
	\|-		\|-
-	\| -s \|\| Spool area \|\| The directory where the Jabber server stores data	+	\| -s \|\| Spool area \|\| The directory where the Jabber server stores data via the xdb_file module.
-	\| via the xdb_file module.	+
	\|-		\|-
	\| -v \|\| Show version \|\| Reports Jabber server version and exits.		\| -v \|\| Show version \|\| Reports Jabber server version and exits.

Mikeh: /* jabberd Command-Line Switches */

2006-09-13T19:05:19Z

jabberd Command-Line Switches

←Older revision		Revision as of 19:05, 13 September 2006
Line 443:		Line 443:


-	{\|	+	{\|<br>

	\|+ Command-line switches -		\|+ Command-line switches -
	! Switch !! Relating to !! Description		! Switch !! Relating to !! Description
	\|-		\|-
-	\| -c \|\| Alternate configuration \|\| Use this to specify an alternative	+	\| -c \|\| Alternate configuration \|\| Use this to specify an alternative configuration file if you don't want to use jabber.xml.
-	\| configuration file if you don't want to use jabber.xml.	+
	\|-		\|-
	\| -D \|\| Debugging info \|\| Specifying this switch will cause (a large		\| -D \|\| Debugging info \|\| Specifying this switch will cause (a large

Mikeh at 19:00, 13 September 2006

2006-09-13T19:00:12Z

New page

=Installing the Jabber Server=
 
This chapter explains what you have to do to
obtain, install, configure, and start up a Jabber server of your own
with the minimum of fuss.

It's certainly possible to learn about the Jabber protocols and
technology and develop solutions using someone else's Jabber server, but
for real understanding and control, it's definitely worth setting up one
of your own. By installing and configuring a Jabber server, you will
gain a valuable insight into how it and its components work together.
Understanding how components are controlled and configured allows us to
build Jabber solutions in the context of the "big picture."

Installations of earlier versions (1.0, 1.2) of the Jabber server were
often complex affairs, and while the installation process has become
much more straightforward, some people still shrink back from installing
and configuring their own. This chapter shows how straightforward it is.

If you already have a server set up, you might want to skip this chapter
and go on to Chapter 4, where the configuration and system architecture
are explained in more detail.

Although the Jabber development platform is Linux, the Jabber server
will compile and run on many flavors of Unix, including FreeBSD,
Solaris, AIX, and IRIX.<ref>In fact, the next patch level version of the
Jabber server, 1.4.2, which is available already, has the modifications
necessary for it to be compilable under Mac OS X. </ref> Versions of the
C compiler and make utility from the GNU project (at http://www.gnu.org)
are recommended if you don't already have them installed.

The examples shown in this and other chapters are taken from Linux
platforms (various Slackware and Red Hat distributions with 2.2 and 2.4
kernel versions); consult your local documentation for equivalent
commands on your Unix OS.

The incarnation of the Jabber server at the time of writing is Version
1.4, more specifically 1.4.1. Version 1.4 represents a major advance in
the server code and brings increases in performance and reliability over
earlier versions. Jabber server Version 1.4.1 is the one we will obtain
and install here, and this will be used as the server for the recipes in
the rest of this book.

 
==Downloading the Jabber Server==
 The Jabber server package can be
obtained from the Jabber project site, http://www.jabber.org; the 1.4.1
version is available in the downloads area:

<blockquote>http://download.jabber.org/dists/1.4/final/jabber-1.4.1.tar.
gz

</blockquote>The tarball jabber-1.4.1.tar.gz contains everything that
you need to get a Jabber server up and running.<ref>If you want the
Jabber server to support SSL connections, you will need to have
installed an SSL package; see the next chapter for more details. </ref>
Previous versions of the Jabber server came in multiple packages; it was
necessary to separately obtain and install GNU's portable threads
library (pth) and the asynchronous DNS package (ADNS), as well as
obtaining and installing various Jabber-specific libraries such as
libxode, libjabber, and libetherx. Now some of these libraries and
packages have become obsolete as far as the Jabber server is concerned
(ADNS and libetherx) and others have been combined into the main Jabber
server tarball.

If you don't want to compile the server yourself, you can also download
prebuilt binaries for some of the platforms already mentioned, from
http://download.jabber.org.

 

==Installing the Server==
 Once you have downloaded the Jabber server
tarball, you need to unpack it, configure the build environment, and
compile the server. The general idea is that the Jabber server will be
compiled and run from wherever you decide to unpack it; that is, there
is no separate "install" step.

For this reason, and because it's also often useful to be able to
install and start up a different version of the Jabber server for
testing and comparisons, create a generic jabber directory somewhere
central but local, for example in /usr/local/:

<code>| yak:/usr/local# <tt>mkdir jabber</tt></code>

The Jabber server does not need to be and should not be run as ''root'';
so create a new user ''jabber'' (group ''jabber'') to be used as the
Jabber server administrator and make that user the owner of the generic
Jabber server directory:

<code>| yak:/usr/local# <tt>groupadd jabber</tt> yak:/usr/local#
<tt>useradd -g jabber -d /usr/local/jabber jabber</tt> yak:/usr/local#
<tt>passwd jabber</tt> Changing password for jabber Enter the new
password (minimum of 5, maximum of 127 characters) Please use a
combination of upper and lower case letters and numbers. New password:
<tt>********</tt> Re-enter new password: <tt>********</tt> Password
changed. yak:/usr/local# <tt>chown jabber:jabber jabber</tt>
yak:/usr/local#</code>

Once you've created the generic Jabber server directory, switch to the
new Jabber server administration user ''jabber'', unpack the tarball you
downloaded, and enter the resulting directory:

<code>| yak:/usr/local# <tt>su - jabber</tt> yak:~$ <tt>tar xzf
jabber-1.4.1.tar.gz</tt> yak:~$ <tt>cd jabber-1.4.1/</tt>
yak:~/jabber-1.4.1$</code>

 

===Running the Configure Server ===
 
Examining the contents of the
jabber-1.4.1 directory, we see the following files:

* configure (the configuration script) 
* jabber.xml (the server configuration file) 
* Makefile (for compiling the Jabber server) 
* README (some basic instructions) 
* UPGRADE (information on upgrading from an earlier server version) as well as a number of directories that contain the source code. 

The first step is to run the configure script:

<code>| yak:~/jabber-1.4.1$ <tt>./configure</tt></code>

to determine your platform's compiler settings.

If you want SSL support in the Jabber server, run the script with the
--enable-ssl switch:

<code>| yak:~/jabber-1.4.1$ <tt>./configure --enable-ssl</tt></code>

If you specified the --enable-ssl switch, the configure script looks for
your SSL installation and adds the appropriate compiler flags. If it
doesn't find your SSL installation, it says so and your Jabber server is
compiled ''without'' SSL support.

Next, it will try to determine whether you have pth installed and if so
will use the pth-config command to glean the extra compiler options for
building the Jabber server. pth is required, so if it ''isn't'' already
installed, it will be set up within your current jabber-1.4.1 directory
tree (as pth is included in the jabber-1.4.1.tar.gz tarball) and the
appropriate compiler options added.

If pth is set up during the course of running configure, you may see a
message: "<tt>Now please type 'make' to compile. Good luck.</tt>", which
comes at the end of the pth configure procedure; you can ignore this
because there is only one make step, for the Jabber server, that must be
carried out as we are merely preparing the pth build environment for
binding into the Jabber Server build.

Finally, after extra platform-specific compiler settings are determined,
a shell script to set the build environment variables is created with
the name platform-settings. This is used in the next step.

Example 3-1 shows typical output from the configure script.

''Typical output from configure''

<code>| Running Jabber Configure ========================

Getting pth settings... Done. Setting Build Parameters...
Done. Generating Settings Script... Done.

You may now type 'make' to build your new Jabber system.
</code>

 
===Running make===
 
Once the platform settings have been determined by
the configure script, we are ready to build the Jabber server with make:

<code>| yak:~/jabber-1.4.1$ <tt>make</tt></code>

Example 3-2 shows abbreviated typical output from the make command.

''Typical output from make''

<code>| Making all in pthsock make[1]: Entering directory
`/usr/local/jabber/jabber-1.4.1/pthsock' gcc -g -Wall -fPIC -I. -I..
-I/usr/local/include -I../jabberd/ -c client.c -o client.o gcc -g
-Wall -fPIC -I. -I.. -I/usr/local/include -I../jabberd/ -shared -o
pthsoc k_client.so client.o -L/usr/local/lib -lpth -ldl -lresolv
make[1]: Leaving directory `/usr/local/jabber/jabber-1.4.1/pthsock'
Making all in xdb_file make[1]: Entering directory
`/usr/local/jabber/jabber-1.4.1/xdb_file' gcc -g -Wall -fPIC -I. -I..
-I/usr/local/include -I../jabberd -c xdb_file.c -o xdb_file.o

...

gcc -g -Wall -fPIC -I. -I.. -I/usr/local/include
-DHOME="\"/usr/local/jabber/jab ber-1.4.1\""
-DCONFIGXML="\"jabber.xml\"" -o jabberd config.o mio.o mio_raw.o mi
o_xml.o mio_ssl.o deliver.o heartbeat.o jabberd.o load.o xdb.o mtq.o
static.o lo g.o lib/expat.o lib/genhash.o lib/hashtable.o lib/jid.o
lib/jpacket.o lib/jutil. o lib/karma.o lib/pool.o lib/pproxy.o
lib/rate.o lib/sha.o lib/snprintf.o lib/so cket.o lib/str.o
lib/xmlnode.o lib/xmlparse.o lib/xmlrole.o lib/xmltok.o lib/xst ream.o
lib/xhash.o base/base_connect.o base/base_dynamic.o base/base_exec.o base
/base_stdout.o base/base_accept.o base/base_file.o base/base_format.o
/base/base_
stderr.o base/base_to.o -Wl,--export-dynamic -L/usr/local/lib -lpth -ldl
-lresol v make[2]: Leaving directory
`/usr/local/jabber/jabber-1.4.1/jabberd' make[1]: Leaving directory
`/usr/local/jabber/jabber-1.4.1/jabberd' make[1]: Entering directory
`/usr/local/jabber/jabber-1.4.1' make[1]: Nothing to be done for
`all-local'. make[1]: Leaving directory
`/usr/local/jabber/jabber-1.4.1'</code>

{{Sidebar|Running from the Build Environment?You may be wondering where
the make install step is—there isn't one. The Jabber server is run from
within its build environment. One of the reasons for this is that
additional components, such as transports, which may be installed at any
time after the basic server installation, must be compiled with
reference to various Jabber server header file information. One of the
simplest ways of making this happen is to have the source for those
components unpacked in a subdirectory within the jabber-1.4.1 directory
tree, and at compilation time component-level references to header files
at the Jabber server level can be made using relative directory names
that point back up the directory hierarchy.

}}

 
==Configuring the Jabber Server==
 The nature and behavior of a Jabber
server is controlled by the contents of a configuration file (with a
default name of jabber.xml), which you will find in the jabber-1.4.1
directory. As you can probably guess from the filename's extension, the
configuration is formatted in XML, which offers a very powerful way of
expressing the nature and features of your Jabber server and associated
services and components.

Details on how to navigate, interpret, and edit this configuration file
are given in Chapter 4; here we will just look at the basic settings
that can be modified before you start up the Jabber server.

For an experimental Jabber server (such as for the purposes of this
book), there isn't actually anything you ''need'' to change in the
configuration. The out-of-the-box configuration settings are pretty much
what we need in order to experiment with our recipes later in the book;
nevertheless, let's look at some of the settings you may wish to change
right now:

; Server hostname
: The <tt><host/></tt> parameter specifies the Jabber server's
: hostname. As delivered, the jabber.xml configuration has this set to
: localhost: :
<code>|<host><jabberd:cmdline
flag="h">localhost</jabberd:cmdline></host>
</code>
: You can change this to the name of your server hostname; in the case
: of our examples, this would be yak. : The localhost setting occurs
: elsewhere in the configuration too—as a literal in the welcome message
: that is sent to users after a successful registration with the server.
: You may wish to replace this occurrence of localhost; furthermore, you
: will find other occurrences, but they are within sections of the
: configuration that are commented out in the standard delivered version
: of jabber.xml (specifically, administration JIDs and definitions for
: various add-on agents and transports; we will cover these in the next
: chapter). : One other place that localhost occurs is in the
: <tt><update/></tt> section, which is explained next.
; Server software update notification mechanism
: The Jabber server development team offers a facility for servers to
: check for updated versions of the Jabber server software. The facility
: is addressed with this configuration setting: :
<code>|<update><jabberd:cmdline
flag="h">localhost</jabberd:cmdline></update>
</code>
: which causes a versioning module, mod_version, in the Jabber Session
: Manager (JSM), to send a <tt><presence/></tt> packet (which
: carries the server version—in our case, 1.4.1) from the server to the
: Jabber ID ''jsm@update.jabber.org'' when the Jabber server starts up.
: : If your server is purely internal, and/or behind a firewall, it
: makes no sense to have this facility switched on (you can check for
: updates to the server on the http://www.jabber.org web site) as the
: <tt><presence/></tt> packet will never reach its intended
: destination. You can comment it out like this: :
<code>|
</code>

; Automatic user directory update
: The configuration as delivered contains a directive: :
<code>|<vcard2jud/>
</code>
: which means that any vCard data—a vCard is a virtual "business card"
: containing contact information and so on—that is maintained by a
: Jabber client will be automatically passed on to the central user
: directory (the Jabber User Directory, or JUD), defined elsewhere in
: the jabber.xml as the one at ''jabber.org'', ''users.jabber.org''. :
: If you've commented out the update notification mechanism because
: you're not going to be able to (or want to) reach the servers at
: ''jabber.org'', then you might as well comment this out to avoid error
: messages being sent to Jabber clients when vCard data is modified: :
<code>|
</code>
: Alternatively, instead of commenting out the
: <tt><vcard2jud/></tt>, you could comment out the definition of
: the JUD service in the <tt><browse/></tt> section: :
<code>|
</code>
: because the mechanism looks in the <tt><browse/></tt> section
: for a reference to a JUD service; if there isn't one there, no vCard
: update will be sent.
{{Note|Some Jabber clients such as Jabber Instant Messenger (JIM)
require vCard information to be entered when registering for a new
account, which means that an attempt to contact ''users.jabber.org''
would be made the first time a user connects.

}}
You may have noticed that the values for each of these two settings
(<tt><host/></tt> and <tt><update/></tt>) were wrapped in
another tag:

<code>|<jabberd:cmdline flag="h">...</jabberd:cmdline>
</code>

This means that you can override the setting with a command-line switch
(or "flag"), in this case -h. So, in fact, you don't even need to modify
the jabber.xml configuration at all, if you specify your hostname when
you start the server up (the welcome message will not be changed, of
course).

 

==Starting and Stopping the Jabber Server==
 
At this stage, we have a
Jabber server with enough basic configuration to be able to start it up
and have it do something useful (like accept client connections). If
you're curious about the rest of the configuration you encountered while
editing the jabber.xml file, you can jump to Chapter 4. Otherwise, let's
start it up!

 

===Starting the Server===
 The basic invocation looks like this:

<code>| yak:~/jabber-1.4.1$ <tt>./jabberd/jabberd</tt></code>

but if you haven't bothered to change localhost anywhere in the
configuration (as described earlier), you can use the -h switch to
specify the hostname:

<code>| yak:~/jabber-1.4.1$ <tt>./jabberd/jabberd -h yak</tt></code>

As it stands, there's a directive in the standard jabber.xml
configuration file that specifies that any server error messages are to
be written out to STDERR:

<code>|<log id='elogger'> <host/> <logtype/>
<format>%d: [%t] (%h): %s</format>
<file>error.log</file> <tt><stderr/></tt> </log>
</code>

So either comment the directive out:

<code>|
</code>
Or redirect STDERR to /dev/null:

<code>| yak:~/jabber-1.4.1$ <tt>./jabberd/jabberd -h yak
2>/dev/null</tt></code>

You won't lose the error messages—as you can see they're also written to
the error.log file.

Assuming you wish to free up the terminal session after starting the
server, you can send it to the background:

<code>| yak:~/jabber-1.4.1$ <tt>./jabberd/jabberd -h yak 2>/dev/null
&</tt></code>

 

===Connecting a Client===
 Once the server is started, you're ready to
start up a client and make a connection. The thing to remember at this
point, when specifying which server to connect to, is to use the same
hostname as you specified in the <tt><host/></tt> part of the
configuration, described earlier in Section 3.3.

{{Note|If your client supports the <tt><alias/></tt> mechanism,
described in Section 4.6.3 in Chapter 4, this may not be necessary.

}}

 
===Stopping the Server===
 To stop the server, just kill the processes,
and it will shut down:

<code>| yak:~/jabber-1.4.1$ <tt>killall jabberd</tt></code>

or:

<code>| yak:~/jabber-1.4.1$ <tt>kill `cat jabber.pid`</tt></code>

 
=== jabberd Command-Line Switches ===
 We've seen the -h switch to
specify the host when starting the server up. There are other switches
available on the command line, too; they are listed in Table 3-1.

{|

|+ Command-line switches -
! Switch !! Relating to !! Description
|-
| -c || Alternate configuration || Use this to specify an alternative
| configuration file if you don't want to use jabber.xml.
|-
| -D || Debugging info || Specifying this switch will cause (a large
| amount of) debugging information to be sent to STDERR.
|-
| -h || Hostname || The hostname of the Jabber server.
|-
| -H || Home folder || Used to specify "home" folder or directory.
|-
| -s || Spool area || The directory where the Jabber server stores data
| via the xdb_file module.
|-
| -v || Show version || Reports Jabber server version and exits.
|-
| -V || Show version || Same as -v.
|-
| -Z || Debugging info || Limits the debugging information to certain
| "zones" (comma-separated).<ref>The "zones" are the filenames that
| immediately follow the timestamp in the debug log records, for
| example, xdb_file or deliver. Specifying one or more zones will limit
| debug output to lines that pertain to those zones. </ref>
|}
Starting the Jabber server with any unrecognized switches will cause
it to show you a list of valid switches:

<code>| [yak: ~/jabber-1.4.1]$ <tt>./jabberd/jabberd -badswitch</tt>
Usage: jabberd & Optional Parameters: -c configuration
file -D enable debug output -H location of home
folder -v server version -V server version</code>

Yes, the list that it shows isn't complete. If the common switch -h were
present in the list, we could almost consider the unlisted switches as
undocumented, but it isn't present, so we won't.

 

==Monitoring and Troubleshooting the Server==
 We've already seen a
glimpse of the configuration relating to logging of messages in the
previous section. As standard, the Jabber server configuration describes
two types of logging record and a recipient file for each type:

; Error logging
: Error log records are written to error.log in the current directory,
: as determined thus: :
<code>|<log id='elogger'> <host/> <logtype/>
<format>%d: [%t] (%h): %s</format>
<file><tt>error.log</tt></file> <stderr/> </log>
</code>

; Statistical logging
: Statistical log records used for tracking purposes are written to
: record.log in the current directory, as determined thus: :
<code>|<log id='rlogger'> <host/>
<logtype>record</logtype> <format>%d %h
%s</format> <file><tt>record.log</tt></file>
</log>
</code>
: Log records of this type are written when a client connects to the
: server and when a client disconnects. Furthermore, we can use the
: debugging switch (-D) when we start the server and have debugging and
: trace output written to STDERR.

 
===If Your Server Doesn't Start===
 A number of likely candidates might
have prevented your server from starting.

; Bad XML configuration
: It is not difficult to make errors (typographical or otherwise) in the
: server configuration. The first line of defense is to be careful when
: editing your jabber.xml file. After that, the Jabber server isn't
: going to be too forthcoming with information if you have broken the
: well-formedness of the XML: :
<code>| yak:~/jabber-1.4.1$ <tt>./jabberd/jabberd -h yak</tt>
Configuration parsing using jabber.xml failed</code>
: Help is at hand in the shape of Perl and the <tt>XML::Parser</tt>
: module, which is a wrapper around the XML parser, expat. : Providing
: you have Perl and the <tt>XML::Parser</tt> module installed, you can
: get expat to give you a clue where the XML is broken: :
<code>|yak:~/jabber-1.4.1$ perl -MXML::Parser -e
'XML::Parser->new->parsefile("jabber.xml", ErrorContext => 3)'

not well-formed (invalid token) at line 47, column 35, byte 1750: be on
one line, the server doesn't like it otherwise! :) -->

<host><jabberd:cmdline
flag="h"yak</jabberd:cmdline></host>
==================================^

<!-- This is the custom configuration section for the at
/usr/local/lib/perl5/site_perl/5.6.0/i586-linux/XML/Parser.pm line
185 yak:~/jabber-1.4.1$
</code>
: This shows us exactly where the problem is.<ref>Better highlighting of
: problems in parsing the configuration file is available in Version
: 1.4.2 of the server. You're told where the configuration is broken or
: if there were problems opening the file. </ref> In this case, the
: close-tag symbol (>) had been inadvertently removed when replacing
: localhost with yak.
{{Sidebar|No XML Is Bad XML!If you don't use the -c switch to specify
which configuration file to use, the standard jabber.xml is used. If
that file can't be found, you get ''exactly the same error'' as if your
XML was not well-formed. You've been warned!

}}

; Unable to listen on port(s)
: Taking the standard jabber.xml configuration, the Jabber server tries
: to bind to and listen on two ports: 5222 (for client connections) and
: 5269 (for server-to-server connections). If other processes are
: listening to these ports, then the Jabber server can't start and
: you'll see something like this in the error log: :
<code>| 20010407T12:11:06: [alert] (-internal): io_select unable to
listen on 5222 [(null)] 20010406T12:11:06: [alert] (-internal):
io_select unable to listen on 5269 [(null)]}}
: If this is the case, use the netstat command to check the status of
: the ports: :
<code>| yak:~/jabber-1.4.1$ <tt>netstat -an | grep -E '5222|5269'</tt>
tcp 0 0 0.0.0.0:5269 0.0.0.0:*
LISTEN tcp 0 0 0.0.0.0:5222 0.0.0.0:*
LISTEN</code>
: If you see entries like this, it means that processes have been bound
: to these ports on ''all'' IP addresses.<ref>This "all" relates to the
: <tt>(null)</tt> shown in the unable-to-listen error messages shown
: earlier. </ref> For example, if <tt>0.0.0.0:5222</tt> is being
: listened to then you may have another instance of a Jabber server
: already running. : On some BSD systems, you cannot bind to the
: "default" null address; the same error messages will be issued as if
: the ports were already bound. In the standard jabber.xml configuration
: file, a bind to the null address is specified for each port as
: standard; you must change this and specify an explicit IP address for
: each of the ports in the configuration. That is, instead of: :
<code>|<ip port="5222"/>
</code>
: do something like this: :
<code>|<ip port="5222">127.0.0.1</ip>
</code>

JabChapter 3 - Revision history

KruegerN: insert content template

Mikeh: /* jabberd Command-Line Switches */

Mikeh: /* jabberd Command-Line Switches */

Mikeh: /* jabberd Command-Line Switches */

Mikeh at 19:00, 13 September 2006

←Older revision		Revision as of 10:03, 7 October 2006
Line 1:		Line 1:
-	~~<br>~~	+	{{Content Programming Jabber}}
	=Installing the Jabber Server=		=Installing the Jabber Server=
-	~~<br>~~	+
	This chapter explains what you have to do to		This chapter explains what you have to do to
	obtain, install, configure, and start up a Jabber server of your own		obtain, install, configure, and start up a Jabber server of your own

←Older revision		Revision as of 19:04, 13 September 2006
Line 448:		Line 448:
	! Switch !! Relating to !! Description		! Switch !! Relating to !! Description
	\|-		\|-
-	\| -c \|\| Alternate configuration \|\| Use this to specify an alternative	+	\| -c \|\| Alternate configuration \|\| Use this to specify an alternative
	\| configuration file if you don't want to use jabber.xml.		\| configuration file if you don't want to use jabber.xml.
	\|-		\|-