oreilly.comSafari Books Online.Conferences.
Articles Radar Books  

Installing the Jabber Server
Pages: 1, 2, 3, 4

Running make

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

yak:~/jabber-1.4.1$ make

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

Example 3-2. Typical output from make

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
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


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
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'

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 <host/> parameter specifies the Jabber server's hostname. As delivered, the jabber.xmlconfiguration has this set to localhost:

<host><jabberd:cmdline flag="h">localhost</jabberd:cmdline></host>

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 <update/> 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:

<update><jabberd:cmdline flag="h">localhost</jabberd:cmdline></update>

which causes a versioning module, mod_version, in the Jabber Session Manager (JSM), to send a <presence/> 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 <presence/> packet will never reach its intended destination. You can comment it out like this:

<update><jabberd:cmdline flag="h">localhost</jabberd:cmdline></update>

Automatic user directory update

The configuration as delivered contains a directive:


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:


Alternatively, instead of commenting out the <vcard2jud/>, you could comment out the definition of the JUD service in the <browse/> section:

<service type="jud" jid="users.jabber.org" name="Jabber User Directory">

because the mechanism looks in the <browse/> 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 attcodept to contact users.jabber.orgwould be made the first time a user connects.

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

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

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).

Pages: 1, 2, 3, 4

Next Pagearrow

P2P Weblogs

Richard Koman Richard Koman's Weblog
Supreme Court Decides Unanimously Against Grokster
Updating as we go. Supremes have ruled 9-0 in favor of the studios in MGM v Grokster. But does the decision have wider import? Is it a death knell for tech? It's starting to look like the answer is no. (Jun 27, 2005)

> More from O'Reilly Developer Weblogs

More Weblogs
FolderShare remote computer search: better privacy than Google Desktop? [Sid Steward]

Data Condoms: Solutions for Private, Remote Search Indexes [Sid Steward]

Behold! Google the darknet/p2p search engine! [Sid Steward]

Open Source & The Fallacy Of Composition [Spencer Critchley]