Alright, will try to put some 'meat on the bones' as it were. In relation to the following thread,
http://www.ejabberd.im/node/743
I have begun doing some systematic testing, and the following is what I have discovered thus far. I am cross-posting this both here on the ejabberd forums and on the Pandion forums as well, as I do not know whether one or both are at fault.
Hopefully this provides some insight into what's going on. I'm not sure if we're dealing with one or more problems here, possibly one with ejabberd and another with Pandion, but let's see where the chips fall.
____________________________________________________________
CONFIGURATION:
* Windows XP Professional SP2 (with all updates)
* Erlang R10B-10
* ejabberd 1.0.0 Windows binary
* Pandion 2.5 (Windows client)
* ejabberd is configured to authenticate using LDAP. This
works as expected.
____________________________________________________________
SUMMARY
With the above configuration, if a user changes their profile nickname,
it appears to cause havoc on presence notifications, causing others
to not be able to see the user and vice versa, at least until
everyone has signed off/on TWICE.
And after initial nickname configuration, any attempts to change
the profile nickname later have no effect (i.e., they don't work;
the nickname stays as it was initially created).
____________________________________________________________
REPEATABLE?
Always.
____________________________________________________________
INITIAL CONFIGURATION/SETUP
For each test, 'reset' ejabberd to pristine condition by doing
the following:
1. Shutdown ejabberd server
2. Removed .\Ejabberd\log\ files
3. Removed .\Ejabberd\spool\ files
4. Restarted ejabberd server
[Since all authentication information is stored in LDAP, the
only lost are such things as shared rosters, queued offline
messages, etc.; which for our purposes are not essential.]
____________________________________________________________
STEPS TAKEN [results after step showin in brackets]:
* Login via ejabberd web admin (hereafter 'web admin' refers to
view as seen from the ejabberd web administration tool)
* Create a shared roster as follows:
telcomm
Name: Telecommunications
Description: blah blah blah
Members:
Displayed Groups:
telcomm
The idea was simple. Everyone in our group could see everyone else.
For the purposes of this test, I only used two (2) users, 'allen'
and 'frank' to keep things simple.
* Check everyone's rosters via web admin [all empty]
* At this point, begin using Pandion clients on two PCs, one configured
as user 'frank', the other as user 'allen'
* Login 'frank' [see 'telcomm' roster by its name "Telecommunications',
with each user's full JID; everyone is offline (as expected)]
* Check web admin for 'frank' roster [empty]
* Logout 'frank', repeat web admin check [empty]
* Login 'allen'
* Check web admin for 'allen' roster [empty]
* Logout 'allen', repeat web admin check [empty]
* Login 'frank', then login 'allen' [both see each other as
full JID; web admin still shows empty rosters]
* Logout 'frank', then logout 'allen' [presence still works as expected]
* Login 'frank', change profile nickname to 'Frank' in Pandion
(Actions | Edit Profile...) [web admin still shows empty roster]
* Logout 'frank' [web admin still shows empty roster]
* Login 'frank' [web admin now shows following (reformatted
to make easier to read):
__________
JID Nickname Subscription Pending Groups
Frank none none Telecommunications
__________]
* Login 'allen' ['frank' gets 'allen' signon notification, but
NEITHER SEES THE OTHER IN THEIR ROSTER!! They appear 'offline'
to each other. Web admin shows 'frank' roster still the same,
'allen' roster now shows the following:
__________
JID Nickname Subscription Pending Groups
Frank none none Telecommunications
__________]
* Logout 'allen' [web admin still shows 'allen' roster empty]
* Login 'allen' ['frank' gets 'allen' signon notification and 'allen' JID
shows up; 'allen' sees 'Frank' in roster; web admin rosters the same]
* Change 'allen' profile nickname to 'Allen' in Pandion
[web admin shows rosters the same]
* Logout 'allen' [web admin shows rosters the same]
* Login 'allen' ['frank' gets 'allen' signon notification and
sees JID in roster; 'allen' sees 'Frank'; web admin shows 'frank'
web roster same, while 'allen' web roster now shows
__________
JID Nickname Subscription Pending Groups
Allen none none Telecommunications
Frank none none Telecommunications
__________]
* Logout 'frank' ['allen' sees 'Frank' signoff; web admin rosters same]
* Login 'frank' ['allen' gets 'Frank' signon notification, but
NEITHER SEES EACH OTHER IN THEIR ROSTER!! They appear 'offline'
teo each other. Web admin shows 'allen' roster still the same,
while 'frank' roster now shows
__________
JID Nickname Subscription Pending Groups
Allen none none Telecommunications
Frank none none Telecommunications
__________]
* Logout 'allen' [web admin rosters same]
* Login 'allen' ['frank' gets 'allen' signon notification, sees 'Allen' in roster;
'allen' does NOT SEE 'frank'!!; web admin rosters same]
* Repeat last 2 steps [same results: 'frank' sees 'allen'; 'allen' does not see 'frank']
* Logout 'frank' ['allen' sees nothing]
* Login 'frank' ['allen' gets 'frank' signon notification and sees 'Frank' in roster;
'frank' sees 'Allen' in roster]
____________________________________________________________
As can be seen from the steps above, presence is not being handled properly
when someone adjusts their nickname.
After doing the above steps, I signed off both 'allen' and 'frank'.
I then repeated the steps indicated within ... above, but as
Pandion still showed 'Frank' and 'Allen' as the respective nicknames in the
main roster window, I decided to make one adjustment: I changed the nicknames
so that 'frank' was 'Chucky' and 'allen' was 'Waldo'.
HOWEVER, even though the Pandion clients showed the names 'Frank' and 'Allen'
just below the Pandion menubar, when you go to Actions | Edit Profile...,
you will see that the profile indicates no nickname (which appears to show that
Pandion pulls down the profile, but still does not accurately reflect this in
the name it shows just below the menubar.)
More important, at this stage, changing profile nicknames appears to have no effect
whatsoever. That is, the web admin rosters continue to show 'allen' with nickname
'Allen' and 'frank' with 'Frank'. Though Pandion shows 'Chucky' and 'Waldo' in
the profile screen, the names 'Chucky' and 'Waldo' are never seen in the web admin
rosters, nor do they appear on each other's roster lists. It's as if Pandion no
longer actually sends this information to ejabberd, or ejabberd no longer listens
since a nickname already exists.
Because of this, the steps above where presence was inaccurate do not occur, since
each client still sees the other as 'Allen' and 'Frank' at this point, thus logins/logouts
are properly reflected in the rosters as they occur.
Final note: Attempting to change the resource in Pandion at this point and reconnecting
causes Pandion to segfault. And yes, this is repeatable also.
____________________________________________________________
COMMENTS
As all the users in a shared roster group are on the same server, I would think
that ejabberd should tag their subscription as 'both' when added to someone's roster,
not 'none' as indicated above. I can understand that this is not possible with
JIDs that belong to a separate domain, since authorization is required from the
recipient in Jabber/XMPP (e.g., as opposed to AIM), but if all the users are on the
SAME ejabberd server where the shared roster group is located, I would think it made
more sense to set subscription to 'both'. This obviates the constant need for people
to authorize each other, especially in cases such as above where a group is set to
display its own group (i.e., everyone in the group sees everyone else in the group).
As always, if any additional information is needed--such as traces of specific
steps, etc.--please advise.
ejabberd on WinXP, Pandion, shared roster groups, & presence
Just wanted to add some new info to this thread. As I mentioned, this configuration does external authentication via LDAP, which works just fine. So decided to do some more Googling.
End result: learned a little about mod_vcard_ldap. Though there is VERY little documentation regarding this, I was able to re-run my test above with a slight change to my ejabberd.cfg file; namely, I replaced the line
{mod_vcard, []},
with
{mod_vcard_ldap, ["jud.mycompany.com"]},
[NOTE: As we also had DNS entries setup for our previous jabberd 1.4.x install which included 'jud.mycompany.com', I thought why not try this. Maybe the issue was that with LDAP used for authentication, using the internal storage for vCards was "confused" or something. Besides, vCard user searches never worked before.]
And sure enough, all of a sudden doing vCard user searches in Pandion worked like a champ!
UNFORTUNATELY, the issues mentioned above actually only got WORSE. You see, the issue appears to be with respect to the NICKNAMES. I say this because the original setup (LDAP authentication, basic vcard support) works just fine UNTIL someone gets the bright idea to modify their profile and change their nickname. Only after a user does this does presence get goofy.
With the above adjustment to use mod_vcard_ldap, all of a sudden EVERYONE has a nickname. This appears to be due to the fact that mod_vcard_ldap sucks in various attributes from your LDAP tree and maps them to the various vCard entries. And, as quickly witnessed through the web admin interface, if you have shared rosters setup, then the first time you login, every single person on those shared rosters gets a nickname. And the end result of this? You can't see ANYONE!
So now magnify the logout/login 2x since the you've changed your nickname thing before things settle out. It's absolutely awful.
And based on a rudimentary glance at the XMPP stream, it does appear that presence is not being sent when a user signs in. I really need to go read the RFCs/JEPs on this, but not sure if the client is supposed to request the roster, then begin requesting presence of each member on the roster, or the server is supposed to push presence at the client automatically based on the roster stored in the server. The latter seems more logical, but who knows.
Anyway, this hopefully will give the ejabberd folks enough information to work with. But as it stands now, shared roster groups in ejabberd are extremely frustrating.
Hello, We hear you, but I
Hello,
We hear you, but I just wanted to remind you some small basic psychological tips on how to ask people to solve your specific problem. Bear in mind, that solving bug are a time consuming and sometime frustrating exercice.
Please, could you have a look at the following document which is explaining quite nicely how to interact in a friendly way with an open source communities:
Some sections are particularly interesting:
-
-
-
We hear you, but it is not very pleasant for the participants of a community to see someone coming and taking for granted that developers have to work as soon as possible on his own particular problem. It could even have a counter-effect, getting people to think that they will not read any more posts of the rude demanding person.
That said, this bug will (however ;-) be solved in the next release. We had scheduled it before you send your flood of messages.
Do not take any offense but simply try to get into the shoes of people working hard, nights and week-ends included, to make the nice software you are using.
--
Mickaël Rémond
Obvious misunderstanding
Mickaël,
I appreciate the links. I am well aware of Eric Raymond's writings. I have/read "The Cathedral and the Bazaar" among other things. But it's quite clear signals have crossed and there have been some misunderstandings. Your reply shows I have done a poor job of getting my point across, so bear with me here.
1. Yours is the first actual written reply to anything I've posted for several weeks, be it here or in Bugzilla. This includes a simple, "we see it" flag. TRANSLATION: no feedback = no clue whether anyone is even paying attention. The only responses I could get was by logging into the ejabberd conference room and talking with folks there, including badlop, sander, and even alexey. If there are transcripts, check them out. Might help clarify my position. [HINT: Note the change on the front page where it now clearly warns newbies that shared rosters have issues.]
2. In connection with #1, note I was not writing "whah whah whah! Fix my problem now!!!" I was trying to get the point across that this needs, if nothing else, to be documented in plain sight so others do not begin using ejabberd, only to want to throw it out the window because of something that was a known problem. If admins go in with eyes wide open, they know what they're in for.
You write "this bug will (however ;-) be solved in the next release. We had scheduled it before you send your flood of messages." Fantastic! How about putting that out someplace where people might actually SEE it. To be clear, it's not for me (I already know it's an issue obviously). But to cut down on even more...how did you put it..."flood of messages."
3. Regarding that "flood of messages", you might notice I wrote up an extremely specific test case, one that is reproducible EVERY TIME. And if you'd bothered to pay attention, you might realize that this wasn't something I could slap together in 5 minutes. As a user of ejabberd and fully aware and appreciative of the effort that Alexey & co. put into the software, I spent an inordinate amount of time testing and retesting to absolutely nail down where the issue was, complete with traces. This is what a developer usually wants...a reproducible bug they can follow and get to the heart of. No offense, but this wasn't exactly "Hey, your sh*t's broke. Fix it."
4. You might consider following your own advice. Your snide comments like "someone coming and taking for granted that developers have to work as soon as possible on his own particular problem" (something I never stated, meant, or in any way implied...the fact I spent a few nights building the test case was done to SAVE Alexey time, not waste it), "getting people to think that they will not read any more posts of the rude demanding person" (care to point out exactly when I was rude?), the whole "flood of messages" bit, and "to make the nice software you are using" aren't exactly nice. If you wish to build a community, it's also not wise to insult those trying to help.
ejabberd is a free, open-source project. It's done for whatever reasons Alexey & everyone else involved chooses to do it, and those of us who use it are greatful they've chosen to share it. And it's a great little piece of software.
But like any software out there, the ecosystem isn't just made up of the developers. If no one uses it, there's not much point. As a user of ejabberd, I'd like to see it used a great deal more. So I try to help, in what way I can, to make it a better program. Maybe my writing isn't as succinct as you'd like. Then again, maybe yours is too succinct (as in lack of documented issues you're working on) for me. But my intention wasn't to give grief. It was to nib in the bud the typical comment from some developers who want exacting, specific instructions on how a bug shows its ugly little head. And that's exactly what I did. And after the initial post, as I found other information, I posted that as well, if for no other reason than to hopefully prevent others reinventing the wheel. It was also to say, "If this is not a priority, that's fine. But you might want to put a notice up so others are aware and don't keep nagging you about this."
A simple, "We're working on it" would've been enough to keep me from going further. I'd know you were on it, and any further writings would just get in the way.
Regardless, thanks for responding here. I realize you likely didn't see the conversations on the conference room, so that you took the time to respond, thank you.
Re: Obvious misunderstanding
I was trying to get the point across that this needs, if nothing else, to be documented in plain sight so others do not begin using ejabberd, only to want to throw it out the window because of something that was a known problem. If admins go in with eyes wide open, they know what they're in for.
You write "this bug will (however ;-) be solved in the next release. We had scheduled it before you send your flood of messages." Fantastic! How about putting that out someplace where people might actually SEE it. To be clear, it's not for me (I already know it's an issue obviously). But to cut down on even more...how did you put it..."flood of messages."
As a user of ejabberd, I'd like to see it used a great deal more. So I try to help, in what way I can, to make it a better program.
It was also to say, "If this is not a priority, that's fine. But you might want to put a notice up so others are aware and don't keep nagging you about this."
A simple, "We're working on it" would've been enough to keep me from going further. I'd know you were on it, and any further writings would just get in the way.
Have you thought about contributing an entry to the about the issue (and maybe others)?
Re: Obvious misunderstanding
I wrote my answer to work out and eliminate the misunderstanding, even it would have increase the misunderstanding.
I think however that we are now on the page :-)
I will keep you informed of our progress on the shared roster problem you have exposed.
Thank you !
--
Mickaël Rémond
To finish the whole
To finish the whole mod_vcard_ldap coverage, I decided to disable any form of vcard by commenting out the appropriate lines in the ejabberd.cfg file. Then I reran the tests I originally described.
Of course, with mod_vcard* disabled, users are no longer able to search for others, NOR are they allowed to change their nickname in their profile. Thus all users appeared by their JIDs. But it all did work well. While not the long-term solution, it prevents what I found to be the cause of all my nightmares.
Digging further, I believe I have discovered that ejabberd is doing something incorrectly when a user has a NICKNAME set in their profile. First I reset the config to what it was with mod_vcard enabled. Redoing the steps I originally posted, I used the console window in Pandion (hit F12) to capture the XMPP streams from EACH login/logout session of both the 'allen' and 'frank' users. These traces are available if you'd like.
Analyzing those streams, all seems normal up through 'frank' setting his NICKNAME to 'Frank' and sending that to ejabberd. During 'frank's next login, ejabberd sends the usual stream (which includes the roster which indicates each member has subscription=both). Then Pandion does an {iq} to get vcard data on each roster member, and ejabberd sends back a response for each user, and the profile information for 'frank@mycompany.com' including the nickname 'Frank'. Pandion then sends an {iq} set command to set the roster name to 'Frank'. ejabberd responds by sending an {iq} push packet that sets the name of the user to 'Frank' AND sets subscription=none! Well that's not right.
Even worse, when user 'allen' signs on the first time after that, ejabberd sends 'frank' first the {presence} packet for 'allen' with avatar information, followed immediately by a second {presence} packet indicating 'allen' is 'unavailable'!!!
And oddly enough, the same occurs from 'allen's perspective. That is, as 'allen' signs on, ejabberd sends to allen first a {presence} packet with 'frank's avatar information, then sends another {presence} packet indicating 'frank' is 'unavailable'!!!
Please note at NO time do either client send a {presence} packet indicating they are 'unavailable'. This is purely generated by ejabberd.
Note from the steps above that, upon the second login by user 'allen', the name 'Frank' appears in the roster. Looking at the XMPP stream, the same thing happens as did for user 'frank'. That is, 'allen' receives the roster. 'allen' requests vcard data. ejabberd responds with packets for each user, and for 'frank' it includes the profile information. 'allen' then does an {iq} set command to set the roster name to 'Frank', and ejabberd responds with an {iq} push that not only sets the name, but also sets subscription=none!!!
Please also note, as I already indicated earlier, that via the ejabberd web admin, it seems that although all users are on the same server, their subscription appears in the web interface to be set to 'none'. Considering that when a user signs on, the stream shows they are receiving the roster with each user's subscription=both, and then throw in how ejabberd sends an {iq} push that then changes it to subscription=none, there's definitely some goofiness in how ejabberd is storing subscriptions as well.
Anyway, hopefully this will give the ejabberd team enough data to work with. Again, if you would like the traces, let me know. I will keep them handy and can either email them or post them somewhere for you to download.
[NOTE: I had to use {} instead of greater-than/less-than due to Drupal's formatting limitations.]
ejabberd on WinXP, Pandion, shared roster groups, & presence
I have logged this as a bug in BugZilla here:
Note I have also made the traces available there.
ejabberd 1.1.0 on Windows, shared rosters, presence problem
Sorry to disappoint, but I finally got around to testing the latest ejabberd 1.1.0 binary for Windows, and I am sad to report that the presence problems as described in this thread and in the related bugzilla report (#233) persist. Renaming a user on one's roster when it is a shared roster causes absolute havoc to presence notifications. This is simply not right.
I had very high hopes that 1.1.0 binary contained the fix(es) needed. I was asked to test the SVN version, which I did not have the time to download/compile/build/etc. But that was BEFORE the release of 1.1.0. So I'm guessing whatever I would've found in the SVN version likely would not have worked either.
It is very clear that the subscription settings are just plain wrong with regard to shared roster entries. Why do they persist in showing 'none'? Anyway, I need to find a resolution to this. It's really a pain in the butt, and it's quite the show-stopper for anyone who wishes to use shared rosters.
This is a nightmare from an admin's point of view, as it makes the shared roster feature more than useless. You're better off simply NOT using this feature at all. Anyone attempting to do the most simple of things (renaming someone on their roster to a name they prefer) suddenly loses presence of that user, as does that user of them! That is NOT a minor issue.