powered by Jive Software

Administration Tool

Can someone please help me understand how I cn do two things:

  1. Why is it when I reboot my Linux Server the OpenFire Admin console requires me to re-run the setup.jsp process? This should not occur. I should be able to go directly to the admin console without having to reset everything.

  2. What steps are involved to get the admin console to be visible and useable from a web browser outside of the system it is loaded on?

The admin console is critical for what I do and I need one rectified fast while number 2 is more for convenience.



Hi Texman,

#1, how did you install openfire? My guess is that the user by which openfire runs is unable to write its configuration file to the conf/ folder.

#2, you probably need to add a rule in iptables to allow remote connections. There are different ways to do this depending on which Linux you are on.

Could you clarify your environment some more?


Thanks for responding.

  1. I installed openfire as ‘root’ on the Linux server. It should have the ability to write the conf file information… well, by definition right?

  2. I have the port 5222 open and I can open port 9090 no problem. The issue I have is where is the admin webpage files? I cannot seem to locate them.

I have a RH Enterprise 4.0 server (patches all up-to-date as of Monday), MY SQL (local) database (called openfire). Everything seems to be working except I cannot get back into the admin console without that stupid configuration setup program being called. What else would you like to know about the environment?

Hello texmansru47,

I too had this problem with a Fedora 6 VM machine. I solved it by doing a chown -R : ( being the user openfire is supposed to run as; defined in your /etc/sysconfig/openfire) on the openfire directory. Also I was using an external database (MYSQL) and I think the database configuration in /conf/openfire.xml was misconfigured… I manually changed the settings to point to my mysql database and it worked. That error seems to appear when it can’t write or find the database so it assumes are starting fresh…


Thanks I will try that. I will re-post here shortly to let you all know what I found out.

Thanks again,


The results… NOT GOOD

Here are the contents of the two files that I was going to look at reported:




  1. Set this to the path where openfire lives.

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

  3. /opt/openfire.


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

  2. change the following line.


  1. If you wish to change the location of the openfire pid file,

  2. change the following line.


  1. If you wish to explictly specific the location of the log directory,

  2. you can set it here. Note that this applies to the logs generated outside

  3. openfire itself. If you want to change the location of openfire’s own

  4. logs, see the system property ‘log.directory’. If this is not set,

  5. it will default to $OPENFIRE_HOME/logs.


  1. If you wish to override the auto-detected JAVA_HOME variable, uncomment

  2. and change the following line.





<?xml version=“1.0” encoding=“UTF-8”?>


This file stores bootstrap properties needed by Openfire.

Property names must be in the format: “prop.name.is.blah=value”

That will be stored as:








Most properties are stored in the Openfire database. A

property viewer and editor is included in the admin console.


<!-- root element, all properties must be under this element -->



<!-- Disable either port by setting the value to -1 -->





<!-- Use this section to define users that will have admin privileges. Below,

you will find two ways to specify which users are admins. Admins will

have access to the admin console (only local users) and may have also access

to other functionalities like ad-hoc commands. -->

<!-- By default, only the user with the username “admin” can login

to the admin console. Alternatively, you can specify a comma-delimitted

list usernames that should be authorized to login to the admin console

by setting the <authorizedUsernames> field below. -->

<!-- <authorizedUsernames></authorizedUsernames> -->

<!-- Comma-delimitted list of bare JIDs. The JIDs may belong to local

or remote users. -->

<!-- <authorizedJIDs></authorizedJIDs> -->



<!-- Network settings. By default, Openfire will bind to all network interfaces.

Alternatively, you can specify a specific network interfaces that the server

will listen on. For example, This setting is generally only useful

on multi-homed servers. -->







<className>org.jivesoftware.database.EmbeddedConnectionProvider</classN ame>




It appears that there is nothing there - but I have 35 users configured and they are working on Spark right now even though I cannot administer the database via the admin console. I’m very confused.

So those files look normal, they just show that you are using all the default settings and when you first setup openfire the embedded database was chosen…

have you tried to view your log files for any errors? The info.log and error.log in /opt/openfire/logs might be reporting some errors…

Is there a difference when logging in to the console via https vs http? http://servername:9090 or https://servername:9091

This maybe dumb of me to ask, but have you tried to restart the openfire service?

Your situation is similar to this thread maybe he can give you a little insight… http://www.igniterealtime.org/community/message/148685#148685



In regards to that thread I sent you the command to check what he is talking about would be “ps aux |grep openfire” and see how many are running… my openfire box has 2 one for root and one for daemon if there are any more than that I would kill them like that thread suggested… Hope that helps!



Thanks for the input. I will be checking out your thread here shortly. Here is what I found. At this point, everything looks correct to me so maybe other eyes can find what I cannot see.


2007.08.17 13:16:15 [org.jivesoftware.openfire.session.OutgoingServerSession.createOutgoingSession( OutgoingServerSession.java:258$

java.net.ConnectException: Connection refused

at java.net.PlainSocketImpl.socketConnect(Native Method)

at java.net.PlainSocketImpl.doConnect(Unknown Source)

at java.net.PlainSocketImpl.connectToAddress(Unknown Source)

at java.net.PlainSocketImpl.connect(Unknown Source)

at java.net.SocksSocketImpl.connect(Unknown Source)

at java.net.Socket.connect(Unknown Source)

at org.jivesoftware.openfire.session.OutgoingServerSession.createOutgoingSession(O utgoingServerSession.java:253)

at org.jivesoftware.openfire.session.OutgoingServerSession.authenticateDomain(Outg oingServerSession.java:142)

at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.sendPa cket(OutgoingSessionPromise.java:199)

at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.run(Ou tgoingSessionPromise.java:184)

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)

Command to see about the openfire running:

root 3456 0.0 0.2 6324 1212 ? S Aug16 0:00 su -s /bin/sh -c /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” daemon

daemon 3581 0.0 9.5 219908 49032 ? Sl Aug16 0:17 /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

root 4623 0.0 11.0 234124 56620 ? Sl Aug16 0:30 /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

root 6686 0.0 0.1 4612 628 pts/3 S+ 15:41 0:00 grep openfire

When I try to run the “setup” in the Secure mode (localhost:9091) I get the following error (same as running it in regular mode):




Caused by:

java.lang.NullPointerException at org.jivesoftware.util.JiveGlobals.deleteXMLProperty(JiveGlobals.java:492)

at org.jivesoftware.openfire.admin.setup.setup_002dprofile_002dsettings_jsp._jspSe rvice(setup_002dprofile_002dsettings_jsp.java:75)

at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1074)

at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:11 8)

at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:52)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1065)

at org.jivesoftware.util.LocaleFilter.doFilter(LocaleFilter.java:65)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1065)

at org.jivesoftware.util.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingF ilter.java:41)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1065)

at org.jivesoftware.admin.PluginFilter.doFilter(PluginFilter.java:69)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1065)

at org.jivesoftware.admin.AuthCheckFilter.doFilter(AuthCheckFilter.java:98)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1065)

at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)

at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185)

at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)

at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689)

at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)

at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollect ion.java:146)

at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)

at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)

at org.mortbay.jetty.Server.handle(Server.java:285)

at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457)

at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:765 )

at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:627)

at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:203)

at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357)

at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:217)

at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)

Powered by Jetty://

I honestly have no clue. All I did was reboot my server (Linux) and this problem arose. It was perfect prior to this.

Try killing this process

root 4623 0.0 11.0 234124 56620 ? Sl Aug16 0:30 /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

then reconnect to the console… if that works check to make sure nothing is calling that process twice on boot. Other than that… I too am clueless:D. I hope that resolves the issue



just because your root doesn’t mean you can write to a file, some files are read-only and can’t be written to unless you change permissions.

other then changing owner have you tried chmod on the files. But your problem sounds exactly like it doesn’t have permissions.

chmod -R 777 /…/…/openfire/conf/

This will make it completly world writable, so if it works then you can go back and change it.

I ran the kill process on that job and it killed the service to the openfire (brought everyone down). I had to restart the service. Here are services running now:

ps aux |grep openfire

root 3456 0.0 0.2 6324 1212 ? S Aug16 0:00 su -s /bin/sh -c /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” daemon

daemon 3581 0.0 9.5 220932 49280 ? Sl Aug16 0:17 /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

root 8386 0.9 9.7 226528 50020 ? Sl 09:23 0:22 /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

root 8473 0.0 0.1 4892 628 pts/3 S+ 10:02 0:00 grep openfire

Should I try to kill job 3581? It has been running since last week.

Ok. I ran the chmod command to the directory in question (/opt/openfire/conf). Should I try the admin console again?


Thanks for the help. I stopped all services, and I tried the startup command I did originally (/opt/openfire/bin/./openfire.sh) and now everything is back to normal. Now I have this thing under control. Thanks for everyone who helped me out.


Sorry for the delay, I was in a meeting… I would definetely kill the other daemon process see if that brings everyone down also… if not, it may be your culprit. Try and log back onto the admin console after killing it, if successful reboot and run the ps aux |grep openfire and see if it comes back…

You are welcome, glad things are back to normal!