Change XMPP domain and JIDs

Hey guys, I’m in a similar position to a few others here, but the threads are old so I’ll start a new one. - My server is (sort of) live - we have around 110 sessions daily, but we will be going to a lot more soon. Before that happens I want to change my xmpp domain - main reason as currently it’s set to servername.internaldomain.com - and i want it to be easily available externally for federation, mobile access etc. So I’m thinking the best way to achieve this is by changing the xmpp domain to servername.externaldomain.com (or even just externaldomain.com so the JIDs are the same as the email addresses - better option?)

I’m running OF 3.5.2 on Red Hat EL, MySQL database. I don’t want to migrate to a new server. Am I looking at :

  1. Sorting out DNS

  2. Changing server name in admin console

  3. changing all the JIDs (and other occurrences of the old domain) in MySQL

Is this feasible ie. is it likely to break everything horribly? I want the experience to be as transparent as possible to my current users…

Any help appreciated

Nick

Hi Nick,

when you change the node identifier of the JID you may really prefer to use example.com without servername so the email and XMPP addresses are equal. Anyhow you need to use DNS SRV records as you may want that “example.com” resolves to your web server and not to your XMPP server.

  1. Changing server name in admin console

This is not necesary. Just shutdown Openfire and change the node identifier everywhere in the database and restart Openfire.

is it likely to break everything horribly?

No, as you use it only internally currently and your users have no remote contacts this is not a problem.

Do you use LDAP or AD somewhere? It’s a good idea to attach Openfire to an existing user directory so you don’t have to care about new users and lost passwords. Anyhow it may be then tricky to use the email address as the JID while you are usually using another Windows Username for Windows login / authentication.

LG

I disagree with LG on some parts of his reply.

  1. You will need to make sure the server has a DNS name that can be found by an outside query. That name should be servername.externaldomain.com. externaldomain.com is usually reserved for port 80 hosting.
  2. You should change the name of the server in the admin console and make sure the certificates match the new name. This is critical for some of the more advanced features if you ever decide to use them.
  3. Changing JID is also a must. LDAP would be easier. The JID being the same as email does not matter so much as some clients (Spark, SparkWeb, etc) do not use a JID as much as a username and a server name.

Hi Todd,

while “externaldomain.com is usually reserved for port 80 hosting.” is true I said that using DNS SRV records would be much better. Anyhow I want to correct myself, it works also without DNS SRV records if you

a) host your web server and your XMPP server on the same hardware using the same IP address or

b) have a firewall in fornt of your server which does support NAT, so you can “NAT” external-ip:80–>internal-webserver:80 and external-IP:5222–> internal-XMPP-server:5222. I could do this even at home with my DSL-router as it supports NAT.

change the name of the server in the admin console” - no need to. Openfire will detect invalid certificates after startup (as it does after the first installation). But you’re right, one should update then.

LG

Thanks - two of the top guys answering my question, excellent I’m glad that it looks relatively straightdorward - I’ll have a good look at your advice on Monday, and have a think about the best way to proceed.

One point though - I do indeed use LDAP for users - this doesn’t make a difference, I still need to change JIDs right? Just wasn’t sure why you both mentioned LDAP in your replies…

Cheers, Nick

I do indeed use LDAP for users

Do you already use it also for Openfire?

Just wasn’t sure why you both mentioned LDAP in your replies

I did mention it because it would make sense to use it now unless you use it already, anyhow you did not mention it in your first post. Adding it later may be painful as it could require another JID change and a password change.

LG

OK, got you (I think) - yes we do already use LDAP / AD for Openfire.

I’m going to run this up on the test box and see how I get on. Thanks for your replies.

Nick

Update - I’ve done the following on a test box :

  1. Changed server name in Openfire web console

  2. Deleted certificates

  3. Generated new certificates

  4. Logged back in via Spark

Now bearing in mind I’m using LDAP / Active Directory, with MySQL as the Openfire DB - simply following the process above seems to have worked. I haven’t changed any entries in MySQL at all. The Spark rosters are all present and correct, IM gateway users are still there, contact groups etc are all OK. When you hover over a contact it displays the correct “new” JID.

Searching through the Openfire DB with phpMyAdmin still shows plenty of old JID references, in places like the archives, offline messages etc. So - my plan after a bit more testing is to just do a find and replace on all these entries.

Does this sound feasible and / or am I missing something horrible? The whole thing seems too painless to me. Maybe it’s down to my lack of appreciation of what the Openfire DB actually does when you’re using an external DB for users like AD. I thought (probably incorrectly) that the Openfire DB would still store all the JIDs somewhere, but it either appears that it doesn’t at all, or changing the server name simply updates them all…

Nick

really shouldn’t be that much trouble, if i remember we pulled the rosters with an export, changed all the domains, changed the server domain, restarted, put the rosters in, changed the ssl certs and let people back on.

OK I definitely spoke too soon - it’s a bit of a mess

I’ve now updated all the JIDs and references to the old domain name in MySQL (remember I’m using LDAP for authentication). Although rosters all look ok, Openfire itself isn’t doing so well. The main problem seems to be the certificates - as advised here I deleted the old certificates and created new ones. This appeared to work ok - but like some other threads, every time Openfire is restarted, the following is displayed in “Server Certificates” in the admin console - “Unable to access the certificate store. The keystore may be corrupt.” and startup generates further errors in the log - example here:

2008.08.20 14:51:20 [org.jivesoftware.openfire.net.SSLConfig.(SSLConfig.java:104)] SSLConfig startup problem.
storeType: [jks]
keyStoreLocation: [/opt/openfire/resources/security/keystore]
keypass: [changeit]
s2sTrustStoreLocation: [/opt/openfire/resources/security/truststore]
s2sTrustpass: [changeit]

2008.08.20 14:51:22 [org.jivesoftware.openfire.container.AdminConsolePlugin.startup(AdminConsolePlu gin.java:121)]
java.io.IOException
at org.jivesoftware.openfire.net.SSLConfig.getKeyStore(SSLConfig.java:267)
at org.jivesoftware.openfire.container.AdminConsolePlugin.startup(AdminConsolePlug in.java:96)
at org.jivesoftware.openfire.container.AdminConsolePlugin.initializePlugin(AdminCo nsolePlugin.java:170)
at org.jivesoftware.openfire.container.PluginManager.loadPlugin(PluginManager.java :448)
at org.jivesoftware.openfire.container.PluginManager.access$300(PluginManager.java :47)
at org.jivesoftware.openfire.container.PluginManager$PluginMonitor.run(PluginManag er.java:1014)
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)
2008.08.20 14:51:37 [org.jivesoftware.openfire.plugin.emailListener.EmailListener.openFolder(EmailL istener.java:281)] Error while initializing email listener
java.lang.NullPointerException
at java.util.Hashtable.put(Unknown Source)
at java.util.Properties.setProperty(Unknown Source)
at org.jivesoftware.openfire.plugin.emailListener.EmailListener.openFolder(EmailLi stener.java:243)
at org.jivesoftware.openfire.plugin.emailListener.EmailListener.access$100(EmailLi stener.java:36)
at org.jivesoftware.openfire.plugin.emailListener.EmailListener$1.run(EmailListene r.java:80)
2008.08.20 14:51:41 [org.jivesoftware.openfire.http.HttpBindManager.createSSLConnector(HttpBindMana ger.java:158)] Error creating SSL connector for Http bind
java.io.IOException
at org.jivesoftware.openfire.net.SSLConfig.getKeyStore(SSLConfig.java:267)
at org.jivesoftware.openfire.http.HttpBindManager.createSSLConnector(HttpBindManag er.java:134)
at org.jivesoftware.openfire.http.HttpBindManager.configureHttpBindServer(HttpBind Manager.java:258)
at org.jivesoftware.openfire.http.HttpBindManager.start(HttpBindManager.java:90)
at org.jivesoftware.openfire.spi.ConnectionManagerImpl.startHTTPBindListeners(Conn ectionManagerImpl.java:523)
at org.jivesoftware.openfire.spi.ConnectionManagerImpl.startListeners(ConnectionMa nagerImpl.java:136)
at org.jivesoftware.openfire.spi.ConnectionManagerImpl.access$000(ConnectionManage rImpl.java:54)
at org.jivesoftware.openfire.spi.ConnectionManagerImpl$1.pluginsMonitored(Connecti onManagerImpl.java:108)
at org.jivesoftware.openfire.container.PluginManager.firePluginsMonitored(PluginMa nager.java:533)
at org.jivesoftware.openfire.container.PluginManager.access$800(PluginManager.java :47)
at org.jivesoftware.openfire.container.PluginManager$PluginMonitor.run(PluginManag er.java:1024)
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)

The permissions on /opt/openfire/resources/security look correct (same as the working live server - “daemon” user has rw permissions on the folder). It does allow me to generate new certificates, and this process does work, so I’m sure permissions are ok, it’s just when Openfire restarts that I see the problem. These are “internal” certificates, not from a CA, and I’ve never added or changed the password.

There are other problems but I have a feeling this is the root cause so I’d like to get to the bottom of this first. The only thing that I can think of that might be related is that the new “Openfire” server name now has a different domain suffix to the actual host name in Red Hat (and also as displayed under Openfire Server Information under Environment) - could that cause a problem with the certificates?

Any ideas from anyone?

Nick

You could delete the keystore and let it regenerate it?

Done that! If I just clear the keystore (cat /dev/null > keystore) or even delete it completely, the result is the same - nothing is automatically created on restart of Openfire. I have to manually recreate the certificates in the admin console, which works, but then the error reappears when I next restart.

So you deleted keystore, restarted openfire, remade the certificates, restarted the server (I had to do the whole box) and it still doesn’t work?

Correct. Been restarting and deleting certificates, trying different things all day. Starting to lose my sense of humour now, but at least it’s the test box. Need to get it working though as I need to get the live server internet facing asap…