mod_vcard_ldap fetches data located in jpegPhoto LDAP attribute of specific user.Unfortunately I cant test it but I can tell you that this could me more "image format" rather than LDAP itself. VCard = ldap_attributes_to_vcard(Attributes, VCardMap,
Ejabberd monitoring install#
So, maybe you can provide me enough information to reproduce the problem without setting all the required:Ĭan you add this debug line to mod_vcard_ldap.erl, recompile that file, install it, restart ejabberd (or reload the module at runtime), then request vcard with a good photo, and another with a problematic photo, and show here the logged lines? (Of course, you can remove anything sensitive that the log may show) diff -git a/src/mod_vcard_ldap.erl b/src/mod_vcard_ldap.erl But as I am not an LDAP admin at all, I'm having trouble setting all the required.
Ejabberd monitoring Patch#
Hi, I'm trying to reproduce the problem, and then I'll write a patch proposal. Ldap_ufilter: "(&(objectClass=inetOrgPerson)(uid=%u))" Ldap_memberattr_format: "uid=%u,cn=users,cn=accounts,dc=osec,dc=pl" Ldap_gfilter: "(&(objectClass=ipausergroup)(cn=%g))" Ldap_rootdn: "uid=xxxxxx,cn=users,cn=accounts,dc=osec,dc=pl" Here's a part of my LDAP-related configuration: auth_method: ldap The XMPP service is in alpha testing in my company, so I only have a couple of users now. My configuration is as simple as it can get. Even trying to get vcard information for a single user is causing high cpu load by beam.smp. After this, same problems appeared as is having. Everything was stable and fast until mod_vcard_ldap was enabled. I can say I am experiencing very similar problems, just installed latest ejabberd on CentOS 7.2. If anything else needed to provide, just let me know. Having photos working was one of our reasons to move to the new version. Just one more important info at the end: this issue is exactly the same like we had with using ejabberd version 2.1.13 (EPEL package for centos6). Last time issue happen this weekend, when only few users were connected (up to 10 users). If photos are disabled, the overal load is minimal: load average: 0.04, 0.03, 0.05, environment stable, RAM memory consumption with about 370MB totally. as you can see from attached kernel snip, beam.smp processes consumes all memory and SWAP. If photos are enabled, overal load starting to increase with RAM consumption. System resources: 2cores, 1,7GB RAM, 1.5GB SWAP all photos are correctly working in other tools mapped with LDAP. each user has its own foto/avatar in LDAP. we use LDAP authentication with mod_shared_roster_ldap and with mod_vcard_ldap.Once we keep avatars enabled/activated within mod_vcard_ldap, then after some time (half to one day) the beam.smp will be killed by schedulers oom-killer due huge amount of memory it consumes. Was the unexpected behavior? What was the expected result? What did not work as expected? Are there error messages in the log? What How did you install ejabberd (source, package, distribution)?
What operating system (version) are you using?
0 kommentar(er)
