powered by Jive Software

Wildfire with LDAP authentication on SUSE Linux 10.0

Hi, everyone!

A big thank you to Jive Software for providing Wildfire as free (as in freedom) software - and at no cost too.

I’'ve added a short howto on adding Wildfire with LDAP authentication for users of SUSE Linux 10.0 over at the openSUSE.org wiki. It is based on the excellent tutorial found at this site. Here is the address:

http://www.opensuse.org/Instant_messaging_and_presence_notification.

Feel free to contribute to the wiki if you find the article in error or a bit short.

Wildfire works like charm for us at work, we switched from one day to another - it was that easy.

Cheers,

Haakon

Hello!

I’'ve added a short howto on adding Wildfire with LDAP

authentication for users of SUSE Linux 10.0 over at

the openSUSE.org wiki. It is based on the excellent

tutorial found at this site. Here is the address:

Thanks for this great article.

Just a short question: Why do you start SuSEconfig after the rpm-install ??

IMHO there is one important info missing: How to automatically start Wildfire after bootup. Either via some sort of hand written script or (much better) from within Suse yast.

I do start it manually and hope that the machine does not reboot when I am out of sight!

Bye

Starry

Hi Starry,

I agree, the article needs to address how to automatically start Wildfire after bootup AND start/stop after changes in run level.

I hope to fix it by Monday. Thanks - this was a great suggestion!

Cheers,

Haakon

I forgot to answer your question about why I started SuSEconfig after the rpm install. Novell explains it quite well here:

http://www.novell.com/coolsolutions/trench/15520.html

The gist of it is in the following quote:

"This is because newly installed packages may have included changes to the configuration options in /etc/sysconfig/.

It is important for these changes to be migrated to the proper configuration files. Thus, it is important to run SuSEconfig manually after installing packages manually."

YaST - SUSE’'s GUI configuration tool does this automatically, but if you install/upgrade rpm packages manually, you need to do the same - just to be sure.

I haven’'t really checked if the wildfire rpm does any changes to /etc/sysconfig. Running SuSEconfig is just to be sure.

Cheers,

Haakon

how about adding this line:

/etc/init.d/wildfired start

to your file named:

boot.local

Just a suggestion.

Peace. Love. Linux.

Jason

I hit post too quickly … I just thought of one other idea: how about entering this:

chkconfig wildfired on

on that SuSe server to start it automatically at boot time.

Peace. Love. Linux.

Jason

Hello!

Hmm, did not work out, that way…

proxy:~ # locate wildfired

/opt/wildfire/bin/extra/wildfired

proxy:~ # chkconfig wildfired on

wildfired: unknown service

proxy:~ # chkconfig /opt/wildfire/bin/extra/wildfired on

/opt/wildfire/bin/extra/wildfired: unknown service

proxy:~ #

Hi Starry and Jason!

Thanks for the tip, Jason.

Starry, under /opt/wildfire/bin/extra there are two scripts; redhat-postinstall.sh and wildfired, and you need to run the redhat-script to get what you want. I haven’'t tried it, but it looks OK.

I would like the scripts to LSB compliant and according to the manual from Novell on how to add a new service under /etc/init.d. This is described in the SuSE Linux Reference, pages 418 to 421. Doing it this way, I believe SuSE users will be more at home.

I’'ve created a copy of redhat-postinstall.sh which I called suse-postinstall.sh. I then changed the lines about

  1. Install the init script

cp $WILDFIRE_HOME/bin/extra/wildfired /etc/init.d

/sbin/chkconfig --add wildfired

/sbin/chkconfig wildfired on

to this

  1. Install the init script

cp $WILDFIRE_HOME/bin/extra/wildfire-im /etc/init.d

insserv /etc/init.d/wildfire-im

The effect of running the script is to create a user and a group called jive, move the script wildfire-im to /etc/init.d/, then run insserv to add symlinks in the correct runlevels defined inside wildfire-im.

  1. BEGIN INIT INFO

  2. Provides: wildfire

  3. Required-Start: $remote_fs $syslog

  4. Required-Stop: $remote_fs $syslog

  5. Default-Start: 3 5

  6. Default-Stop: 0 1 2 6

  7. Description: Start wildfire to provide a server for instant messaging and presence notification using XMPP, see http://www.jivesoftware.org/.

  8. END INIT INFO

The rest of the script uses startproc to do the same as wildfired, but I’‘ve run into a small, but annoying problem, which I haven’'t been able to figure out yet - any help would be appreciated. Here is the problem:

When running /etc/init.d/wildfire-im start, it tries to run .install4j from the home directory of user jive. This does not work, as .install4j is in the /opt/wildfire directory. When checking the original wildfired script it changes directory to /opt/wildfire and then executes wildfire start/wildfire stop before returning to the calling directory where the command was issued. Is it required? strace output shows chdir() being called if you run /opt/wildfire/bin/wildfire start directly. Why? Any ideas?

Cheers,

Haakon

Hi, the problem was with the creation of the jive user - no home directory was created so there was no where to write the .install4j. I need to fix the script suse-postinstall.sh to get it right, and some other stuff as well.

That probably sounds correct to me, also, since I do have a directory for my user “jive” at “/home/jive/” and that script located at “/etc/init/d/wildfired” works for me. I can do the very routine SuSe type /etc/init.d/wildifred ‘‘stop’’ or ‘‘start’’ on that thing any time I want. One thing it does not have that it does need to be consistent with all other services, and if youre feeling ambitious, and would like the love and adoration of your colleagues, is a “restart” function for that same script.

I am not positive, but I wonder if that “chkconfig” failed for “starry99” because that script was not in the “/etc/init.d/” directory.

Jason

Hi, I’'ve finally found time to fix the /etc/init.d/skeleton script to start and stop wildfire in runlevel 3 (multi-user, network, no graphics) and runlevel 5 (multi-user, network, graphics)

As /opt/wildfire/bin/wildfire from the RPM is a script which requires the parameter ‘‘start’’ or ‘‘stop’’ - and I didn’‘t want to mess with that script directly - I needed to give startproc a start parameter and replace killproc with startproc to give a stop parameter in a copy of the skeleton script. I’'ll post the entire script in the article over at opensuse.org, but here is how I did it:

case “$1” in

start)

  1. Start daemon with startproc(8). If this fails

  2. the return value is set appropriately by startproc.

/sbin/startproc $WILDFIRE_BIN start

  1. Remember status and be verbose

rc_status -v

;;

stop)

  1. Stop daemon with killproc(8) and if this fails

  2. killproc sets the return value according to LSB.

  3. /sbin/killproc -TERM $WILDFIRE_BIN

  4. NOTE: killproc doesn’'t work for wildfire, as this is a script with nohup inside, and it takes a stop argument to stop.

/sbin/startproc $WILDFIRE_BIN stop

  1. Remember status and be verbose

rc_status -v

;;

As for implementing a restart function, you need to mess with the script /opt/wildfire/bin/wildfire.

However, isn’'t it enough to create a case called restart, then copy the stop and start part - in that order - from the existing script? Finally, you just edit the copy of the skeleton script to call startproc like this:

/sbin/startproc $WILDFIRE_BIN restart

I might have time to look at this later, but not today.

Cheers,

Haakon

Hello, restart now works - create a copy of /opt/wildfire/bin/wildfire called wildfire-new like this

cp /opt/wildfire/bin/wildfire /opt/wildfire/bin/wildfire-new

and add the following restart case (I included to the entire case statement to give some context):

case “$1” in

start)

echo “Starting wildfire”

nohup “$app_java_home/bin/java” -server -Dinstall4j.jvmDir="$app_java_home" -Dinstall4j.appDir="$app_home" -Dexe4j.moduleName="$prg_dir/$prg" $INSTALL4J_ADD_VM_PARAMS -classpath “$local_classpath” com.install4j.runtime.Launcher start org.jivesoftware.wildfire.starter.ServerStarter false false “$prg_dir/…/logs/stderror.log” “$prg_dir/…/logs/stdoutt.log” true true false “” true true 0 0 “” 20 20 “Arial” “0,0,0” 8 500 “version 2.6.1” 20 40 “Arial” “0,0,0” 8 500 -1 -DwildfireHome=$app_home -Dwildfire.lib.dir=$app_home/lib “$@” &

;;

stop)

echo “Shutting down wildfire”

“$app_java_home/bin/java” -server -Dinstall4j.jvmDir="$app_java_home" -Dinstall4j.appDir="$app_home" -Dexe4j.moduleName="$prg_dir/$prg" -classpath “$local_classpath” com.install4j.runtime.Launcher stop

;;

restart)

echo “Restarting wildfire”

“$app_java_home/bin/java” -server -Dinstall4j.jvmDir="$app_java_home" -Dinstall4j.appDir="$app_home" -Dexe4j.moduleName="$prg_dir/$prg" -classpath “$local_classpath” com.install4j.runtime.Launcher stop

nohup “$app_java_home/bin/java” -server -Dinstall4j.jvmDir="$app_java_home" -Dinstall4j.appDir="$app_home" -Dexe4j.moduleName="$prg_dir/$prg" $INSTALL4J_ADD_VM_PARAMS -classpath “$local_classpath” com.install4j.runtime.Launcher start org.jivesoftware.wildfire.starter.ServerStarter false false “$prg_dir/…/logs/stderror.log” “$prg_dir/…/logs/stdoutt.log” true true false “” true true 0 0 “” 20 20 “Arial” “0,0,0” 8 500 “version 2.6.1” 20 40 “Arial” “0,0,0” 8 500 -1 -DwildfireHome=$app_home -Dwildfire.lib.dir=$app_home/lib “$@” &

;;

*)

echo “Usage: $0 {start|stop|restart}”

exit 1

;;