dn: cn=modules{0}, cn=config
olcModuleLoad: {0}accesslog.la
olcModuleLoad: {1}auditlog.la
olcModuleLoad: {2}constraint.la
olcModuleLoad: {3}dynlist.la
olcModuleLoad: {4}memberof.la
olcModuleLoad: {5}ppolicy.la
olcModuleLoad: {6}refint.la
olcModuleLoad: {7}seqmod.la
olcModuleLoad: {8}syncprov.la
olcModuleLoad: {9}sssvlv.la
olcModuleLoad: {10}translucent.la
olcModuleLoad: {11}unique.la
olcModuleLoad: {12}back_monitor.la
olcModulePath: /usr/lib/openldap2.4
objectClass: olcModuleList
cn: modules{0}
NOTE: Double check that the "olcModulePath" is the absolute path to the directory containing the OpenLDAP modules.
Step#2: Check that your schema has the groupOfURLs objectclass defined. If you attempt to configure the dynlist module without that schema available you still crash slapd. To define the dynamicGroup schema (if it is missing) you can import the following LDIF into your cn=config:
dn: cn=dynamicGroup, cn=schema, cn=config
olcObjectClasses: {0}( 2.16.840.1.113730.2.33 NAME 'groupOfURLs'
SUP top STRUCTURAL MUST cn MAY ( memberURL $ businessCat
egory $ description $ o $ ou $ owner $ seeAlso ) )
olcAttributeTypes: {0}( 2.16.840.1.113730.1.198 NAME 'memberURL'
DESC 'Identifies an URL associated with each member of a group. Any type
of labeled URL can be used.' SUP labeledURI )
objectClass: olcSchemaConfig
cn: dynamicGroup
Step#3: Create an olcOverlayConfig object in the scope of your Dit database. For example, our Dit is the 1st HDB database on the server so the appropriate object is:
dn: olcOverlay=dynlist,olcDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcDynamicList
olcOverlay: dynlist
Step#4: Now you are ready to actually use the dynlist module. A common use-case is to create dynamic mail alias objects; with dynlist you don't need to maintain mail aliases, they will automatically contain everyone who matches the relevent criteria. Provided you use the traditional nisMailAlias objectclass in order to define mail aliases adding the attribute -
olcDlAttrSet: {0}nisMailAlias labeledURI rfc822mailmember:mail- to "olcOverlay=dynlist,olcDatabase={1}hdb,cn=config" will enable dynamic mail aliases. Specifically any nisMailAlias containing a labeledURI attribute will be expanded by the query specified in that attribute. The results of that query will be rewritten by the optional rfc822mailmember:mail clause which will rename the mail attributes resulting from the query into the rfc822mailmember attribute required by consumers of the nisMailAlias objects. So rather than populating the mail alias object with rfc822mailmember attributes manually, you extend the object with the auxilliary labeledURIObject objectclass and define the query in the labeledURI attribute.
dn: cn=gr_parts, ou=ListAliases, ou=Aliases, ou=Mail, ou=SubSystems, o=Morrison Industries,c=US
mail: gr_parts@morrison-ind.com
labeledURI: ldap:///ou=People,ou=Entities,ou=SAM,o=Morrison Industries,c=US?mail?one?(&(morrisonactiveuser=Y)(objectclass=morrisonuser)(departmentNumber=*P*)(morrisonbranch=GRD))
objectClass: nisMailAlias
objectClass: top
objectClass: labeledURIObject
cn: gr_parts
The object will immediately populate with rfc822mailmember attributes derived from the mail attribute of those objects matching the specified filter: "(&(morrisonactiveuser=Y)(objectclass=morrisonuser)(departmentNumber=*P*)(morrisonbranch=GRD))". The third parameter, "one", of the URI is the scope of the query so only objects immediately subordinate to "ou=People,ou=Entities,ou=SAM,o=Morrison Industries,c=US" are candidates for the filter.
