Description of problem: Nested automount maps fail when using "automount sssd", but the same ldap data works when using "automount ldap". Version-Release number of selected component (if applicable): autofs-5.0.7-19.fc19.x86_64 sssd-1.10.0-5.fc19.beta1.x86_64 How reproducible: Every time Steps to Reproduce: 1. Have a nested automount map, such as the attached example in ldap 2. Configure autofs to use sssd via /etc/nsswitch.conf and /etc/sssd/sssd.conf 3. Actual results: Jun 10 10:57:28 testsys5 automount[1116]: attempting to mount entry /var/phy/project/linux Jun 10 10:57:28 testsys5 automount[1116]: setautomntent: lookup(sss): setautomntent: No such file or directory Jun 10 10:57:28 testsys5 automount[1116]: lookup(sss): lookup for linux failed: connection failed Jun 10 10:57:28 testsys5 automount[1116]: key "linux" not found in map source(s). Jun 10 10:57:28 testsys5 automount[1116]: failed to mount /var/phy/project/linux Expected results: Jun 10 14:36:45 testsys5 automount[1417]: mounted /var/phy/project/linux Additional info:
Created attachment 759313 [details] Example of ldap nested automount entry
Can you post a full debug log please, from autofs start and include reproducing the error.
(In reply to Ian Kent from comment #2) > Can you post a full debug log please, from autofs start and > include reproducing the error. Jakub will probably want to see /etc/sssd/sssd.conf so could you post that as well please.
If you see that the same data works with ldap but do not work with sss, then I suspect you might be hitting an SSSD bug rather than automounter bug. Ian is right that /etc/sssd/sssd.conf would be handy, feel free to remove any sensitive data (bind DNs, passwords) from the file. Also, could you please put "debug_level = 10" into the [autofs] and [domain] sections of the sssd.conf, restart the SSSD and re-run your test case? Then attach /var/log/sssd/sssd_autofs.log and /var/log/sssd/sssd_$domain_name.log. Thank you!
One more question -- is this kind of setup something that used to work with any older version of the SSSD and broke recently or is this a new setup?
(In reply to Jakub Hrozek from comment #5) > One more question -- is this kind of setup something that used to work with > any older version of the SSSD and broke recently or is this a new setup? No. This is the first time I'm using sssd with automount. F19-Beta install doesn't set things up well for "non-sssd" ldap. I've been using sssd for passwd and such and it works great. Was aware of the autofs + sssd feature and wanted to test it out. Apart from this issue I've very happy with sssd.
Good; there's still a bug or a misconfiguration somewhere but at least we know we didn't regress.
Created attachment 759659 [details] autofs debug log messages with failed nested mount when using sssd
Created attachment 759660 [details] sssd autofs debug from failed nested mount
Created attachment 759665 [details] sssd default debug from failed nested mount Altered krb5 server hostnames and krb5 domain name because I'm not sure if it's OK to have that be public.
Created attachment 759674 [details] sssd config from failed nested mount krb5 domain and hostnames change to protect the innocent
(In reply to Jimmy Dorff from comment #8) > Created attachment 759659 [details] > autofs debug log messages with failed nested mount when using sssd This looks ok from an autofs POV. The only thing that I saw that's not expected is the leading ":" on the dn but sssd appears to be getting the correct query dn, assuming the one in the log is actually correct of course.
(In reply to Ian Kent from comment #12) > This looks ok from an autofs POV. Should I change this to a sssd bug ?
Changed. Pavel, can you also append this to your todo list?
Sure.
Hi, I had to modified your ldif to make it work with autofs+ldap. However, I can see from the autofs log that you actually use -fstype=autofs. Modified ldif: dn: ou=auto.master,dc=ldap,dc=pb objectClass: automountMap objectClass: top ou: auto.master dn: cn=/test/phy,ou=auto.master,dc=ldap,dc=pb objectClass: top objectClass: automount automountInformation: ldap ldap-server.ldap.pb:ou=auto.phy,dc=ldap,dc=pb cn: /var/phy dn: ou=auto.phy,dc=ldap,dc=pb objectClass: automountMap objectClass: top ou: auto.phy dn: cn=project,ou=auto.phy,dc=ldap,dc=pb objectClass: top objectClass: automount automountInformation: -fstype=autofs :ou=auto.project,dc=ldap,dc=pb cn: project dn: ou=auto.project,dc=ldap,dc=pb objectClass: automountMap objectClass: top ou: auto.project dn: cn=linux,ou=auto.project,dc=ldap,dc=pb objectClass: top objectClass: automount automountInformation: -fstype=nfs mount.ldap.pb:/home/pbrezina cn: linux The problem is that SSSD receives unexpected map name from autofs - 'ou=auto.project,dc=ldap,dc=pb' instead of 'auto.project', which generates wrong filter '(&(ou=ou=auto.project,dc=ldap,dc=pb)(objectclass=automountMap))'. Do we want to change this on autofs or SSSD side? You can stop using dn as a workaround. The following ldif will work with both SSSD and LDAP: dn: ou=auto.master,dc=ldap,dc=pb objectClass: automountMap objectClass: top ou: auto.master dn: cn=/test/phy,ou=auto.master,dc=ldap,dc=pb objectClass: top objectClass: automount automountInformation: auto.phy cn: /var/phy dn: ou=auto.phy,dc=ldap,dc=pb objectClass: automountMap objectClass: top ou: auto.phy dn: cn=project,ou=auto.phy,dc=ldap,dc=pb objectClass: top objectClass: automount automountInformation: -fstype=autofs auto.project cn: project dn: ou=auto.project,dc=ldap,dc=pb objectClass: automountMap objectClass: top ou: auto.project dn: cn=linux,ou=auto.project,dc=ldap,dc=pb objectClass: top objectClass: automount automountInformation: -fstype=nfs mount.ldap.pb:/home/pbrezina cn: linux
(In reply to Pavel Březina from comment #16) > > The problem is that SSSD receives unexpected map name from autofs - > 'ou=auto.project,dc=ldap,dc=pb' instead of 'auto.project', which generates > wrong filter > '(&(ou=ou=auto.project,dc=ldap,dc=pb)(objectclass=automountMap))'. Ahh .. right. > > Do we want to change this on autofs or SSSD side? > > You can stop using dn as a workaround. The following ldif will work with > both SSSD and LDAP: Using the map name alone is the recommended (simplest) way to use the NSS source lookup functionality. But I think we have cases were the map is located under a different dn which might not work for map name only. The autofs SEARCH_BASE I think will be usable by the LDAP module only too. Maybe I should consider changing that as well? Thoughts... > > dn: ou=auto.master,dc=ldap,dc=pb > objectClass: automountMap > objectClass: top > ou: auto.master > > dn: cn=/test/phy,ou=auto.master,dc=ldap,dc=pb > objectClass: top > objectClass: automount > automountInformation: auto.phy > cn: /var/phy > > dn: ou=auto.phy,dc=ldap,dc=pb > objectClass: automountMap > objectClass: top > ou: auto.phy > > dn: cn=project,ou=auto.phy,dc=ldap,dc=pb > objectClass: top > objectClass: automount > automountInformation: -fstype=autofs auto.project > cn: project > > dn: ou=auto.project,dc=ldap,dc=pb > objectClass: automountMap > objectClass: top > ou: auto.project > > dn: cn=linux,ou=auto.project,dc=ldap,dc=pb > objectClass: top > objectClass: automount > automountInformation: -fstype=nfs mount.ldap.pb:/home/pbrezina > cn: linux
I am having a similar problem. autofs + openldap + sssd works if /etc/nssswitch.conf contains "automount: files ldap sss", but not "automount: files sss" autofs-5.0.7-40.fc20.x86_64 openldap-2.4.36-4.fc20.x86_64 glibc-2.18-11.fc20.x86_64 sssd-1.11.3-1.fc20.x86_64
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.