Dieter Kluenter wrote:

Oren Laadan orenl@cs.columbia.edu writes:

...

Hi,

I use the configuration below to extend a given remote LDAP database with a relatively small number of local records. Specifically, the local database adds new (posix) groups and new autofs maps, adding to the ones already given by the remote server. (see the original thread at: http://www.openldap.org/lists/openldap-software/200802/msg00128.html)

...

... moduleload back_ldap moduleload back_bdb ... backend bdb backend ldap ... # bdb backend, configured as a subordinate of the main server database bdb suffix "dc=SUB,dc=EXAMPLE,dc=COM" readonly on subordinate ... # ldap backend, with the right DN base database ldap lastmod off suffix "dc=EXAMPLE,dc=COM" uri "ldaps://REMOTE_SERVER/" ...

The extension of groups works like charm, without any modification to the clients' setup (/etc/ldap/ldap.conf). However, the additional maps aren't observed by the autofs-ldap method and are therefore not working for users.

Running on Debian (unstable), autofs-ldap-auto-master gives:

/home ldap:ou=auto.home,ou=AutoFS,dc=EXANPLE,dc=COM /proj ldap:ou=auto.proj,ou=AutoFS,dc=EXAMPLE,dc=COM

A remote LDAP entry for /proj looks like:

dn: cn=blast,ou=auto.proj,ou=AutoFS,dc=EXAMPLE,dc=COM objectClass: automount cn: blast automountInformation: -rw blast:/export/blast

A local (added to the subtree SUB) entry for /proj looks like:

dn: cn=extra,ou=auto.proj,ou=AutoFS,dc=SUB,dc=EXAMPLE,dc=COM objectClass: automount cn: extra automountInformation: -rw extra:/export/extra

Problem is, that autofs only "sees" entries of the first type; if I run automount manually (prepending "dc=SUB," to the default way it is otherwise invoked):

/usr/sbin/automount --pid-file=/var/run/autofs/_proj.pid --timeout=300 /proj ldap ou=auto.proj,ou=AutoFS,dc=SUB,dc=EXAMPLE,dc=COM

then I can make it see the second type, but then it ignores the first type. Note that the same technique works for adding more groups. So I suspect the problem is that somehow autofs does not consider subtrees as valid results for its query to ldap.

Any ideas how to fix this ? (or perhaps suggestion how to arrange the entire setup differently and still have the same end result).

This presumably is an autofs problem, but you may have a look at slapo-rmw(5) and slapo-translucent(5).

I also believe this is an autofs problem, however I'm looking for a workaround with LDAP.

Originally I used a different setup: I used the "meta" back-end to merge two databases: the original remote one, and the extension one. I put the extension database on the local ldap server. Unfortunately However, that config resulted in the server locking-up frequently because the ldap server couldn't handle self-referrals safely.

So with the new setup I try to accomplish something similar - extend the remote database with local entries, using "subordinate". Problem is that subordinate doesn't merge two databases with the same DN, but instead extends one with the second as a "subtree", and autofs doesn't like it :(

As for your suggestions:

slapo-transparent: according to the man page it is designed to change or add attributes of/to an entry; I'm not sure how to use it to change the apparent DN of the entry ?

slapo-rwm: I tried to add this two lines after the "subordinate" line: overlay rwm rwm-suffixmassage "dc=EXAMPLE,dc=COM" and it didn't do any good. In fact, the group queries stopped working as well (from the extended database).

Can you be more specific as to how to glue everything together ?

Thanks,

Oren.