On Mon, 2006-07-03 at 15:53 +0200, Guillaume Rousse wrote:
> Ian Kent wrote:
> >>>>> The default name can be set in the autofs config by uncommenting the
> >>>>> line:
> >>>>>
> >>>>> DEFAULT_MASTER_MAP_NAME="auto.master"
> >>>>>
> >>>>> and changing auto.master to what you require.
> >>>> I'm still not sure however what is this file meant for: is this
> >>>> automount daemon configuration file (aka read by it whatever way you
> >>>> launch it) or the init script configuration file (aka read by the shell
> >>>> init script to give additional configurations options, such as
> >>>> command-line arguments) ?
> >>> Is used whichever way you launch it.
> >>> Except for the OPTIONS variable which is only used in the init script to
> >>> pass command line options.
> >>>
> >>>> >From your answer, it seems it is both, which make me feels
> >>>> >unconfortable.
> >>> Why.
> >>> Don't you like having the same configuration whether you launch autofs
> >>> from the init script or the command line.
> >> First, it is unusual and unexpected, hence my surprise.
> >>
> >> Second, it mix issues. As developer, you should only deal about software
> >> itself, and you let packager deal with initscripts, that belongs to
> >> specific distribution customisation. For instance, I use a mandriva
> >> specific init script to deal with specific mandriva requirements, such
> >> as parallel init system. If I want to achieve a standard setup, I have
> >> to use:
> >> - --configdir %sysconfdir/autofs option just to make automount use
> >> standard configuration location
> >> - and delete the unused OPTIONS from the example file
> >
> > A third party packager can do what ever they wish.
> > They don't have to use the init script in the package.
> > The fact is this stuff has to go somewhere because autofs needs it.
> > The sensible place for it it in the expected configuration directory.
> And my point is: the expected configuration directory for package foobar
> is /etc/foobar (%sysconfdir/foobar, actually), which is
> distribution-agnostic, not any of `/etc/sysconfig', `/etc/default' and
> `/etc/conf.d', which are merely used for storing distribution-specific
> initialisation preferences.
Personally I don't feel there is as clear distinction between package
configuration and program configuration is this particular case. I guess
the point that I make is that in version 4 configuration of this nature
(used by the init script as you point out) was held in that directory.
Also I saw other distributions using this directory for the same
purpose. So, since one of the requirements of version 5 was to take the
parsing into the daemon proper I thought it sensible to locate that type
of configuration in the place it was originally. Path of least confusion
was my motivation. You seem to have been caught out by this.
Never the less it is configurable now so it can be changed by package
maintainers.
>
> > Your example above won't work.
> > Have you actually read the INSTALL file which tells you what options
> > autofs configure understands?
> I didn't tested it, and I indeed meant --with-confdir. I just wanted to
> express that it was quite weird to have to ressort to explicit option to
> stick to standards.
At least it's configurable and these defaults can be changed fairly
easily.
Perhaps I had this sort of issue in mind when I did it and clearly you
would like to make use of it until the climate is right for it to
change.
> > Fact is that for configuration to be at all usefull autofs has to
> > understand it and cooperate with it. The only reason I added these
> > configure options was in an effort to make it easier for those who wish to
> > use different locations to customise them. If it doesn't meet with your
> > approval then I'm sorry but I like it and it works well for me. And I
> > don't see any patch submissions from you for discussion so I guess you'll
> > just have to live with it.
> I don't see the point of investing time to produce patches that will be
> rejected, so I usually try to reach agreement before. Now, if all you
> want is a patch, I can easily produce one, once we agree on the
> following points:
> - is is desirable to have distinct directories for automount
> configuration and master map location (aka --with-confdir and
> --with-mapdir switches) ?
I think so.
Certainly the map directory is different on different distributions so
that's definitely a good thing to have. And your point above would imply
having the configuration directory configurable is good as well.
> - if they differ does, autofs_ldap_auth.conf belongs to automount
> configuration or master map location ?
Good point.
But I would refer back to my original reason for the division. Perhaps
as time passes and people become familiar with the change we can move
the program configuration file to the map directory without to much
confusion.
> - is is really desirable to make those directories configurable, whereas
> a fixed /etc/autofs would be perfectly fine ?
I think so for the reasons I pointed out above.
I don't want to have to go and modify the source code if it's decided to
change this in the future. The configure script is much easier to change
if we need to change these defaults.
> - do you want initscript-related corresponding options, such as
> --with-initscriptdir and --with-initscriptconfigdir ?
Don't think that is needed.
I think the main issue being discussed here is the location of the
program configuration only. Hopefully the rest is ok.
>
> [..]
> >>>>>> - what are precedence with system configuration for openldap libraries
> >>>>>> ?
> >>>>> Don't understand what you mean here?
> >>>>>
> >>>>> If you specify a server name it will be used.
> >>>>> If not the LDAP default will be used.
> >>>>> If you specify a map only like:
> >>>>>
> >>>>> ldap:auto.master
> >>>>>
> >>>>> This should use the the LDAP default base and autofs default or
> >>>>> configured schema.
> >>>>>
> >>>>> Otherwise you must use a full dn such as:
> >>>>>
> >>>>> ldap:ou=auto.master,ou=autofs,dc=village,dc=inria,dc=fr
> >>>>>
> >>>>> consistent with requirements of LDAP utility commands.
> >>>> I was purely speaking of LDAP connection parameters, not LDAP content
> >>>> handling.
> >>>>
> >>>> I have no idea about openldap librarie API or usage in C, so I may be
> >>>> absolutly wrong here, but basically, openldap library configuration
> >>>> (classicaly, /etc/openldap/ldap.conf) already handle everything needed
> >>>> to contact (including secure connection parameters) LDAP server. So what
> >>>> is the use of distinct LDAP configuration for autofs, and additional
> >>>> SSL/TLS support there ?
> >>> Again I'm not clear on which configuration you are talking about.
> >>> Can you be specific as to the configuration options that are duplicated?
> >> Here is my current openldap configuration:
> >> BASE dc=village,dc=inria,dc=fr
> >> URI ldaps://yquem.inria.fr ldaps://julien.inria.fr
> >> TLS_CACERT /etc/ssl/ca.pem
> >> TLS_REQCERT demand
> >> TIMELIMIT 3
> >>
> >> It has everything needed for openldap clients to contact servers,
> >> including the need to use SSL connection. I just realized however it
> >> doesn't allow to start encrypted communication on standard port, so I
> >> guess that's the reason you need an additional configuration file if you
> >> want to use TLS, right ?
> >
> > The bug below means that LDAP auth config may not be installed.
> > A patch, coming soon, makes the defaults in this file more sensible and
> > adds explanations of each possible entry.
> >
> > The only configuration in autofs for TLS is a "yes" I want to use it
> > (which implies you have setup your certificates in your LDAP
> > configuration) or "no" don't use it.
> >
> > Other configuration is such things as authentication type like DIGEST-MD5
> > and a userid and secret if required. These things aren't in the LDAP
> > config either.
> >
> > The default values are used by the LDAP library if they are not
> > otherwise specified. What if your map is several more levels deep in the
> > tree. In this case, as is the case with LDAP utilities, you need to
> > specify the full dn in your specification. LDAP doesn't seem at all good at
> > filling in parts of a specification. Anuway that's my impression.
> >
> > autofs needs to know what LDAP objects and attributes your map data is
> > held in. This is also not in the default LDAP configuration.
> >
> > I'm still not clear which parts of the configuration you think shouldn't
> > be present?
> None. I was just wondering at what specific connection directives it was
> meant for, and you just replied:
> - tls support
> - secure autentication
> Basically, if you don't use them, you don't need a autofs_ldap_auth.conf
> file.
>
> >>>> [..]
> >>>>>> - are they supposed to be exported in environment before launching
> >>>>>> automount, passed to it through a bunch of -Dkey=value ?
> >>>>> Not needed.
> >>>>> The values in the config are read at startup by /usr/sbin/automount.
> >>>>> They may be overridden by values that are exported in the environment
> >>>>> prior to running /usr/sbin/automount.
> >>>> See my previous comment about distinction between program configuration
> >>>> and init script configuration. Only init script configuration should use
> >>>> /etc/sysconfdir (which happens to be /etc/default under Debian), and
> >>>> program configuration should use plain /etc or /etc/autofs location.
> >>> And /etc/default should be used by configure on a Debian system
> >>> and /etc/conf.d on a Gentoo system.
> >>>
> >>> I think the division is OK myself.
> >> Those directories are generally made for storing init parameters only,
> >> not plain configuration, wich belongs to /etc directly (or /etc/autofs
> >> eventually). And you would save yourself some troubles (such as a
> >> configure switch) if you let this kind of issues to packagers (that's
> >> their work, not yours).
> >>
> >> I just used beta6, it seems to work. However:
> >> - I have to explicitely define a LDAP dn in auto.master file, otherwise
> >> it doesn't work. it seems a bit logic, but it worked without
> >> automagically with autofs 4 :)
> >
> > No you don't.
> If I don't specify a master map name anywhere, it won't work, right ?
> With autofs4, I didn't had too, apparently autofs-ldap-auto-master was
> able to identify it alone.
Unfortunately you got caught by this bug.
This should be automatic is a similar way to version 4 and it will be
once this is sorted out. It should have been sorted out in beta6 so I'm
not sure what's happening here.
> >> - as I have to use a master file, I can't use nss master map lookup, as
> >
> > No you don't.
> > In the configuration uncomment
> > DEFAULT_MASTER_MAP_NAME="your_ldap_object_name"
> > and ensure that either the nsswitch.conf "automount:" entry doesn't have
> > files in it or there is no file of the same name in the map directory.
> AHHHHHHH... I know understand than nss-based lookup only means 'ask nss
> what facilities are available for automount, I'll interpret them
> myself', whereas I was misleaded it was 'let nss compute what my master
> map is'.
Yes. Where to look only, not what to look for.
>
> I'll submit a patch for the man page ASAP.
>
> >> I didn't found how to define this base in autofs configuration
> >
> > If there is nothing else but a map name alone then LDAP configured
> > defaults are used.
> >
> > There are some examples in the samples directory of the tarball.
> > They should be present in the normal doc directory if you built an rpm.
> I got no trouble with LDAP content, just with changes between autofs4
> and autofs5 for configuring its use.
>
> > An example of an ldap master map might be:
> >
> > DEFAULT_MASTER_MAP_NAME="nisMapName=auto_master,dc=themaw,dc=net"
> >
> > Then the LDAP configured hosts should be used for the connection.
> >
> >> - automount -d -v doesn't produce any sensible output
> >
> > Configure syslog to send deamon.* somewhere.
> > The output is meant for debuging purposes and is possibly not that
> > meaninful to most. You will be expected to provide it you have a
> > bug that you would us to try and fix.
> I was refering to log content.
> With a wrong setup, launching automount without -d -v produces 3 lines
> out output:
> Jul 3 15:19:46 alceste automount[32750]: parse_ldap_config:
> lookup(ldap): stat(2) failed with error No such file or directory.
> Jul 3 15:19:46 alceste automount[32750]: lookup_init: lookup(ldap):
> failed to get query dn
> Jul 3 15:19:46 alceste automount[32750]: master_read_master: can't read
> master map auto.master
>
> With those additional -d -v flags, it just produce one additional line:
> Jul 3 15:19:33 alceste automount[32741]: Starting automounter version
> 5.0.0_beta6, master map auto.master
> Jul 3 15:19:33 alceste automount[32741]: parse_ldap_config:
> lookup(ldap): stat(2) failed with error No such file or directory.
> Jul 3 15:19:33 alceste automount[32741]: lookup_init: lookup(ldap):
> failed to get query dn
> Jul 3 15:19:33 alceste automount[32741]: master_read_master: can't read
> master map auto.master
>
> But I guess there is not many more information to display.
But in beta6 I check if this file exists and return values as though
everything is disabled. It should work. I'll do some more testing but
are you sure that you got beta6 installed ok?
>
> >> - error message in logs for missing ldap configuration is a bit
> >> excessive for an optional file:
> >> parse_ldap_config: lookup(ldap): stat(2) failed with error No such file
> >> or directory.
> >
> > That bug should have been fixed in beta6.
> > You will need to provide appropriate information if I'm to understand
> > what's wrong and hopefully fix it.
> I'm using beta6, and this message appears if
> /etc/autofs/autofs_ldap_auth.conf doesn't exist. If I create it with
> touch, the error message becomes:
> stat(2) failed with error Inappropriate ioctl for device.
>
> The only configure flag used is --with-mapdir=%{_sysconfdir}/autofs
Shouldn't happen this way. I'll do more testing.
>
> > This problem, as it seems it still exists, will stop autofs from
> > working with LDAP almost completely, as you have seen.
> >
> > This works OK for me so unless I get more information I can't fix it.
> >
> >> I made some tests with strace, it seems automount scan all existing
> >> process at startup, is it normal ?
> >
> > It's checking to see if another instance is already running.
> > I will be adding a command line option at some point to optionally disable
> > the check.
> It doesn't hurt, I was just curious.
>
And because of other functionality in the new version it's not simple to
add this option after all, as I found out today. Oops.
Ian
_______________________________________________
autofs mailing list
[email protected]
http://linux.kernel.org/mailman/listinfo/autofs
