powered by Jive Software

Openfire 3.3.0 rpm and openfired

I found some errors in openfired located in bin/extras.

  1. There is no openfire.sh so I had to replace “openfire.sh” with “openfire” notice I removed the “.sh”

  2. The command line that actually started openfire was missing the word “start” in the command so instead of

su -s /bin/sh -c “$OPENFIRE_CMD” $OPENFIRE_USER > nohup.out 2>&1 &

I had to add the word start next to OPENFIRE_CMD.

su -s /bin/sh -c “$OPENFIRE_CMD start” $OPENFIRE_USER > nohup.out 2>&1 &

  1. I had to add the following inside the “stop” function since it was missing the command line to actually stop opefired

su -s /bin/sh -c “$OPENFIRE_CMD stop” $OPENFIRE_USER > nohup.out 2>&1 &

RETVAL=$?

openfired /status didn’'t work after reboot.

I just commented everything under status() and put the following

su -s /bin/sh -c “$OPENFIRE_CMD status” $OPENFIRE_USER

Thank you. I was about to post this as well.

It looks like there still hasn’'t been time to address the rpm installation issues previously reported.

Given that the upgrade from 3.2.4 to 3.3.0 involved replacing alot of files anyway, it’'s hard to say if the overwrite/clobber issue with the conf/<$PROG>.xml file and the JKS keystore and truststore files is still a problem, but this exact same problem with the start file being referenced as .sh as opposed to just openfire (or in the past wildfire) has been reported before.

On the up side, it does seem that the wildfireHome variable that seemed broken in past releases isn’‘t popping up anymore. But something as small as a typo in the start scripts doesn’'t seem to be something that ought to be this persistent.

If additional help is needed with supporting the RPM install methods, please let me know. I’'ll gladly assist.

Yeah for what it’‘s worth, I have taken on improving the rpm. That said I haven’‘t had time to finish working out all of the details. My goal/hope is to have it worked out for 3.3.1. I would be interested in some input though: Currently, I’‘m focusing on something that will work with all flavors of Redhat dists (rhel, fedora, centos, etc) or dists compatible with Redhat dists. That said, I’‘m trying to avoid tapping into things like the ‘‘functions’’ that are used by many of the init files so enhance compatibility. Either way, I’‘m generally curious to hear thoughts on this. I’'m also planning on forging both a “bundled jre” and “no bundled jre” version.

Is there any performance changes if using a bundled JRE than using a non bundled?

No performance changes that I’‘m aware of, but it is easier for some folk apparently. (I just hit up sun’‘s site, download the rpm they have there, and install it, but apparently that’‘s considered a pain so I’‘m going to offer a bundled as well. It’'s more or less trivial to do both, and at the end of the day I often see that done. (click here for bundled, and here for non-bundled)

As far as the openfired script. I say just make it as simple as possible.

if a user does /etc/rc.d/init.d/openfired start

just have it run $openfire_path start

and so on.

It’‘s not quite that easy. The install4j stuff is what creates that script called openfire (not openfire.sh) and it ties into a library or something that it builds into itself. (or at least as far as I can tell, but the openfire script itself without the .sh is not in svn, it’‘s autogenerated somehow) openfire.sh “just starts” openfire, doesn’‘t have a stop mechanism. So I’‘m trying to work around the logistics of all of that and figure out for sure what parts really are part of install4j and what parts aren’'t. =/

Openfire (tar.gz package) doesnt work for me. i’‘ve tried to edit openfired with papwu changes, i’‘ve tried to edit old wildfired (or maybe even it’‘s an old jive-messengerd), replaced all wild with open. No luck. Doesnt launch. Great… linux version was weak all the time, but now i cant figure out how to fix it. So i’'m back to 3.2.3

i’'m with Arch Linux, my daemons is in /etc/rc.d/

openfire is in /opt/openfire

i’'m adding export JAVA_HOME=/opt/java/jre to the top of wildfired (well, i had to with jive-messengerd 2 years ago, but it wasnt causing any issues with wildfired, and it was working)

this is my wildfired, which is working with Wildfire 3.2.3

#!/bin/sh

export JAVA_HOME=/opt/java/jre

  1. wildfired

  1. chkconfig: 2345 20 80

  2. description: Used to start and stop the wildfire XMPP server

  3. Script used to start wildfire as daemon

  4. The script has currently been tested on Redhat Fedora Core 3,

  5. but should theoretically work on most UNIX like systems

  1. before running this script make sure $WILDFIRE_HOME/bin/wildfire is

  2. executable by the user you want to run wildfire as

  3. (chmod +x $WILDFIRE_HOME/bin/wildfire)

  1. This script should be copied into /etc/init.d and linked into

  2. your default runlevel directory.

  3. You can find your default runlevel directory by typing:

  4. grep default /etc/inittab

  1. Link to the directory like follows

  2. cd /etc/rc.d

  3. ln -s …/init.d/wildfired $90wildfired

  1. Set this to tell this script where wildfire lives

  2. If this is not set the script will look for /opt/wildfire, then /usr/local/wildfire

#export WILDFIRE_HOME=

  1. If there is a different user you would like to run this script as,

  2. change the following line

export WILDFIRE_USER=jive


  1. If a wildfire home variable has not been specified, try to determine it

if ; then

if [ -d “/opt/wildfire” ]; then

WILDFIRE_HOME="/opt/wildfire"

elif [ -d “/usr/local/wildfire” ]; then

WILDFIRE_HOME="/usr/local/wildfire"

else

echo “Could not find Wildfire installation under /opt or /usr/local”

echo “Please specify the Wildfire installation location in environment variable WILDFIRE_HOME”

exit 1

fi

fi

function execCommand() {

OLD_PWD=pwd

cd $WILDFIRE_HOME/bin

CMD="./wildfire $1 >/dev/null"

su -c “$CMD” $WILDFIRE_USER &

cd $OLD_PWD

}

start() {

execCommand “start”

}

stop() {

execCommand “stop”

}

case “$1” in

start)

start

;;

stop)

stop

;;

*)

echo “Usage $0 {start|stop}”

exit 1

esac

exit 0

Yeah for what it’‘s worth, I have taken on improving the rpm. That said I haven’'t had time to finish working out all of >the details. My goal/hope is to have it worked out for 3.3.1

I’'ve run into the same issues this evening. Is there a Jira ticket to track these fixes mentioned above?

There is no jira bug abou this.

Personally I really hate the way wildfire RPM are made. I’‘m using it for about 2 years and there was no upgrade without bugs. It’‘s like it’'s made not to work without manual user intervention…

Other than me modifying the openfired script, my upgrade went well. I followed the upgrade instructions.

I’'m still hopping to see the moment when I run “yum update” or “yum install” it will install/update wildfire/openfire without additional intervention.

There is still work to do about this but the irony is that it’'s far more easy to be done than other tasks. Probably this is why wildfire is not included in major linux distributions.

It wouldn’'t be hard to make an upgrade script that would even download the install, backup the original and do the install. The only issue i would for see is with modifying the startup script if needed.

I am having problems with the startup script. I can run openfire as another user with no problems. I also didn’'t use the default “jive” user, I wanted to use a generic user from my domain “gen_jabber”

I can login as gen_jabber and start openfire with no problems. I made the changes above to my openfired script and it actually starts now but apparently doesn’'t see my conf files or DB since it trys to get me to set it up from scratch.

help please.

using centOS 4.4 and the openfire rpm


sorry, openfire.xml wasn’'t writable by gen_jabber. working fine now.

Message was edited by: jledhead

I am running openfire-3.3.0-1 on 2 different machines and after install I ran /opt/openfire/bin/extra/redhat-postinstall.sh as I usually do but this time the script does not work. It simply ignores me, nothing in syslog, nothing in /opt/openfire/logs/* either. I tried running it as root & jive, didnt seem to matter. I deleted the startup script from /etc/init.d/ and re-ran redhat-postinstall.sh to same results. Running “/opt/openfire/bin/openfire start” works perfectly. Doesnt seem to be permissions. Server runs perfectly once I manually start it. Pain that after a reboot we realize after a few hours go by that no IM’'s coming in, oh, yeah, we need to go start it manually. Also, “chkconfig --list openfired” looks perfect. Any suggestions as to why /etc/init.d/openfired" does not output anything at all. Or how to get it to work? Thanks so much everyone for the great community & great software. Stop this war.

I wonder if this means anything. I just re-read the thread & noticed someone mentioning the “.sh” on the end of the command, so … I did this:

ln -s /opt/openfire/bin/openfire.sh /opt/openfire/bin/openfire

and now I’'m getting something. However, I am not there yet, but just wanted to post to see if helped anyone else, or helped anyone else to help me.

Cheers.

Thanks.

Jason Sjobeck

I worked with Jive to improve their RPM as of Openfire 3.3.1. You shouldn’‘t need (and I think I even removed) the redhat-postinstall script. I can’'t really vouch for 3.3.0. =) I always had problems with the RPM beforehand.

I agree with jadestorm. If this is a fresh install why not just use 3.3.1, if not just upgrade and follow the upgrade instructions step by step.

http://wiki.igniterealtime.org/display/WILDFIRE/Openfire+3.3.0+to+Openfire+3.3.1 +Upgrade+Guide