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.
=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?
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.
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.
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.
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.
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.
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 ;):
Some sort of whitespace issue?