I've had Tigase-5.2.0 installed since about 2013-07-27. However, since I retired I haven't needed it operationally, and I haven't been running it. A need for an XMPP server may reappear in another project, and so it's time to upgrade to the current version.
While I was using it, Tigase was vey functional and reliable. I'm not tempted to switch to a different server. However, five years of advances in Java and supporting libraries have left the old version in a questionable state both as to security and backward compatibility.
The Tigase organization has mutated with what looks like a more corporate
business model. Custom extensions and paid support are available, which
supports maintenance of the FOSS infrastructure. The server is licensed under
AGPL (which means that your custom plugins also have to be AGPL), but you can
also purchase a commercial license that allows non-open-source plugins.
There is a new Tigase project
family website. The relevant projects for me are the Tigase XMPP Server and
Tigase MUC (Multi User Chat, XEP-0045).
Product hype for the current version, from the (useful)
product page for
XMPP Server:
Tigase XMPP Server documentation. Click on the release number (I'm
picking Past experience shows that it's best to download the JAR file of the
needed objects.
Minimum requirements: Java Development Kit v8 or later. They recommend
Oracle JDK; OpenJDK They recommend that you use the GUI installer. Look for the JAR file.
It's in
the Tigase file download directory.
Download it and run it (as root). I wanted to do the installation as my
xmpp user, but there are too many tangles, and instead I will fix permissions
later, particularly on the Derby database.
Configuration pages in the installer: Credits, etc. Read them and hit Next. Agree to the GPL.
Action list: Default is to install (i.e. unpack the jar file)
and to configure. After a botched configuration you can configure
again without installing.
Installation path (base directory): /usr/local/Tigase .
A variable is used below: TIGASE_HOME=/usr/local/Tigase .
They install in a versioned directory by defauilt. For root it is
in /usr/local, whereas for the xmpp user it's in ~xmpp/lib (and I
change it back to /usr/local/Tigase).
I create that
directory by hand (owned by the xmpp user) with a symlink to it from
/usr/local/Tigase.
During installation I erase the version. There aren't supposed to be
any absolute paths in the generated configuration files, but if there
were, the symbolic link would take care of switching to the then-current
versioned directory.
Package selection: Base, Unix Files, Docs, Extras, Derby,
PostgreSQL. Deselected MySQL, Microsoft SQL Server and MongoDB; also
OSGi, HTTP API (Rest), and Sources are available but left unselected.
OSGi is for reconfiguring without a restart. Total space predicted:
187Mb. After installation the actual space is 202Mb.
What's the deal with Basic Configuration: Type=Default; domain=jfcarter.net (see below),
server admin: admin@jfcarter.net; admin password = current administrator
password (got to remember to change it), database=PostgreSQL.
Gotcha, I first tried Derby, but see
complaints below about user creation, so I'm changing to PostgreSQL.
What they call the Advanced Configuration (check the box in Basic Configuration):
Optional components active: MUC, PubSub, Socks5, Message Archive.
Declined (by default): STUN, HTTP API. Cluster mode is on by default
even if you have only one machine. ACS extensions are off, though.
Debug log from the base server, not plugins, database, or cluster.
Later you will want to turn this off.
I actually changed nothing here (per their recommendation).
Database Configuration (Derby): Database Configuration (PostgreSQL): For the additional parameters MySQL seems to want
useUnicode=true&characterEncoding=UTF-8 and one user copied this
to his connect string for PostgreSQL, but I have no evidence that
PostgreSQL actually needs (or recognizes) this.
Review the configuration that will end up in ./etc/init.properties .
If you made a mistake you can either hit the Previous button enough
times, or edit it on this page (textarea). I appended
&autoCreateUser=true (ampersand separated key=value pairs)
to --usr-db-uri.
Unfortunately it botches connecting to the PostgreSQL database
engine as the postgres user, and the database is not created. The
reported error is Plugins active: All except Zlib stream compression.
Additional steps after installation and configuration: Gotcha: the admin guide calls the Tigase database user
What they don't tell you: to create the tigase user role and the
database itself, you need to be a superuser (postgres). The easiest
way is: In my setup -h localhost was essential to get the
correct authentication mechanism, and the database name was essential
because the default is the database named after the -U user.
Hashed passwords: By default, Tigase stores user passwords in plain
text in the database, which is a security hazard if the Black Hats
break into your server. Admin Guide section 7.3 (I think) tells how to
get them hashed. The For me, all users on the host system (that excludes
admin) are authenticated by LDAP and are authorized to use XMPP, so
their passwords are not in tigasedb, and it saves a lot of hassle in
client setup if autoCreateUser=true. And only those users can get
through my firewall to even attempt to connect to Tigase. On the other
hand, if I ever allow a foreign user to use my server, he will need his
password in tigasedb (better be hashed), and I will need to authorize
him explicitly. But that's next month's can of worms.
If in your logs you see In my system users are authenticated with LDAP and all users with a
host account are authorized to use XMPP. See Sect. 6.3.4 LDAP
Authentication; insert these parameters in ./etc/init.properties :
Sect. 6.3.5 Configuration of SASL EXTERNAL: For the moment I'm just
testing this. The client can authenticate by an X.509 certificate.
This is optional (unless you set it as mandatory) and other
authentication mechanisms can let the client on. Per RFC 3920 and RFC
6120, the cert must include a SAN of type otherName with an OID of
They recommend providing SRV records for both the client to server
and server to server ports. Even if you don't expect to talk to alien
servers, some clients look for both records. And I might need
federation in an upcoming project. The SRV records (under
jfcarter.net) would be:
Move the log files to someplace reasonable. Make sure it's
writeable by the xmpp user and/or group.
TLS certificates: They describe procedures for installing certs.
Basically, for each domain (virtual host) that you serve, you need a
chain file in ./certs/$DOMAIN.pem which contains (in this recommended
order) a private key, the corresponding certificate, the issuer's
intermediate certs (if any), and the trust anchor. The certificate
should have a SAN for the domain. Multiple or wildcard SANs are OK.
Tigase is supposed to be flexible in the component order, but I didn't
tempt fate in that aspect.
Frequently you will have one chain file and the $DOMAIN.pem objects
will be symbolic links to this file. Typically the chain file is
installed elseware, like in /etc/ssl/private. Make sure that the
xmpp user (the user that Tigase runs as) has permission to read the
chain file and to traverse containing directories like
/etc/ssl/private. I have a group If TLS is needed and there is no chain file, Tigase will create a
lameass self-signed certificate, which the client will not trust.
You should replace it with a correct chain file.
Gotcha: you need to use the correct trust anchor. See
this forum post for details. OpenSuSE has three copies of the
Mozilla collection of trust anchors: The Trusted Uses and Alias attributes are poison to this version
of Tigase, and you should include in your chain file either the
Mozilla original or the one in the /pem/ directory.
./etc/init.properties has --debug=server by default, and this
produces diarrhea of the log file. After initial testing, comment this
out (with a # sign). Don't delete it; turn it back on if you get
into trouble and/or have to send logs to the forum.
Start it up: cd $TIGASE_HOME ; su xmpp -c ./scripts/tigase.sh start
I have a systemd unit file which does the equivalent.
Snoop in /var/log/tigase/tigase.log.0 and/or tigase-console.log
Test it by using a XMPP client to connect to the admin account.
Issues noticed when turning on the server for the first time (after fixing
the various schemas): SimpleCache. In tigase-console.log a lot of properties are printed out at the
WARNING priority, but they seem to be informational, not actual error
messages.
When error-free it took 12 secs to open the c2s port 5222, whereas
when there were various kinds of errors it took typically 60 secs.
The plugin for starttls is loaded after the c2s port is
opened, leaving a race condition in which the client might assume that
TLS is unavailable and might connect without it.
Remember to turn off In the various uproar while setting up the server, I trashed the
administrator's password. How to change the administrator's password in
Tigase: Connect to PostgreSQL as the Tigase user. On my net the defaults
are unhelpful and you need to give -h localhost to get the right
authentication mechanism (you don't get on via a socket), and you need
to give the database because the default is named after the -U user.
Check the password-encoding currently being used. If it's not
as intended you should fix it first. See the
instructions in the documentation.
Inspect the current password value. If the user always
authenticates by LDAP (or other means), the password will be NULL
(shows as an empty field).
Did you get zero rows, in which case the admin account does not
exist? If so, create it like this (and inspect again afterward):
If it did exist, set the password of the administrator (described
in that doc page).
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).
The next step is to run the GUI installer (or a command line installer
is also available). Make sure that the Here are notes
on the installation process. Some uninteresting screens are not described.
Verify that you have both the Java Runtime Environment (JRE) and
Java Development Toolkit (JDK) installed, at least version 1.6 (we
have 1.7 from SuSE). The JDK path is usually autodetected; if it
isn't, you may not have it installed. For OpenSuSE the package
java-1_7_0-openjdk contains just the JRE (despite the name);
the JDK is in java-1_7_0-openjdk-devel.
For a new installation it's recommended to both install and
configure the server.
The default installation path for UNIX is
/usr/local/Tigase-${VERSION}. I accepted this default. Later I moved
it to a directory that fits my backup scheme better and made a
symlink to it as /usr/local/Tigase.
What sub-packages do you want? By default, all but source code is
turned on. I suppressed drivers for MySQL, PostgreSQL and Microsoft
SQL Server, leaving Derby Database. Docs were kept (16.9Mb, oink). I
hope I have the tools to read them. Eventual total size: 44Mb.
In 5.2.0, total size is 33Mb.
Are we going to set up shortcuts? This probably means .desktop
files in the desktop environment's list of applications. This is
useless since root never runs a desktop environment. Suppressed.
The Advanced options (showing only the ones that were changed):
PubSub is like multicast for XMPP. Various publishers send
messages to named channels, and subscribers designate channels whose
messages they want to receive. By being creative about the channel
namespace, the app developer can make this surprisingly flexible.
Examples given were an RSS-like service where the names are search
terms with source restrictions, and a social geolocation service where
names represent people and places. This looks interesting but is not
useful for my operation.
Plugins: by default everything is turned on except compression
(experimental in Tigase), and I left it that way. The plugin list
makes interesting reading: Where should the Derby database store files? The default is
./tigasedb under the install directory. I changed to
/var/lib/tigase. The program will create it for you. The user-db-uri
ends up as jdbc:derby:/var/lib/tigase.
If you select Final check of server configuration. It still has --admins =
admin@jfcarter.net. Later I will give myself admin privileges and
change the admin password.
Post install actions happen on the next screen. Give it some time;
it probably has to compile all the bytecode before it can do anything.
Despite my hacking it claims to have finished all steps.
Installation is finished. They have given you an uninstall script
in ${INSTDIR}/Uninstaller. The main configuration file is in
${INSTDIR}/etc/tigase.conf and there are several other conf-type files
in this directory. Apparently Tigase always refers to config files by
a relative path from ${INSTDIR}, e.g. to start it they say to do (cd
${INSTDIR}; ./scripts/tigase.sh start etc/tigase.conf).
The last screen has a button to generate an automatic installation
script. Presumably this is for cloning the configuration. I did not
press it.
There is a LSB-type startup script for Red Hat in
${INSTDIR}/scripts/redhat/init.d/tigase . It will not be happy on
the OpenSuSE system; I have made my own using this as a base, in
/etc/init.d/tigase. It depends on these symbolic links: 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:
I made symlinks from the indicated files to /var/log/tigase/(name), taking
derby.log to mean it's in /usr/local/Tigase/.
To set up TLS, you need these items: You need the tigase-extras package and the TLS plugin (we have).
A certificate chain file in PEM format containing
the host cert, the private key, and the CA certs up to the root cert.
The chain file for Apache wants the key first and the root cert is
optional. This means you will need separate chain files for the two
servers; but a change is promised so Tigase can work with an Apache
chain file. Update: in version 5.2.0 the key may come first, then
the host cert, then the intermediate cert(s) and the trust anchor.
I did not experiment to find if the trust anchor really can be omitted,
though the client will never believe in it. The 5.1.5 order is also
acceptable, i.e. the host cert, then the key, and the intermediate
cert(s) and trust anchor.
Copy this PEM file to ${INSTDIR}/certs/${HOST}.pem. (Will a
symlink be satisfactory? Apparently so.) Stop the server, remove
./etc/tigase.xml, and restart the server. It will rebuild tigase.xml
taking the cert(s) into account. (tigase.xml appears to no longer be
generated, don't have to remove it.)
I made symlinks in ./certs to the chain files for
jfcarter.net, jacinth.jfcarter.net and jacinth.cft.ca.us.
As with Openfire, there is a Java keystore in ./certs whose
permissions are 644 and whose password is hardwired in the code and
is widely known. Tigase has succesfully used the external
(/etc/ssl) certs and has never written anything into this keystore.
Good riddance.
I edited ./etc/init.properties making these changes: Added some comments and re-ordered it more logically.
--virt-hosts = jfcarter.net (established during setup, but it's
promised to be able to add (and configure?) vhosts at runtime)
--vhost-anonymous-enabled = false (no anonymous logins/sessions)
--vhost-tls-required = false (this is the default, but when
debugging is finished I should turn this on)
--ssl-def-cert-domain = jfcarter.net (for SSL connections;
with TLS it will tell the server which host cert it wants to see)
Somewhere it must be possible to configure SASL or LDAP auth.
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
Testing TLS: This is the test command line:
s_client hangs with high CPU usage. tigase.log.0 shows that it
seems to accept the connection and shut it down when I kill s_client,
with no error messages. Same behavior with jacinth.cft.ca.us.
Since it's listening to 5223, let's try that minus -starttls.
Same behavior except no high CPU usage.
In a forum post someone says
that s_client messes up the SSL/TLS negotiation (something to do with
single versus double quotes) and fails to connect to some but not all
XMPP servers. Evidently including Tigase.
Testing with Pidgin. On 5222 it did starttls, and tigase sent
over a self-signed cert for jfcarter.net (which was generated at
the time of this connection by Pidgin, confirmed in log). The server
then closed the connection, probably because the user is not
registered.
More Pidgin with admin@jacinth.jfcarter.net. Now it says host
unknown. I think this is the server's error message to the client.
I changed the domain (--virt-hosts) to the hostname,
jacinth.jfcarter.net. Now s_client can connect and attempt starttls,
but the server did not send any certificate.
It wants ./certs/jacinth.jfcarter.net.pem to be the name of the
certificate chain file.
Even with the correct cert chain file, s_client on port 5222
receives no certificate after starttls, and on 5223 it hangs forever.
No errors in the logs.
I changed the domain and all related hosts to jacinth.cft.ca.us,
including the cert chain file. s_client is back to high CPU usage
on port 5222, and hangs on 5223. No error messages in the logs.
Tidbit from a forum post dated 2012-06-25: if the client uses SSL
(vs. TLS), you need to call the cert chain file default.pem (because
there is no requested hostname). This is for 5.1.0beta7. I thought
that's what the --ssl-def-cert-domain key is for (in 5.1.5).
Also you
can set component properties as e.g. --c2s/5222/port_type=plain
I tried creating default.pem. No change in behavior.
Other people seem to be able to get this to work; it's not a
generic problem with Tigase.
Testing with Pidgin. [This is with 5.1.5.] I told it to register
admin@jacinth.cft.ca.us. It claimed that registration was successful.
And I can connect. I also connected from another host. Confirmed with
tcpdump that TLS was in use with the expected certs. The remote host
connected using IPv6.
However, the
server attempts a S2S connection (to where?) and announces (to the
remote sender) It then sent a packet from admin/jacinth of type=error with the
reported content. It found the session and wrote the packet to the
session's socket.
In 5.2.0, the clients connect by IPv6 and can do normal activities.
I edited the client account records to use the IPv4 address
explicitly as the connect server (5.1.5 only; 5.2.0 works with IPv6).
A certificate override was required, after which both clients
connected. (In 5.2.0 I installed the certificate right the first
time so the override was not necessary.)
And the chat session succeeds.
Issues for next time: I moved the install directory to become /m1/Tigase-5.1.5-b3164 and
made a symbolic link /usr/local/Tigase to that directory. INSTDIR
was changed to use the link wherever occurring.
I hacked my LSB startup script to run Tigase as a non-root user
xmpp:xmpp. Its home directory is /var/lib/xmpp. The /var/lib/tigase
directory was renamed to become /var/lib/xmpp and was re-owned, mode
640 or 750.
Move the logs to /var/log/tigase . It needs
a symlink from /usr/local/Tigase/logs to /var/log/tigase and the
log dir and content needs to be owned by xmpp:xmpp. The PID file
remains in the log directory. The derby database writes derby.log
in the current directory (${INSTDIR}). I changed its ownership also
and moved it to /var/log/tigase with a symlink.
Log rotation. Find out what we need to do to make Tigase use the
new log file(s).
The debug output is rather extensive. But valuable for
troubleshooting. When Tigase is working, turn this off.
Find out why systemctl failed to stop Tigase -- maybe because it
was not used to start Tigase? Enable for auto startup.
Experiment, see if the order of the cert and key is relevant.
Beware, the chain files in /etc/ssl/private do not include the root
cert and the docs say it's wanted. For Apache it's optional.
Find out how to configure SASL auth, specifically GSSAPI, using
saslauthd. Configure LDAP auth.
Get it to give admin privilege to the admin user.
My next goal was to revert my domain to jfcarter.net -- the step where
I got locked out of the admin account on Openfire. If the client is talking to domain jfcarter.net, it will ask the
server for a cert for that domain, not the name by which it contacted
the server. This seems bogus, but that's what Pidgin does (and
probably everyone else). That bypasses the issue of multi-homed, DHCP
and cluster hosts, by not referring to the server hostname at all.
Let's try to come up with a cert for jfcarter.net.
Reviewing the procedure on Startcom: I put the key and cert in /etc/ssl/{private,hostcerts} using a
naming scheme so I can keep track of which is which, and I made
symlinks jfcarter.{key,crt} to these objects. I also assembled the
certificate chain file (mode 640 root:hostcert) with (in order) the
cert, the key, Startcom's intermediate CA cert, and their root CA cert.
And a symlink jfcarter.pem-ck to this as well. Note, the user
executing Tigase must be in group hostcert to read the chain file,
and you need to restart Tigase after adding the user to the group.
In ${INSTDIR}/certs I made a symbolic link:
Documentation says you can add (and remove?) certs while the
server is running, but this didn't work and I had to restart Tigase,
but it is likely that the problem was that the process was not in
the hostcerts group and could not read the chain file.
This done, I could use a XMPP client (Pidgin) to connect without
security warnings to the server, create the admin@jfcarter.net user
account, log in on a different machine as admin@jfcarter.net (using a
different resource), and have a chat session.
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:
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
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.
Per the
Admin Guide, Server Configuration 5.x, add this line to init.properties:
What this has to do with SASL is not clear.
Dealing with the problem where a client can authenticate but his session
is I received a response from Artur Hefczyc, one of the Tigase developers.
You need to append this to the --user-db-uri:
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.
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
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.
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: Must be multi-protocol, doing XMPP and MSN. We don't use other
protocols.
Must be able to connect to the Tigase XMPP server using TLS.
Must serve the core functions of presence and chat.
We aren't picky about fancy features and a glitzy UI.
Only free clients for Linux will be considered. Browser-based
clients are not going to be considered (yet).
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. Ayttm --
Last release is Ayttm-0.6.3 (2010-07-10), so not much developer
attention. Protocols: Yahoo, MSN, Jabber, IRC, AIM, ICQ.
Nonetheless looks good in a cursory examination.
Coccinella --
Main feature is a shared whiteboard. I think it doesn't serve
our purpose, though it's interesting in other contexts.
emesene --
Supports MSN and XMPP, but as of 2013-03-19 MSN servers got
reorganized and this functionality is now dead in Emesene.
Empathy --
The default chat client for Gnome. Uses the Telepathy library and
the Gossip UI.
Can do video chat. Uses GnuTLS (is this good or bad?) It's in the
main SuSE distro. I installed it and its numerous dependencies.
If run from a SSH session (no Gnome infrastructure) it gets a
segfault. If run from a XFCE session it has lots of warning messages
(such as theme parsing error…) but it runs. It even can import
your accounts from Pidgin. Attempting to connect from a formerly
working client host to the XMPP server, it times out. This is not
useful. Uninstalled.
Gajim --
XMPP protocol only. I've seen it mentioned in forum posts.
Galaxium --
Protocols: MSN, XMPP, IRC. You need version 0.8 or above for XMPP.
This was released 2008-4Q, and no releases after that (not good).
Screenshots look decent.
Gossip --
XMPP only, see Empathy for multi protocol extension.
Instantbird --
Multi-protocol. On a Mozilla chassis. GPL. What's their business
model?
Kopete -- The official chat
client for KDE. The problem is, it's going to drag in all the KDE
infrastructure, which I otherwise don't use and have avoided installing
on my net.
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: Turn on mandatory TLS in the server.
Turn off the server's debug output.
Make sure log rotation is working.
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.
stable snapshot
), then the desired format of each guide
(HTML-Chunk for me).
may work but some features might cause errors.
Installation needs root access.
cd /usr/local
mkdir Tigase-7.1.3-b4482
ln -s Tigase-7.1.3-b4482 Tigase
export JAVA_HOME=/usr/lib64/jvm/java
java -jar /path/to/tigase-server-7.1.3-b4482.jar
Setup Shortcuts
? I don't want lusers
starting this server from the menu system! Deselected.
Existing
Tigase server configuration; these must be defaults
with the local hostname substituted. admin-credentials = admin:tigase,
admins = admin@jacinth, etc. You edit these on subsequent pages.
domain
is the realm appearing in Jabber
IDs, e.g. jfcarter.net if your JID is jimc@jfcarter.net. It is not
the name of the server (unless your JIDs are tied to the server name),
although the default is the 1-component
hostname of the server, which is not too useful. You can give a
comma-separated list of domains, all of which your Tigase instance
will serve. You need a host cert that applies to each one; the realm
should appear as a SAN (wildcards OK), and you could have multiple
certs with one or more SANs each.
authentication failure
. You can authenticate
using the psql program. I put a lot of work into fixing this, but
eventually I had to use the command line tools; see below.
upgrade
the schema version to 7.1
by \i database/postgresql-schema-upgrade-to-7-1.sql . Also see below
for turning on hashed passwords; do that now.
\q to quit.
tigase_user
whereas the default from the installer, which I
did not change, is just tigase
. Change the command lines
to match your Tigase user's name.
su postgres -c psql
and then type in the two create
commands (ending with semicolons). \q to quit. Then load the schemas
as the tigase user, so it will have permission to write on all the
tables and to use the stored procedures. psql -U tigase -h localhost
tigasedb
, give password, and then source the two schema files using
\i (no semicolons). Plus the schema upgrade file. Plus the commands
to turn on hashed passwords.
shortcut
method is sufficient on initial
installation. I used 'MD5-USERID-PASSWORD' as the Tigase hash variant.
But you have to change admin's password; look near the
end for how to use TigUpdatePasswordPlainPw . The examples
are for MySQL and the syntax differs for PostgreSQL: to execute
a procedure called Proc, in MySQL you do
call Proc(arg1,arg2…);
,
whereas in PostgreSQL you do an actual
select Proc(arg1,arg2…);
.
You had better test it using TigUserLoginPlainPw (see the previous
stanza) with both the correct password and a wrong one. Unfortunately
with PostgreSQL the outcomes are not distinguishable, as they are
with MySQL.
SEVERE: exception during reload of
config repository items
, suspect a nonexistent database or botched
initialization of the schema or failure to authenticate the tigase
database role. There are good diagnostics in the logs for the latter
problem.
Creating the user
means to
create XMPP metadata in the database, not to create the user for
the host operating system.
--auth-db = tigase.db.ldap.LdapAuthProvider
%1$s means use the user ID minus domain part from the JabberID.
The DN sought here is from UNIX schemas, particularly RFC 2307bis,
not Windows Active Directory.
--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
id-on-xmppAddr
, see RFC 6120 sect 13.7.1.4. (So how am I going
to get that SAN into the cert?) The cert must be signed by one trust
anchor (yours) (possibly an intermediate cert will be OK) which you
specify in init.properties like this:
c2s/clientCertCA=/etc/ssl/ca/ca-cft.crt
_xmpp-{client,server}._tcp.dom.ain. TTL IN SRV Prty Weight Port Referent
_xmpp-client._tcp 86400 IN SRV 0 5 5222 jfcarter.net.
_xmpp-server._tcp 86400 IN SRV 0 5 5269 jfcarter.net.
mkdir /var/log/tigase
chown xmpp:xmpp /var/log/tigase
rmdir $TIGASE_HOME/logs
ln -s /var/log/tigase $TIGASE_HOME/logs
hostcert
and the relevant
files are readable or traversable by it; and the xmpp user is a member.
Trusted
Uses
and an Alias (copy of the CN) appended
debug=server
in init.properties.
psql -U tigase -h localhost tigasedb
select TigGetDBProperty('password-encoding');
It prints:
tigasedb-> ;
tiggetdbproperty
---------------------
MD5-USERID-PASSWORD
(1 row)
select user_id, user_pw from tig_users where user_id = 'admin@jfcarter.net';
select TigAddUserPlainPw('admin@jfcarter.net','wouldntyouliketoknow');
select TigUpdatePasswordPlainPw('admin@jfcarter.net', 'wouldntyouliketoknow');
------ OLD STUFF ------
Installation
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.
existing
server configuration defines --admins =
admin@jacinth, --virt-hosts = jacinth. I'm changing these as follows:
resource
appended to the user's loginID)
Separate Authentication Database
it gives
you a screen for this. I picked Your Custom
as the (second)
database type, but in the next screen it showed --auth-db=Type Your Class
Here. So I went back and tried Tigase Custom
. Maybe it will work.
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)
Setting Up TLS
SessionManager.addPlugin() WARNING: No implementation found for
plugin id: basic-filter
openssl s_client -connect jacinth.jfcarter.net:5222 -CApath /etc/ssl/certs -starttls xmpp
systemctl stop tigase
does not stop Tigase, what's going
on? systemctl start tigase
does start it.
Message delivery to admin/iris failed: S2S -
destination host not found (Code 404)
. The log file says it
checked routes to everywhere and could not find a route by which to
deliver the packet. It tried to open a connection to (maybe)
jacinth.cft.ca.us and could not find such a remote host.
Cleaning Up TLS Configuration
(umask 077; openssl req -new -newkey rsa:2048 -out /etc/ssl/hostcerts/h-jfcarter-startcom-2014.csr -keyout /etc/ssl/private/h-jfcarter-startcom-2014.key -nodes)
ln -s /etc/ssl/private/jfcarter.pem-ck jfcarter.net.pem
Host Integrated Authentication
--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
%1$s
is replaced with the local part (minus domain) of the Jabber ID.
Tidbit: SASL External (X.509 Authentication)
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).
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.
--user-db-uri = jdbc:derby:/var/lib/tigase;autoCreateUser=true
Fly in the Ointment: Client Can't Connect
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.
Picking a New IM Client
Pidgin Reprieve: Making It Work