[Leap 16.0] Indirect automount maps and sssd

English Install/Boot/Login
,
1

I have been trying out Leap 16.0 beta, and a configuration for autofs and sssd that works fine on 15.6 fails for 16.0. Can anyone suggest what changes are needed to get around this, or have I found a problem that needs fixing?

TL;DR: autofs retrieves the master map fine through sssd, but reverts to ldap to read an indirect map. In 16.0 /usr/lib64/autofs/lookup_ldap.so is no longer provided, so the attempt to use ldap fails.

More details:

I have the following line in /etc/nsswitch.conf:

automount:   files sss

I define the following master map auto2.master on the LDAP server:

dn: nisMapName=auto2.master,ou=autofs,dc=example,dc=com
description;lang-en-gb: Top level automount map
objectClass: nisMap
nisMapName: auto2.master

dn: cn=/.net/fs4,nisMapName=auto2.master,ou=autofs,dc=example,dc=com
objectClass: nisObject
objectClass: top
nisMapEntry: nisMapName=auto.fs4,ou=autofs,dc=example,dc=com --ghost
nisMapName: auto2.master
cn: /.net/fs4

and the map that is referred to here (auto.fs4) as follows:

dn: nisMapName=auto.fs4,ou=autofs,dc=example,dc=com
description;lang-en-gb: Testing automount map
objectClass: nisMap
objectClass: top
nisMapName: auto.fs4


dn: cn=am_test,nisMapName=auto.fs4,ou=autofs,dc=example,dc=com
cn: am_test
objectClass: nisObject
objectClass: top
nisMapEntry: -fstype=nfs,rw,soft,async,noatime fs4:/volume10/exports_am_test
nisMapName: auto.fs4

automount -vf auto2.master then gives me the following output:

Starting automounter version 5.1.9, master map auto2.master
using kernel protocol version 5.06
reading files master auto2.master
lookup(file): file map /etc/auto2.master missing or not readable
lookup(file): file map /etc/auto2_master missing or not readable
reading sss master auto2.master
reading ldap map nisMapName=auto.fs4,ou=autofs,dc=example,dc=com
open_lookup:68: cannot open lookup module ldap (/usr/lib64/autofs/lookup_ldap.so: cannot open shared object file: No such file or directory)
mount_autofs_indirect: failed to read map for /.net/fs4
handle_mounts: mount of /.net/fs4 failed!
failed to stat directory or symlink /.net/fs4
could not unmount 1 dirs under /.net/fs4
umount_autofs_indirect:234: ioctl failed: Bad file descriptor
master_do_mount: failed to startup mount
no mounts in table

I can understand the reasons for favouring sssd over ldap for autofs, but then there should be a way of getting autofs to go back to sssd after the master map retrieval to cope with the decision to withdraw lookup_ldap.so. I have not managed to find anything though. Have I missed something?

2

Leap “16” is at RC, which is newer than Beta … you should use RC.

3

OK - I’ve just tried a ‘zypper up’ which told me “Nothing to do”. I should be on the latest version, or are you saying that I need to do a re-install?

4

Moving from Beta to RC (or Alpha to Beta etc) is considered a “version upgrade”, so a …

# zypper -v dup

is the appropriate choice. Try that and see how it goes.

(otherwise, yes, an “up” is what we should do).

5

You must configure both nsswitch.conf and sssd.conf so that all maps (master and indirect) are resolved through the “sss” backend. Can you also show us the current sssd.conf?

6

I am pretty sure that at some point I had done zypper dup as well. I have just tried again, and it still answers “Nothing to do”

7

Yes, you are right and thinking about this a bit more, the configuration that I said

works fine on 15.6

doesn’t really work very well on closer examination: it retrieves the master map from sss, but then gets the indirect map using ldap. This means that I am not getting the advantages of sssd in practice, for the autofs service. The sssd configuration is:

[sssd]
config_file_version = 2
services = nss,pam,autofs,ifp
domains = default

[autofs]

[domain/default]
id_provider = ldap
autofs_provider = ldap
auth_provider = ldap
ldap_schema = rfc2307
chpass_provider = ldap
ldap_uri = ldap://ldap.example.com,ldap://ldapfailover.example.com
ldap_search_base = dc=example,dc=com
ldap_id_use_start_tls = False
ldap_tls_cacertdir = /etc/openldap/certs
cache_credentials = True
ldap_tls_reqcert = allow

I have already looked for a way of configuring sssd so that indirect maps are resolved through sss as you say, but haven’t found anything (although this is not my area of expertise). If you can point me to anything that describes how to do this, I would be very grateful.

As for openSUSE, I guess the issue is:

  • If the withdrawal of autofs_ldap.so is deliberate (and I guess that it is, maybe coming from SLE?), this should be discussed in the release notes. As far as I have been able to find, there is no mention of this (in for example the documents at Index of /release-notes/x86_64/openSUSE/Leap/16.0)
  • OTOH, if autofs_ldap.so was omitted by accident, it should be restored. Even in this case, I would still be very interested in improving my sssd configuration though :wink:
8

I do not see anything in the package that indicates it. The package still BuildRequires openssl-devel and there is nothing in logs or commits. But as we are not entitled to see the build log (build happens on the internal SUSE server) I have no idea what happens and why LDAP detection fails during build.

Open bug report.

9

Unfortunately the new IDP login system on openSUSE’s Bugzilla has had the effect of locking me out. I have reached out to the Bugzilla admins to see if they can restore my access, but in the meantime it might be quicker if someone else submitted this report, sorry.

10

I have been looking into this more, and I am starting to wonder if such a configuration is even possible. I have not found any documentation or examples that show how this might be done. I suspect that the problem is in fact that the integration of automount into sssd is incomplete (or at the very least, the relevant documentation was never written). As I said, I do not consider myself an expert on this, and I could be wrong, but unless someone can show me a working sssd+ldap configuration and/or automount maps so that automount doesn’t switch to ldap for indirect maps that is my conclusion.

I’m still hoping that I am wrong, and someone on this forum can point out what I have misunderstood - otherwise my next step will to take the issue to the sssd mailing list, to try to clarify whether the problem lies with sssd or automount/autofs (or their respective documentation).

11

Returning to the master map entry you shared…

I’m at the limits of my knowledge here…but try changing that to

nisMapEntry: auto.fs4 --ghost

so that autofs asks SSSD for the map called auto.fs4.

Then check
getent automount auto2.master
and the indirect map
getent automount auto.fs4
should return entries from the auto.fs4 map

This will confirm that SSSD can resolve the map name to the actual mounts.

12

OK, I have managed to resurrect an old account and submitted a bug report: bug#1250801. Let’s see what happens.

13

Thanks for that really useful hint, a very preliminary test indicates that that works, both for systems that have automount: sss and automount: ldap in /etc/nsswitch.conf

getent automount ....

doesn’t work, because automount is not one of the services recognised by glibc. Insteasd autofs reads /etc/nsswitch.conf directly. From nsswitch.conf(5):

The GNU C Library ignores databases with unknown names. 
Some applications use  this  to  implement  special handling for their own
databases.

However, it is easy to test the map by invoking automount -fv auto2.master and checking in another shell that the remote filesystem is mounted correctly on demand.

So, I guess that the use of explicit LDAP syntax for the indirect map name is interpreted by sssd as a hint to not resolve the map by using LDAP internally. This form of the automount maps was generated originally by YaST on an old install of SLES before sssd came into the mix, so it looks like it is time for some tidying up.

I need to do some more testing, but maybe tomorrow I can mark this as solved. Thanks again!

14

Glad to have been of assistance.

Oh, right…that makes sense.

15

A full tidy up and test of the automount maps will have to wait until the middle of next week, but I have now done enough to be sure that this is the way forward. Marking this as solved, thanks.

16

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.