On Fri, 2016 Jun 3 14:21+0200, Arthur de Jong wrote: > > The tricky bit here is that autofs, while partially configured in > /etc/nsswitch.conf does not use the C library NSS layer for these > lookups. You can use LDAP to export automounter maps but these will > not go through nslcd. > > Maybe I don't understand your use case completely.
The goal is, as you later mention, to centralize the LDAP configuration in nslcd. I want /etc/nslcd.conf to have all the LDAP server-related configuration (including SSL cert info in my setup), and have everything else talk to the Unix socket. I don't know about autofs not using proper NSS calls, but in theory you can point it to nslcd's Unix socket as well. (I already do this with nscd.) For autofs, I'm using "program" maps (i.e. a script that, given a key, returns a mount path), which are more flexible. What I want is a command I can call in there that will do an LDAP query via nslcd---instead of, say, a standalone invocation of ldapsearch(1) with most of the config stuff in nslcd.conf duplicated. > The problem here is that this also does not go through the NSS > subsystem so will not reach nslcd. Note that part of my request is to enable getent.ldap(1) to query these custom maps, so the query *would* go through nslcd, even though NSS has no concept of them. Making it possible to set up arbitrary maps [without needing to hard-code them in] is the goal. > Extracting these pictures and updating local copies should be pretty > simple with a small script. Not so simple when the company has over 10K users :] > A long time ago I made something like that for gdm (probably no longer > works with the most recent version), see > https://arthurdejong.org/ldapgdmfaces/ I was thinking of something along these lines for LightDM. But it would be something that returns just a single photo, not all the photos in LDAP. > At one point I did have a look into providing an autofs lookup module > that would direct requests to nslcd but the main benefit would be to > centralise configuration while that may not always be what you want > (e.g. having automounter maps on a different LDAP server than user > accounts). This would be worthwhile. Centralizing configuration is very helpful, especially for a fire-and-forget system facility like LDAP. If you have mount maps on a different server, then, well, you can't centralize two (or more) configs into one... that's less of a counterargument than it is an orthogonal use case. And at least in my (quite large) organization, it's still one all-powerful LDAP server, not a bunch of LDAP fiefdoms. > I would gladly help integrating an autofs lookup module and > automounter map support in nslcd but for me personally the current > software solution works without any real problems. Well, what I'm asking for is something more general. It could be used to implement an autofs backend, or the user-photo lookup, or any number of other things. At present, the best I can do is call ldapsearch(1) with a dozen or so arguments, post-process it with Perl, and return the requested nugget of information. > For some background see: > https://bugs.debian.org/638007 In theory, arbitrary maps could be used to implement support for sudo-ldap without requiring modifications to nslcd. > Anyway, patches for implementing automounter lookups in nslcd and > perhaps an autofs lookup module are welcome and I will do my best to > try to integrate them into nss-pam-ldapd. Again, automount maps are just an example. What I'm after is a general facility. I think quite a few folks would find that useful.
