Ignite Realtime: Ignite Realtime Blog: Installers, Installers, Everywhere!

Ignite Realtime Blog

Previous Next

Installers, Installers, Everywhere!

Posted by jadestorm Jan 17, 2008

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!

Tags: ignite_realtime, planetjabber, openfire-server, openfire

Jan 17, 2008 11:02 AM

andylockran

I read this post through the ubuntu-uk planet.

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.

Jan 17, 2008 1:54 PM

wroot

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.

Jan 17, 2008 5:43 PM

mcepl

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.

Jan 21, 2008 4:22 AM

MarkJayz

Hi jadestorm,

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??

best,

Mark

Jan 21, 2008 9:22 AM

jadestorm in response to: mcepl

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)

Jan 21, 2008 9:25 AM

jadestorm in response to: MarkJayz

Hi MarkJayz, that's a good idea =) Didn't think of it:
http://www.igniterealtime.org/issues/browse/JM-1250

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!

Jan 21, 2008 11:15 AM

mcepl in response to: jadestorm

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.

I am quite sure that OpenFire binary tar.gz as downloaded from your site (http://www.igniterealtime.org/downloads/download-landing.jsp?file=openfire/openfire_3_4_4.tar.gz) works with IcedTea, but I haven't managed to compile OpenFire with the free Java stack at all. I am not big programmer, even less Java programmer.

I will try to ask some of our Java gurus to comment here.

Jan 21, 2008 11:35 AM

AndrewHaley in response to: mcepl

Fedora 8 contains IcedTea, which is a pre-release spin of what will one day become Java 1.7. I don't know if it will run Openfire.

If you install the IcedTea development package you'll get all the usual JDK stuff.

yum install java-1.7.0-icedtea-devel

should do it.

To switch between gcj and Icedtea, use alternatives:

/usr/sbin/alternatives --config java
/usr/sbin/alternatives --config javac

let me know if it works.

Jan 21, 2008 1:03 PM

jadestorm in response to: MarkJayz

Hey MarkJays ... we actually already support that. I forgot about it.

if ~~-f /etc/default/openfire~~ ; then
. /etc/default/openfire
fi

If you look at /etc/default/openfire you should be able to configure that to set your vm options.

Jan 24, 2008 8:12 AM

MarkJayz in response to: jadestorm

thanks for your answer. thats cool - i'll give it a try.

Jan 25, 2008 7:48 AM

MarkJayz in response to: MarkJayz

didn't work for me.
i tried it with:

/etc/default/openfire:
DAEMON_OPTS="-Xmx24m -server -DopenfireHome=${DAEMON_DIR} \
-Dopenfire.lib.dir=${DAEMON_LIB} -classpath ${DAEMON_LIB}/startup.jar\
-jar ${DAEMON_LIB}/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=${DAEMON_DIR} \
-Dopenfire.lib.dir=${DAEMON_LIB} -classpath ${DAEMON_LIB}/startup.jar\
-jar ${DAEMON_LIB}/startup.jar $DAEMON_OPTS"

directly into the /etc/init.d/openfire script, it works fine.

Jan 25, 2008 10:20 AM

jadestorm in response to: MarkJayz

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!

Feb 6, 2008 1:43 AM