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.

For the SRV stuff

The command

dig _xmpp-server._tcp.domain.com SRV

should spit out something resembeling

<<>> DiG 9.2.4 <<>> _xmpp-server._tcp.domain.com SRV

;; global options: printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42276

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:

;_xmpp-server._tcp.internaldomain.com. IN SRV

;; ANSWER SECTION:

_xmpp-server._tcp.internaldomain.com. 14400 IN SRV 5 0 5269 yourserver.externaldomain.org.

;; AUTHORITY SECTION:

internaldomain.com. 154764 IN NS dns249.d.register.com.

internaldomain.com. 154764 IN NS dns117.a.register.com.

internaldomain.com. 154764 IN NS dns123.b.register.com.

internaldomain.com. 154764 IN NS dns223.c.register.com.

;; ADDITIONAL SECTION:

yourserver.externaldomain.org. 13734 IN A IPAddress

dns117.a.register.com. 172764 IN A IPAddress

dns223.c.register.com. 149982 IN A IPAddress

dns249.d.register.com. 150487 IN A IPAddress

;; Query time: 52 msec

;; SERVER: IPAddress#53(IPAddress)

;; WHEN: Mon Jul 20 16:48:07 2009

;; MSG SIZE rcvd: 250

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've subscribed to the blueprint, and added some trivial notes to the whiteboard.