Why am I being asked setup info in the GUi again?

Openfire Openfire Support
1

I set up and started running openfire 3.6.4 on a solaris 10 system seeveral months ago. Everything went smoothly and it workes a treat. Its using an internal DB FTR.

Our admin ops types have used the gui interface on port 9090 happily since adding new users - its a small deployment maybe about 100 users.

A few weeks ago the server got rebooted, openfire came back up as expected (startup script) and we have carried on happily.

Now the adin ops have come to me to say they have just tried to add a new user but when they load the admin GUI - same URL as before - they now get the “setup” page!

ie language - server - database - profile and admin setup selections.

the correct information appears to be on each page as if it already knows what the answers should bge (or of course the default matched what I created!) - except for the adminaccount page which if I select it errors

(see bottom)

Now - I could just step through each opage from the start using “continue” on each page… but i am concerned it will blow away all the accounts setup and histories existing etc!

So, has anuyone any idea if tghis is normal, and what will happen if I just tell it “continue” on each page until 9hopefully) it clears and we get back to the expected admin page?

cheers

didds

HTTP ERROR: 500

INTERNAL_SERVER_ERROR

RequestURI=/setup/setup-admin-settings.jsp

Caused by:

java.lang.NullPointerException     at org.jivesoftware.openfire.admin.setup.setup_002dadmin_002dsettings_jsp._jspService(setup_002dadmin_002dsettings_jsp.java:99)     at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)     at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)     at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)     at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093)     at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:118)     at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:52)     at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)     at org.jivesoftware.util.LocaleFilter.doFilter(LocaleFilter.java:66)     at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)     at org.jivesoftware.util.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:42)     at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)     at org.jivesoftware.admin.PluginFilter.doFilter(PluginFilter.java:70)     at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)     at org.jivesoftware.admin.AuthCheckFilter.doFilter(AuthCheckFilter.java:146)     at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)     at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)     at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)     at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)     at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726)     at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)     at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206)     at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)     at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)     at org.mortbay.jetty.Server.handle(Server.java:324)     at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)     at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:829)     at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514)     at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)     at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)     at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)     at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488)

Powered by Jetty://

2

bump…

help! does nobody know what will happen if I click through?

how do I back it up (local DB) so if it carps akll over the existing install/DB I can esasily restore it? Clearly I can;t use a GUI orientated soplution for this!

cheers

didds

3

Just copy the /openfire/embedded-db folder, though going through the setup again shouldn’t harm your existing database. I suspect permissions issue. Check that /conf or better whole /openfire directory has the same user permissions as the one running the startup script.

4

it seems, they opened another openfire folder and started the openfire…as this new openfire folder is not configured against any db it presented the installation screen

please be sure where you first installed your openfire (i.e. into which folder)…and invoke the openfire from that folder…

Its nothing related to DB…you just selected openfire from wrong folder

5

just to check then…

the openfire directory has perms

drwxr-x— 10 daemon daemon 512 Feb 4 2011 openfire/

everything below it is owned daemon:daemon, generally with 755 or 644 perms.

the startup script is

rwxr-xr-x 1 daemon daemon 4040 May 1 2009 /opt/openfire/bin/openfire.sh*

This is started I see in a solaris startup script by root, and the running processes are

$ /usr/ucb/ps -auxwww | grep fire

root 835 0.1 2.2331000176632 ? S Sep 16 489:10 /usr/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 314 0.1 1.3259656101584 ? S Sep 16 57:31 /usr/java/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

so should the startup script in fact just start the process as the user daemon?

cheers

didds

6

Oh - for knight raider… there is no “other” installation of openfire on this server… it hasn’t been moved etc.

or do you mean when the startup script runs /opt/openfire/bin/openfire.sh, it should do so by first cd’ing to

/opt/openfire/bin ?

cheers

didds

7

bump…

8

If you are running on a different Linux/Unix varient, and/or youhave used the .tar.gz ‘installer’,you can start and stop Openfire usingthe bin/openfire script in your Openfire installation:

`# ./openfire
Usage: ./openfire {start|stop}

./openfire start

Starting openfire`

I just want to know how you installed the openfire using RPM or through tar.gz

For Solaris it should be tar.gz

is this how are you starting openfire ?

9

Can’t rememebr how I installed it now to be honest. It was back in Februarty and this issue didn’t occur until very early October, during which time the nadmins including me were able to administer as expected.

It wasn;t until a system reboot and openfire restart that this showed. Nothing has been changed wrt the installation and startup directory etc since Feb.

Anyhow, KR nudged me in the right direction it seems… he got me thinking about permissions. So even thopugh everybody that is an admin and the startup/runtime user are all in the correct groups for the openfire install etc, nevertheless a workld read-execute setting on the entire hierarchy has fixed it. Its a small and very internal use of openfire and it now works.

I don;t understand why, but it works :slight_smile:

cheers

didds