On Thu, 14 Mar 2013, Gerhardus Geldenhuis wrote:
Just to clarify how I am testing: If my user is part of the adm user in Ubuntu it can less log files if not then it can't less log files. Adding myself to an ldap based adm group gives me the abillity to access the log files but as said above this does not seem to correlate with what nsswitch is configured to do.
I don't know if this is your actual use case, but a classic trick for file access is to make multiple groups:
adm:*:4:foo adm2:*:4:bar
with the same gid. Then you'll initgroups() the proper gid (regardless of if you're in adm or adm2) and the kernel should let you less log files or whatever. In your environment, you might consider it safe to even have adm on disk and adm2 in LDAP.
Things can get less clear for userspace programs that might do a getgrnam() or similar, of course...and for sysadmins thereof.
Just a little bit of follow up,I would have preferred to do all user and group management in ldap. We are reluctant to get rid of the adm group because of reliance on it from other services. In the case authentication failure (ldap) it would mean the server can still function without any problem. We can use puppet to configure group members of adm but that fractionates user management.
If your main concern is (potentially) offline access to LDAP this has been approached dozens of times at every possible layer. As an example of doing this on the OpenLDAP side, a local slapd(8) fed with syncrepl providing nssov can gracefully resync as network is available and still function fully when detached (for example, on a laptop or other poorly connected site). There are options at other layers (e.g. offline-aware nss providers) as well.