Status/presence with LDAP rosters

I’‘ve seen some hinting at this on the forums, but I thought I’'d tell about my testing.

I’'m running

  • Jive Messenger 2_3_1 server (I tried the latest wildfire nightly build as well)

  • Spark, Pandion, and Gaim clients (all do the same thing)

  • OpenLDAP with users and groups and a group roster

Presence packets for users in a roster are not being passed on from the server to the clients in the same roster. I watched the packets.

  • Client A (Spark, Pandion, and Gaim) does correctly send the correct Presence packets to the server when logging on, logging off, going Away, etc.

  • The server does get these and change the local Presence tables as listed on the Sessions page on the Jive Messenger admin page immediately as expected.

  • But, other another client B that only has client A listed in the roster account on the server does not receive the presence packets about A from the server.

  • If client A is online, it will not see B come online for the same reason.

So basically, if you have a roster set up, and that’‘s the only way you have a “buddy” in your list, then you won’'t see their status (online, offline, away, etc) after you log on.

A work around is to put all the clients you wish to contact in your client and Jive Messenger server will forward presence packets. Of course, this is no good for large, automated, dynamic deployments.

Another workaround is to logoff and log back on on a client to recieve the current Presence table. But of course, this is not very helpful either.

The reason I would really like to see this working correctly is I’‘m writing a plugin that will forward messages (I’‘m doing email first, then probably sms or another gateway) when the target is away or otherwise probably not there. My code works as the target client sucessfully tells the server if it is away or not, but the clients don’‘t know when they are browsing their roster list… and those lists can change often. For me, I’'ll just post back a message telling the sender that the recipient was away and the message has been forwarded… surprise! he was away

If someone that knows the code better than I would like to point me in the right direction, I will certainly look at fixing this… I’‘m just not sure where to start looking. Somehow, server side rosters aren’'t being treated the same as client side rosters when it comes to presence packets… or something like that

but you know… the strange thing is… I could have swore this worked for a little while when I first installed the server… when I tried the wildfire build I just installed it, set up the group roster, and connected… thinking that maybe some setting I set broke it … but no go.

same problem here, jive + ldap authentication and state information doesn’'t seem to be passed to clients (tried spark gaim and pandion). :confused:

I found this thread:

http://www.jivesoftware.org/community/thread.jspa?threadID=15284

and indeed setting the shared roster to “Show group in all users’’ rosters.” works, i.e. sends Presence packets correctly, but then near constant traffic goes between my server and all my clients as every user in the LDAP is sent to it. I can see them in the “Offline Group” in Spark.

They mention the roster cache and where to find this cache in this thread… let me see if some hackery can fix this up…

If I then change the roster setting back to “Show group in group members’’ rosters” then it still works… but I bet for only a little while…

… yep

  • So I realoaded the database (which dosen’'t have much in it when you use LDAP) - no go

  • Changed the caching stuff around that I could see… basically tried to disable cache - no go (and lost my user listing)

  • Tried to change my LDAP filters so that only a select few users would be in the “Show group in all users’’ rosters.” … I got only those select users in there with the filter … set to “Show group in all users’’ rosters.” - no go (still wouldn’'t update status… it looks like status will only be updated if you are sending a constant dump of the whole LDAP… probably overloading cache?)

So it’‘s got me licked without more help … I’'ve eliminted ldap groups from my config and just set up the groups manually inside mysql. This works great so far. I still use LDAP auth and user.

This problem persists even when i use direct connection (with one subnetwork).

I’'ve got the same problem as you.

Tried it with the latest versions of the following clients PSi, Pandion, BuddySpace, Coccinella, Gaim on Windows XP and Adium X on Mac OS X.

Same problem here, I really hope someone is able to fix this.

I use the third group share option as a workaround : “Show group to members’’ rosters of these groups”

and then just select the group that you are sharing.

That does the same as : “Show group in group members’’ rosters” (i guess)

But the roster updates work ! (for me)

I hope the developers will treat this as a BUG and fix it.

EDIT : Now it seems that this only works when ONLY the shared group is selected, selecting more groups from the list will cause the roster updates to fail again

Message was edited by:

Dopehead.NL

Message was edited by:

Dopehead.NL

This could be helpfull for all of you.

By default I had an empty setting in config file

groupSearchFilter (if it is empty it’'s equal to memberUid=*)

after I set it like this

everything works fine

Do you mean to say, you had the same problem, and this is a definite fix ?

If so, I will try it tommorow and report back.

The config file we use has a groupSearchFilter so it doesn’'t use the default setting.

We’‘re using Active Directory so the filter you’‘re using doesn’'t work for us

I’‘m using openLDAP, not AD… problem is there. What really does it for me is using LDAP users/auth but using SQL groups… little more work that way, and not nearly as slick, but it does work… leads me to believe that something in the LDAP group provider isn’‘t jiving… I thought it was maybe just my group search string too, but that didn’‘t work. mine’'s

/code

(I’‘m using egroupware so that’'s what that phpgwAccountType business is)

EDIT : Now it seems that this only works when ONLY

the shared group is selected, selecting more groups

from the list will cause the roster updates to fail

again

Dopehead.NL

Prepare to pull your hair out as it seems to work for a second, and then quit, and then you can’'t reproduce it. I should make some cafe express tshirts to that effect

Hmmm, yea I noticed…

After that experiment I could not get my Wildfire to go back to the old situation.

Sharing just one group to all users did not give me updated rosters anymore. (as it did before)

I guess some setting gets in the config somewhere and it does not come out anymore.

I fiddled around with the wildfire.script file, since it kept mentioning my already removed shared groups, but to no avail.

I ended up removing an re-installing the wildfire package. I had saved the XML file

When I shared only one group to all users again, updates are working, but my manager is not pleased

Please have the developers take up this BUG.

We need AD authentication… bad…

Message was edited by: Dopehead.NL

TYPO’‘S (why don’'t I use the preview button, silly me)

Er… AD authentication works right? Just not AD (aka LDAP) grouping presence notifications, right?

Exactly, sorry if I was not clear about that.

To get my manager happy, I am gonna test if we can work with AD (ldap) authentication and not the AD groups, but use the build in database for groups.

That should work, no ?

That will definitely work… I do it… not with AD, but with OpenLDAP… but that’'s an ok difference.

So users will use their AD login/pass, the list of users will also be from the AD and be listable in the admin interface of Wildfire, but the groups that that users are in will be in the MSSQL/embedded/mysql/whatever that’'s not LDAP database… and you can push those groups out just fine to contact lists and the presences will update just fine.

It’'s only a little duplication of work, I guess, as you can copy/paste a large amount of users from the user listing (which is straight from the AD) in to a group at a time via the admin console when you create a group.

Ok, thats great, it might even be better, since we have 15 pages of groups from the AD, and I only need like 1 or 2.

And it will also take care of users who appear in more then 1 group I want to share.

They would (natuarly) show up on/off-line in both groups.

By having ‘‘hand made’’ groups I can avoid that.

I still hope they fix the problem though, it would be slick to use AD.