I have one user that does not see anyone online status. Everyone appears to be offline to him. He can still IM people and he appears online to everyone else, but he can not tell if we are online or not.
We have tried different jabber clients on different machine and all react the same. We are using Ejabberd authenticating against Active Directory using LDAP.
Does anyone have any ideas? I have tried to remove the user from EJabberD, but being the user accounts don't actually exist on the EjabberD server I can't really remove him.
Is there a way to search the EjabberD database and manually remove any entries of his userID?
Thanks,
Brian Corbet
Check their rosters on web administration
On the web administration you can see who is online, and you can see the roster of any user, subscription type, and modify it.
Look the roster of the conflicting user, and the roster of one of his contacts. Both of them should have the other on their respective rosters with subscription = both.
For example, on the you can see that and are subscribed to each other presence, and 'subscription=both' for them.
More detail
That's what is weird. I think because we are authenticating against AD, we actually don't register the user accounts with EJabberd. When setting up a Jabber client we usually check the box that says I already have an account, then type in our AD userID and password.
When I click on users within EjabberD web interface, I get prompted for a username and password, but nothing I try works.
This user was one of the users that was testing ejabberd before we figured out how to auth against. He might have been registered the normal way before and now that we are auth against AD, he seems to be lost in the DB. I know that sounds stupid. That is why I was wondering if there was a way I could search through the DB manually to remove and instances of his userID.
We also use all shared Rosters, most users do not add any of there own.
Here is the code we are using to auth against AD using LDAP, if it helps:
% For LDAP authentification use these lines instead of above one:
{auth_method, ldap}.
{ldap_servers, ["x.x.x.x"]}. % List of LDAP servers
{ldap_uidattr, "samAccountName"}. % LDAP attribute that holds user ID
{ldap_base, "dc=Domain,dc=com"}. % Base of LDAP directory
{ldap_rootdn, "CN=ejabberd user,OU=Users,OU=Test,DC=Domain,DC=com"}.
{ldap_password, "passsword"}.
Found the culprit in the DB Dump
I think I found the problem in the DB Dump: This is what I found:
Now I just have to modify it and restore the dump file.
{privacy,{"username","domain.com"},
"JabberooPrivacy",
[{"JabberooPrivacy",
[{listitem,jid,
{"some","jid",[]},
allow,
10,
false,
true,
true,
false,
true},
{listitem,subscription,both,allow,2000,false,true,true,false,true},
{listitem,subscription,to,allow,2001,false,true,true,false,true},
{listitem,none,none,deny,5000,true,false,false,false,false}]}]}.
Restore from Dump File process not working
I think we found the culprit, as listed above, so what we tried was to make this user look like the rest of the users, and then try to use the "Restore from a Dump File" process to make it take affect. The only problem is that it is not taking the restore, after we try it come back to the DB Backup screen and we then dump the DB again and the data remains unchanged.
Is there some special procedure to use the "Restore from Dump File"?
We really need to get these changes to stick.
Thanks for any advice,
Brian C.
Check the logfile for error reports
Maybe the restore proccess fails. Did you check the logfile for error or warning messages?
To make sure the standard restore proccess works, make a little change on the dumpfile, for example modify the group of a contact on a roster and 'restore' it.
the form on 'users' is to register new users
On ejabberd's webadmin, section 'Users', you see a list of registered users. The username+password+button you see is to register new users. Of course, if you don't use the embedded DB, all this section seems useless.