Upgrading from 1.4.3 to 1.?.?
-----------------------------

Some configuration defaults have been changed in the binary.
  xdb_file: keep data in memory for 3600 seconds (previously unlimited)
  xdb_file: limit spool file size to 500000 bytes (new feature)
  pthsock: Authentication timeout 120 seconds (previously unlimited)
  pthsock: Heartbeat every 60 seconds (previously disabled)
  dialback: Legacy s2s connections without identity verification
    are not supported anymore (have been accepted previously)
These defaults should be far more reasonable.
If you use an old config file, you should update the pthsock
settings (<authtime>120</authtime>, <hearbeat>60</heartbeat>). Also,
make sure there is a <resend service="_xmpp-server._tcp">s2s</resend>
entry in the dnsrv section of the config file.

The makefile now has an 'install' target which installs all files
required at runtime to the places specified using the configure script
(the default is to place the server in the /usr/local filesystem tree).
Update your scripts that start the server to reflect the new file
locations and move your old configuration files and the spool directory
to the new location.

In your existing configuration file update the filenames of the shared
objects implementing the services. Check for the following shared
objects in your configuration:
      old name		      new name
	jsm.so			libjabberdsm.so
	xdb_file.so		libjabberdxdbfile.so
	pthsock_client.so	libjabberdpthsock.so
	dnsrv.so		libjabberddnsrv.so
	dialback.so		libjabberddialback.so
Do not forget to update the path to these shared objects!
(The names have changed because we are installing jabberd and do not want
to clash with the file names of other libraries.)

jabberd will not change to its build directory anymore but start running
in the current directory. If you are using relative paths in your
configuration file, change to the right directory before starting jabberd
or use the -H command line option.

The -D command line option now takes an argument to select a class of
debugging messages. The argument is a numerical value interpreted as a
bit field. To get all debugging output (the old behaviour) use '-1' as the
argument of this option.

Optionally, a new hierarchical spool directory structure is supported which
distributes the user's spool files over 256 times 256 directories to speed
up access on some UNIX filesystems that are slow in accessing big
directories (e.g., standard ext2/ext3 without htree support). The structure
has been taken from wpjabber and should be compatible with this server.
jabberd can convert an existing spool directory of the (old) flat format to the
hierarchical format at startup automatically, note that this can take some time.
If you want to convert it back to the flat structure, you can use the following
command:
	cd ${your_spool_directory_root}; \
	for f in * ; do find $f -name "*.xml" -exec mv {} $f \; ; done; \
	rm .hashspool
(Of course replace ${your_spool_directory_root} with the location of your
spool directory structure configured using the <spool/> element in your
server's configuration.)
Default is flat spool directory structure. To enable hierarchical
spools, add the <use_hierarchical_spool/> element to your xdb_file
configuration.


Upgrading from 1.4.2 to 1.4.3
-----------------------------

The default behaviour for c2s now is to only listen on standard/SSL
ports if configured to (<ip...>/<ssl...> tag present in configuration).

Be aware the new mod_auth_crypt module can not run in parallel with
mod_auth_plain and you can not simply replace mod_auth_plain by
mod_auth_crypt in an existing installation. So stick with your mod_auth_*
setup you used in jabberd 1.4.2 if you need plaintext authentification.

Otherwise there should be no issues upgrading from 1.4.2 to 1.4.3.


Upgrading from 1.2 to 1.4
-------------------------

The configuration file format and spool data format have not changed between
1.2 and 1.4.  A 1.4 server should have no issues running in place of 1.2.


Upgrading from 1.0 to 1.4
-------------------------

The upgrade from 1.0 to 1.4 is fairly easy, but not completely straight
forward.  Before we begin I would highly suggest making sure you have a backup
copy of your jserver.xml and jspool directory from your 1.0 setup, you never
can be too safe.  Now that you have that done, you need to decide where your
new spool directory will be.  Ok good, now you need to know the host name that
your Jabber server will be known by, you will have to make a subdirectory in
your spool directory for this host name.  As an example on jabber.org I would
do something like this:

    temas@jabber:/home/jabber/1.4/spool$ mkdir jabber.org

You then need to copy in all of your old jspool files into the new directory
that you created.  The user files are still compatible with 1.4 so you can copy
them directly over.

The next major step is editing the jabber.xml to be like your jserver.xml.
For an in depth look at the configuration file please read the section of the
documentation on it as well as review the sample configurations found in the
configs/ subdirectory.  First you will want to set the host name to the same
value as the subdirectory that you created:

    <host>jabber.org</host>

The next large section is the <jsm/> section.  It contains most of the same
tags as those found in jserver.xml, and should be fairly self explanatory.

Once the jsm setup is complete you need to edit the <xdb/> settings to point
to the correct spool directory, an example as might be done on jabber.org:

    <xdb_file xmlns="jabber:config:xdb_file">
      <spool>/home/jabber/1.4/spool</spool>
    </xdb_file>

It is important to note that this is the directory that contains the
subdirectories for all of the host names, not the actual subdirectory which is
the host name.

Now you should be on the c2s (client to server) service.  This is the default
method for people to enter the server, the only items you may wish to edit
here are the <ip/>, <authtime/>, and <rate/>.  If you wish to play with
karma, I suggest you read the documentation on karma that is included in the
docs/ subdirectory.

Skipping over dnsrv we get to the s2s (server to server) service.  Here you
will want to look at the <legacy/> option, as well as the <ip/> settings for
where you are actually listening.

Once you are done editing your jabber.xml, you should be able to run jabberd
with the new configuration you just made and have it run just like a 1.0
server, completely transparent to your users.
