Openfire wont bind to eth0 (only loopback) therefor cant access gui

sjobeck · December 27, 2007, 5:41am

There are snippets from our brand new install of centOS 5 & yum updates & openfire isntall, not much else going on, on the box:

/opt/openfire/bin/openfire.sh

ls: /usr/java/j*: No such file or directory

Openfire 3.4.2

Admin console listening at http://127.0.0.1:9090

then if you tail the log, you see:

root@pbx:/opt/openfire/logs $ grep 90 *

info.log:2007.12.27 05:21:10 Admin console listening at http://127.0.0.1:9090

info.log:2007.12.26 21:28:22 Admin console listening at http://127.0.0.1:9090

info.log:2007.12.26 21:28:29 Admin console listening at http://127.0.0.1:9090

info.log:2007.12.26 21:30:41 Admin console listening at http://127.0.0.1:9090

info.log:2007.12.26 21:31:04 Admin console listening at http://127.0.0.1:9090

warn.log:2007.12.26 21:30:41 failed SelectChannelConnector@eth0:9090

The “eth0” was my try in the config’ file to force it to eth0, which it will not do either by name or IP for that interface. No other interfaces are in use on thie Compaq ProLiant.

I confirmed this suspicion with “netstat -an | grep 90” and seeing that it is only binding the loopback interface. If it does not bind to the mchines otherwise working fine interface at 10.x.x.x I am not able to see the web gui & not use it. I cant figure this one out yet. Since it’s a fresh isntall, I jsut removed it, deleted the /opt/openfire/ directory & reinstalled, and same thing. I checked my HOSTS file for sanity & unless I’m missing somehting, it looks fine to me, basically looks like the HOSTS files on our other machines which run other app’s as well as other openfires, and those work fine.

Any tips or advice for me?

Thanks.

Cheers.

Jason

sjobeck · January 9, 2008, 9:12am

Bueller? Bueller? Bueller?

Anyone? Anyone?

Hello?

Echo

sjobeck · January 29, 2008, 3:07am

sorry to be such a pest but I have still not figured this out on this specific server, never seen it before, cant seem to get openfire to bind to eth0 no matter what I try. Would be most appreciative for a pointer. Peace. Jason

Daniel_Henninger · January 30, 2008, 5:56pm

Howdy! First off, what are your selinux settings? Openfire does not behave well when selinux is enabled. (course I don’t know many things that behave well with selinux enabled, I don’t think there’s a lot of expertise in the selinux field at this point) Try disabling selinux altogether. Check out /etc/selinux/config. It should look something like:

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= can take one of these two values:
# targeted - Only targeted network daemons are protected.
# strict - Full SELinux protection.
SELINUXTYPE=targeted

Change SELINUX= to disabled. Try restarting after that. Note that the admin console currently ignores the interface setting you choose. Other things, like the XMPP ports, do not.

sjobeck · January 30, 2008, 6:57pm

Thanks so much for the reply. I am sorry for not updating the post to note that I did check SElinux, and it is off. Thanks again. Any one else have any pointers for me? Please.

Daniel_Henninger · January 30, 2008, 10:52pm

Oh wait a minute, this is pre-setup? I don’t think the setup admin console is willing to bind to anything but localhost. (otherwise anyone on your network, or possibly the world) could come in and set up your openfire instance insecurely or whatever before you got a chance to. When you eventually get it to a point where it’s listening on more than localhost, it’ll read something like:

Admin console listening at:

http://server.example.org:9090

https://server.example.org:9091

In theory, you would fire up a web browser from your server and access it remotely if you needed to do a remote setup. (or use something like links, which actually does work amazingly enough) Now that said, can you get around this? The code itself prevents you from overriding this, I’m sorry to say. If you’re in setup mode, there’s no way to set the bind interface. So you might be able to accomplish this task with some simple iptables rules. Something like… and let me prefix this by saying i’m not -totally- up on my iptables, so you might have to fiddle with this a bit:

/sbin/iptables -t nat -I PREROUTING 1 -p tcp -i eth0 --dport 9090 -j DNAT --to 127.0.0.1:9090

But the concept is, have iptables intercept something coming in on the external interface and redirect them over the loopback.

LG1 · February 2, 2008, 3:48pm

Hi,

do you have a browser on your client and ssh access to your server?

You can use SSH to tunnel 127.0.0.1:9090 on your client (where no Openfire runs and thus this port should no be used) to 127.0.0.1:9090 on your server.

If you want to configure this within Putty make sure to use a recent version which supports SSH forwarding, choose Connection/SSH/Tunnels and specify 9090 as source port and 127.0.0.1:9090 as destination and press “Add” before you login to your server.

If you use ssh as client use the L parameter: “-L 9090:127.0.0.1:9090”.

Navigate then to http://127.0.0.1:9090/ on your client and you should see the setup screen.

LG

Daniel_Henninger · February 2, 2008, 5:58pm

Thank you LG! I completely forgot about that option!

sjobeck · February 2, 2008, 10:52pm

This is indeed a great option & now I wonder why I didnt think of it either since we do a lot of SSH tunneling around here to get at machines when a direct/routed path isnt available. Great suggestion.

But … now I wonder if I have another issue going on here since this isnt working either, and this seems impossible to not work (if that makes sense), it would have to work, is what I mean, but isnt now. So, I dug some more and stumbled on something in the warn.log that makes me wonder if something isnt right. I have installed this a number of times on a number of machines & never seen this before, it ought to bind straight away to the machine’s eth0 without issue & fire up & 2 seconds later youre in the GUI. I am not aware of any security “feature” which prevents access to the GUI after a fresh install. This is (& ought to be) entirely up to the sysadmin, his firewall, his network, etc, to keep from running an unconfigured daemon on his server accessible to all. I can imagine this “feature” but I dont think it is the case. I am successfully running 6 other daemons on this server which have been flawless, and no issues whatsoever with binding to any interface. There is only one interface activated & configured on the machine (eth0). I tried entering “eth0” in to /conf/openfire.xml but it has no effect. The “info.log” does report it is listening on 127.0.0.1:9090 but this is not true when compared against a “netstat -an | grep 90”.

Thank you both (& everyone) very much for your great ideas & help. I hope we are narrowing in on this.

Here is some output from “warn.log” :

2008.02.02 14:27:51 failed SelectChannelConnector@eth0:9090

java.net.SocketException: Unresolved address

at sun.nio.ch.Net.translateToSocketException(Unknown Source)

at sun.nio.ch.Net.translateException(Unknown Source)

at sun.nio.ch.ServerSocketAdaptor.bind(Unknown Source)

at org.mortbay.jetty.nio.SelectChannelConnector.open(SelectChannelConnector.java:2 11)

at org.mortbay.jetty.nio.SelectChannelConnector.doStart(SelectChannelConnector.jav a:309)

at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)

at org.mortbay.jetty.Server.doStart(Server.java:228)

at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)

at org.jivesoftware.openfire.container.AdminConsolePlugin.startup(AdminConsolePlug in.java:134)

at org.jivesoftware.openfire.container.AdminConsolePlugin.initializePlugin(AdminCo nsolePlugin.java:169)

at org.jivesoftware.openfire.container.PluginManager.loadPlugin(PluginManager.java :447)

at org.jivesoftware.openfire.container.PluginManager.access$300(PluginManager.java :46)

at org.jivesoftware.openfire.container.PluginManager$PluginMonitor.run(PluginManag er.java:1013)

at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)

at java.util.concurrent.FutureTask$Sync.innerRunAndReset(Unknown Source)

at java.util.concurrent.FutureTask.runAndReset(Unknown Source)

at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101 (Unknown Source)

at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodi c(Unknown Source)

at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknow n Source)

at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

at java.lang.Thread.run(Unknown Source)

Caused by: java.nio.channels.UnresolvedAddressException

at sun.nio.ch.Net.checkAddress(Unknown Source)

at sun.nio.ch.ServerSocketChannelImpl.bind(Unknown Source)

… 20 more

2008.02.02 14:27:51 failed Server@2f356f