Hi there
My company is investigating ejabberd as a chat server but is having one major issue which is basically a show stopper.
When connecting as a user with Pidgin, Pandeon or any other XMPP client we've tried, the buddy list is downloaded with JIDs, usernames, instead of the users proper name, the full name. So a first time user logs on and his buddy list looks like this:
etc.
When we want the full name to be downloaded, ie.
John Smith
John Bob
etc.
A work around is that the user right clicks and clicks the "Update info" option. Then the proper name is suddenly displayed. But for a company like ours with hundreds of employees, a user cannot be asked to do this for hundreds of contacts. It needs to be done autmoatically when you sign on.
Does anyone know how to achieve this?
Thanks kindly!
Try this patch, and comment if it looks good
When connecting as a user with Pidgin, Pandeon or any other XMPP client we've tried, the buddy list is downloaded with JIDs, usernames, instead of the users proper name, the full name.
A work around is that the user right clicks and clicks the "Update info" option. Then the proper name is suddenly displayed.
Probably when you click in "Update info", the client requests the contact's vCard, and puts the nickname or the full name as the roster item name.
You didn't mention how you get hundreds of contacts in each user's roster. I imagine you use mod_shared_roster with @all@. Also, you didn't mention if you are using mod_vcard, mod_vcard_odbc or mod_vcard_ldap.
ejabberd 2.1.2 doesn't yet support automatic get from vcard. But there's a ticket, with a patch available: . It would be nice if somebody else can test also the patch.
Can you please try the patch, and comment here if it works correctly? If so, please comment also what mod_vcard* are you using.
If you installed ejabberd 2.1.2 with a binary installer, you can get the patched and compiled file here:
Hi
Hello Badlop
Thanks for taking an interest in my problem. Sorry for taking so long to get back to you.
Probably when you click in "Update info", the client requests the contact's vCard, and puts the nickname or the full name as the roster item name.
Correct.
You didn't mention how you get hundreds of contacts in each user's roster. I imagine you use mod_shared_roster with @all@. Also, you didn't mention if you are using mod_vcard, mod_vcard_odbc or mod_vcard_ldap.
Yes we use mod_vcard_ldap and @all@ in a shared roster. Our ldap server has around 120-150 users.
ejabberd 2.1.2 doesn't yet support automatic get from vcard. But there's a ticket, with a patch available: . It would be nice if somebody else can test also the patch.
Can you please try the patch, and comment here if it works correctly? If so, please comment also what mod_vcard* are you using.
I tried this patch but am not having much luck. In my testing environment I cannot even create a proper shared roster with @all@ without recieving the following error:
The process <0.9280.0> is consuming too much memory:
[{old_heap_block_size,832040},
{heap_block_size,196418},
{mbuf_size,0},
{stack_size,62},
{old_heap_size,198769},
{heap_size,69620}]
[{current_function,{eldap,'-polish/3-fun-0-',1}},
{initial_call,{proc_lib,init_p,5}},
{message_queue_len,2},
{links,[<0.9248.0>,<0.9279.0>,#Port<0.8602>]},
{dictionary,[{'$ancestors',['ejabberd_auth_ldap_mymachine.com',
ejabberd_sup,<0.9036.0>]},
{'$initial_call',{gen,init_it,
[gen_fsm,<0.9279.0>,<0.9279.0>,
{local,'eldap_#Ref<0.0.0.234260>'},
eldap,
{["ldap.mydomain.net"],
389,"cn=administrator,dc=mydomain,dc=com",
"password",undefined},
[]]}}]},
{heap_size,196418},
{stack_size,42}]
I have found a work around though. If I create a shared roster with myself as member pointing in the "group" field to another shared roster with @all@ it works. But the names etc are not resolved and I keep getting these errors.
Work goes on
I've made some progress with this. The patch does work but not when using the @all@ group in the members field. I can get it to work with nicely resolved names if I specify each user individually.
My group looks like this in the web gui:
Name: MyCompany
Description: All users in my company
Members: @all@
Displayed groups: MyCompany
This yields an empty contact list.
However if I put some names into the members field they resolve eachother and show up in the contact list.
Use the group id
Name: MyCompany
Description: All users in my company
Members: @all@
Displayed groups: MyCompany
This yields an empty contact list.
However if I put some names into the members field they resolve eachother and show up in the contact list.
In "Displayed groups" put the group id you used when creating the group, not its "Name". The field labels are misleading, will be fixed in next release.
No luck
In "Displayed groups" put the group id you used when creating the group, not its "Name". The field labels are misleading, will be fixed in next release.
Hi badlop
The name of the group I created is also MyCompany, same as the "name" and what I put in "groups". So no luck there.
Has anyone reported success with this patch and using the @all@ variable? Note that @all@ worked with the previous mod_shared_roster.beam, but not this new patched one.
Try this
With the risk of being labeled a spammer, I wanted to share a step by step reproduction of as far as I have gotten with this new patch.
This is using Ejabberd 2.1.2 and an LDAP server for authentication. Our LDAP server has 135 users. Do not use Pandion to test this (pandion tends to add shared roster members autmatically to the contact group on the server (not good)), try a client like Psi.
1. In the web admin console, create 2 groups. "MyFirstGroup" and "MySecondGroup".
2. In "MySecondGroup" set the name to "Group2", members to @all@ and displayed groups to "MySecondGroup".
3. In "MyFirstGroup", set the displayed groups to "MySecondGroup".
4. Now log on with a user to the server. He will have a blank roster.
5. In "MyFirstGroup", add this user to "members".
6. As soon as you press the Apply ("Send?) button, the users list should populate with the contents of the ldap. Great! Unfortunately, not with their names, but with JIDs.
7. Try log off and back in with the user. The shared roster that was just downloaded is now missing!
Any input would be appreciated. Is our LDAP too big for shared roster?
You only need to make step 2
1. In the web admin console, create 2 groups. "MyFirstGroup" and "MySecondGroup".
2. In "MySecondGroup" set the name to "Group2", members to @all@ and displayed groups to "MySecondGroup".
With step 2, all host users are members of the group, and all members get displayed the group itself. This means that all host users get all the host users (everybody in the vhost sees everybody else in the vhost).
In my small ejabberd 2.1.2 with LDAP authentication, with 2 users in the LDAP, using Tkabber, it works as I explain. And the contact is shown with the nickname he set in his vcard.
3. In "MyFirstGroup", set the displayed groups to "MySecondGroup".
4. Now log on with a user to the server. He will have a blank roster.
After doing step 3, in step 4 I still see the other LDAP user as a contact, in the roster, when I login with a user.
5. In "MyFirstGroup", add this user to "members".
6. As soon as you press the Apply ("Send?) button, the users list should populate with the contents of the ldap. Great! Unfortunately, not with their names, but with JIDs.
After doing step 5, in step 6 I immediately get myself in the roster. But strangely both contacts are shown with JIDs, not nicknames.
7. Try log off and back in with the user. The shared roster that was just downloaded is now missing!
When I relogin, I get again only the other contact, with its correct nickname, similarly to step 2 that I described.
Still trying
When I relogin, I get again only the other contact, with its correct nickname, similarly to step 2 that I described.
[/quote]
I've tried to vary some variables in the group info but keep on hitting the same results. Another thing that is weird is that if I create a group with only me as member, and change the members to @all@, I recieve 58 messages pertaining to this memory issue I mentioned earlier:
[15:25:38] (ejabberd@localhost) The process <0.28765.0> is consuming too much memory:
[{old_heap_block_size,1682835},
{heap_block_size,317811},
{mbuf_size,0},
{stack_size,145},
{old_heap_size,930889},
{heap_size,1805}]
[{current_function,{io_lib,printable_list,1}},
{initial_call,{proc_lib,init_p,5}},
{message_queue_len,1},
{links,[<0.0.0>,<0.28788.0>,#Port<0.17732>]},
{dictionary,[{'$ancestors',[<0.28762.0>]},
{'$initial_call',{gen,init_it,
[gen_event,<0.28762.0>,<0.28762.0>,
{local,error_logger},
[],[],[]]}}]},
{heap_size,317811},
{stack_size,164}]
I am including my modules config this time if it's of any help. Is anything wrong with the way we load mod_vcard_ldap?
{modules,
[
{mod_adhoc, []},
{mod_announce, [{access, announce}]}, % requires mod_adhoc
{mod_caps, []},
{mod_configure,[]}, % requires mod_adhoc
{mod_disco, []},
{mod_http_bind,[]},
{mod_irc, []},
{mod_last, []},
{mod_muc, [
{access, muc},
{access_create, muc},
{access_persistent, muc_admin},
{access_admin, muc_admin},
{logging, true},
{anonymous, false}
]},
{mod_muc_log, [
{dirtype, subdirs},
{file_format, plaintext},
{outdir, "/opt/ejabberd-2.1.2/logs/muclogs"},
{timezone, local}
]},
{mod_offline, []},
{mod_privacy, []},
{mod_private, []},
{mod_pubsub, [ % requires mod_caps
{access_createnode, pubsub_createnode},
{plugins, ["default", "pep"]}
]},
{mod_register, [
{welcome_message, {"Welcome!",
"Welcome to this Jabber server."}},
{access, register}
]},
{mod_roster, []},
{mod_shared_roster,[]},
{mod_time, []},
{mod_vcard, [{search, true},
{matches, infinity},
{allow_return_all, true}]},
{mod_vcard_ldap,
[
{ldap_rootdn, "cn=admin,dc=mycompany,dc=com"},
{ldap_password, "password"},
{ldap_base, "ou=people,dc=mycompany,dc=com"},
{ldap_uids, [{"cn", "%u"}]},
{ldap_vcard_map, [
{"NICKNAME", "%s %s", ["givenName", "sn"]},
{"GIVEN", "%s", ["givenName"]},
{"FAMILY", "%s", ["sn"]},
{"EMAIL", "%s", ["mail"]},
{"FN", "%s %s", ["givenName", "sn"]}]},
{ldap_search_fields, [
{"User", "%u"},
{"Name", "givenName"},
{"Family Name", "sn"}]},
{ldap_search_reported, [
{"Full Name", "FN"},
{"Nickname", "NICKNAME"}]}
]},
{mod_version, []}
]}.
Nogo
< edited >
Try mod_shared_roster_ldap
If you use LDAP, then you might be interested in mod_shared_roster_ldap
(here is documetation - )
This module provides more flexible configuration of the shared roster then mod_shared_roster
Take a look at this option:
ldap_userdescThe name of the attribute which holds the human-readable user name. Defaults to cn.
PS: This module has performance problems when a large number of users (greater then 200), but I can provide patches which allow to increase performance approximately twice.
Close now
If you use LDAP, then you might be interested in mod_shared_roster_ldap https://alioth.debian.org/projects/ejabberd-msrl/
Hi D.K.Brazz
Thanks for the tip. I've tried making this module work and gotten pretty far, but cannot get the JIDs to resolve to names properly.
Here's how it looks in my ejabberd.cfg:
{mod_shared_roster_ldap,[
{ldap_base, "dc=mycompany,dc=com"},
{ldap_rfilter, "(objectClass=posixGroup)"},
{ldap_filter, ""},
{ldap_gfilter, "(&(objectClass=posixGroup)(cn=all-users))"},
{ldap_memberattr, "memberUid"},
{ldap_ufilter, "(objectClass=inetOrgPerson)"},
{ldap_userdesc, "cn"}
Now, no matter what I put in the ldap_userdesc field, it still only downloads the JIDS (the uid from ldap). I would rather it displayed the cn ldap value which stores the users full name.
Any idea why it does this?
I also find that connecting now takes about 4-5 seconds longer than before. We have around 130 names in our ldap. How can I fix this?
Thanks for your assistance.
I also had JID displayName issue, turned out to be mis-cfg'ed
I had the exact same issue that andreasd described, where my Debian apt-get built ejabberd v2.0.1 server which auths against LDAP with mod_vcard_ldap & mod_shared_roster_ldap enabled would only download the JIDs as the displayName in the shared roster instead of the full names - despite the fact that when I turned on query tracing in slapd I could clearly see that the "displayName" field was being retrieved!!
My eureka! moment came when I was staring blindly at a configuration snippet elsewhere on this site: http://www.ejabberd.im/mod_shared_roster_ldap
My Problem: I didn't define a value for "ldap_useruid", I only defined "ldap_userdesc". After getting it working and looking at the code I realized why, ldap_useruid defaults to "cn" but in the case of our LDAP tree the username field is stored in "uid".
Here's my working (and cleansed) configuration, which I am sharing in the hopes that it might also be helpful to others suffering from this same problem:
Also note that I disabled (commented out) mod_vcard & mod_shared_roster - but left mod_roster enabled.
I hope that this is helpful to others - because I also found this problem very frustrating as everything appeared to be working properly, but the problem in reality turned out to be a problem of omitting one very critical configuration parameter.
Good Luck,
-David.
Just wanted to note, there is
Just wanted to note, there is an alternative solution to this issue rather than using mod_shared_roster_ldap (I can't use it here, since it would result in easily a few thousand people on every user's shared roster). I wrote up a simple module that hooks the roster saving process and injects a name from LDAP if the alias is blank. You can find it at -- I am commenting on this very old thread because it's one of the easiest ones to find when google searching for this problem!