One of the things you may have noticed that appeared in the 3.4.3 release of Openfire is a couple of new installers, and some improvements to existing installers. Oddly enough, building installers can be one of the more difficult tasks a developer has. Simply putting out a tarball or zip file is easy, but it’s not exactly the most pleasant thing to deal with from an administrator perspective. In the process of creating installers, you often find yourself fighting with differing standards between OS distributions, or different architectures altogether. That said, typically once you have created the installer, there’s not much to do with it after, so it’s generally a one time cost, so to speak, and the benefits far outweigh the time spent!
In an effort to make Openfire as easy to install as possible, we added official Debian and Solaris packages. Yes, I am aware the Solaris package is listed under Linux right now, but please ignore that for now. Are we stopping there? Not really. I’m not yet sure what other OS’s we might be providing packages for at this point. FreeBSD is about the only other one I’ve seen a request for and there’s a well maintained port (net-im/openfire) of Openfire already.
What we are investigating now is providing hosted repositories for the packages. Specifically, I’m looking at a Yum and APT repository at the moment. This would allow system administrators to point their repository configs at our repositories and be able to easily keep up to date. We are still working out the logistics of this, so stay tuned!
We’re also investigating getting Openfire into more distributions. In other words, instead of having to come to our site to get Openfire, perhaps you could install it from a central Debian repository, or an extras cd, or something of that nature. There are a couple of possibilities in the works on that front, and a couple more I’d like to pursue.
So hopefully in the near future, it will be as easy as ever to get rolling with Openfire!
I just wanted to show my support for the openfire project. Despite not having any specific ‘installers’ when I first started using it - the web-based setup is a breath of fresh air. It’s a fantastic product. Thanks again.
what would be greater than any installers it’s the ability to upgrade Openfire through the Admin Console:) I thinkit was “planned” some time ago. For now, as long as i dont have to compile anything, i’m fully satisfied with tarballs:) of course, would be great to have a package for my Arch linux someday.
I would gladly help with packaging for Fedora (and try to include it into Fedora), if it was for the real Fedora, i.e., without included JRE and compiled with IcedTea/ECJ. I have tested that tar.gz version works with IcedTea JVM, but don’t know about compilation from source using only opensource tools.
here comes a little suggestion/feature request concerning the debian /etc/init.d/openfire script.
as probably many people out there (like me) use openfire on one of those crappy (but cheeaaap) virtual dedicated systems (vps) with limited memory, it would be cool if we could store somewhere in the config the maximum memory (without manuall editing the init script and putting the -Xmx100m parameter in the DAEMON-OPTS line.
if the init script would read this setting from the /etc/openfire config somewhere, it would be safe to just overwrite the init file with every update (to get the changes there as well - if there are any)
b.t.w. is there already a openfire repo? apt-get upgrade??
Hi mcepl, we semi-talked about this elsewhere, but am I to assume Fedora now disapproves of using the standard Sun JVMs? So ECJ isn’t the same as GCJ, right? (GCJ causes a wealth of problems with Openfire and the IM Gateway plugin to where I had to warn people off of it) IceaTea would definitely be an “unknown” from our perspective, but if it works, then I don’t really know what the harm is. (I’ve thought through this a bit since last we talked) I don’t really understand why it would need to be built with only open source tools … or are you saying that in terms of, for the src RPM? When did IceaTea become the ‘standard’ in Fedora? (Like what’s the minimum release I need to get myself a VM of)
And no, no openfire repo yet. =) I’m going to be flying to Portland next week for a week, so I was thinking that would be a good time to get the repo logistics worked out!
Well, Fedora never really like any proprietary software (remember, people from RH were the driving force behind OpenOffice.org working with GCJ, and anyway GCJ is probably developed mostly by RH people), but now when there is IcedTea, it seems really possible to get old Sun JVM altogether.
ECJ is Eclipse Java Compiler by IBM, which is used in the current Fedora as the Java Compiler, because it is 1.5 compatible, whereas old GCJ was only 1.4 compatible. IcedTea became part of Fedora (note, that we still ship GCJ as a secondary Java environment, because some things – ehm, Eclipse – are still GCJ only) in Fedora 8. More information about IcedTea in Fedora is on http://fedoraproject.org/wiki/Features/IcedTea.
DAEMON_OPTS="-Xmx24m -server -DopenfireHome=$ \ -Dopenfire.lib.dir=$ -classpath $/startup.jar\ -jar $/startup.jar $DAEMON_OPTS" and
/etc/default/openfire:
DAEMON_OPTS="-Xmx24m" (dont know if this is a replacement or additional) in both cases openfire did not startup. when i put:
DAEMON_OPTS="-Xmx24m -server -DopenfireHome=$ \
-Dopenfire.lib.dir=$ -classpath $/startup.jar\
-jar $/startup.jar $DAEMON_OPTS"
directly into the /etc/init.d/openfire script, it works fine.
Yeah, it turns out there’s a bug in the ordering there. It’s been fixed in SVN and should be fixed for 3.4.5. The $DAEMON_OPTS should be at the beginning of the setting. Your fix should do the trick until the next release though!
How hard is to create an APT repository? more than 5 years? Thre is one (good) way of software distribution on Linux, and that’s the APT or yum repository method.