You are here

At my work, my boss wanted to set up an openfire server for employees to communicate with.

We chose to use an openfire jabber server.

Knowing how easy turnkey linux was to use to set up a mediawiki, we decided to give setting the openfire server up on top of turnkey core.

Opensource is all about giving back right? Well heres the script that we used to install (but not configure, as that is done though the web interface) the openfire server ontop of turnkey core. It was almost stupidly easy.

Hopefully I can download an openfire virtual appliance from turnkey in a few months the next time I need to do the setup! That would be awesome.

Thanks! Sharing your experience not only helps other users with similar needs it also helps us figure out what appliances to target for development. We've developed a chat server appliance for the next release but it's not based on OpenFire. On the other hand, adding an OpenFire based appliance doesn't really look very difficult so maybe we'll manage to squeeze that into the next release.

Given that OpenFire is mostly configured through the application's own setup interface, I can't say that there were issues that were encountered with simply setting up the packages needed to run it. As you saw in my badly mangled script with broken english explaitions above :-P, going from not having an xmpp openfire server to having one was extremely simple.

The web interface for openfire can be reachable by default through http://hostname:9090/.

If the user chooses to use the optional LDAP integration with their local active directory, I caution them on how they go about that. We encountered problems with logging in to the server do to the server having identity issues. We were authenticating as domainname.com where the machine was in actuality on a subdomain IM.domainname.com.

On Windows, when going from finishing the initial setup of openfire to logging into the admin console, the openfire needs to be fully restarted. On Linux, we didn't encounter this problem initially, but thats not to say that we avoided in some other manner.

My understanding is that the default admin account is "admin" and that the email asked for is meaningless unless your machine has access to an email server. We block the email port on our filewall and access our email through a web interface. I don't know if the email option works or not, but I do know that the default admin account is "admin", unless your reading users from some other system (Such as LDAP).

The embedded database that openfire offers the option of using worked just fine for us. But if turnkey is going to offer an openfire virtual appliance, I recommend that the liveCD have a database external to the openfire application (perhaps in a later release), as it is much more scalable.

LDAP integration (because thats what we used it against), does NOT automatically populate users who log in with groups. The admin of the virtual appliance will need to manually configure which groups are auto added to each users contact list by using the web interface. This has its plus's and minus's, but the steps won't be immediately obvious to some folks.

XMPP supports server to server federation. The openfire install we have does work with this. The configuration, however, requires correctly setting up the network topology. We needed to configure SRV records (because of the identity crisis i mentioned above), and DNS records. This might not be necessary for most users of a virtual appliance built on openfire.

Adding new administers to the user list through the web interface was problematic for me. What I found to be ambiguous was how to seperate usernames, and which domain to claim the user is under. At various times in our tinkering, the system thought my username was jonesmz@chat.domain.com, jonesmz@domain.com, and just plain jonesmz. If the user has their topology set up from the get go, that likely won't be a problem for them.

If a user locks themselves out of the admin console somehow, as I happened to go quite a bit, adding this XML tag to their openfire.xml configuration file

<admin>

<authorizedUsernames>joe, jane</authorizedUsernames>

</admin>

where joe, and jane, are comma seperated usernames that the openfire system already knows about.

doing that will replace the admin list with ONLY the usernames in the xml tag.

I'm not sure how extensive the openfire.xml files control over the server is.

After modding the .xml file, the server has to be restarted for the changes to take effect.

The reason for all that, is that previously we had the same domain internally and externally, but have in recent years moved our external domain to something else, and our interal stuff is still catching up.

Let me know if I can help in any way.

I am interested in helping to create virtual appliances. An earlier attempt of mine was to create a Trac/SVN appliance. I managed to do so by modifying an Ubuntu desktop Live CD, but I haven't had luck with the turnkey core images & UCK or remastersys.

I'm fairly new to the linux world which is why turnkey is my best friend right now. I've been trying for several hours and multiple scrapped VM's to get openfire on turnkey core. I copied the script above, and saved as openfire.sh. I then uploaded to the server and ran the script via: sh openfire.sh while in the cwd and as root.

Is the script working for anyone else? Is it missing anything like other dependencies or am I just doing something wrong?