There might be another issue with the *.deb (or a fault on my side?)
My logfile tells me that OF tries to log the jive.autdit to /opt/openfire/logs which is not existing as they are in /var/log/openfire.
No.2 wrote:
There might be another issue with the *.deb (or a fault on my side?)
My logfile tells me that OF tries to log the jive.autdit to /opt/openfire/logs which is not existing as they are in /var/log/openfire.
Hrm. That setting is stored in the database, so it’s probably leftover from a previous install. If you go under Message Audit settings in the admin console, you can change it to the proper path.
BTW, thanks to Francisco and the Debian Java team, we will be able to support “sun-java5-jre | sun-java6-jre” for dependencies for the next release. =)
Also, for those having issues with the avatars in LDAP, we have 3.4.4 in QA with a planned release on the 17th. We have moved to the “release train” so to speak at this point so we will be regularly releasing every 3 weeks with 3 weeks of QA before a release. (though we may be shifting the next couple of releases just a tad to sync them up with some other release trains) Anyway, stay tuned! =) Already the QA process has uncovered some things you all would have run into so I’m very excited about embracing the new process and getting much longer and more involved testing time!
I have to say sorry to Java/Debian and the openfire.deb. The issue I described has nothing to do with Java1.5 or 1.6 it just occured at the same time and that was the only thing I thought I’d changed…
Problem has been caused by saving the same information again (so I really didn’t change a thing).
If you put a “&” into your LDAP filter (both user and group filter) the webserver converts it to “&” which of course screws the filter, so LDAP-lookup throws the exception. This has worked fine in the past, so it never occured to me to check the filter (that worked perfectly, and that I never changed). I probably was browsing through the backpanel setup and thus was saving the already existing entry to get to page 3…and after a restart the whole thing went down the drain…
You would’t believe how happy I am to actually found this error Thanks for fixing it (or telling me, why it’s my fault :P)
BUMP
Could someone please either confirm or reject that this is a general error (and need to be fixed quickly, which should be fairly easy)? Thank you!
What error are you talking about? The last thing I saw you say was “thanks for fixing it”.
I’ll never again say thank you in advance bg
I was talking about this one:
If you put a “&” into your LDAP filter (both user and group filter) the webserver converts it to
> &
which of course screws the filter, so LDAP-lookup throws the exception. This has worked fine in the past, so it never occured to me to check the filter (that worked perfectly, and that I never changed). I probably was browsing through the backpanel setup and thus was saving the already existing entry to get to page 3…and after a restart the whole thing went down the drain…
I’ve seen…the HTML-Code was partly interpretated in my posting above…so it was quite not so understandable what I meant.
Aha. JM-703 is related to this.