Valid HTML 4.01 Transitional

Setting Up Tigase

James F. Carter <jimc@math.ucla.edu>, 2013-07-27

The documentation for Tigase promises a very functional server. Let's see if the product meets the hype. The website reports 105k downloads since 2008-08-02, though it's impossible to tell how many sites are actively using it today.

From the Tigase website I downloaded the software. The latest non-beta version (as of 2013-07-27) is 5.1.5 and 5.2.0-beta1 is also available. I downloaded the former. It's not clear whether you should download the exe, jar, tar.gz or zip file; I suspect but do not know that all have the same content. I downloaded tar.gz (13Mb). (Update: better to download the jar file, 12Mb.) It will unpack into ./tigase-server-5.1.5-b3164/ mode 644/755 root:root. A LSB style startup script is provided (for Red Hat). I'm putting it in /usr/local/share, since it is not architecture dependent, plus a symlink of tigase-server to the versioned dirname. 38Mb uncompressed.

Update: I'm trying Tigase again in 2014-06-14, and the current version is 5.2.1 dated 2014-04-07, 18MiB. I downloaded the dist-max.tar.gz variant; they no longer just give you a jar file. This time, I'm un-tarring into /m1 with a symlink from /usr/local/Tigase to the versioned directory. Oops, ./jars/java-server.jar is not the installer (maybe the server itself?) This isn't going to work.

So I'm backing up to 5.2.0 which does have a jar file https://projects.tigase.org/attachments/download/1342/tigase-server-5.2.0-b3447.jar dated 2014-02-13 (25.6Mb).

Installation

The next step is to run the GUI installer (or a command line installer is also available). Make sure that the java interpreter is available, then run this command line: java -jar tigase-server-${VERSION}.jar. I'm going to back out of the tar.gz installation and do it their way.

Here are notes on the installation process. Some uninteresting screens are not described.

Starting up the server for the first time: It starts. It runs for quite a long time but eventually it listens to port 5222. Here are all the ports it is listening to:

Further configuration: Edit ./etc/init.properties, remove ./etc/tigase.xml, stop and restart the server. Finding no tigase.xml it will rebuild it from init.properties. (tigase.xml appears to no longer be generated, don't have to remove it.)

Format of init.properties:

The log files are going into ${INSTDIR}/logs. This should be symlinked to /var/log/tigase and a /etc/logrotate.d file should be installed. Log files have an extension of .log or log.0 making rotation easier. A lock file and the PID file are also here. The default configuration turns on server debugging, which is prolix and should be turned off for production.

Update: Tigase itself rotates the log file when it reaches about 1Mb in size, which happens in less than a day with debug logging turned on. How many old files does it keep? Don't know yet.

Nightmare starting up Tigase -- it will start up and do a lot of service even though it can't open certain files. (What are they for?) Affected files:

Mon Jun 16 17:03:17 PDT 2014 Thread[main,5,main] java.io.FileNotFoundException: derby.log (Permission denied)
2014-06-16 17:03:51.031 [main] ConfigurationCache.store() WARNING: Cannot dump server configuration.
java.io.FileNotFoundException: etc/config-dump.properties (Permission denied)

I made symlinks from the indicated files to /var/log/tigase/(name), taking derby.log to mean it's in /usr/local/Tigase/.

Setting Up TLS

To set up TLS, you need these items:

I edited ./etc/init.properties making these changes:

Starting it up after making these changes. It did start and is listening on 5222. It did not write on the Java keystore. The only error message was SessionManager.addPlugin() WARNING: No implementation found for plugin id: basic-filter

Testing TLS:

Cleaning Up TLS Configuration

Issues for next time:

My next goal was to revert my domain to jfcarter.net -- the step where I got locked out of the admin account on Openfire.

Host Integrated Authentication

My ideal is to do single sign-on through Kerberos (GSSAPI), but there is no sign that Tigase can do Kerberos or interact with saslauthd. A less preferred but feasible option is LDAP authentication. See the admin guide page for the LDAP authentication connector. You just have to put in init.properties:

--auth-db = tigase.db.ldap.LdapAuthProvider
--auth-db-uri = ldap://localhost:389
basic-conf/auth-repo-params/user-dn-pattern = uid=%1$s,ou=people,dc=cft,dc=ca,dc=us

The first line turns on LDAP authentication. The second gives the URL of the LDAP server. The docs don't mention multiple servers. TLS is not needed, so it's OK to use localhost if you have a server on the same machine as Tigase. The third line gives the Distinguished Name of the user record, where %1$s is replaced with the local part (minus domain) of the Jabber ID.

This works, and any user known to LDAP can authenticate and can use the XMPP service. Remember that XMPP has no permission (or programming) to write on LDAP so as to introduce a new user.

Tidbit: SASL External (X.509 Authentication)

Per the Admin Guide, Server Configuration 5.x, add this line to init.properties:

c2s/clientCertCA=/path/to/cacert.pem
Specifying a Certificate Authority cert with which client certificates were signed. The client cert needs a SAN of type otherName containing an OID of "id-on-xmppAddr", whose content is a JabberID (user@domain). See XEP-0178 and RFC 6120 (sect. 13.7.1.4).

What this has to do with SASL is not clear.

Dealing with the problem where a client can authenticate but his session is not authorized yet so he cannot receive his roster, vCard, etc., i.e. he cannot see the presence of other people and cannot become a buddy.

I received a response from Artur Hefczyc, one of the Tigase developers. You need to append this to the --user-db-uri:

--user-db-uri = jdbc:derby:/var/lib/tigase;autoCreateUser=true

Then if a user gets authenticated which is not in the user database, it will be inserted. Now it works, and the new user can participate properly.

To set up your vCard, select Accounts, then hover over the account to be set up. In the sub-menu, pick Set User Info. The resulting form has all the defined text fields for a vCard (and I think you can upload a photo also). The vCard lives on the server and is individual per account. Not every protocol supports user info, but XMPP does.

Fly in the Ointment: Client Can't Connect

A big fly in the ointment: Of two Android clients and six Intel boxes running OpenSuSE 12.3 (up to date on patches, same versions of everything), two of the SuSE clients (one each i586 and x86_64) cannot connect. This is with pidgin-2.10.7.

The affected machines send starttls and the server responds proceed, the client sends a big binary packet which the server acks, and everyone just sits there. The big binary packet does not include the XMPP domain name, which the other clients send at that point in a smaller packet. The failing (linux) clients have the same version of Pidgin and all libraries. All clients are configured identically, i.e. use the SRV record (and all get the correct server) on port 5222 with use TLS wnen available (not old style SSL). I'm starting to suspect that the failing clients are trying to use SSL anyway.

Posted on the Ubuntu issue tracker, OP Mahendra (2011-09-28). He upgraded his OS getting OpenSSL 1.0.0e 6 Sep 2011. (We have openssl-1.0.1e.) wget and curl get aborts when they attempt tlsv1, which can be worked around by forcing tlsv3. A number of other client packages show similar behavior. If the server has openssl-0.9.8k the error is not seen.

In the above bug report, Paul Harvey gives a link about securing SSL in Apache Tomcat which made the problem go away for him. Basically you're suppressing certain ciphers, with the side effect of making TLSv1 impossible and forcing TLSv3. He retains SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA.

Pidgin's license is apparently not compatible with OpenSSL's license, so they use a substitute. TLS support is provided by a plugin found in /usr/lib64/purple-2/ (modify according to your distro and architecture). I have ssl.so ssl-gnutls.so ssl-nss.so. The running Pidgin maps all three of these. (This is on a failing client.) Key libraries for ssl-nss.so are libnss3.so and libssl3.so. For ssl-gnutls.so it is libgnutls.so.28. All these libraries are in /usr/lib64. How does it know which one to use, and how do you influence cipher selection?

libpurple/cipher.c is a generic API for encryption (of the stream? of the content?) and has nothing for choosing the cipher. Digging through the source code and learning how it works: Several of my other other projects are past their due dates due to instant message problems.

Picking a New IM Client

We all like Pidgin's user interface and we aren't happy about learning a new client, but if Pidgin doesn't work, I'm going to fire it and use a different client.

Client requirements:

These clients are listed in xmpp.org's list of client software. It does not distinguish multi-protocol or non-free clients; these have been eliminated by checking the project websites.

Pidgin Reprieve: Making It Work

I have a very strong suspicion that the killer for Empathy was libgnutls28. Suppose I remove it, forcing Pidgin (libpurple) to use libnss3/libssl3? Not a good move; it would remove literally half the packages on the machine, 1024 packages that depend indirectly on libgnutls28. Forget that.

Suppose I remove or sabotage the GnuTLS plugin for libpurple? This is /usr/lib64/purple-2/ssl-gnutls.so . Changed mode to 000: Unbelievable, it worked! And no error messages. Pidgin on the formerly failing machine can connect to Tigase. I've filed an OpenSuSE bug report; here is a local copy of the bug report.

So this has brought the saga of the XMPP instant message server to a successful conclusion. Remaining cleanup items:

Famous last words. Two users log on to Tigase and negotiate buddy status. This works, and they receive presence updates from each other. One logs out. The other sees the gone user, not as offline but as unauthorized -- the buddy status is gone. I don't know what's going on here.