[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: extend remote server with local (subordinate) entries



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.