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 configuration elements have been renamed to , 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 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. , , , , , , and . 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 element in the configuration. See jabber.xml.dist for an updated example. Please have a very careful look at the 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 element of the session manager configuration, but inside the 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 , 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 (120, 60). Also, make sure there is a s2s 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 element inside the 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 element in your server's configuration.) Default is flat spool directory structure. To enable hierarchical spools, add the 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 (/ 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: jabber.org The next large section is the 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 settings to point to the correct spool directory, an example as might be done on jabber.org: /home/jabber/1.4/spool 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 , , and . 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 option, as well as the 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.