Upgrading from 1.6.0 to 1.6.1
-----------------------------

Version 1.6.1 is mainly just a switch from OpenSSL to GnuTLS as the
TLS implementation. Therefore you now need GnuTLS to be installed on your
system. The TLS layer configuration in the jabber.xml configuration file
has had some small changes, so you might want to check it.

Take care that mod_filter has been removed from your configuration file.
The empty dummy implementation of this module has been removed.


Upgrading from 1.4.4 to 1.6.0
-----------------------------

The example template for handling of jabber:x:offline namespace in
xdb_sql has changed to support Flexible Offline Message Retrieval.
A new field "node VARCHAR(24)" is needed in the database table messages.

When someone is talking about SSL, he normally speaks about the TLS
protocol. SSL is an old protocol defined by Netscape, while TLS is
a newer version of it, standardized by the IETF as RFC 2246.
Nearly nobody still uses real SSL our days, but now uses TLS. To
reflect this fact, the <ssl/> configuration elements have been renamed
to <tls/>, but the old elements are still processed.
Please note, that there is a difference between TLS and STARTTLS.
TLS is (like SSL) just a protocol to encrypt data sent on a network socket,
while STARTTLS is a protocol used to establish a TLS protected connection.

The dialback component (which implements the s2s connection manager) now
supports authenticating peers using SASL EXTERNAL authentication (instead
of the older dialback protocol). SASL EXTERNAL is implemented to
authenticate the peer using X.509 certificates. To enable this feature,
you have to configure jabberd14 to know which certification authorities
you are trusting. This is done using the <cacertfile/> configuration
element. An example is present in the default configuration file.

The following base handlers have been removed from jabberd14: base_exec,
and base_dynamic. These handlers have rarely been used, and this should not
be a problem for you.

Correct handling of namespaces has been introduced to jabberd14. This results
in some modifications, that have to be made in the configuration file.
Elements in there, that are copied to stanzas, that are sent to a stream,
need to have the correct namespace in the configuration. This affects
some of the elements in the session manager configuration. Up to version
1.4.4 of jabberd14, these elements have incorrectly been declared in the
'jabber:config:jsm' namespace. If you do not update these elements in the
configuration file, they will be copied as elements in this namespace
to the stream. While most clients at present would ignore these wrong
namespaces, it still would be incorrect.
Check for the following elements in the jabber.xml configuration file and
update their namespace. For an example see the new jabber.xml.dist.
<jabber/>, <vCard/>, <register/>, <welcome/>, <reply/>, <browse/>, and
<disco/>.
Namespace handling has also affects on xdb_sql. In the node selections
paths in the SQL query definitions, you now have to specify the namespaces
as well using prefixes. Which namespace these prefixes define, has to
be configured using the new <nsprefixes/> element in the configuration.
See jabber.xml.dist for an updated example. Please have a very careful
look at the <delete/> definition for the 'jabber:x:offline' handler, the
SQL for it has changed.

If you are using xdbfiletool to access or manipulate spool files, note
that the command line syntax of this utility has changed completely.

If you used Jabber browsing to get a list of the users, that are online,
you have to update this to using service discovery.

The following functionality has been removed from jabberd14:
mod_filter, and mod_groups. Please remove them from your session manager
configuration.

Access control settings have been changed. They are no longer inside
the <admin/> element of the session manager configuration, but inside
the <global/> section of the configuration file. You have to update
your configuration file, to keep having accounts with admin access.

jabberd14 now checks registration requests, that all data requested in
the configuration file is submitted by the client. This causes problems
with some non XEP-0077-conformant clients. If you want to keep
compatibility with them, configure your server to only request the
<username/>, or offer account registration on your web-site. For
configuration examples see the included jabber.xml.dist file.

If your Jabber server was configured to store user data in a spool
directory (AKA xdb_file), you can easily migrate this data to storing
data in a SQL database if you want. Just reconfigure your jabberd14
server to use the xdb_sql module to handle storage (this is in the
default configuration file now) and import your old spool directory
using the -I command line option of jabberd:
    jabberd -c yourNewConfigFile.xml -I /path/to/var/spool/jabberd
Your jabberd14 server will then import all data from your existing
filespools in /path/to/var/spool/jabberd to the new storage module
configured in your configuration file.
(Note that the path you specify using the -I option should be the
directory containing the directories that are named after your domains,
and should not point to the domain directories directly.)


Upgrading from 1.4.3(.1) to 1.4.4
---------------------------------

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

The mod_auth_0k module has been removed from jabberd. Please remove the
<mod_auth_0k/> element inside the <load/> element for the session manager,
else jabberd will not start.

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.
