Hi,
I have created a wiki page summarizing my design proposal on integrating SSSD with automounter: https://fedorahosted.org/sssd/wiki/DesignDocs/AutofsIntegration
Feedback is much appreciated - a reply to this email would probably work best. The target of this work is 1.8
Thank you!
On Thu, 2011-12-08 at 17:52 +0100, Jakub Hrozek wrote:
Hi,
I have created a wiki page summarizing my design proposal on integrating SSSD with automounter: https://fedorahosted.org/sssd/wiki/DesignDocs/AutofsIntegration
Feedback is much appreciated - a reply to this email would probably work best. The target of this work is 1.8
Thanks for writing this summary, it's excellent. There's not much I have to say about it because it is already quite thorough.
One thing I dislike about the discussion, and while I let it pass in bugs and mailing list discussions, I think it is wrong to put it in public design documents. The statement "autofs abuses the nsswitch.conf configuration file" I find a little offensive. autofs uses that configuration file and parses only the "automount" entry using the same semantic behavior as nss, so the word "abuse" is wrong and a little rude IMHO.
In the section "The LDAP schema used by autofs" which talks about schema it is probably worth mentioning the difficulty with the cn attribute being case insensitive. That introduces problems because key names (essentially directory names) are case sensitive and I believe that is the main reason RFC2307bis (as it relates to autofs) was adopted.
Ian
1 inline comment.
Sent from my iPhone
On Dec 8, 2011, at 16:01, Ian Kent ikent@redhat.com wrote:
On Thu, 2011-12-08 at 17:52 +0100, Jakub Hrozek wrote:
Hi,
I have created a wiki page summarizing my design proposal on integrating SSSD with automounter: https://fedorahosted.org/sssd/wiki/DesignDocs/AutofsIntegration
Feedback is much appreciated - a reply to this email would probably work best. The target of this work is 1.8
Thanks for writing this summary, it's excellent. There's not much I have to say about it because it is already quite thorough.
One thing I dislike about the discussion, and while I let it pass in bugs and mailing list discussions, I think it is wrong to put it in public design documents. The statement "autofs abuses the nsswitch.conf configuration file" I find a little offensive. autofs uses that configuration file and parses only the "automount" entry using the same semantic behavior as nss, so the word "abuse" is wrong and a little rude IMHO.
From googling: define:abuse
a·buse/əˈbyo͞oz/ Verb: Use (something) to bad effect or for a bad purpose; misuse. Indeed, what autofs is doing fits this definition to a tee. People reading technical documents generally have thick enough skin that the work abuse is not offensive. Not trying to flame, but I can't comprehend why you see the word abuse as offensive when it (to me) clearly is it. Especially not when it is used in a context fitting the definition. Much like how OpenVZ abuses procfs and IOCTLs, that's just how it is. If they used things as they were meant to be, it would not be abuse.
On Fri, Dec 09, 2011 at 08:01:44AM +0800, Ian Kent wrote:
On Thu, 2011-12-08 at 17:52 +0100, Jakub Hrozek wrote:
Hi,
I have created a wiki page summarizing my design proposal on integrating SSSD with automounter: https://fedorahosted.org/sssd/wiki/DesignDocs/AutofsIntegration
Feedback is much appreciated - a reply to this email would probably work best. The target of this work is 1.8
Thanks for writing this summary, it's excellent. There's not much I have to say about it because it is already quite thorough.
One thing I dislike about the discussion, and while I let it pass in bugs and mailing list discussions, I think it is wrong to put it in public design documents. The statement "autofs abuses the nsswitch.conf configuration file" I find a little offensive. autofs uses that configuration file and parses only the "automount" entry using the same semantic behavior as nss, so the word "abuse" is wrong and a little rude IMHO.
I'm sorry -- I didn't mean to offend you and perhaps abuse was a strong word. I've changed the design docs.
That said, I'm still not convinced that it is a good idea to use another application's config file.
My main concern is that users often mistakenly think that there is a standard glibc interface defined. Also, when the shared config file changes (not that it's likely that nsswitch would change drastically), you're in trouble -- for instance, sudo suffered recently when Fedora changed from using ldap.conf to nslcd.conf
In the section "The LDAP schema used by autofs" which talks about schema it is probably worth mentioning the difficulty with the cn attribute being case insensitive. That introduces problems because key names (essentially directory names) are case sensitive and I believe that is the main reason RFC2307bis (as it relates to autofs) was adopted.
Good point, I've included that in the design page.
On Fri, 2011-12-09 at 09:48 +0100, Jakub Hrozek wrote:
On Fri, Dec 09, 2011 at 08:01:44AM +0800, Ian Kent wrote:
On Thu, 2011-12-08 at 17:52 +0100, Jakub Hrozek wrote:
Hi,
I have created a wiki page summarizing my design proposal on integrating SSSD with automounter: https://fedorahosted.org/sssd/wiki/DesignDocs/AutofsIntegration
Feedback is much appreciated - a reply to this email would probably work best. The target of this work is 1.8
Thanks for writing this summary, it's excellent. There's not much I have to say about it because it is already quite thorough.
One thing I dislike about the discussion, and while I let it pass in bugs and mailing list discussions, I think it is wrong to put it in public design documents. The statement "autofs abuses the nsswitch.conf configuration file" I find a little offensive. autofs uses that configuration file and parses only the "automount" entry using the same semantic behavior as nss, so the word "abuse" is wrong and a little rude IMHO.
I'm sorry -- I didn't mean to offend you and perhaps abuse was a strong word. I've changed the design docs.
None taken, the word is simply to strong for the message that is being conveyed.
That said, I'm still not convinced that it is a good idea to use another application's config file.
My main concern is that users often mistakenly think that there is a standard glibc interface defined. Also, when the shared config file changes (not that it's likely that nsswitch would change drastically), you're in trouble -- for instance, sudo suffered recently when Fedora changed from using ldap.conf to nslcd.conf
It's hard to argue this point since that is my own opinion as well. But, in this case, it was so much more sensible to take the risk (the longevity of this configuration file counted in the decision) and use this particular configuration.
During the initial autofs version 5 development I spent a sufficient amount of time (quite a bit actually) trying to use the glibc nss interface for the autofs ldap lookup module (including writing the glibc backend since there were no nss "automount" modules at all) to work out that using it was going to be very painful for me, not to mention that I would have had to write "all" needed source modules myself, including their backend component and hope they would be accepted into glibc within a time frame that met my tight schedule.
So, the decision was made to break my own rule and re-use large portions of existing autofs code, and yes, I would have rather used a published interface, but for better or for worse, that is the way it was done which happens some times, unfortunately.
Ian
On Fri, 2011-12-09 at 09:48 +0100, Jakub Hrozek wrote:
One thing I dislike about the discussion, and while I let it pass in bugs and mailing list discussions, I think it is wrong to put it in public design documents. The statement "autofs abuses the nsswitch.conf configuration file" I find a little offensive. autofs uses that configuration file and parses only the "automount" entry using the same semantic behavior as nss, so the word "abuse" is wrong and a little rude IMHO.
I'm sorry -- I didn't mean to offend you and perhaps abuse was a strong word. I've changed the design docs.
Please don't get me wrong, I'm happy for people to say what they think within mailing list discussions and, to a lesser extent, within bug discussions, but in a web presented design document a little more care really should be taken IMHO.
Ian
Great document. Thanks.
Two things: 1. I do not care too much if /etc/nsswitch.conf is supposed to be used only by Glibc or not. For me the functionality is the bottom line - and here autofs does the right thing. I hate too many configuration files - the less, the better. One configuration file per service is enough (I am even sick of the extra /etc/autofs_ldap_auth.conf config file) and I don't have anything against sharing configuration files for multiple services if it makes a sense.
2. I am still not too sure about the schema expected by to automounter in LDAP. I would expect these variants should work:
a) not using full DN in automountInformation
dn: automountMapName=auto.master,dc=example,dc=com objectClass: top objectClass: automountMap automountMapName: auto.master
dn: automountKey=/home,automountMapName=auto.master,dc=example,dc=com objectClass: automount automountKey: /home automountInformation: auto.home
dn: automountMapName=auto.home,dc=example,dc=com objectClass: automountMap automountMapName: auto.home
dn: automountKey=foo,automountMapName=auto.home,dc=example,dc=com objectClass: automount automountKey: foo automountInformation: filer.example.com:/export/foo
b) same as a) but using full DN - for backward compatibility reasons
dn: automountMapName=auto.master,dc=example,dc=com objectClass: top objectClass: automountMap automountMapName: auto.master
dn: automountKey=/home,automountMapName=auto.master,dc=example,dc=com objectClass: automount automountKey: /home automountInformation: automountMapName=auto.home,dc=example,dc=com
dn: automountMapName=auto.home,dc=example,dc=com objectClass: automountMap automountMapName: auto.home
dn: automountKey=foo,automountMapName=auto.home,dc=example,dc=com objectClass: automount automountKey: foo automountInformation: filer.example.com:/export/foo
c) simplified setup - nice to have as it reflects the real filesystem
dn: automountMapName=auto.master,dc=example,dc=com objectClass: top objectClass: automountMap automountMapName: auto.master
dn: automountMapName=/home,automountMapName=auto.master,dc=example,dc=com objectClass: automountMap automountMapName: /home
dn: automountKey=foo,automountMapName=/home,automountMapName=auto.master,dc=example,dc=com objectClass: automount automountKey: foo automountInformation: filer.example.com:/export/foo
As far as I understand the options a) and b) are standards now. I have added a nice_to_have option c) as well as it somewhat reflects the actual filesystem hierarchy. I am just posting it here for feedback, knowing it would be probably rejected.
Thanks, Ondrej
On Tue, Dec 13, 2011 at 05:04:29PM +0100, Ondrej Valousek wrote:
Great document. Thanks.
Two things:
- I do not care too much if /etc/nsswitch.conf is supposed to be used
only by Glibc or not. For me the functionality is the bottom line - and here autofs does the right thing. I hate too many configuration files - the less, the better. One configuration file per service is enough (I am even sick of the extra /etc/autofs_ldap_auth.conf config file) and I don't have anything against sharing configuration files for multiple services if it makes a sense.
- I am still not too sure about the schema expected by to automounter in
LDAP. I would expect these variants should work:
a) not using full DN in automountInformation
dn: automountMapName=auto.master,dc=example,dc=com objectClass: top objectClass: automountMap automountMapName: auto.master
dn: automountKey=/home,automountMapName=auto.master,dc=example,dc=com objectClass: automount automountKey: /home automountInformation: auto.home
dn: automountMapName=auto.home,dc=example,dc=com objectClass: automountMap automountMapName: auto.home
dn: automountKey=foo,automountMapName=auto.home,dc=example,dc=com objectClass: automount automountKey: foo automountInformation: filer.example.com:/export/foo
b) same as a) but using full DN - for backward compatibility reasons
dn: automountMapName=auto.master,dc=example,dc=com objectClass: top objectClass: automountMap automountMapName: auto.master
dn: automountKey=/home,automountMapName=auto.master,dc=example,dc=com objectClass: automount automountKey: /home automountInformation: automountMapName=auto.home,dc=example,dc=com
dn: automountMapName=auto.home,dc=example,dc=com objectClass: automountMap automountMapName: auto.home
dn: automountKey=foo,automountMapName=auto.home,dc=example,dc=com objectClass: automount automountKey: foo automountInformation: filer.example.com:/export/foo
c) simplified setup - nice to have as it reflects the real filesystem
dn: automountMapName=auto.master,dc=example,dc=com objectClass: top objectClass: automountMap automountMapName: auto.master
dn: automountMapName=/home,automountMapName=auto.master,dc=example,dc=com objectClass: automountMap automountMapName: /home
dn: automountKey=foo,automountMapName=/home,automountMapName=auto.master,dc=example,dc=com objectClass: automount automountKey: foo automountInformation: filer.example.com:/export/foo
As far as I understand the options a) and b) are standards now.
I believe that from SSSD's point of view, a) and b) are the same. Only the "automountInformation" attribute differs and that will be consumed on the autofs side.
I have added a nice_to_have option c) as well as it somewhat reflects the actual filesystem hierarchy. I am just posting it here for feedback, knowing it would be probably rejected.
Is this schema used anywhere? If so, we might want to add support for it, even if not in the first iteration.
sssd-devel@lists.fedorahosted.org