[jabberd] Some jabberd2 enhancements and corrections

Nikita Smirnov nvs at fromru.com
Sun Mar 21 22:31:22 CST 2004


Hi!

Lately I worked on jabberd2 adoption to my corporate network, and I seen that 
it lacks for some features and has some nasty bugs.

Here is files:
http://nvs.fromru.com/jabberd-2.0s2-nvs-patches.tar.gz

Now short description.

At first, features :)

All authorization and user accounts data in my network stored in LDAP.

, and write access to this data has only administrators of appropriated 
systems.

So I wanted that authentication of users and retrievial of user's info worked 
with LDAP. I rewrote authreg_ldap.c module and called it authreg_ldapfull.c, 
with it not only plain text authentication allowed (but as negative side, 
password stored in cleartext, but as another positive side, not in 
userPassword attribute). I wrote it with ldap_initialize, so multiple ldap 
servers in form of LDAP URI may be specified (I didn't added checks to 
configuration script for ldap_initialize in ldap library).

I wrote module for vcard retrivial from LDAP (read-only), called 
storage_ldapvcard.c. You may specify ldapvcard storage driver for type 
'vcard'

Next wanted feature was roster updates for each user when new corporate user 
created, deleted, or moved to another department. I called this feature 
"published roster". I implemented it on base of mod_roster (created new 
module mod_roster_published) and storage_ldapvcard (added new storage type 
"published-roster"). I made this feature so it affects only corporate 
contacts of user's roster, algorithm described in supplied patch to 
sm.xml.in.dist

All features configured with appropriate config files (examples are in patches 
to sm.xml.in.dist and c2s.xml.in.dist)

Now bugs and fixes.

Bug in 2.0s2's authreg.c cause c2s to crash when removing user. See 
http://www.jabberstudio.org/projects/jabberd2/bugs/view.php?id=3368
or patch-c2s_authreg.c

SM leaks havily. If it doesn't, kick me ;-)

I found (thanks, dmalloc) only one obvious place where memory was not freed 
(see patch-sm_storage_db.c).

But I found one thing that I can't call bug, but sm leaks indirectly because 
of this thing.  Leak (one of many) happens somewhere in mod_roster in 
user-load chain. When user becomes online, sm tries to load/use each other 
user's data for some reason. If user which data is to be used is not online 
(and is not loaded already), data loaded from database and then freed. But as 
I can see, roster is not needed in that situation (loading roster for each 
offline makes big cpu overhead), and I corrected mod_roster.c, sm.h and 
sess.c so roster loaded only for that user for which session is created now. 
This is dirty hack, but memory now does not leaks so fast and sm does not 
consume much cpu time at every user registration.
I have no time for debugging leaks, but when I compiled sm with dmalloc, I 
seen that biggest leaks happens with jid's and pool's.

I supplied file with openldap schema called local.schema. It uses unregistered 
OIDs, you warned :-)

Please let me know if you have any suggestions, and correct me if I was wrong 
or said things that already has been discussed.

And sorry for my English ;-)

-- 
Nikita.




More information about the jabberd mailing list