LDAP Shared Groups Not Updating Status Correctly

Running Openfire 3.4.5 linked to Novell eDirectory via LDAP. We have a shared group enabled. We can see all the users in the group correctly however the statuses seem to be incorrect for certain users. There are 90 users total in the group. On the server side, I can see the correct number of actively logged in users, say 13 for example. In my Spark Client (2.5.8), I see the same number, 13. But other users are seeing less, 10 or 11. Having them log off then back on does not do anything. I tried having them use a different XMPP client, Pidgin as a test and they are still seeing incorrect statuses. While the affected user may not be able to see certain contacts online, the contacts who are missing can usually see the user and initiate chat with that person. What would cause the clients to not update properly? Is there some type of issue with the shared group? I figured that logging off then back on would have forced it to grab the latest statuses but apparently not.

I do not believe that the shared groups are the issue. I would check the error logs of the spark users and the server when your are seeing this. Somewhere there is a communication error happening.

I just checked the error log of an affected user…

Mar 6, 2008 11:21:40 AM org.jivesoftware.spark.util.log.Log error

SEVERE:

No response from the server.:

at org.jivesoftware.smackx.ServiceDiscoveryManager.discoverItems(ServiceDiscoveryM anager.java:457)

at org.jivesoftware.smackx.ServiceDiscoveryManager.discoverItems(ServiceDiscoveryM anager.java:426)

at org.jivesoftware.spark.SessionManager.discoverItems(SessionManager.java:86)

at org.jivesoftware.spark.SessionManager.initializeSession(SessionManager.java:74)

at org.jivesoftware.LoginDialog$LoginPanel.login(LoginDialog.java:831)

at org.jivesoftware.LoginDialog$LoginPanel.access$400(LoginDialog.java:196)

at org.jivesoftware.LoginDialog$LoginPanel$1.construct(LoginDialog.java:594)

at org.jivesoftware.spark.util.SwingWorker$2.run(SwingWorker.java:129)

at java.lang.Thread.run(Unknown Source)

Mar 6, 2008 11:21:50 AM org.jivesoftware.spark.util.log.Log error

SEVERE:

Timeout getting VCard information: request-timeout(408) Timeout getting VCard information

at org.jivesoftware.smackx.packet.VCard.doLoad(VCard.java:532)

at org.jivesoftware.smackx.packet.VCard.load(VCard.java:507)

at org.jivesoftware.sparkimpl.profile.VCardManager.getVCard(VCardManager.java:320)

at org.jivesoftware.spark.ui.status.StatusBar$10.run(StatusBar.java:380)

at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)

at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)

at java.util.concurrent.FutureTask.run(Unknown Source)

at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

at java.lang.Thread.run(Unknown Source)

Mar 6, 2008 11:21:50 AM org.jivesoftware.spark.util.log.Log error

SEVERE: Unable to contact shared group info.

No response from the server.:

at org.jivesoftware.smackx.SharedGroupManager.getSharedGroups(SharedGroupManager.j ava:46)

at org.jivesoftware.spark.ui.ContactList$18.run(ContactList.java:1551)

at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)

at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)

at java.util.concurrent.FutureTask.run(Unknown Source)

at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

at java.lang.Thread.run(Unknown Source)

I enabled debug on the server side. I did not see anything in the error, warn, or info logs after clearing them. I did see the following in the debug logs. This particular user is in the same physical location is the Openfire server just as I am. She is seeing 2 or 3 less contacts online than I am. Any ideas?

2008.03.06 11:21:38 LdapManager: Creating a DirContext in LdapManager.getContext()…

2008.03.06 11:21:38 LdapManager: Created hashtable with context values, attempting to create context…

2008.03.06 11:21:38 LdapManager: … context created successfully, returning.

2008.03.06 11:21:58 005352 (01/03/00) - #10 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:58 005353 (01/03/00) - #8 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:58 005354 (01/03/00) - #9 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:58 005356 (02/03/00) - #10 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:58 005358 (01/03/00) - #8 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:58 005359 (01/03/00) - #9 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:58 005360 (01/03/00) - #10 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:58 005361 (01/03/00) - #8 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:58 005362 (01/03/00) - #9 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:58 005363 (01/03/00) - #10 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:58 005364 (01/03/00) - #8 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:58 005366 (01/03/00) - #10 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:58 005367 (01/03/00) - #8 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:58 005368 (01/03/00) - #9 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:58 005369 (01/03/00) - #10 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:58 005370 (01/03/00) - #8 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:58 005371 (01/03/00) - #9 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:58 005372 (01/03/00) - #10 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:58 005373 (01/03/00) - #8 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:58 005374 (01/03/00) - #9 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:58 005375 (01/03/00) - #10 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:58 005376 (01/03/00) - #8 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:58 005377 (01/03/00) - #9 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:58 005378 (01/03/00) - #10 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:58 005379 (01/03/00) - #8 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:58 005380 (01/03/00) - #9 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:58 005381 (01/03/00) - #10 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:58 005382 (01/03/00) - #8 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005383 (01/03/00) - #9 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005384 (01/03/00) - #10 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005385 (01/03/00) - #8 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005386 (01/03/00) - #9 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005387 (01/03/00) - #10 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005388 (01/03/00) - #8 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005389 (01/03/00) - #9 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005390 (01/03/00) - #10 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005391 (01/03/00) - #8 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005392 (01/03/00) - #9 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005393 (01/03/00) - #10 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005394 (01/03/00) - #8 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005395 (01/03/00) - #9 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005396 (01/03/00) - #10 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005397 (01/03/00) - #8 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005398 (01/03/00) - #9 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005399 (01/03/00) - #10 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005400 (01/03/00) - #8 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005401 (01/03/00) - #9 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005402 (01/03/00) - #10 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005403 (01/03/00) - #8 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005404 (01/03/00) - #9 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005405 (01/03/00) - #10 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005406 (01/03/00) - #8 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005407 (01/03/00) - #9 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005408 (01/03/00) - #10 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005409 (01/03/00) - #8 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005410 (01/03/00) - #9 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005411 (01/03/00) - #10 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005412 (01/03/00) - #8 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005413 (01/03/00) - #9 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005414 (01/03/00) - #10 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005415 (01/03/00) - #8 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005416 (01/03/00) - #9 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005417 (01/03/00) - #10 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005418 (01/03/00) - #8 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005419 (01/03/00) - #9 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005420 (01/03/00) - #10 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005421 (01/03/00) - #8 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005422 (01/03/00) - #9 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005423 (01/03/00) - #10 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005424 (01/03/00) - #8 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005425 (01/03/00) - #9 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005426 (01/03/00) - #10 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

2008.03.06 11:21:59 005427 (01/03/00) - #8 registered a statement as closed which wasn’t known to be open. This could happen if you close a statement twice.

Just a comment that will in no way help you… sorry…

I am using ldap via edir and sharing rosters through groups and all is working perfectly on 3 campuses, one of which is over 20 miles away and connected VIA a wireless link. Just set it up last week with the latest openfire server and spark client. Just mentioning this as I don’t think it is any kind of bug in the software…

As mentioned, it could be a communication issue or maybe a timeout issue.

Is it the same users all the time that are getting incorrect status information? If so, have you checked the network segments that they are on for twittering nics, problematic switches, etc?

Wayne

to add to waynes check list: any rogue firewalls or at least misconfigured ones.

Right now, I’m working with one specific user that has the problem. Another user was seeing the same issue earlier today but his roster list suddenly updated itself to show the correct number of online users. To rule out a network issue, I had this affected user attempt to log into Spark via Citrix, which I had previously done before she did and got all the correct statuses. She logged into Spark and was still short two contacts who were showing as online when I was logged in.

You talking about a citrix virtual desktop?

that would just mean that the citrix server does not have a network problem where the workstation does, right?

You know, it could be something to do with that particular workstation… does it have any funky software firewalls running? disable them all… Then check for junkware, toolbars, and bandwith eating apps that may be running on the desktop… You may want to do a msconfig and disable everything and then test…

I am really starting to think that it is something on that computer.

Wayne


and don’t forget a full virus scan and anti-spyware scan as well…

Sorry, maybe I wasn’t very clear in what I said. Basically I had the affected user try logging through Spark published through the Citrix session and she got the same result. When I logged into the app published on Citrix, I saw the correct number of users online. This would seem to rule out a network problem as we both logged into Spark from the same Citrix system with two different results. As to her personal machine, there are no firewalls enabled, we update or AV daily. She really doesn’t have anything else on there that I could think of causing a problem. Being that she saw the same thing on the seperate Citrix box, it doesn’t seem to be specific to her PC/Network Connection, Etc.

Well, I really don’t know…

I do have to ask though… Have you logged in as this “affected” user from your computer, and if so, did you get the same result as she did from hers? Another words, does the problem follow here around from if she logs into spark on different computers… Just gotta know…

If it does, then it just seems like it does not like her user account for some reason…

Wayne

Yes, this is what I was trying to explain. Citrix is “another computer” so the issue did appear to follow her around because she had the same issue logging to Spark on there as she did on her personal desktop PC.

Now, I do have some more information. The three people that she was not seeing as online in her list logged into the Openfire for the first time this morning. These three individuals, who are members of the shared group, were also seeing similar behavior in that they were not able to see all the online contacts either. One user was seeing 11, another user seeing 12, etc. So I had these users logoff and back on a few times earlier today to see if that would clear up the issue. It did not. They still were not seeing everybody, and some folks who had been on Spark for the past couple days were not seeing them. A few minutes ago, the three users who logged in this morning logged back out then got back on again. They were now seeing all 13 contacts who are online. Also, the user who I was working with before received the updated contact list to reflect these three missing individuals. She did not have to do anything. Most likely, when these users logged back on, her roster got updated to reflect their statuses.

In general, I’ve seen some odd things happen when new users log on to Spark for the first time. Usually their contact lists don’t populate and logging off and back on fixes this. However, is there some caching that happens that takes a while? In other words, when new users log in, does something have to happen in order for their statuses to fully propegate every other user’s contact list?

I thought it might be helpful to provide an update on this issue.

After reading this post http://www.igniterealtime.org/community/message/122160#122160 which I know is quite old, I decided to comment out ldapgroupprovider. I then manually created a local shared group using the eDirectory accounts. I’ve been running this configuration with Openfire 3.4.5 for the past two months and have not encountered the status update issue since.

While I understand there are some here that are successfully using eDirectory LDAP groups with Openfire, perhaps there is still a bug somewhere that is being exposed in our environment. I’ve checked everything from network connections, to PC hardware, firewalls, etc but commenting out ldapgroupprovider has been the only fix that has actually worked.

Thanks

I can confirmed this bug.

my environnement is :

openfire version : 3.5.0 (tried as well : 3.4.1, 3.4.3 and 3.4.5 with same error)
OS = debian etch (4.0)
openldap version : 2.3.30
users = around 150user pulled from LDAP
groups = around 50 groups pulled from ldap and all shared groups to all users.
backend = mysql 5.0.32

ISSUE= everything works except the status are not updating at all ( all subscription are equal to “TO” when it should be “BOTH” in any roster ) my users need to logout /login again to see the online user.

  • i tried the upgrade solution ->same issue

  • i tried the scratch fresh install ->same issue

  • I tried setup the ldap manully into the config file instead of the wizard –>same issue

  • I tried flushing cache adn restarting the server –>same issue

  • i tried different version ( from 3.3.0 to 3.5.0)-> same issue

  • I tried changing the varchar(50)of the mysql tables to varchar(255) and flush the cache and restart (from Group name length - Openfire Support - Ignite Realtime Community Forums )-> same problem.

The only workaround (IT"S not an acceptable solution for my company) is to fetch the user from ldap but create all the groups manually and populate them manually .–>but it’s voiding all the point of using the LDAP features.

The shared groups feature are not working.!! that’s a fact. So can someone please accept this forum thread as a bug and fix it… i’m happy to provide any details/debug and even beta test any solution or piece of code.

Cheers, Aurelien

I think this is the same problem we are seeing with 3.5.1. When I add someone to an ldap group they appear in the group in openfire straight away, but not in the rosters of other people in that group. If I “disable contact list group sharing” for that group, save settings, and then enable it and save settings, then all the users in the group can see each other. It looks like group rosters are static and not pulled dynamically from ldap. This manual refresh from ldap seems to fix it, but it would be nice to not have to do it. After that they all have “both” for subscription and the locked symbol under the delete column like they’re supposed to.

Daniel.

Hi ,

I noticed it like danile that disbale and reenable the "shared group to all " on teh group make all teh user in this group subscription changed to BOTH. ubtil they log again. next time all my users log in the server (happens every morning) all subscription are back to “TO”

Youhou Could any openfire devs/contributors have a look to this issue ?

Cheers, Aurelien

I am confirming this bug as well in openfire 3.5.1. linked to Win2003 AD. If I, or anybody else for that matter, have already logged into Spark and recieved the roster and then made changes in AD to the groups the changes will not reflect until I un-share and re-share the group.

Also, if a user was at one time in multiple groups and then taken out, un-sharing and re-sharing the group will make that user appear in the group that he/she is no longer a part of when they never appeared in that group on my roster in the first place.

Can we get some help with this? Pain in the ass getting to look right after you make changes.

Spark does not instantly sync changes made in AD or in shared groups on openfire. Sometimes saving the changes twice helps, also quitting spark and relaunching generally will cause changes to take affect. The biggest issue is AD changes take time to replicate to Openfire the even more time to replicate to Spark.

I have never had to un-share then reshare to make changes take affect.

Thats not entirely true, if I unshare the group it immediatly disappears from Spark. Re-sharing it is what takes time. Sometimes I have to log out and back on to see the group again if I get tired of waiting.

I know AD takes time to replicate, but in a small environment with 2 DC and less than 100 clients how long should it take to replicate to openfire? Because I took a user out of a group in AD over an hour ago and he still shows in the group in the admin console. I am afraid to un-share/re-share a group because I don’t want members who aren’t in the AD group anymore to suddenly show up in the openfire group. Which is happening.

Is there anyway to force a re-sync with AD? Reboot the server?

The only manual processes right now are purging the cache and restarting openfire. There is an issue open for a manual resync option for openfire.

I think Dreudown you are speaking another issue thant the one explain in this thread :

Your issue is :

when the groups are update in AD : the update does not happens (like it should be ) into teh openfire server.

The issue on this thread is :

when using openfire with LDAP and shared group : the buddies status are not updating preoperly (all roster subscription remains to “to” instead of “both” ).

Do you have this “roster status not updating” issue as well ?

Cheers, Oly

I can confirm the “roster status not updating” issue, what can we do to get this some attention? Do we have to fire a bugreport?

Kind regards,

Muldini