When you setup OpenFire, one of the things you initially setup from the Web Console is the service name (I think it calls it the “Domain”). It will prepopulate this field with your Linux Server name. This is what I unwittingly did for our test install at the company I work for. Mistake! Everyone liked the service a lot, so we knew we were going to keep it. So I wanted to roll the test server into production, rather than building from scratch. The production server setup, however, was going to have a public DNS record (you know, a friendly URL like http://im.mycompany.com, to make connecting to it easier for everyone). This is what you want the service name to be, not the server name itself.
When I rolled into production I attempted to change the service name… big problem. This locked me out from logging in to the admin console as it breaks the domain that your accounts are attached to… We are using active directory for authentication in our environment which further complicated things. There are some hackish ways to go about trying to fix this via manipulating the database directly… which I started to do… then I realized I would be more comfortable just rebuilding the server from scratch and using a different service name during setup. Which I did.
You can read more about this issue here:
http://community.igniterealtime.org/message/197643#197643
Unfortunately, the best advice I can give you if you are in this situation is to rebuild… setting the service up is much faster than trying to fix it once it is broken… and it will break if you try to change the service name… Also, I think even if I had gotten the login to work there would have been some residual uneasiness. This is just not something you want to have to think about if you are deploying for enterprise use. Just start over, do the grunt work again, and then you won’t have to worry… My 2-cents…
Hey, I managed to do the same mistake as you, but I’m unable to “rebuild” like you suggested. I tried uninstalling openfire and reinstalling, and also the false trick, but it doesn’t seem to work for me. Can you point me in the right direction?
@DeepTL
OpenFire, blessedly, hasn’t required a lot of administration so I haven’t had to work much on it sincee I set it up. Per the article, I wasn’t comfortable with any of the other “fixes” I came across for this rather frustrating issue. I certainly feel your pain. I am not sure what the best way to go about straightening it out is if you can’t rebuild. What is preventing you from rebuilding the IM server (if I can ask)? I am thinking you could possibly backup the existing files/database if you need to keep historical chat logs and still go with a rebuild. That would be the primary thing that I would want to hold onto if the server has been around and in use for a while. However, I am also not sure if rebuilding for you also requires re-creating a bunch of user accounts in which case I could see it getting to be a bit of a bigger headache.
I tried to reinstall OpenFire to re-setup, apparently it did not get uninstalled correctly the first time, and hence I wasn’t able to go through with it. Now, it’s done. Thanks for your help!
Glad you were able to get it hammered out! I don’t think openfire software has seen an update in a long time, it would be nice if they could find a workaround for this issue so it wasn’t such a pain to fix.
the fix is pretty easy. you just search the embedded database for a string matching the domain name you changed and then replace it for the ip address of your server. voilá.
of course this doesn’t fix the domain name problem. and your jabber accounts will still be @ which sucks. but it’s better than having some serious downtime.
in ubuntu the db is located at: /usr/share/openfire/embedded-db
and is plaintex.
@ip-address … sry, forgot ppl tend to use character escaping.