I am running Redhat Linux and would like to install Openfire Enterprise. I found only the tar.gz file on the Jive website, but then found an RPM, which turned out to not be the Enterprise version.
Through much tinkering, I was able to get the RPM installation workingand configured through the Admin, but then discovered it was not the Enterprise version. So, I tried reinstalling the tar.gz version. I have not been able to get anything to work since.
I have onctacted Jive via chat and phone and finally got a sales person to work with me. A software engineer said that I should not be using the tar.gz version, as it has no Enterprise features (well, why is it called Enterprise I wonder?) and that I needed to get the RPM from Redhat Exchange. That enterered me into a whole new adventure, trying to navigate the Redhat RHX site and find Openfire. It looks like it depends on the server being subscribed to automatic Redhat upgrades and the installation is not a matter of downloading the RPM and installing it.
Can anyone shed some light on this and why it seems to be such a convoluted process?
Why don’t you install the standard RPM and upgrade to the Enterprise version through the web interface once it’s installed? Openfire Enterprise is basically just a plugin for the standard Openfire that provides the extra features.
grin That’s basically what I was suggesting. I might be the software engineering you were referring to. I wasn’t actually aware of an openfire_enterprise.tar.gz until now. (course I don’t really know where it is, where are you seeing it?) Anyway, yes, I was suggesting installing the standard RPM off of igniterealtime.org and installing the enterprise plugin via the admin console. (ie, first you set up openfire, then you, through the admin console, download the enterprise plugin, then you give it your license key under the enterprise tab, and a restart later and you should be good to go) After that, future upgrades via RPM should only require installing the RPM from igniterealtime.org. Your enterprise plugin license key will remain intact. (you will need to upgrade the enterprise plugin though, but the admin console will guide you through that)
Sorry grimsy, I know I’m responding to you, but it’s meant for the original poster.
Thank you for the information. I have pretty much tried everything that has been mentioned. I did have it running at one time, had configured through the admin, had the database set up, but now I get a message that I am unable to connect to port 9090. I tried flusing all the iptables firewall rules, but still I can’t connect.
FYI, the enterprise version in tar.gz is located here: http://www.jivesoftware.com/support/login.jspa. After logging in, you can download it.
Anyways, I found the RPM for the latest version (not Enterprise) and installed it. I can’t connect.
Any suggestions,
Christopher Adams
Hrm. Nothing in the error logs that’s indicating why it can’t start? I would almost recommend copying your important files (openfire.xml and keystores if you have modified them and your enterprise license key) and rpm -ev openfire and rm -rf /opt/openfire and reinstalling the rpm to start fresh. It’s hard to debug whats going on without being able to see it. =/
Thank you for your reply. It appears to start without a hitch.
There doesn’t apear to be anything in the openfire logs of use, such as error.log. Here is what is in the warn.log.
2008.01.23 08:11:58 Can’t reuse /tmp/Jetty_0_0_0_0_9090_webapp____-dnguxu, using /tmp/Jetty_0_0_0_0_9090_webapp____-dnguxu_40133
2008.01.23 08:15:28 Can’t reuse /tmp/Jetty_0_0_0_0_9090_webapp____-dnguxu, using /tmp/Jetty_0_0_0_0_9090_webapp____-dnguxu_3416
2008.01.23 08:19:32 Can’t reuse /tmp/Jetty_0_0_0_0_9090_webapp____-dnguxu, using /tmp/Jetty_0_0_0_0_9090_webapp____-dnguxu_20125
Here is what it shows if I issue a ps command.
daemon 26928 0.1 6.1 214248 31368 pts/2 S 08:19 0:07 /opt/openfire/jre
/bin/java -server -DopenfireHome=/opt/openfire -Dopenfire.lib.dir=/opt/openfire/
lib -classpath /opt/openfire/lib/startup.jar -jar /opt/openfire/lib/startup.jar
I have not applied any license to it. This is the RPM, not Enterprise. I was told to install it, then use the Plugins to upgrade to Enterprise. I have a license that was purchased by one of our partners, but I have not gotten to the point where I can apply it. Since I haven’t even gotten it configured, openfire.xml and any other files have not been modified.
As I previously noted, I had this running at one time, but when it stopped running, I tried other installs, using a tar.gz file, then back to the RPM.
I don’t remember for certain if this is true or not, but if Openfire is in setup mode, it might not answer on any other interface than localhost. (I think that’s actually not true, but it’s something to test =) )
In theory that Jetty error shouldn’t matter.
I’m rather perplexed as to what’s going on. (as I’m sure you are)
What happens if you edit openfire.xml and set to false and restart? Do you at least get the setup screen?
Thank you for your reply.
I’m not sure it you received this information. I added an iptables rule to my firewall and updated it. I couldn’t connect to port 9090. So, I flushed all rules. I still couldn’t connect to port 9090. I am trying to figure out if this is just an application issue or if port 9090 is truly not open, though I don’t know why it would not be without any restrictions.
There is no <setup> in openfire.xml.
Hrm, well that’s a good place to start:
netstat -an | grep 9090
tcp 0 0 :::9090 :::* LISTEN
See if netstat returns that 9090 is open. =)
Well, I have tried scanning for open ports using nmap and netstat and it appears that it is not open. However, I understand from others in the know, that sometimes, if an application is not bound to the port, it will show as closed. I even flushed the firewall rules and then shutdown the iptables service, so everything should be open.
It would seem that, without a firewall, if the application still can’t connect to a port, it has something to do with the application.
Oh I have no doubt that it’s the application. Just need to narrow down what about the application is having issues.
One simple thing to try:
shut down openfire (if it’s running)
chown -R daemon:daemon /opt/openfire
then start it up back up
Just in case it’s as simple as a weird permissions issue.
Another thing to ask… are you using SElinux? (is it enabled?)
Yes, SELinux is what I would be asking for. Log in as root and run
setenforce 0
and you would have Permissive mode, where SELinux shouldn’t cause any havoc (of course, it doesn’t prevent any breach, but let’s keep it silent while testing).
Hey mcepl, do you “understand” SELinux? Would you mind chatting with me about it at some point so I can get a grasp on it?
Not likely. I am running Red Hat Enterprise Linux ES release 3.
You should be able to see SElinux yells and screams in /var/log/messages if it’s enabled. I -think- it was disabled by default in EL3, but I get them all mixed up nowadays. I’m running Centos 4 (effectively EL4) and it was enabled in a “warning” mode by default when I first installed. I think EL5 actually asks you during setup.
Well, I know only one guy who understands SELinux, the rest of us is just trying to survive !http://www.igniterealtime.org/community/images/emoticons/wink.gif!, but yes being a Red Hat I know a tiny little bit and I have access to people who can help me. What’s the problem? What’s you JID (mine is ceplma on the server jabber.cz)?
I see no evidence of SELinux, either in the /var/log/messages or in the directory structure. I would expect to find it in /etc/selinux.
Out of curiousity, what would be the reason for enabling it for testing purposes in this case?
Do you have any ideas for next steps?
I actually tried installing it on another RH server (same version) and it installed fine, I opened up the machine (all ports) and get the same result. Strange… Maybe I should try a Windows install. I wanted to avoid that, but I am pretty much out of ideas. What is strange to me is that I had it running at one time (at least to the point of configuring it through the Administration). I shut it down on a Friday and when I came back after the weekend and started it up, I didn’t have access.
I haven’t knew that you have RHEL3 – there was not SELinux for RHEL3 (which was based on RHL 9, long time before Fedora Core 2 which was the first distro with SELinux).
