powered by Jive Software

Openfire 3.4.3 has been released

We are pleased to announce the release of Openfire 3.4.3! This release includes a number of nice improvements such as the ability to store avatars in the database even when LDAP is being used (60 votes!), new packages for Solaris and Debian systems, and a slew of performance improvements. A complete list of changes can be found here.

The SparkWeb client included in the Enterprise edition has been updated too. Lots of bug fixes and performance improvements have been made, including support for HTTPS and programmatic launch for SSO. You can use the SparkWeb client from here.

We are also releasing two new plugins alongside this Openfire release! The MOTD plugin, brought over from Ryan Graham’s work, allows administrators to have a message automatically sent to users upon login. The new Email Listener plugin listens for emails and sends alerts to specific users, and was highly voted for at 32 votes! Plugins can be found here.

Download Openfire from here.

Download Openfire Enterprise from here.

Download Connection Manager from here

Enjoy!

Openfire Team

wohoo! THANKS FOR THE DEBIAN PACKAGES!!!

b.t.w. whats the correct way to install them?

edit /etc/apt/sources or just download and install the .deb?

best regards,

Mark

For the other debian people out there:

i just installed via dpkg -i thepackage.deb

then i stopped openfire via /etc/init.d/openfire stop

then i copied my configuration and keystore from the old manuall install to the new debian directory via:

cp /opt/openfire/conf/openfire.xml /etc/openfire/openfire.xml

and

cp /opt/openfire/resources/security/* /etc/openfire/security/

and since my system is a bit low on memory (probably applies to everybody using a vps / vserver) i had to edit

the /etc/init.d/openfire script.

i just added:

“-Xmx24m” in front of “-server”, which limits openfire to use 24mb of ram, which is enough for my config, but my not be enough for yours.

have fun and thanks for this great release!

=D For future updates, you shouldn’t have to make a copy of your config files. The package should protect them for you.

And since you brought it up (regarding the sources files), we are evaluating setting up an APT and Yum repository for the DEB/RPM packages, respectively. =) Just working out the logistics.

I tried installing this on ubuntu, but it looks like the debian package depends explicitly on sun-java5-jre, which apparently is the only sun java jre package available in the debian repositories, but with ubuntu, there is a newer sun-java6-jre which I’d like to use, but can’t with a simple dpkg -i install.

Can I skip the requirement for java5 package, and with java6 installed, will openfire still work?

Any way to setup the deb package to accept both java5 and java6 jre packages?

Thanks.

Howdy! I was working with one of the Ubuntu developers on that package and we decided to go with the java5 requirement for now. There were, unfortunately, a number of things I needed but could not depend on. Most of which was, no /etc/alternatives/jre that would have been provided by any of the packages. It’s easy for my to set a depends of sun-java5-jre | sun-java6-jre, but I have to set JAVA_HOME at one point. =(

One of my tasks though is to hop on the debian java list and see if there is a workaround!

If you skip the requirement, you may need to tweak some variables in the init script, but otherwise you should be good to go!

I had some serious troubles installing the Openfire package for Debian on an Ubuntu JeOS VM where sun-java6 was already installed:

After java5 was installed Openfire starts fine but Active Directory LDAP authentication fails with something like "Parenthesis not matched, looking for ’ ’ " and a biiiig error. No login neither with the client nor to the admin interface possible.

Same for the old manually installed 3.4.2.

Uninstalling/reinstalling Java5 and/or 6 does not help. I just reloaded my snapshot (oh I’m so happy I took one).

Uninstalling Java6 completely BEFORE installing Java5 and openfire.deb did the trick.

Btw. changing the init.d/openfire to use java6 got me to the same error than java5 (additional note: if you don’t use LDAP, it might work to run it with java6 on Ubuntu)

I don’t have the time to check if it always screws up this way. I just like to point out that it could happen, before someone with a live system runs into it unprepared ;).


One more thing:

The .deb installs Logfiles as group/world readable. This is IMHO a security concern at least for the debug.log which logs plaintext passwords for LDAP and transports (and probably more).

The debug logs have plaintext passwords in them? I’ve never witnessed that.

So debian’s java 6 and java 5 don’t get along? That’s… uncool. If I were to hedge a guess, I would say that it’s setting JAVA_HOME to that of java6, but using java5, and running into stupidity on that front.

JeOS VM? What is that?

Regarding the logs: JM-1231

Good catch!

Using LDAP, but having a problem storing avatars in the database with the new release. I keep getting an error:

Server does not support VCards. Unable to save your VCard.

I have verified that the ‘ldap.override.avatar’ property is set to true.

I’m investigating this problem with mtstravel at the moment. Stay tuned. (so far it doesn’t make any sense)

Some of our users are seeing the same issue. Looking at the code my initial guess is that the vcard data, other than the avatar, is being altered at some point so that it fails in the LdapVCardProvider#isValidVCardChange, which in turn doesn’t allow the saving of the avatar. For users where this isn’t working if they open up their profile in Spark, don’t change anything, and click on the Save button they receive the same error.

What we’re seeing at the moment is that it’s failing on the fullname check.

The bizarre thing is, there does not appear to be anything difference between the two at all. Printed side by side they look identical. =/

Hmm… :confused: Some sort of whitespace issue?

that’s what I was thinking, but I can’t imagine what at the moment! Nothing appears to different on that front. =( I can’t catch any byte-level differences. Yarg. =(

Maybe I should offer an ability to say “I don’t care about the verification, let it fly” hidden option. Who knows, it might come in handy.

jadestorm wrote:

that’s what I was thinking, but I can’t imagine what at the moment! Nothing appears to different on that front. =( I can’t catch any byte-level differences. Yarg. =(

Bummer…

Maybe I should offer an ability to say “I don’t care about the verification, let it fly” hidden option. Who knows, it might come in handy.

I could see that. And/or, I wonder if the logic should be reworked to not use the isValidVCardChange method when updating the avatar if LDAP is being used?

I had the user I’ve been in contact with use Exodus to see if it was a client issue but they still were not able to save their avatar, which would seem to point towards it being an Openfire issue. The account I have access to doesn’t have the issue so I don’t have an easy way to investigate the problem.

For the record removing all vCard mappings resolved the issue. So that being said I tried removing just the mapping at the failure point <FN></FN> and the problem also goes away. This seems to be the point of failure. I wonder if it has to do with Spaces in the names or an AD checksum.

mtstravel wrote:

For the record removing all vCard mappings resolved the issue. So that being said I tried removing just the mapping at the failure point <FN></FN> and the problem also goes away.

Good to know, thanks!

I wonder if it has to do with Spaces in the names or an AD checksum.

Something along those lines would be my guess, too.

I got this working easily by changing the JAVA_HOME variable to my java6 jre path.

BTW, I noticed that both debian and ubuntu packages link the java binary to /usr/bin/java for java5 and java6 jre packages. That location links to /etc/alternatives/java, which in turn links to the /usr/lib/jvm/… path.

I would think then that setting JAVA_HOME = “/usr” since the java binary is at /usr/bin/java and links to the active java binary.

It’s a mute point anyway since I’ve using the 1.6u3 binary right from sun’s website since ubuntu only has the 1.6 original release available. Even still, it would be nice for it to install without forcing it.

Happy new year to you all

Concerning Passwords in debug.log:

At least the LDAP connection is logged with the password. I’v seen it in there *g.

I’m not so sure about the rest. I just thought debug would log absolutely everything “as is”, even passwords.


JeOS is an Ubuntu with optimized kernel & modules for VMware and a minimum software selection. It’s basicly small, fast and not very demanding and everything else is Ubuntu/Debian ;):

http://cdimage.ubuntu.com/jeos/releases/gutsy/release/