I’‘ve seen some hinting at this on the forums, but I thought I’'d tell about my testing.
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.
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…
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.
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
(I’‘m using egroupware so that’'s what that phpgwAccountType business is)
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.