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.
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)
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)
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?
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…
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.
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 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.