Bug 972895 - autofs with sssd doesn't work for nested automount maps in ldap
autofs with sssd doesn't work for nested automount maps in ldap
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: sssd (Show other bugs)
19
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Jakub Hrozek
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 976922
  Show dependency treegraph
 
Reported: 2013-06-10 14:40 EDT by Jimmy Dorff
Modified: 2015-02-18 08:56 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 976922 (view as bug list)
Environment:
Last Closed: 2015-02-18 08:56:02 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Example of ldap nested automount entry (827 bytes, text/plain)
2013-06-10 14:41 EDT, Jimmy Dorff
no flags Details
autofs debug log messages with failed nested mount when using sssd (12.17 KB, text/plain)
2013-06-11 10:55 EDT, Jimmy Dorff
no flags Details
sssd autofs debug from failed nested mount (24.15 KB, text/plain)
2013-06-11 10:56 EDT, Jimmy Dorff
no flags Details
sssd default debug from failed nested mount (70.26 KB, text/plain)
2013-06-11 10:58 EDT, Jimmy Dorff
no flags Details
sssd config from failed nested mount (553 bytes, text/plain)
2013-06-11 11:00 EDT, Jimmy Dorff
no flags Details

  None (edit)
Description Jimmy Dorff 2013-06-10 14:40:36 EDT
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:
Comment 1 Jimmy Dorff 2013-06-10 14:41:35 EDT
Created attachment 759313 [details]
Example of ldap nested automount entry
Comment 2 Ian Kent 2013-06-10 22:38:52 EDT
Can you post a full debug log please, from autofs start and
include reproducing the error.
Comment 3 Ian Kent 2013-06-11 01:07:06 EDT
(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.
Comment 4 Jakub Hrozek 2013-06-11 03:54:27 EDT
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!
Comment 5 Jakub Hrozek 2013-06-11 03:55:17 EDT
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?
Comment 6 Jimmy Dorff 2013-06-11 07:30:00 EDT
(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.
Comment 7 Jakub Hrozek 2013-06-11 07:41:38 EDT
Good; there's still a bug or a misconfiguration somewhere but at least we know we didn't regress.
Comment 8 Jimmy Dorff 2013-06-11 10:55:32 EDT
Created attachment 759659 [details]
autofs debug log messages with failed nested mount when using sssd
Comment 9 Jimmy Dorff 2013-06-11 10:56:25 EDT
Created attachment 759660 [details]
sssd autofs debug from failed nested mount
Comment 10 Jimmy Dorff 2013-06-11 10:58:18 EDT
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.
Comment 11 Jimmy Dorff 2013-06-11 11:00:57 EDT
Created attachment 759674 [details]
sssd config from failed nested mount

krb5 domain and hostnames change to protect the innocent
Comment 12 Ian Kent 2013-06-11 21:58:59 EDT
(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.
Comment 13 Jimmy Dorff 2013-06-18 10:41:16 EDT
(In reply to Ian Kent from comment #12)
> This looks ok from an autofs POV.

Should I change this to a sssd bug ?
Comment 14 Jakub Hrozek 2013-06-18 11:19:17 EDT
Changed.

Pavel, can you also append this to your todo list?
Comment 15 Pavel Březina 2013-06-19 04:22:27 EDT
Sure.
Comment 16 Pavel Březina 2013-06-21 05:14:24 EDT
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
Comment 17 Ian Kent 2013-06-21 05:54:47 EDT
(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
Comment 18 W. Michael Petullo 2014-01-11 15:53:37 EST
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
Comment 19 Fedora End Of Life 2015-01-09 17:08:59 EST
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.
Comment 20 Fedora End Of Life 2015-02-18 08:56:02 EST
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.

Note You need to log in before you can comment on or make changes to this bug.