Bin/extra/openfired is broken + "Critical Error! The home directory has not been configured"

Openfire Openfire Support
1

Hello,

I had no problem running openfire on Windows.

I tried to install openfire 3.3.3 from openfire_3_3_3.tar.gz on a Debian system.

I executed the bin/extra/openfire-launchd-wrapper.sh and it unpacked the jar.pack files and it seemed to work (did not test). I guess I needed to set execute permission for this file. You’ll need Sun’s Java installed for it to work (check java -version).

I also found bin/extra/openfired, set executable permission (chmod +x), and created the usual link:

ln -s /opt/openfire/bin/extra/openfired /etc/init.d/openfire

I set export OPENFIRE_HOME and the OPENFIRE_USER environment variables in openfired (I added the openfire user by “adduser openfire” command).

The first weird thing is that is tries to call openfire.sh from the bin directory, but it does not exist!

function execCommand() {

OLD_PWD=pwd

cd $OPENFIRE_HOME/bin

CMD="./openfire.sh $1"

su -c “$CMD” $OPENFIRE_USER &

sleep 1 # allows prompt to return

cd $OLD_PWD

}

So I corrected it to to openfire, which exists.

When I try to execute “/etc/init.d/openfire start” it gives the following error in the nohup.out file:

Critical Error! The home directory has not been configured,

which will prevent the application from working correctly.

ERROR 11926 ():

java.io.FileNotFoundException: XML properties file does not exist: openfire.xml

<…>

I deleted nohup.out before I executed “/etc/init.d/openfire start”.

I checked the source what may be the problem. I learned from the source that this openfire home is passed via the “openfireHome” Java system property to the application.

I checked the openfire script and it sets this property with the “-DopenfireHome=$app_home” option.

Before this line I echo $app_home and it is set correctly to “/opt/openfire” (without the quotes, as always).

So it could as well work.

What’s wrong?

2

After a lot of trouble I have solved the problem (I am not a Linux guru, just a programmer, so it took a while - about a whole day). I had to compile the stuff from source and debug it to see what’s the problem.

The solution:

Do not bother with openfire_3_3_3.tar.gz. Some of the jar files are packed, so they appear as .java.pack. I first did not know how I could unpack them, so I simply copied the missing .jar files from the Windows installation. I had some problem unpack them with openfire-launchd-wrapper.sh if I didn’t copy the .jar files previously.

Instead download the rpm file and convert it to .deb package with alien. You have two choices: to either include the scripts (like postinstall, preuninstall) with the --scripts (or -c) option or not.

E.g. execute these as root (cannot use # at the beginning of the lines in this editor as it will be converted to numbering):

apt-get install alien

alien --scripts openfire-3.3.3-1.i386.rpm

(this may take a few minutes)

dpkg -i openfire-3.3.3-2_i386.deb

You can see what the scripts are doing if you open the rpm file with mc (midnight commander) and inside the rpm go to the INFO/SCRIPTS directory. The most important thing - and that’s what caused my problem - is to set the permission on the installation directory after install if you do not add the scripts as root, e.g.:

chown -R daemon:daemon /opt/openfire

But I think it is safe to include the scripts. It will give errors not finding /sbin/chkconfig, which is of course not present on a Debian system (instead see update-rc.d). If you wish I guess you can hack the rpm or the deb file and correct this problem.

So my feedback for openfire developers is:

  • I have quickly checked openfire_3_3_3.tar.gz and found no mention to set the permission in the install guide, neither about how to deal with the .java.pack files.

  • Which (the former one) would be no problem if the software did not print the misleading error message, but instead would print the right error message immediately and not a few stacktraces later.

  • It would be nice to have Debian packages, or at least mention that Debian users can alternatively convert the rpm package with alien, in which case they are much better off than struggling with the .tar.gz file.