I had this problem too but i was able to fix it with the group search filter. I dont have the file here now but was able to piece together a solution from one of the other threads. Wildfire is so picky with its ldap integration. I believe my group search filter was:
(&
(member=)
(objectClass=group)
)
Hope this helps
Gato,
Looks like the presence problem still exists for us. I used the latest nightly (July, 9) build. I turned on debug but wasnt able to get much. Here is a screen shot.
http://www.tfponline.com/wildfire.jpg[/url]
and here is the debug log
http://www.timesfreepress.com/debug.txt[/url]
Let me know if there is anything else I can do.
Hey snowman386,
Could you share with us more information about the modification you made to the filter? Which was the old filter and how is the new one? Which was the problem you fixed by changing the filter?
Thanks,
– Gato
Gato,
Just tried the 7-10 build and problem still exists for me as well. From what Ive read, it sounds as though Poppa Smurf and I are seeing the same bug. I am using AD integration for both user auth and shared groups. Only users with a cn/name of “last, first” are not sending presence updates when they login.
I also notice that in the Admin GUI, a user with the problem (a comma in the cn/name) shows “None” for Group under Properties (Users/Groups then click on a user…). If I choose a user without the comma, it shows the AD shared group.
My user and group filters currently looks like this:
<![CDATA[(&(objectCategory=Group)(objectClass=group) (memberOf=cn=All IM Groups,ou=CORP IM Groups,ou=CORP IM,ou=CORP Groups,dc=corp,dc=somewhere,dc=com)
(member=))]]></groupSearchFilter>
Let me know if any other information might be helpful.
Poppa Smurf,
Do you see the same issue I see in the Admin GUI as well?
-Andy
Hey Andy,
Is there any chance you can provide me a vmware image with a similar LDAP server so I can reproduce the problem? I have ADAM here which is a lightweight version of AD but not quite similar.
Could you also post the .ldif content for a user with comma and another with out comma? I would like to check the sAMAccountName and member values (amongst other things).
Thanks,
– Gato
Hey Smurf,
The log that you captured is when a user logs in (and authenticates). Since the problem seems to be related when retrieving the user’'s groups could you also try capturing that information? You can log into the admin console and get the user details to see the user groups.
BTW, just like I asked Andy could you also post some sample ldif of your users, the filters that you are using and maybe some screenshots of the users in the admin console?
Thanks,
– Gato
I’'ll need to work on that. Our production domain consists of a parent and 5 child domains. Not something that is easily managable. I should be able to setup a standalone Windows 2003 server/domain and reproduce the issue however. Then Ill just need to figure out how to create the VMWare vmx…I dont own VMWare. Will take a couple of days.
I’'d prefer not to post the ldif content on the forum, can I email it to you?
-Andy
Hey Andy,
Feel free to send me by email the ldif files. I will see how to process them into my ADAM instance.
Thanks,
– Gato
Hey guys,
Thanks to Andy’‘s help I was able to gather more information about this problem. The next nightly build includes a bug fix for this problem. Since I don’‘t have an AD (yet) to test the fix I’‘m going to ask you if you can confirm that it worked for you. I partially tested and at least it won’'t produce any exceptions.
Thanks,
– Gato
Gato,
Great working with you yesterday. I’'m not sure if the change made it into 7-11, but I tried it this morning and problem still there. Let me know if I can be of anymore help.
-Andy
Hey guys,
We have good news for you. The problem is fixed now. You can find the fix in the next nightly
build (wildfire_2006-07-12) or if you are using SVN then update your install. Thanks to Andy we were able to identify exactly the problem we were having and he also helped me test the fix.
Regards,
– Gato
Hey everyone. Sorry, this is my first post and hopefully no one will kill me for this. I’‘ve been following the development of Wildfire for awhile now and I’‘ve noticed that shared roster groups have been a nightmare for just about everyone attempting them. I’‘m currently running an ejabberd installation (http://ejabberd.jabber.ru) and they, too, have their share of issues with this feature. (Visit the site and you’‘ll see I’'m partially responsible for a note on the main page regarding a bug in their implementation.)
So it was with high hopes that I decided to test Wildfire 3.0.0. Now I won’‘t bore you with details on the why’‘s/wherefor’‘s of running ejabberd over Wildfire in the first place/etc., but let’‘s just say I was blown away by Wildfire’'s installation/setup. The admin console. Wow. What a beautiful interface. And in general the entire installation process. Anyway, just wanted to get that in there before digging in. You guys have done a wonderful job from a UI perspective, and with this project in general. Please keep it up.
Now as shared roster groups and proper basic presence/IM functionality are key to us, I thought I’‘d begin testing Wildfire to see how it held up vs. ejabberd. In short, shared roster groups appear to be a real headache for developers. I’'ve found almost identical issues with respect to shared roster group usage in Wildfire as occurs in ejabberd. I suspect it revolves around handling the subscription settings, pushing the rosters down to clients, etc., because so far no one seems to have this working as one might hope.
However, in the process of my testing, I did start building a test case for the developers which I HOPE will at least give them an indication as to where to look. The following instructions are with regard to a basic setup (no LDAP, no fancy configs) and are reproducible EVERY TIME. Except where noted in square brackets, the results were identical between Wildfire 3.0.0 and the nightly build wildfire_2006-07-11. If there is anything else I can do, please let me know. I apologize in advance for the length of this message, but the test case should help track down some of the remaining issues.
FYI: Yes, you have fixed at least a few of the issues (see lines below in square brackets), but by no means is presence being handled properly at the moment. See the lines which say [BUG] at the end. For a product touting itself as an enterprise IM solution and offering paid support services, this is simply unacceptable. It may, at least for the time being, be advisable to do as the ejabberd folks have done and warn your users/customers that shared rosters do funny things to presence notifications/etc.
Final comment: In ejabberd, one of the other issues involving shared roster groups was what happened if a client renamed a roster entry that was part of a shared roster group. Basically, renaming a user could make them simply disappear from the roster (e.g., renaming ‘‘usera’’ as ‘‘Frank’’ on userb’‘s roster). However, a quick check of Wildfire at the end of the steps below shows I was able to rename users to my heart’'s content in any of the four clients I used, even shutting down/starting Wildfire, and all ran beautifully. So kudos on that! I am very impressed with how Wildfire is progressing.
SETUP
Windows XP SP2 with all updates through 11 July 2006
Sun Java JDK/JRE v1.5.0_07
Wildfire v3.0.0 (and nightly build)
Pandion v2.5 Windows client (usera)
Exodus v0.9.1.0 Windows client (userb)
Psi v0.10 Windows client (userc)
JAJC 0.0.8.114 Windows client (userd)
All client connections are done from the same box running the server, though NOT using the loopback (127.0.0.1) address, but rather a fully qualified domain name (FQDM), as one would do in a production environment. This means results should be the same regardless of whether clients connect from the local box or around the world. To make it possible to test easily from one box, I used four (4) different XMPP clients, one for each test account used below.
Reproducible steps to show presence/shared rosters not working properly:
INSTALLATION OF WILDFIRE
WHEN TESTING NIGHTLY BUILD:
1.1. Rename ‘‘wildfire’’ directory to ‘‘wildfire_2006-07-11’’
1.2. Decompress wildfire_2006-07-11 nightly build on top of 3.0.0 install
1.3. Rename ‘‘wildfire_2006-07-11’’ back to ‘‘wildfire’’
INITIAL CONFIG
Execute C:\Program Files\wildfire\bin\wildfire.exe
Once initialized, click [Launch Admin].
Choose Language: (*) English, [Continue]
Domain: set to test box FQDM, [Continue]
Select (*) Embedded Database, [Continue]
Set
Admin Email Address:
New Password:
Confirm Password:
and [Continue]
This brings up the admin console webpage.
Click ‘‘Login to the admin console’’
Login with username ‘‘admin’’ and password set in step #7.
Leave all server settings at default. (Presence issue seems to apply regardless)
Click ‘‘Users/Groups’’ tab
Click ‘‘Create New User’’
Username: usera (fill in rest as you like), [Create & Create Another]
Username: userb (same), [Create User]
[NOTE: For testing, I tend to create users with passwords set the same as the username. To usera has password usera, userb has password userb, etc. Makes testing go quicker.]
Verify users exist by clicking ‘‘User Summary’’
Login with XMPP client as usera to verify account active/working. (I used Pandion 2.5 in my case)
Login as userb with another client to verify account active/working (Exodus 0.9.1.0 in my case)
Back in admin console, click ‘‘Sessions’’ tab to verify accounts logged in.
Logout of both accounts/quit clients for now.
Refresh ‘‘sessions’’ page & verify users logged out.
Click ‘‘Users/Groups’’ tab
Click ‘‘Group Summary’’ to verify no groups exist yet
Click ‘‘Create New Group’’
Group Name: group1
Initial Member(s): usera,userb
(*) Enable sharing group in rosters
Group Display Name [Test Group]
(*) Show group in all users’’ rosters.
[Create Group]
Click ‘‘Group Summary’’ to verify group created.
Login as usera. No ‘‘Test Group’’ appears, no userb in roster. [BUG]
Login as userb. ‘‘Test Group’’ appears in roster, with usera showing as online.
Logout usera. On userb’'s roster, usera remains showing as online. [BUG]
Logging back in/out as usera has no effect; usera does not get ‘‘Test Group’’ and userb does not see usera presence accurately. [BUG]
With usera logged in, logout userb.
Log back in userb. usera shows as online and stays that way even if you logout usera. [BUG]
Logout both usera and userb.
Login userb. usera does not show (as expected)
Login usera. In userb roster, usera STILL does not show. [BUG]
Logout usera and userb.
[Stop] Wildfire server. [Start] Wildfire server.
Login to admin console and verify users and groups are intact.
Login usera; NOW you get ‘‘Test Group’’ in usera’'s roster.
Login userb; NOW presence works as expected.
Try various logins/logouts of usera and userb; all works now.
In the admin console, click ‘‘Users/Groups’’ and ‘‘Create New User’’
Username: userc
Login userc (Psi 0.10 in my case) to verify acct. userc roster shows ‘‘Test Group’’ and both usera & userb; both show online, but presence doesn’'t change even if usera or userb sign off. [BUG]
Logout all users. [Stop] Wildfire server. [Start] Wildfire server.
Login userc.
Login usera. userc does not see usera [BUG: FIXED in 2006-07-11 nightly]
Login userb. usera sees userb and vice versa; userc sees NEITHER [BUG: FIXED in 2006-07-11 nightly]
Logout/login userc. Now both usera userb show online; but logout usera or userb and they show online. Once again userc not getting presence properly. [BUG: FIXED in 2006-07-11 nightly]
Logout all users. [Stop] Wildfire server. [Start] Wildfire server.
Login users; even now userc does not get correct presence. [BUG: FIXED in 2006-07-11 nightly]
In admin console, add userc to group1. The moment you do, all of a sudden usera and userb see userc in their roster.
Logout/login usera. userc does not see presence; and usera loses sight of userc. [BUG]
Logout/login userc. usera still does not see userc; userc sees both usera and userb online. userb never saw userc go offline. [BUG]
Logout/login userb. usera and userb see each other just fine, but userc does not. And now userb does not see userc. [BUG]
Logout all users. [Stop] Wildfire server. [Start] Wildfire server.
Login userc.
Login usera. NOW userc sees usera properly and vice versa.
Login userb; NOW userc sees userb properly and vice versa.
Logout/login usera. All works well now.
Logout/login userb. All works well now.
In the admin console, create userd and immediately add to group1.
Login userd (JAJC in my case). All users see each other.
Logout usera. All but userd see usera logout. [BUG: FIXED in 2006-07-11 nightly]
Login usera.
Logout/login userd. userb and userc see userd; usera does not. [BUG: FIXED in 2006-07-11 nightly]
Logout userb. All but userd see userb logout. [BUG: FIXED in 2006-07-11 nightly]
Login userb. Again, userd has disappeared. [BUG: FIXED in 2006-07-11 nightly]
Logout/login userd. Now usera and userb do not see userd. [BUG: FIXED in 2006-07-11 nightly]
Logout userc. All but userd see userc logout. [BUG: FIXED in 2006-07-11 nightly]
Login userc. userd has disappeared from userc’'s roster. [BUG: FIXED in 2006-07-11 nightly]
Logout/login userd. userd now effectively invisible. [BUG: FIXED in 2006-07-11 nightly]
Logout all users. [Stop] Wildfire server. [Start] Wildfire server.
Login all users. Everyone sees everyone.
Logout/login usera. Everyone sees usera logout/login.
Do same for userb, userc, and userd. Everyone see presence properly now.
fseesink,
Thanks for your very detailed post and test cases; these will be very helpful for finding and fixing additional shared group bugs. Over the next couple of days, we’'ll get these issues categorized and posted into our issue tracker.
One thing we’'ve been considering is adding support for some ad-hoc commands that would allow creating and editing groups and shared groups. That would let us create automated tests for a lot of this functionality and should better protect against regressions.
Best Regards,
Matt
Hey Frank,
Thanks for the detailed report. I managed to fix several issues for Wildfire 3.0.1 to be released today. Below is the list of issues that were fixed.
JM-775 - Member of public group was not able to add to his roster contact that did not belong to public group.
JM-776 - Members of public shared groups were not getting their rosters updated when a new user was created in the system.
JM-777 - Presence was not working when creating new shared groups and at the same time defining list of members.
and
JM-744 - Presence updates were not being sent to shared contacts whose subscriptions is FROM.
JM-745- Users of the same group (not shared) that can see a shared group were receiving presences of each other.
JM-750- Presence subscription was incorrect when adding group member to non-shared group that could see shared group.
JM-758 - Available presence was not being sent to all connected resources after subscription was approved.
I didn’'t have time to finish checking your list since I wanted to be sure that these fixes were well tested and ready to be included in the 3.0.1 release. Many of the reported errors were in fact symptoms of a single error so it is possible that many other errors have been fixed with the above bug fixes.
More tests will be run soon.
Thanks,
– Gato
Taking Wildfire 3.0.1 and following the exact same sequence of steps as I outlined on 11 July 2006, I have found that, EXCEPT for step #51, all bugs listed have now been fixed!! Awesome job, guys.
The one exception is step #51, and it’'s a slight variation. In step #50, I wrote
This was FIXED in 3.0.1. So userc DOES see presence of usera and userb and vice versa.
So for step #51,
The issue is not that user still does not see userc (as usera saw userc in #50). And userc does see both usera and userb online. However, now NEITHER usera nor userb see user go offline.
To verify this further, I tried to logout/login userc repeatedly, and regardless, usera and userb continued to see userc online the whole time. As usual, once everyone signs out and the server is restarted, things are fine.
Since step #49 works now, it implies that when userc was added to the shared roster group, a roster push was immediately initiated to usera and userb to update their rosters. However, when userc later does a logout/login in step #51, usera and userb do not see that, indicating that they never received presence updates from Wildfire.
Anyway, just wanted to say kudos for all the hard work you’'ve done on this. Keep at it. Wildfire is really coming along quite nicely.
Hello!
Is the JM-701 shared group thing in any way related to the recent huge improvement of 3.0.1?
I dont have any chance of checking this within the next week or two so I would be glad to get some feedback out of you guys!
Bye Starry
Hey Gato,
I spent some time running another battery of tests and have come up with this simplified test case to demonstrate the remaining bug.
SETUP
Windows XP SP2 with all updates through 14 July 2006
Sun Java JDK/JRE v1.5.0_07
Wildfire v3.0.1
Pandion v2.5 Windows client (usera)
Exodus v0.9.1.0 Windows client (userb)
Psi v0.10 Windows client (userc)
All client connections are done from the same box running the server, though NOT using the loopback (127.0.0.1) address, but rather a fully qualified domain name (FQDM), as one would do in a production environment. This means results should be the same regardless of whether clients connect from the local box or around the world. To make it possible to test easily from one box, I used three (3) different XMPP clients, one for each test account used below.
Reproducible steps to show presence/shared rosters not working properly:
INSTALLATION OF WILDFIRE
INITIAL CONFIG
Execute C:\Program Files\wildfire\bin\wildfire.exe
Once initialized, click [Launch Admin].
Choose Language: (*) English, [Continue]
Domain: set to test box FQDM, [Continue]
Select (*) Embedded Database, [Continue]
Set
Admin Email Address:
New Password:
Confirm Password:
and [Continue]
This brings up the admin console webpage.
Click ‘‘Login to the admin console’’
Login with username ‘‘admin’’ and password set in step #7.
Leave all server settings at default. (Presence issue seems to apply regardless)
Click ‘‘Users/Groups’’ tab
Click ‘‘Create New User’’ and create usera, userb, and userc.
12.a. Username: usera (fill in rest as you like), [Create & Create Another]
12.b. Username: userb (fill in rest as you like), [Create & Create Another]
12.c. Username: userc (same), [Create User]
[NOTE: For testing, I tend to create users with passwords set the same as the username; e.g., usera has password usera, userb has password userb, etc. Makes testing go quicker.]
Verify users exist by clicking ‘‘User Summary’’
Login usera to verify account active/working. (I used Pandion 2.5 in my case)
Login userb with another client to verify account active/working (Exodus 0.9.1.0 in my case)
Login userc with another client to verify account active/working (Psi 0.10 in my case)
Back in admin console, click ‘‘Sessions’’ tab to verify accounts logged in.
Logout of all accounts/quit clients for now.
Refresh ‘‘sessions’’ webpage & verify users logged out.
Click ‘‘Users/Groups’’ tab
Click ‘‘Group Summary’’ to verify no groups exist yet
Click ‘‘Create New Group’’
Group Name: group1
Initial Member(s): usera,userb
(*) Enable sharing group in rosters
Group Display Name [Test Group]
(*) Show group in all users’’ rosters.
[Create Group]
Click ‘‘Group Summary’’ to verify group created.
Login as usera. Login as userb. ‘‘Test Group’’ appears in both; presence works as expected. Logout/login usera and userb various ways to verify. Login both usera and userb.
Login as userc. userc also shows ‘‘Test Group’’ and presence of usera and userb works as expected. Again logout/login usera and userb to verify.
Logout all users. [Stop] Wildfire server. [Start] Wildfire server.
Login to admin console and verify users and groups are intact.
Login all users.
In admin console, add userc to group1. That is,
29.a. Click ‘‘Users/Groups’’ tab
29.b. Click ‘‘Group Summary’’
29.c. Click ‘‘group1’’ link.
29.d. Add User(s): userc [Add]
The moment you click [Add], all of a sudden usera and userb see userc in their roster. (Nice roster push.)
[NOTE: Nothing you do, regardless of which user does a logout/login, will make this work. Only a server restart.]
Logout all users. [Stop] Wildfire server. [Start] Wildfire server.
Login all users. Presence now works as expected. Try various logouts/logins to verify.
Step # 30 shows where the bug is.
Now here is the interesting part. If you repeat the test case but skip step #26
It all works!!! That is, userc is pushed onto usera and userb’'s rosters, and presence is accurate for everyone. So go figure. But this is reproducible every time.
Hi!
AS JM-701 moved up to “critical” but is still “unscheduled” I wonder when we can get a solution on this one?
I cannot roll out our system with this “feature” so this is a real show stopper for us.
Short question: Is there a price tag on it which “motivates” the developers to tackle it NOW? If yes, how much $$$ is it? If somebody else is really needing this, which I assume based on the discussion herre, how about joining forces and feed the hungry souls. One could also call it a bountie I guess?
What da ya think?
Starry
Hey Starry,
I’'m now analyzing JM-701 so a fix should be available soon. I will let you know if I need more information.
Thanks,
– Gato
Hey Starry,
The problem has been fixed. In the next nightly build (Aug 8) you will find the bug fix. Let me know how it worked for you.
Thanks,
– Gato