3.2.0 to 3.2.2 Upgrade Issue

[Frank2]

I downloaded 3.2.2 and backed up my DB and config files. Running Fedora Core 6 (zod), ran rpm -U wildfire_3.2.2.rpm

THe server appears to be up fine, I can login as well as my users, however, when I try to login to the administration page. I’'m getting this after I authenticate to the box.

HTTP ERROR: 500

INTERNAL_SERVER_ERROR

RequestURI=/index.jsp

Caused by:

java.io.IOException

at org.jivesoftware.wildfire.net.SSLConfig.getKeyStore(SSLConfig.java:155)

at org.jivesoftware.wildfire.admin.index_jsp._jspService(index_jsp.java:291)

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.headerComplete(HttpConnection.j ava:751)

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

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

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

at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:329)

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

Any idea what I am doing wrong here?

[Frank2]

Just as some add on information. I was reading another post about 3.2.0 to 3.2.1 that suggested removing all plugins except for the admin plugin and that was just done. WIth no change to my issue.

Thanks

[LG1]

Hi,

I assume that you are using port 9091 / SSL, maybe the update did break your SSL certificate?

Port 9090 could work fine.

LG

[Frank2]

I don’‘t have ssl enabled on this server. The server itself doesn’'t have permission to get outside the company network.

Here’‘s the config file if someone wants to look at it and see if I’‘ve missed something. Trying to connect via 9090 is what I have been doing in the past and normally works fine. I can get to the login page, and I’'m able to pass my user and password to the page.

]]>

cn

mail

cn

member

description

false

(objectClass=group)

org.jivesoftware.wildfire.ldap.LdapVCardProvider

org.jivesoftware.wildfire.ldap.LdapUserProvider

org.jivesoftware.wildfire.ldap.LdapAuthProvider

org.jivesoftware.wildfire.ldap.LdapGroupProvider

true

[LG1]

Hi,

I can’‘t reproduce this issue as I don’'t have 3.2.x installed, so I wonder if the /index.jsp page does an SSL check and fails. Does /logviewer.jsp or any other page within the admin console work?

LG

[Gaston_Dombiak]

Hey cbtl,

Could you check in your error log for something like SSLConfig startup problem and post the exception? It appears that Wildfire is failing to load the keystore file that should be located in [wildfire home]/resources/security. Either the files does not exist or the user running Wildfire does not have permission to read it.

Regards,

– Gato

[Frank2]

Yes, it seems that any other page but index.jsp works, that and the ssl page being that I don’'t have a cert generated.

Here’‘s the Error log that dombiak asked for, it looks like the exception is there. I’'m going to check the permissions on that directory real quick.

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

2007.02.20 16:32:49 org.jivesoftware.wildfire.session.ClientSession.createSession(ClientSession.java :247)

java.io.IOException

at org.jivesoftware.wildfire.net.SSLConfig.getKeyStore(SSLConfig.java:155)

at org.jivesoftware.wildfire.session.ClientSession.createSession(ClientSession.jav a:244)

at org.jivesoftware.wildfire.net.ClientStanzaHandler.createSession(ClientStanzaHan dler.java:70)

at org.jivesoftware.wildfire.net.StanzaHandler.createSession(StanzaHandler.java:56 6)

at org.jivesoftware.wildfire.net.StanzaHandler.process(StanzaHandler.java:96)

at org.jivesoftware.wildfire.nio.ConnectionHandler.messageReceived(ConnectionHandl er.java:131)

at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived (AbstractIoFilterChain.java:703)

at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:362)

at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:54)

at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:800)

at org.apache.mina.filter.codec.support.SimpleProtocolDecoderOutput.flush(SimplePr otocolDecoderOutput.java:62)

at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecF ilter.java:192)

at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:362)

at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:54)

at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:800)

at org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java :250)

at org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(Execut orFilter.java:305)

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)

2007.02.20 16:32:53 org.jivesoftware.wildfire.handler.IQvCardHandler.handleIQ(IQvCardHandler.java:91 )

java.lang.UnsupportedOperationException: VCard provider is read-only.

at org.jivesoftware.wildfire.vcard.VCardManager.setVCard(VCardManager.java:122)

at org.jivesoftware.wildfire.handler.IQvCardHandler.handleIQ(IQvCardHandler.java:8 2)

at org.jivesoftware.wildfire.handler.IQHandler.process(IQHandler.java:48)

at org.jivesoftware.wildfire.IQRouter.handle(IQRouter.java:300)

at org.jivesoftware.wildfire.IQRouter.route(IQRouter.java:104)

at org.jivesoftware.wildfire.spi.PacketRouterImpl.route(PacketRouterImpl.java:67)

at org.jivesoftware.wildfire.net.StanzaHandler.processIQ(StanzaHandler.java:283)

at org.jivesoftware.wildfire.net.ClientStanzaHandler.processIQ(ClientStanzaHandler .java:79)

at org.jivesoftware.wildfire.net.StanzaHandler.process(StanzaHandler.java:248)

at org.jivesoftware.wildfire.net.StanzaHandler.process(StanzaHandler.java:147)

at org.jivesoftware.wildfire.nio.ConnectionHandler.messageReceived(ConnectionHandl er.java:131)

at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived (AbstractIoFilterChain.java:703)

at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:362)

at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:54)

at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:800)

at org.apache.mina.filter.codec.support.SimpleProtocolDecoderOutput.flush(SimplePr otocolDecoderOutput.java:62)

at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecF ilter.java:192)

at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:362)

at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:54)

at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:800)

at org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java :250)

at org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(Execut orFilter.java:305)

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)

[Frank2]

I checked the permissions for the user that handles the daemon process. It does have read permission to all files and folders from /opt/wildfire up. Not sure what else to do so I shall wait for your advice

[Gaston_Dombiak]

Could you paste the exception next to SSLConfig startup problem? I cannot find it in your previous post. That info may help us figure out what is going on.

Thanks,

– Gato

[Frank2]

That should be it, I’‘ve never had a ssl cert on this box, hence my surprise that a single page isn’'t loading. Thanks

2007.02.20 15:20:37 [org.jivesoftware.wildfire.net.SSLConfig.(SSLConfig.java:81)] SSLConfig startup problem.

storeType: [jks

]

keyStoreLocation: /opt/wildfire//opt/wildfire/resources/security/

keypass:

trustStoreLocation: /opt/wildfire/

trustpass:

java.security.KeyStoreException: jks

not found

at java.security.KeyStore.getInstance(Unknown Source)

at org.jivesoftware.wildfire.net.SSLConfig.(XMPPServer.java:148)

at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)

at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)

at java.lang.reflect.Constructor.newInstance(Unknown Source)

at java.lang.Class.newInstance0(Unknown Source)

at java.lang.Class.newInstance(Unknown Source)

at org.jivesoftware.wildfire.starter.ServerStarter.start(ServerStarter.java:93)

at org.jivesoftware.wildfire.starter.ServerStarter.main(ServerStarter.java:49)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

at java.lang.reflect.Method.invoke(Unknown Source)

at com.exe4j.runtime.LauncherEngine.launch(Unknown Source)

at com.install4j.runtime.Launcher.main(Unknown Source)

Caused by: java.security.NoSuchAlgorithmException: jks

KeyStore not available

at sun.security.jca.GetInstance.getInstance(Unknown Source)

at java.security.Security.getImpl(Unknown Source)

… 23 more

2007.02.20 15:20:38 org.jivesoftware.wildfire.session.ClientSession.createSession(ClientSession.java :247)

[Fritz_Elfert]

cbtl wrote:

That should be it, I’‘ve never had a ssl cert on this box, hence my surprise that a single page isn’'t loading. Thanks

2007.02.20 15:20:37 [org.jivesoftware.wildfire.net.SSLConfig.(SSLConfig.java:81)] SSLConfig startup problem.

storeType: [jks

]

keyStoreLocation: /opt/wildfire//opt/wildfire/resources/security/

keypass:

So in your previous installation you (accidently?) changed the keystore’'s password ant during update, the keystore got overwritten with the default password “changeit”

You can fix it like this:

cd resources/security

…/…/jre/bin/keytool -storepasswd -keystore keystore -storepass changeit

(enter jabber1 twice)

-Fritz

Message was edited by: felfert

[Frank2]

Hmm, well my previous assumption that the ssl pass change fixed that issue, it has not.

Message was edited by: cbtl

[Frank2]

So here’'s another question relating to this. After 3.1.0 shipped I moved to a faster server to handle the load.

I went from Debian Sarge to Fedora Core 6. The only thing that was transfered from the old server to the new server was the mysql database.

Is there any place in the Database where the keystore password would be? or should I get another keytool and keystore file with the default password and use those?

[Gaston_Dombiak]

Hey cbtl,

By default the keystore and its certificates as well as the truststore use the password “changeit”. If you changed the password then Wildfire needs to be configured to use the new password. The system property xmpp.socket.ssl.keypass can be set for the keystore password and the system property xmpp.socket.ssl.trustpass for the truststore password. System properties are stored in the jiveProperty table.

Regards,

– Gato

[Frank2]

The password isn’'t meshing with what I had set it at, which tells me either I screwed up and forgot what I changed it to. Or something happened during the server move and the password corrupted.

So what I need to know, is that password stored anywhere in the database that wildfire maintains.

Or Can I take a fresh keystore and truststore file from a fresh install not being configured and replace those two files. SSH to the box and then change the keystore and truststore passwords from the defaults to whatever I wish them to be.

[Gaston_Dombiak]

Hey cbtl,

If your previous Wildfire setup was able to use the keystore and truststore files then you can check if the previous properties I mentioned were defined. If they are not there then you were using the default changeit password. If you changed the password and forgot the new one and Wildfire was not configured to use the new password then you are lost. You can try using the keytool as an easier tool for testing password and see if it works.

If nothing works then you will need to start from scratch again. That means replacing the keystore and truststore with the ones provided with Wildfire. Complete the setup process to generate self-signed certificates for the hosted domain or just use the certificate management page to create new certificates. You can also import a private key and signed certificate using the import-certificate.jsp page. Or you can always go back to the old command line tool and use the keytool tool to generate and import certificates.

Regards,

– Gato

[Frank2]

Forgive my ignorance here.

The only common thing between the two servers is that I kept the mysql database, that way I didn’'t have to rebuild a bunch of chat rooms or have users complain about their rosters being gone.

So now that changeit doesn’'t work, remember nothing but an upgrade and I never used the ssl functions before I jumped to 3.2.2.

So I basically need to throw the database out the window and start from scratch?

Or Can I change the wildfire.xml to say setup false.

Extract the keystore and truststore files from my test machine which hasn’'t been used at all, copy those over. Redo the setup of wildfire, and try changing the keystore password?

[Gaston_Dombiak]

cbtl wrote:

So I basically need to throw the database out the window and start from scratch?

No need to do that. You can reuse the database from your previous setup.

Or Can I change the wildfire.xml to say setup false.

Yes. You can do that to rerun the setup process. Running the setup process again will not erase your database so you are safe. Anyway, running the setup process again will help you to generate new self-signed certificates for the hosted domains. Would that be enough for you? Or did you have certificates signed by a CA that you need to import/migrate?

Extract the keystore and truststore files from my test machine which hasn’'t been used at all, copy those over. Redo the setup of wildfire, and try changing the keystore password?

If you want to use the certificates that you had in your previous setup you can just copy those files to the new server. If your keystore and truststore in your previous setup have another password than changeit then you will need to 1) configure Wildfire to use the new password by setting the properties I mentioned or 2) change the password of the keystore and truststore to be changeit. You can use the keytool for that but you will need to know the current password to set a new one.

You can rerun the setup process but that will only be good for generating new self-signed certificates. Anyway, that will work only if Wildfire has the correct password to access the keystore and truststore.

Regards,

– Gato

[Frank2]

Strangely enough I’'ve fixed it.

I uninstalled 3.2.2 and mysql, saved the db of course. Downloaded 3.2.2 again and reinstalled it, same issue. So I wiped the setup and put 3.2.0 back on.

THe self signed certs installed fine, I can login to the admin tool via ssl or non ssl now. The changeit password still doesn’'t work however with this fresh install on the server, only common thing is that database.

But I’‘m not going to worry about it. It works and I’'m happy.

[Corsica]

Hello

First sorry for my very bad english. I had the same problem (upgrade 3.2.0 to 3.2.2) with Ubuntu serveur. My base is the Wildfire Base, not an mysql and i va solutionned the problem :

• Stop the wildfire process

• Rename the /opt/wildfire (/opt/wildfireold for example)

• Download and extract and copie the new version in /opt/wildfire

• Copy my old base (/opt/wildfire/embedded) in new wildfire rep

• Start wildfire process

• Connect to admin (http://xxxxxx:9090) and make the setup

Hollo from Corscica