Stop the openfire server, edit your openfire.xml file sot that the setup tag read false. Then start the server and and go to the admin page and restep through teh setup again. This fixed my issue with invalid admin logins.
Hrm. This is MySQL! What the crap? I’m betting that was a failing in script 14 — what version of Openfire were you upgrading from? Looks like this script is missing the … well you can edit (or manually run) the script and replace jid wth jid(1024) and that should do it.
seb_llgc wrote:
Hey,
I have the same problem as above. The upgrade/install using the RPM worked fine but it was unable to make the neccasary modifications to the database. After the upgrade I get this in my error logs
12:25:50 [org.jivesoftware.database.SchemaManager.executeSQLScript(SchemaManager.java:37 9)] SchemaManager: Fail
ed to execute SQL:
ALTER TABLE jiveRoster ADD INDEX jiveRoster_jid_idx (jid);
2008.08.27 12:25:50 [org.jivesoftware.database.SchemaManager.checkSchema(SchemaManager.java:269)]
com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: BLOB/TEXT column ‘jid’ used in key specification without a key length
I have seen similar referenced in other posts, it seems that the schema requires some modification. I have tried to make these mods (specifying a length for jid) but it falls down as my database already has the tables it is trying to create, and I do not wish to drop the whole database and reapply the schema. Is there a fix for this in the pipeline? After the failure to apply this schema, subsequent openfire startups leave me with errors complaining about missing tables, speficically ofID. I have tried downgrading again to my previous version but that does not work now either, any help with this would be greatly appreciated.
Cheers,
Sebastian Clarke
That is not the -only- changes. Some indexes were renamed (wouldn’t be a problem unless a future upgrade script needs to change something) Plus there were a couple of other db updates beyond just renaming tables.
seb_llgc wrote:
serfonteinj wrote:
OK it was easy, just make a dbdump of your database and rename the tables and re-import it.
Regards
Jan
can anyone confirm that the only changes to the DB between these versions is that the jive* tables names are changed to of* - if this is the only difference then yeah, shouldn’t be too hard to dump these out then inject them back in.
Cheers,
Seb
jadestorm wrote:
Hrm. This is MySQL! What the crap? I’m betting that was a failing in script 14 — what version of Openfire were you upgrading from? Looks like this script is missing the … well you can edit (or manually run) the script and replace jid wth jid(1024) and that should do it.
I was upgrading from 3.5.2-1 I think. I did try editing the script, but it wont run because I already have the tables its trying to add in my database, it looks like my only choice is to manually run it line by line, changing it where neccessary, and not running the lines that would replace tables I already have.
Seb
serfonteinj wrote:
OK it was easy, just make a dbdump of your database and rename the tables and re-import it.
Regards
Jan
That’s not all that changed. (there are a couple of other db upgrade scripts that need to be run) Plus some indexes changed names, which could cause problems in the future if those indexes are ever adjusted via automatic update. If you just renamed the tables, when you start up Openfire 3.6.0 it’s going to get “very angry” because it’s going to think it hasn’t upgraded yet and try to rename tables.
seb_llgc wrote:
jadestorm wrote:
Hrm. This is MySQL! What the crap? I’m betting that was a failing in script 14 — what version of Openfire were you upgrading from? Looks like this script is missing the … well you can edit (or manually run) the script and replace jid wth jid(1024) and that should do it.
I was upgrading from 3.5.2-1 I think. I did try editing the script, but it wont run because I already have the tables its trying to add in my database, it looks like my only choice is to manually run it line by line, changing it where neccessary, and not running the lines that would replace tables I already have.
Seb
Yes unfortunately some of the tables will exist since it partially completed. =/ Hrm. Unless you’ve already completed the upgrade procedure, can you share with me what’s in your ofVersion table (or jiveVersion if it hasn’t been renamed yet)
Is anyone actually having success with the new release? I upgraded 4 different servers with different starting versions, different things installed, etc and they all went smoothly so I’m a little unhinged to see so many issues creeping up.
jadestorm wrote:
Yes unfortunately some of the tables will exist since it partially completed. =/ Hrm. Unless you’ve already completed the upgrade procedure, can you share with me what’s in your ofVersion table (or jiveVersion if it hasn’t been renamed yet)
It says 13, and its jiveVersion like all my tables. I have downgraded, and it still doesnt work, so I tried to mod the mysql script to put in TEXT lengths where required, but when I run the upgrade again this is overridden and I get the same problems. It simply seems to be that the sql changes bomb out after hitting this jid error, and no changes are made at all to my database, then on subsequent runs, obviously all the tables are named wrong.
Seb
Well, I’m looking for the Mac-version but can’t download it from the downloads-page. It also shows there as 0MB.
We have tried the upgrade on three different servers… all running 3.5.2 with auth against Active directory and DB of MSFT SQL. ALl have failed during the install on database schema error when trying to upgrade from 16 to 20
A restore has sucessfully put things back together
Hi Daniel,
thanks for your reply, the installation works fine on my environment (CentOS-mysql5) upgrading from of352, however I am not sure that after installing the rpm the previous demon was actually stopped as I had to reboot the machine prior to work properly as the log file was showing that a nuymber of ports were still in use.
After that, the only issues where those expained in my previous comment:
i.e. Profile settings Base DN and Administrator DN only showing “CN=” or “DN=”
The enterprise plugin was previously removed and all plugins were updated to the latest ones, however I am still encountering the issues described below, I also tried to remove both jars and directory for the plugins that are producing errors and re-install thourgh administration site, but problem still occurs.
Is there any other way to investigate the issue further? maybe there is some problems with the database? I need your help here.
LDAP DN values quote wrapping doesn’t work when one of its RDN’s contains one char only.
LdapManager.java:
dnPattern = Pattern.compile(“([^\\]=)([^"].*?[^\\])(,|$)”);
Wrong user DN wrapping:
uid=user,ou=Users,dc=a,dc=example,dc=com => uid=“user”,ou=“Users”,dc=“a,dc=example”,dc=“com”
Result: it’s impossible to setup Openfire with LDAP authentication because it doesn’t see the users in LDAP:
2008.08.27 15:25:34 [org.jivesoftware.admin.LdapUserTester.getAttributes(LdapUserTester.java:183)]
javax.naming.NameNotFoundException: [LDAP: error code 32 - No Such Object]; remaining name ‘uid=“user”,ou=“Users”,dc=“a,dc=example”,dc=“com”’
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.c_getAttributes(Unknown Source)
at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(Unknown Source)
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(Unknown Source)
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(Unknown Source)
at javax.naming.directory.InitialDirContext.getAttributes(Unknown Source)
at org.jivesoftware.admin.LdapUserTester.getAttributes(LdapUserTester.java:160)
at org.jivesoftware.openfire.admin.setup.setup_002dldap_002duser_005ftest_jsp._jsp Service(setup_002dldap_002duser_005ftest_jsp.java:97)
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.ja va:1093)
at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:39)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1084)
at org.jivesoftware.util.LocaleFilter.doFilter(LocaleFilter.java:66)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1084)
at org.jivesoftware.util.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingF ilter.java:42)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1084)
at org.jivesoftware.admin.PluginFilter.doFilter(PluginFilter.java:70)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1084)
at org.jivesoftware.admin.AuthCheckFilter.doFilter(AuthCheckFilter.java:99)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va: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(ContextHandlerCollect ion.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.j ava: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)
Unfortunately, I cannot get this version working at all. If anyone has a link I can follow to obtain a copy of 3.5.3, I’d appreciate it.
After encountering issues updating the database, I performed a clean install. AD works and allows users to log into the system. Unfortunately, after about 10 minutes, everyone starts appearing as offline.
Tried the same thing. A clean install sets up ok but noone is able to invite other contacts and eventually all users go offline
excomedia wrote:
Well, I’m looking for the Mac-version but can’t download it from the downloads-page. It also shows there as 0MB.
Sorry about that, named it wrong, mac version is up there now.
seb_llgc wrote:
jadestorm wrote:
Yes unfortunately some of the tables will exist since it partially completed. =/ Hrm. Unless you’ve already completed the upgrade procedure, can you share with me what’s in your ofVersion table (or jiveVersion if it hasn’t been renamed yet)
It says 13, and its jiveVersion like all my tables. I have downgraded, and it still doesnt work, so I tried to mod the mysql script to put in TEXT lengths where required, but when I run the upgrade again this is overridden and I get the same problems. It simply seems to be that the sql changes bomb out after hitting this jid error, and no changes are made at all to my database, then on subsequent runs, obviously all the tables are named wrong.
Seb
13?? What version of Openfire did you say you were at again? (before upgrading)
dthor wrote:
We have tried the upgrade on three different servers… all running 3.5.2 with auth against Active directory and DB of MSFT SQL. ALl have failed during the install on database schema error when trying to upgrade from 16 to 20
A restore has sucessfully put things back together
What specifically are you seeing as the database schema error? I don’t have the slightest idea what MSFT SQL is btw.
michelbugeja wrote:
Hi Daniel,
thanks for your reply, the installation works fine on my environment (CentOS-mysql5) upgrading from of352, however I am not sure that after installing the rpm the previous demon was actually stopped as I had to reboot the machine prior to work properly as the log file was showing that a nuymber of ports were still in use.
After that, the only issues where those expained in my previous comment:
i.e. Profile settings Base DN and Administrator DN only showing “CN=” or “DN=”
The enterprise plugin was previously removed and all plugins were updated to the latest ones, however I am still encountering the issues described below, I also tried to remove both jars and directory for the plugins that are producing errors and re-install thourgh administration site, but problem still occurs.
Is there any other way to investigate the issue further? maybe there is some problems with the database? I need your help here.
Hrm. Do you have some time to join the group chat today and ask me in person? Might need to work through it real time. Did you happen to rerun setup? (Todd suggested that earlier in this thread)
Zwooiq wrote:
LDAP DN values quote wrapping doesn’t work when one of its RDN’s contains one char only.
LdapManager.java:
dnPattern = Pattern.compile(“([^\\]=)([^"].*?[^\\])(,|$)”);
Wrong user DN wrapping:
uid=user,ou=Users,dc=a,dc=example,dc=com => uid=“user”,ou=“Users”,dc=“a,dc=example”,dc=“com”
Result: it’s impossible to setup Openfire with LDAP authentication because it doesn’t see the users in LDAP:
2008.08.27 15:25:34 [org.jivesoftware.admin.LdapUserTester.getAttributes(LdapUserTester.java:183)]
javax.naming.NameNotFoundException: [LDAP: error code 32 - No Such Object]; remaining name ‘uid=“user”,ou=“Users”,dc=“a,dc=example”,dc=“com”’
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.c_getAttributes(Unknown Source)
at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(Unknown Source)
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(Unknown Source)
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(Unknown Source)
at javax.naming.directory.InitialDirContext.getAttributes(Unknown Source)
at org.jivesoftware.admin.LdapUserTester.getAttributes(LdapUserTester.java:160)
at org.jivesoftware.openfire.admin.setup.setup_002dldap_002duser_005ftest_jsp._jsp Service(setup_002dldap_002duser_005ftest_jsp.java:97)
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.ja va:1093)
at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:39)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1084)
at org.jivesoftware.util.LocaleFilter.doFilter(LocaleFilter.java:66)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1084)
at org.jivesoftware.util.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingF ilter.java:42)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1084)
at org.jivesoftware.admin.PluginFilter.doFilter(PluginFilter.java:70)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1084)
at org.jivesoftware.admin.AuthCheckFilter.doFilter(AuthCheckFilter.java:99)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va: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(ContextHandlerCollect ion.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.j ava: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)
Ack what the crap? Try setting: ldap.encloseDNs to false
Lets see if that gets you running.
Cool It seems to work correctly.
Fastpath ok, monitoring ok, LDAP ok.
Does anyone knows if the SIP plugin works correctly ? It can’t make it works
Sorry, the SIP phone plugin seems to work
Does the LDAP works really ? I’m unable to connect a client to my OpenFire server …