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:
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…