Currently the school I go to is researching a new Jabber server
after our previous one, Openfire, kept dieing on us with a memory leak.
One of the requirements that we have is that the server can interface
with our LDAP server for both authentication and then for the vCard
information for the roster auto-population feature (We make over 250
changes to user groups in one year, so having a handmade roster is not
going to be efficient).
I have researched this, and tried to implement it using the
little bits I have found, on a test server running the most recent
Jabberd2 build (As of last weekend) and have authentication working, but
auto-population is not working. We are trying to use a MySQL database
backend for the actual storage, and then the ldapvcard driver for the
auto-population, below is the relevant part of sm.xml, does it look
correct? I know that the actual server should work because it works with
the handmade roster I have right now.
Any help you can provide is greatly appreciated.
Thank you,
-Ian
*Storage Section*
<!-- Storage database configuration -->
<storage>
<!-- Dynamic storage modules path -->
<path>/usr/local/lib/jabberd</path>
<!-- By default, we use the SQLite driver for all storage -->
<driver>mysql</driver>
<!-- Its also possible to explicitly list alternate drivers for
specific data types. -->
<driver type='published-roster'>ldapvcard</driver>
<!-- Store vcards in a ldapvcard database instead -->
<!--
<driver type='vcard'>ldapvcard</driver>
-->
<!-- Read mapping for group id <-> group name from ldap.
Used by mod_published_roster.
See ldapvcard section for options.
When resolving group id to group name, it searches for
groupsobjectclass objects at groupsdn base using group id
(in groupsidattr) as key and returns the first value of
groupattr of first found entry.
E.g.. in general case, if group id is "some-dep", and groupsdn
is o=org, and class is jabberGroup, it searches for
(&(objectClass=jabberGroup)(cn=some-dep)) and returns value of
jabberPublishedItem attribute, which may contain textual
description.
-->
<!--
<driver type='published-roster-groups'>ldapvcard</driver>
-->
<!-- MySQL driver configuration -->
<mysql>
<!-- Database server host and port -->
<host>localhost</host>
<port>3306</port>
<!-- Database name -->
<dbname>jabberd2</dbname>
<!-- Database username and password -->
<user>jabberd2</user>
<pass>**********</pass>
<!-- Transacation support. If this is commented out, transactions
will be disabled. This might make database accesses faster,
but data may be lost if jabberd crashes.
This will need to be disabled if you are using a MySQL
earlier than v3.23.xx, as transaction support did not appear
until this version. -->
<transactions/>
</mysql>
<!-- LDAPVCARD driver configuration -->
<ldapvcard>
<!-- LDAP server host and port (default: 389) -->
<uri>ldap://jabber.aca.imsa.edu</uri>
<!-- DN to bind as for searches. If unspecified, the searches
will be done anonymously. -->
<!--
<binddn>cn=Directory Manager</binddn>
<bindpw>secret</bindpw>
-->
<!-- see authreg.ldapfull int c2s.xml for description. -->
<type>ldap</type>
<!-- LDAP attribute that holds the user ID (default: uid) -->
<uidattr>uid</uidattr>
<objectclass>inetOrgPerson</objectclass>
<pwattr>userPassword</pwattr>
<!-- if you use included jabberd.schema use this:
<uidattr>jid</uidattr>
<objectclass>jabberUser</objectclass>
<pwattr>jabberPassword</pwattr>
-->
<!-- see authreg.ldapfull int c2s.xml for description. -->
<!--
<!--
<validattr>valid</validattr>
-->
<!-- base DN of the tree. You should specify a DN for each
authentication realm declared in the <local/> section above,
by using the realm attribute. -->
<basedn>dc=aca,dc=imsa,dc=edu</basedn>
<!-- attribute that holds published group name or id,
jabberPublishedGroup if not set -->
<groupattr>jabberGroup</groupattr>
<!-- boolean attribute that tells, publish or not this user
jabberPublishedItem by default -->
<publishedattr>jabberVisible</publishedattr>
<!-- If value specified, then keep cache of "published-roster"
database. Cache is renewed when kept more seconds than value
specified. Setting this value increases perfomance of publishing
roster. If not specified, then we don't keep cache. -->
<publishedcachettl>60</publishedcachettl>
<mapped-groups>
<!-- If turned on, then reading mapping of group ids to names with
LDAP will works. -->
<!--
<map-groups/>
-->
<!-- base for searches for group id to group name mappings -->
<basedn>ou=jabbergroups, o=Example Corp.</basedn>
<!-- what objectclass to search, jabberGroup by default -->
<!--
<objectclass>jabberGroup</objectclass>
-->
<!-- what attribute to search, cn by default -->
<!--
<idattr>cn</idattr>
-->
<!-- attribute with text group name, description by default -->
<!--
<nameattr>description</nameattr>
-->
</mapped-groups>
</ldapvcard>
</storage>
*Template Section*
<!-- Templates. If defined, the contents of these files will be
stored in the users data store when they are created. -->
<template>
<!-- Uncomment <publish> if you wish to forcely publish
roster template from ldap on each user login -->
<publish>
<!-- If <check-remove-domain> given, then published contact checked
against sm user database and if user is unknown to sm,
contact
will be deleted from user's roster (if it is in roster). -->
<!--
<check-remove-domain></check-remove-domain>
-->
<!-- Keep cache of "active" database specified number of seconds.
This will significantly speed up publishing of roster.
If unspecified or 0, no cache is used. -->
<active-cache-ttl>60</active-cache-ttl>
<!-- If <fix-subscriptions/> is not commented, set subscriptions of
user's contacts to subscriptions of corresponding published
contacts. As for now, "both". -->
<!--
<fix-subscriptions/>
-->
<!-- If <override-names/> is not commented, then displayed names of
contacts in user's roster will be updated accordingly to
published roster (if they differ). If commented, then user can
rename contacs in roster -->
<!--
<override-names/>
-->
<!-- when mapped-groups is on (<map-groups/> is uncommented, the
actual
group names for published contacts are read from
published-roster-groups storage type, which in turn may be
mapped
to ldapvcard driver. The key for searching is published user's
group, and returned value is used as group name. So you can
assign
textual group IDs to users rather then group names.
group-cache-ttl keeps cache of mapping group id <-> group
name for
specified number of seconds. If unspecified or 0, no cache
is used.
-->
<!--
<mapped-groups/>
<map-groups/>
<group-cache-ttl>120</group-cache-ttl>
</mapped-groups>
-->
<!-- If <force-groups> is commented out, published roster's contact
added to user's roster only when user does not have this
contact.
If <force-groups> is not commented out, then these checks
performed
against roster item when publishing roster item that already in
user's roster:
If user already has added his roster's contact to group of
published contact, no changes are made with this group (note
that contact may be in more than one group).
If <prefix> given, then prefix of each group of user's
compared
whith given prefix, and if it matches, user's contact
removed from
matched group (see below).
Same for <suffix>.
After that, user's contact added to a group of published
roster's
contact.
In other words, all groups of updated contact, that match
prefix
or suffix, replaced with group of published contact.
This is done because there is no way to determine that
group was
published or greated by user. -->
<!--
<force-groups>
<prefix>MyOrg.</prefix>
<suffix>(MyOrg)</suffix>
</force-groups>
-->
</publish>
<!-- If you defined publish, you should comment <roster> -->
<!--
<roster>/usr/local/etc/templates/roster.xml</roster>
-->
</template>
</user>
--
To unsubscribe send a mail to [email protected]
