Wildfire.xml, system property settings, SSL

Frank_Seesink · July 21, 2006, 8:53pm

SETUP

Windows XP SP2 with all updates through 21 July 2006
Sun Java JDK/JRE v1.5.0_07
Wildfire v3.0.1

This is half a question, half a comment.

SHORT VERSION

I guess wildfire.xml cannot be used to set any and all system properties that you’'d like; you MUST use the web admin console to set some of them, most notably the system properties explained in the SSL Guide.

LONG VERSION

I am currently testing Wildfire 3.0.1 for possible deployment and I want to understand it as best I can and know what I’'m getting into with respect to updating the software, etc. As part of this process, I was trying to see just how easily I could configure things such that doing a clean build would go quickly/smoothly. Part of that process involves the keystore/truststore files as I intend to run a tight ship with encrypted connections. Now with a clean install, the process seems to be something along the lines of the following (assuming you use LDAP for user authentication):

Install Wildfire.
Launch Wildfire, then bring up admin console.
Define basic properties like domain name, ports to use for admin, database (external/embedded), and admin email and password. At this point you have basic functional IM server which is using its own, self-signed cert.
Using LDAP Guide, modify .\conf\wildfire.xml for LDAP authentication, and test as needed.
Follow SSL guide, which involves CLI steps that modify the keystore and truststore files in .\resources\security, including changing the default ‘‘changeit’’ password. Build a self-signed cert. (or import a CA one if that’'s your choice) for your domain.
Log into web admin console and add system properties, most notably xmpp.socket.ssl.keypass and xmpp.socket.ssl.trustpass, as these must match the passwords you changed in the keystore and truststore files, respectively.
Restart Wildfire.

Now mind you, all this has gone quite smoothly so far. I have basic LDAP authentication working. (I’'m not going to worry about using LDAP groups, etc., until a later date). I created my own self-signed cert. and that works just fine as well.

But let’'s say Wildfire 3.0.2 is released, or the time comes to move our installation to a new box or the HD in the current server dies. What is the minimal amount of information I need to backup/restore to get the same config back online.

Now with other XMPP servers, notably jabberd2 and ejabberd, I’'ve figured out what files I need and how to get back online ASAP with minimal fuss. So when I read the following header in the wildfire.xml file:

I assumed that when Wildfire launched, it first read in the wildfire.xml config and adjusted itself accordingly. This would let me do the following to bring a clean build of Wildfire online:

Install Wildfire.
Drop wildfire.xml, keystore, and truststore in place.
Launch Wildfire.

However, I found out that this doesn’'t work. It seems that you cannot simply define any system properties you want in wildfire.xml and expect them to get loaded in, as when I tried using this technique, the error messages I received indicated that Wildfire was still using the default ‘‘changeit’’ passwords, when I had clearly defined new ones in wildfire.xml.

Anyway, not sure if this is by design or a glitch, but thought I should mention it. At this point, to do as I’‘d like, I’'ll have to go into the admin console and manually add in those system properties from the SSL guide in order to get SSL working again.

This is not a major issue, but thought it would be nice if I could drop a copy of Wildfire down, throw down a few files (config file and necessary SSL keys), and voila! Working server.

LG1 · July 21, 2006, 9:37pm

Hi,

most system properties start with “xmpp.” while the wildfire.xml contains just a “jive.” section. So “jive.xmpp.” may not be the same as “xmpp.”, anyhow I should look in the code to make sure that this is like I assume that it is.

These are really just a few things which are stored in the database as you are using LDAP - other admins will loose all users and rosters if they drop and recreate the database, so most admins don’'t think like you.

LG

Frank_Seesink · July 21, 2006, 11:11pm

Well, that’‘s exactly my point. If your setup involves using LDAP for authentication and an external DB for storage of all other useful information (e.g., MySQL), then setting up Wildfire should be quite simple, since all the heavy lifting is done elsewhere. For example, you’‘re running an Active Directory (AD) server on box1, have MySQL being served from box2, and Wildfire is installed on box3. If box3 gets hosed, it would be nice if setting up Wildfire WAS this simple; throw down a few config files and you’'re done. There is no loss, as stored messages are over on box2 in MySQL (and I guess I see your point since the config is there, too, I guess), your user accounts are over on box1 in AD, and all you really want to do is rebuild box3, throw down a clean copy of Wildfire with just the config files needed to get it to hook back into your setup. Hence looking at the possibility of pre-setting the SSL settings in the wildfire.xml file vs. HAVING to use the admin console to get that done.

And as for most settings being xmpp.* and the wildfire.xml config having a root element of as a container to hold any and all settings. But again, it was just a hope on my part not to have to jump through hoops to rebuild a server. (Sorry, I’'m just used to some other implementations having simple config files, be it Apache or jabberd1, so was looking to see if it was possible to doing things similarly.)

And yes, I happen to be testing with the embedded database, so likely the best thing I can do is make sure to back up that dir. as well, since the settings are stored there it seems. But as for losing data, if you turn off store-and-forward messaging (i.e., only allowing IMs between currently online users, as Google Talk currently does), other than the basic settings, what do you lose by NOT having the DB?

Anyway, I think I’‘ve got a handle on what I need to do. I think I just mistook the header in the wildfire.xml file to mean that you could pre-set ANY system properties in the file and have them loaded in at startup. My bad. And if that WAS an accurate understanding, then I was trying to report that it wasn’'t the case.