autofs5: unable to locate ldap master map

autofs5: unable to locate ldap master map

[Guillaume Rousse]

I just tested autofs5 (beta5), and I'm a bit confused about using
LDAP-defined master map... Especially when eveything worked out of the
box with autofs 4 :)

First, how the master map is located is still a bit obscure for me...
From the man page, it seems they are two different way to find it:
- file based
- nss based
The first occurs when automount argument or default value for this
argument is an explicit filename, the second occurs otherwise

nss-based master map lookup use the line 'automount' in
/etc/nsswitch.conf, and may use at least the following values (from
autofs4 init script):
- file
- ldap
- nis

Explanations about how behave each of those option is missing, but I
expect ldap value to behave as previously, meaning automagically using
openldap libraries.

So, to use a an ldap master map, I could either
1) used file-based master map lookup, by using "/usr/sbin/automount
/etc/autofs/auto.master" (or just "/usr/sbin/automount" as it is the
default value), and insert something as:
+ldap:ou=auto.master,ou=autofs,dc=village,dc=inria,dc=fr

2) using nss-based master map lookup, by using "/usr/sbin/automount
name-without-path", and insert a "ldap" value in "automount" line in
"/etc/nsswitch.conf"

However, the only way I found to force nss-based master map lookup was
"/usr/sbin/automount +auto.master" (where description says: name has no
 path), or to add +auto.master in auto.master file (where documentation
says: + [map-type,format:]map[options]) and use file-based lookup.

Second, searching master map in ldap doesn't work either, and I'm unable
to understand why:
- what is supposed to happen in the absence of autofs_ldap_auth.conf ?
- what are configuration options available there, beyond the one given
in example (ssl or just tls, for instance) ?
- what are precedence with system configuration for openldap libraries ?
- are the various variables defined in /etc/sysconfig/autofs mandatory,
or are they just alternate default values ?
- are they supposed to be exported in environment before launching
automount, passed to it through a bunch of -Dkey=value ?

The only hints I was able to collect were those error messages in the logs:
Jun 28 11:45:13 alceste automount[4191]: get_server_SASL_mechanisms: No
SASL authentication mechanisms are supported by the LDAP server.
Jun 28 11:45:13 alceste automount[4191]: lookup_init: lookup(ldap):
cannot initialize auth setup

If this matter, I build autofs with --with-mapdir=/etc/autofs as
argument, on x86_64 running mandriva cooker. And i'm running a 2.6.17
kernel.

Thanks for your help.
-- 
Guillaume Rousse
Projet Estime, INRIA
Domaine de Voluceau
Rocquencourt - B.P. 105
78153 Le Chesnay Cedex - France

Re: autofs5: unable to locate ldap master map

[Ian Kent]

On Wed, 2006-06-28 at 11:59 +0200, Guillaume Rousse wrote:
> I just tested autofs5 (beta5), and I'm a bit confused about using
> LDAP-defined master map... Especially when eveything worked out of the
> box with autofs 4 :)

Yes.

I had an incorrect LDAP test database and so this was somewhat broken.
There are a number of patches for beta5 on kernel.org and at least a
couple more coming. Have you applied them all.

There's a patch_order-5.0.0_beta5 which gives the order they need to be
applied.

> 
> First, how the master map is located is still a bit obscure for me...
> >From the man page, it seems they are two different way to find it:
> - file based
> - nss based
> The first occurs when automount argument or default value for this
> argument is an explicit filename, the second occurs otherwise
> 
> nss-based master map lookup use the line 'automount' in
> /etc/nsswitch.conf, and may use at least the following values (from
> autofs4 init script):
> - file
> - ldap
> - nis

nisplus should also work but I'm unable to test this.
Anyone care to try this?

> 
> Explanations about how behave each of those option is missing, but I
> expect ldap value to behave as previously, meaning automagically using
> openldap libraries.

It does and it uses the configured defaults to the extent that the
openldap library calls do.

> 
> So, to use a an ldap master map, I could either
> 1) used file-based master map lookup, by using "/usr/sbin/automount
> /etc/autofs/auto.master" (or just "/usr/sbin/automount" as it is the
> default value), and insert something as:
> +ldap:ou=auto.master,ou=autofs,dc=village,dc=inria,dc=fr

or just have +auto.master and autofs will know not to look for a file
based master map of the same name if files is listed as a nss source.

I'm not sure I've tested the ldap spec (no server present) above with
the recent fixes. I'll check that.

> 
> 2) using nss-based master map lookup, by using "/usr/sbin/automount
> name-without-path", and insert a "ldap" value in "automount" line in
> "/etc/nsswitch.conf"

Yep. Or just use the default name which is auto.master.

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.

> 
> However, the only way I found to force nss-based master map lookup was
> "/usr/sbin/automount +auto.master" (where description says: name has no
>  path), or to add +auto.master in auto.master file (where documentation
> says: + [map-type,format:]map[options]) and use file-based lookup.
> 
> Second, searching master map in ldap doesn't work either, and I'm unable
> to understand why:
> - what is supposed to happen in the absence of autofs_ldap_auth.conf ?

This was broken but has recently been fixed.

> - what are configuration options available there, beyond the one given
> in example (ssl or just tls, for instance) ?

Only tls is available at the moment.
I'm undecided as to ssl support at this stage.

> - 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.

> - are the various variables defined in /etc/sysconfig/autofs mandatory,
> or are they just alternate default values ?

By and large the commented values are the internal defaults except for
the LDAP schema of which there are three examples. The internal default
is noted in a comment above it.

You should be able to use any schema you wish provided the entries have
the correct objectclass and attributes. The goal is to have this work in
that way.

The other values provide a way to alter the internal default values but
if another value is specified in a map then it will be used instead.

> - 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.

The -D option cannot be used to set these values.
This option is used for macro substitution in mount map entries not to
set program defaults.

> 
> The only hints I was able to collect were those error messages in the logs:
> Jun 28 11:45:13 alceste automount[4191]: get_server_SASL_mechanisms: No
> SASL authentication mechanisms are supported by the LDAP server.
> Jun 28 11:45:13 alceste automount[4191]: lookup_init: lookup(ldap):
> cannot initialize auth setup

I believe there may still be a problem with this bit of the LDAP code.
Sorry, I'm aware of it.

> 
> If this matter, I build autofs with --with-mapdir=/etc/autofs as
> argument, on x86_64 running mandriva cooker. And i'm running a 2.6.17
> kernel.

2.6.17 is good.

You will find 2 additional kernel patches on kernel.org.
You may need them as well but possibly not, depending on the map types
used.

I'm planing to update the kernel patches in the distribution soon.

Ian

Re: autofs5: unable to locate ldap master map

[Guillaume Rousse]

Ian Kent wrote:
> On Wed, 2006-06-28 at 11:59 +0200, Guillaume Rousse wrote:
>> I just tested autofs5 (beta5), and I'm a bit confused about using
>> LDAP-defined master map... Especially when eveything worked out of the
>> box with autofs 4 :)
> 
> Yes.
> 
> I had an incorrect LDAP test database and so this was somewhat broken.
> There are a number of patches for beta5 on kernel.org and at least a
> couple more coming. Have you applied them all.
> 
> There's a patch_order-5.0.0_beta5 which gives the order they need to be
> applied.
Ouch, 17 patches :(

>> First, how the master map is located is still a bit obscure for me...
>> >From the man page, it seems they are two different way to find it:
>> - file based
>> - nss based
>> The first occurs when automount argument or default value for this
>> argument is an explicit filename, the second occurs otherwise
>>
>> nss-based master map lookup use the line 'automount' in
>> /etc/nsswitch.conf, and may use at least the following values (from
>> autofs4 init script):
>> - file
>> - ldap
>> - nis
> 
> nisplus should also work but I'm unable to test this.
> Anyone care to try this?
And please document them also... what file will be looked for by nss if
'file' option is used there ?

>> Explanations about how behave each of those option is missing, but I
>> expect ldap value to behave as previously, meaning automagically using
>> openldap libraries.
> 
> It does and it uses the configured defaults to the extent that the
> openldap library calls do.
> 
>> So, to use a an ldap master map, I could either
>> 1) used file-based master map lookup, by using "/usr/sbin/automount
>> /etc/autofs/auto.master" (or just "/usr/sbin/automount" as it is the
>> default value), and insert something as:
>> +ldap:ou=auto.master,ou=autofs,dc=village,dc=inria,dc=fr
> 
> or just have +auto.master and autofs will know not to look for a file
> based master map of the same name if files is listed as a nss source.
As automount argument or as master map file content ?

I guess the second, as that's also the content of the sample master map
file given. However, I really find its meaning obscure: from man page
explanations about this syntax ("+ [map-type,format:]map[options]"), it
seems to be a map name without type, which doesn't have default value.

> I'm not sure I've tested the ldap spec (no server present) above with
> the recent fixes. I'll check that.
> 
>> 2) using nss-based master map lookup, by using "/usr/sbin/automount
>> name-without-path", and insert a "ldap" value in "automount" line in
>> "/etc/nsswitch.conf"
> 
> Yep. Or just use the default name which is auto.master.
Right (according to include/default.h), but then man page template has
to be corrected: it gives "@autofsmapdir@@/auto.master" as default.

> 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) ?

From your answer, it seems it is both, which make me feels unconfortable.

>> However, the only way I found to force nss-based master map lookup was
>> "/usr/sbin/automount +auto.master" (where description says: name has no
>>  path), or to add +auto.master in auto.master file (where documentation
>> says: + [map-type,format:]map[options]) and use file-based lookup.
Which makes me still wonder:
- what does mean description by "name has no path" ? No / inside ?
- what the meaning of this name, if it is just a boolean trigger to use
nss to locate master map ? it could as well be "foobar" then

[..]
>> - 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 ?


[..]
>> - 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.

> The -D option cannot be used to set these values.
> This option is used for macro substitution in mount map entries not to
> set program defaults.
OK.

>> The only hints I was able to collect were those error messages in the logs:
>> Jun 28 11:45:13 alceste automount[4191]: get_server_SASL_mechanisms: No
>> SASL authentication mechanisms are supported by the LDAP server.
>> Jun 28 11:45:13 alceste automount[4191]: lookup_init: lookup(ldap):
>> cannot initialize auth setup
> 
> I believe there may still be a problem with this bit of the LDAP code.
> Sorry, I'm aware of it.
I've just applied available patches, I'll test ASAP.

>> If this matter, I build autofs with --with-mapdir=/etc/autofs as
>> argument, on x86_64 running mandriva cooker. And i'm running a 2.6.17
>> kernel.
> 
> 2.6.17 is good.
> 
> You will find 2 additional kernel patches on kernel.org.
> You may need them as well but possibly not, depending on the map types
> used.
> 
> I'm planing to update the kernel patches in the distribution soon.
I have no hand on the distribution kernel, unfortunatly, and I'm even
using a contributed kernel for those test, not the official mandriva one :/
-- 
Guillaume Rousse
Projet Estime, INRIA
Domaine de Voluceau
Rocquencourt - B.P. 105
78153 Le Chesnay Cedex - France

Re: autofs5: unable to locate ldap master map

[Ian Kent]

On Thu, 2006-06-29 at 13:17 +0200, Guillaume Rousse wrote:
> Ian Kent wrote:
> > On Wed, 2006-06-28 at 11:59 +0200, Guillaume Rousse wrote:
> >> I just tested autofs5 (beta5), and I'm a bit confused about using
> >> LDAP-defined master map... Especially when eveything worked out of the
> >> box with autofs 4 :)
> > 
> > Yes.
> > 
> > I had an incorrect LDAP test database and so this was somewhat broken.
> > There are a number of patches for beta5 on kernel.org and at least a
> > couple more coming. Have you applied them all.
> > 
> > There's a patch_order-5.0.0_beta5 which gives the order they need to be
> > applied.
> Ouch, 17 patches :(

Just missed I think.
I consolidated to beta6 just now.

> 
> >> First, how the master map is located is still a bit obscure for me...
> >> >From the man page, it seems they are two different way to find it:
> >> - file based
> >> - nss based
> >> The first occurs when automount argument or default value for this
> >> argument is an explicit filename, the second occurs otherwise
> >>
> >> nss-based master map lookup use the line 'automount' in
> >> /etc/nsswitch.conf, and may use at least the following values (from
> >> autofs4 init script):
> >> - file
> >> - ldap
> >> - nis
> > 
> > nisplus should also work but I'm unable to test this.
> > Anyone care to try this?
> And please document them also... what file will be looked for by nss if
> 'file' option is used there ?

Don't understand the question?

> 
> >> Explanations about how behave each of those option is missing, but I
> >> expect ldap value to behave as previously, meaning automagically using
> >> openldap libraries.
> > 
> > It does and it uses the configured defaults to the extent that the
> > openldap library calls do.
> > 
> >> So, to use a an ldap master map, I could either
> >> 1) used file-based master map lookup, by using "/usr/sbin/automount
> >> /etc/autofs/auto.master" (or just "/usr/sbin/automount" as it is the
> >> default value), and insert something as:
> >> +ldap:ou=auto.master,ou=autofs,dc=village,dc=inria,dc=fr
> > 
> > or just have +auto.master and autofs will know not to look for a file
> > based master map of the same name if files is listed as a nss source.
> As automount argument or as master map file content ?
> 
> I guess the second, as that's also the content of the sample master map
> file given. However, I really find its meaning obscure: from man page
> explanations about this syntax ("+ [map-type,format:]map[options]"), it
> seems to be a map name without type, which doesn't have default value.

no default => try map sources in nsswitch.

> 
> > I'm not sure I've tested the ldap spec (no server present) above with
> > the recent fixes. I'll check that.

Functions as expected.

> > 
> >> 2) using nss-based master map lookup, by using "/usr/sbin/automount
> >> name-without-path", and insert a "ldap" value in "automount" line in
> >> "/etc/nsswitch.conf"
> > 
> > Yep. Or just use the default name which is auto.master.
> Right (according to include/default.h), but then man page template has
> to be corrected: it gives "@autofsmapdir@@/auto.master" as default.

Oops. I'll fix that.

> 
> > 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.

> 
> >> However, the only way I found to force nss-based master map lookup was
> >> "/usr/sbin/automount +auto.master" (where description says: name has no
> >>  path), or to add +auto.master in auto.master file (where documentation
> >> says: + [map-type,format:]map[options]) and use file-based lookup.
> Which makes me still wonder:
> - what does mean description by "name has no path" ? No / inside ?
> - what the meaning of this name, if it is just a boolean trigger to use
> nss to locate master map ? it could as well be "foobar" then

Mmm .. it should be illegal to pass "+<mapname>" on the command line.
Plus included maps are "only legal in file maps".
I'll check that.

"name has no path" should mean that the name has no "/"s

Don't follow the rest of this question.

Perhaps you could craft a patch that would clear this up?

> 
> [..]
> >> - 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?

> 
> 
> [..]
> >> - 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.

> 
> > The -D option cannot be used to set these values.
> > This option is used for macro substitution in mount map entries not to
> > set program defaults.
> OK.
> 
> >> The only hints I was able to collect were those error messages in the logs:
> >> Jun 28 11:45:13 alceste automount[4191]: get_server_SASL_mechanisms: No
> >> SASL authentication mechanisms are supported by the LDAP server.
> >> Jun 28 11:45:13 alceste automount[4191]: lookup_init: lookup(ldap):
> >> cannot initialize auth setup
> > 
> > I believe there may still be a problem with this bit of the LDAP code.
> > Sorry, I'm aware of it.
> I've just applied available patches, I'll test ASAP.

Sorry.
Just missed with beta6.

> 
> >> If this matter, I build autofs with --with-mapdir=/etc/autofs as
> >> argument, on x86_64 running mandriva cooker. And i'm running a 2.6.17
> >> kernel.
> > 
> > 2.6.17 is good.
> > 
> > You will find 2 additional kernel patches on kernel.org.
> > You may need them as well but possibly not, depending on the map types
> > used.
> > 
> > I'm planing to update the kernel patches in the distribution soon.
> I have no hand on the distribution kernel, unfortunatly, and I'm even
> using a contributed kernel for those test, not the official mandriva one :/

2.6.17 should be fine.

Ian

Re: autofs5: unable to locate ldap master map

[Guillaume Rousse]

Ian Kent wrote:
>>>> nss-based master map lookup use the line 'automount' in
>>>> /etc/nsswitch.conf, and may use at least the following values (from
>>>> autofs4 init script):
>>>> - file
>>>> - ldap
>>>> - nis
>>> nisplus should also work but I'm unable to test this.
>>> Anyone care to try this?
>> And please document them also... what file will be looked for by nss if
>> 'file' option is used there ?
> 
> Don't understand the question?
'file' option for nss user service means 'look for /etc/passwd'. What
does it means for nss automount service ?

And how do you avoid loops if you can make nss look for a file, and a
file trigger nss lookup ?

>>>> Explanations about how behave each of those option is missing, but I
>>>> expect ldap value to behave as previously, meaning automagically using
>>>> openldap libraries.
>>> It does and it uses the configured defaults to the extent that the
>>> openldap library calls do.
>>>
>>>> So, to use a an ldap master map, I could either
>>>> 1) used file-based master map lookup, by using "/usr/sbin/automount
>>>> /etc/autofs/auto.master" (or just "/usr/sbin/automount" as it is the
>>>> default value), and insert something as:
>>>> +ldap:ou=auto.master,ou=autofs,dc=village,dc=inria,dc=fr
>>> or just have +auto.master and autofs will know not to look for a file
>>> based master map of the same name if files is listed as a nss source.
>> As automount argument or as master map file content ?
>>
>> I guess the second, as that's also the content of the sample master map
>> file given. However, I really find its meaning obscure: from man page
>> explanations about this syntax ("+ [map-type,format:]map[options]"), it
>> seems to be a map name without type, which doesn't have default value.
> 
> no default => try map sources in nsswitch.
So basically, it is:
- a way to trigger nss master map lookup even if using file master map
lookup primarily
- a specific syntax not described in auto.master man page

>>> I'm not sure I've tested the ldap spec (no server present) above with
>>> the recent fixes. I'll check that.
> 
> Functions as expected.
> 
>>>> 2) using nss-based master map lookup, by using "/usr/sbin/automount
>>>> name-without-path", and insert a "ldap" value in "automount" line in
>>>> "/etc/nsswitch.conf"
>>> Yep. Or just use the default name which is auto.master.
>> Right (according to include/default.h), but then man page template has
>> to be corrected: it gives "@autofsmapdir@@/auto.master" as default.
> 
> Oops. I'll fix that.
> 
>>> 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

You can't handle distribution diversity from developper point of view,
it is not scalable. But separating concerns make life easier for people
doing this task.

>>>> However, the only way I found to force nss-based master map lookup was
>>>> "/usr/sbin/automount +auto.master" (where description says: name has no
>>>>  path), or to add +auto.master in auto.master file (where documentation
>>>> says: + [map-type,format:]map[options]) and use file-based lookup.
>> Which makes me still wonder:
>> - what does mean description by "name has no path" ? No / inside ?
>> - what the meaning of this name, if it is just a boolean trigger to use
>> nss to locate master map ? it could as well be "foobar" then
> 
> Mmm .. it should be illegal to pass "+<mapname>" on the command line.
> Plus included maps are "only legal in file maps".
> I'll check that.
> 
> "name has no path" should mean that the name has no "/"s
> 
> Don't follow the rest of this question.
If I use "usr/sbin/automount foobar", will it trigger nss master map
lookup also ? Will it pass foobar as argument ?
> 
> Perhaps you could craft a patch that would clear this up?
As soon as I will get sure I understand things correctly, sure :)

>> [..]
>>>> - 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 ?

>
>> [..]
>>>> - 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 :)
- as I have to use a master file, I can't use nss master map lookup, as
I didn't found how to define this base in autofs configuration
- automount -d -v doesn't produce any sensible output
- 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.

I made some tests with strace, it seems automount scan all existing
process at startup, is it normal ?
-- 
Guillaume Rousse
Projet Estime, INRIA
Domaine de Voluceau
Rocquencourt - B.P. 105
78153 Le Chesnay Cedex - France

Re: autofs5: unable to locate ldap master map

[Ian Kent]

On Fri, 30 Jun 2006, Guillaume Rousse wrote:

> Ian Kent wrote:
> >>>> nss-based master map lookup use the line 'automount' in
> >>>> /etc/nsswitch.conf, and may use at least the following values (from
> >>>> autofs4 init script):
> >>>> - file
> >>>> - ldap
> >>>> - nis
> >>> nisplus should also work but I'm unable to test this.
> >>> Anyone care to try this?
> >> And please document them also... what file will be looked for by nss if
> >> 'file' option is used there ?
> > 
> > Don't understand the question?
> 'file' option for nss user service means 'look for /etc/passwd'. What
> does it means for nss automount service ?

There must always be a map name given.
So it looks for this map name in the configured autofs map dir.

> 
> And how do you avoid loops if you can make nss look for a file, and a
> file trigger nss lookup ?

Maybe you are talking about plus included maps.
autofs won't include a map of the same name as the one it's reading.
There's a limit on the depth of plus included maps.

> 
> >>>> Explanations about how behave each of those option is missing, but I
> >>>> expect ldap value to behave as previously, meaning automagically using
> >>>> openldap libraries.
> >>> It does and it uses the configured defaults to the extent that the
> >>> openldap library calls do.
> >>>
> >>>> So, to use a an ldap master map, I could either
> >>>> 1) used file-based master map lookup, by using "/usr/sbin/automount
> >>>> /etc/autofs/auto.master" (or just "/usr/sbin/automount" as it is the
> >>>> default value), and insert something as:
> >>>> +ldap:ou=auto.master,ou=autofs,dc=village,dc=inria,dc=fr
> >>> or just have +auto.master and autofs will know not to look for a file
> >>> based master map of the same name if files is listed as a nss source.
> >> As automount argument or as master map file content ?
> >>
> >> I guess the second, as that's also the content of the sample master map
> >> file given. However, I really find its meaning obscure: from man page
> >> explanations about this syntax ("+ [map-type,format:]map[options]"), it
> >> seems to be a map name without type, which doesn't have default value.
> > 
> > no default => try map sources in nsswitch.
> So basically, it is:
> - a way to trigger nss master map lookup even if using file master map
> lookup primarily

There's only ever one master map possibly with plus included sections.
There's still only one.
It is never "looked up" it's read and parsed.

Map (not the master map) keys are "looked up" and the filesystem locations 
they correspond to are then used to attempt to mount the filesystem.

> - a specific syntax not described in auto.master man page

The master map syntax is described in auto.master(5).
Map entry (not master map) format is described in autofs(5).

Read the litrature for a general understanding of automount if the man 
pages aren't enough.

I'll never include the detail that's in books such as
Managing NFS and NIS, Eisler & Labiaga, chapter 9 or
NFS Illustrated, Callaghan, chaper 11.

You may also find
http://www.themaw.net/autofs_linux_kongress
useful although some of the description is now out of date.

The man pages will only ever attempt to describe the formats and give 
information about differences in a relatively basic way.

> 
> >>> I'm not sure I've tested the ldap spec (no server present) above with
> >>> the recent fixes. I'll check that.
> > 
> > Functions as expected.
> > 
> >>>> 2) using nss-based master map lookup, by using "/usr/sbin/automount
> >>>> name-without-path", and insert a "ldap" value in "automount" line in
> >>>> "/etc/nsswitch.conf"
> >>> Yep. Or just use the default name which is auto.master.
> >> Right (according to include/default.h), but then man page template has
> >> to be corrected: it gives "@autofsmapdir@@/auto.master" as default.
> > 
> > Oops. I'll fix that.
> > 
> >>> 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.

Your example above won't work.
Have you actually read the INSTALL file which tells you what options 
autofs configure understands?

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.

> 
> You can't handle distribution diversity from developper point of view,
> it is not scalable. But separating concerns make life easier for people
> doing this task.
> 
> >>>> However, the only way I found to force nss-based master map lookup was
> >>>> "/usr/sbin/automount +auto.master" (where description says: name has no
> >>>>  path), or to add +auto.master in auto.master file (where documentation
> >>>> says: + [map-type,format:]map[options]) and use file-based lookup.
> >> Which makes me still wonder:
> >> - what does mean description by "name has no path" ? No / inside ?
> >> - what the meaning of this name, if it is just a boolean trigger to use
> >> nss to locate master map ? it could as well be "foobar" then
> > 
> > Mmm .. it should be illegal to pass "+<mapname>" on the command line.
> > Plus included maps are "only legal in file maps".
> > I'll check that.
> > 
> > "name has no path" should mean that the name has no "/"s
> > 
> > Don't follow the rest of this question.
> If I use "usr/sbin/automount foobar", will it trigger nss master map
> lookup also ? Will it pass foobar as argument ?

Basically yes.

auto.master(5).

The parameter is the master map.
If it is not file, ie. starts with a "/", then we use nsswitch to 
attempt to locate it.

> > 
> > Perhaps you could craft a patch that would clear this up?
> As soon as I will get sure I understand things correctly, sure :)
> 
> >> [..]
> >>>> - 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?

> 
> >
> >> [..]
> >>>> - 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.

> - 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.

> 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.

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.

> - 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.

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.

Ian

Re: autofs5: unable to locate ldap master map

[Guillaume Rousse]

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.

> 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.

> 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) ?
- if they differ does, autofs_ldap_auth.conf belongs to automount
configuration or master map location ?
- is is really desirable to make those directories configurable, whereas
a fixed /etc/autofs would be perfectly fine ?
- do you want initscript-related corresponding options, such as
--with-initscriptdir and --with-initscriptconfigdir ?

[..]
>>>>>> - 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.

>> - 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'.

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.

>> - 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

> 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.

-- 
Guillaume Rousse
Projet Estime, INRIA
Domaine de Voluceau
Rocquencourt - B.P. 105
78153 Le Chesnay Cedex - France

Re: autofs5: unable to locate ldap master map

[Ian Kent]

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

Re: autofs5: unable to locate ldap master map

[Ian Kent]

On Tue, 2006-07-04 at 00:15 +0800, Ian Kent wrote:
> > > 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?

Thanks for your persistence.
I have indeed made a mistake with the check for existence of this file.
I'll fix it and get a patch onto kernel.org.

Ian

Re: autofs5: unable to locate ldap master map

[Jeff Moyer]

==> Regarding Re: [autofs] autofs5: unable to locate ldap master map; Ian Kent <raven@themaw.net> adds:
>> > 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) ?

raven> I think so.
raven> Certainly the map directory is different on different distributions so
raven> that's definitely a good thing to have. And your point above would imply
raven> having the configuration directory configurable is good as well.

If you're using a mixed environment (Linux and other Unix variants), then
you'll likely keep your maps in /etc/ for interoperability purposes.  As
such, I don't really see a reason to put maps elsewhere.

-Jeff

Re: autofs5: unable to locate ldap master map

[Guillaume Rousse]

Sorry for this late reply, I was caught by work and hollidays.

Ian Kent wrote:
>>> 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.
Personally, I'd rather take advantage of a new major version release for
this kind of changes, where people expect non-transparent changes, and
the fact than most of these directives didn't existed previously, rather
than some later 5.0 -> 5.1 transition.

>>> 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.
Distributions enforce constraints on distribution-specific items, such
as init scripts for instance. I don't think neither map or autofs daemon
configuration can get considered as "distribution specific".

But you actually answer to my question n°3 here, aka "should they be
configurable" ? My question n°1 was "should they be distinct" ? What
would be wrong having maps _and_ autofs configuration in the same
directory ?

>> - 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.
I was not discussing changing code or configure script issue, but the
use of configure script specific switches for those directories, instead
of just standard sysconfdir variable, that is already configurable.

>> - 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.
Agreed.
-- 
Guillaume Rousse
Projet Estime, INRIA
Domaine de Voluceau
Rocquencourt - B.P. 105
78153 Le Chesnay Cedex - France

Re: autofs5: unable to locate ldap master map

[Guillaume Rousse]

Ian Kent wrote:
> On Thu, 2006-06-29 at 13:17 +0200, Guillaume Rousse wrote:
>>>> 2) using nss-based master map lookup, by using "/usr/sbin/automount
>>>> name-without-path", and insert a "ldap" value in "automount" line in
>>>> "/etc/nsswitch.conf"
>>> Yep. Or just use the default name which is auto.master.
>> Right (according to include/default.h), but then man page template has
>> to be corrected: it gives "@autofsmapdir@@/auto.master" as default.
> 
> Oops. I'll fix that.
Here is the patch, quite longue because the file is renamed now that no
substitution is needed anymore.

diff -Naur autofs-5.0.1/man/automount.8
autofs-5.0.1.fix-man-page/man/automount.8
--- autofs-5.0.1/man/automount.8	1970-01-01 01:00:00.000000000 +0100
+++ autofs-5.0.1.fix-man-page/man/automount.8	2006-08-23
13:52:26.000000000 +0200
@@ -0,0 +1,107 @@
+.\" Linux man page by B. James Phillippe, 1997 <bryan@Terran.ORG>
+.\"
+.\" This page was written to contribute to the Linux kernel autofs
+.\" implementation by H. Peter Anvin (1997).  It is loosly based on
+.\" the documentation for mount(8) and amd(8) Linux manpages.
+.\"
+.\" This is free documentation.
+.\"
+.\" $Id: automount.8,v 1.8 2004/11/20 13:54:39 raven Exp $
+.\"
+.TH AUTOMOUNT 8 "12 Apr 2006"
+.SH NAME
+automount \- manage autofs mount points
+.SH SYNOPSIS
+\fBautomount\fP [\fIoptions\fP] [\fImaster_map\fP]
+.SH DESCRIPTION
+The \fBautomount\fP program is used to manage mount points for
+autofs, the inlined Linux automounter.  \fBautomount\fP works by
+reading the
+.nh
+.BR auto.master (8)
+.hy
+map and sets up mount points for each entry in the master map allowing
+them to be automatically mounted when accessed. The file systems are
+then automatically umounted after a period of inactivity.
+.SH OPTIONS
+.TP
+.I "\-h, \-\-help"
+Print brief help on program usage.
+.TP
+.I "\-p, \-\-pid-file"
+Write the pid of the daemon to the specified file.
+.TP
+.I "\-t, \-\-timeout"
+Set the global minimum timeout, in seconds, until directories
+are unmounted. The default is 10 minutes. Setting the timeout
+to zero disables umounts completely.
+.TP
+.I "\-v, \-\-verbose"
+Enables logging of general status and progress messages for all
+autofs managed mounts.
+.TP
+.I "\-d, \-\-debug"
+Enables logging of general status and progress messages as well as
+debuging messages for all autofs managed mounts.
+.TP
+.I "\-Dvariable=value"
+Define a global macro substitution variable. Global definitions
+are over-ridden macro definitions of the same name specified in
+mount entries.
+.TP
+.I "\-V, \-\-version"
+Display the version number, then exit.
+.SH ARGUMENTS
+\fBautomount\fP takes one optional argument, the name of the master map to
+use.
+.TP
+\fBmaster_map\fP
+Location for autofs master map that defines autofs managed mount points
+and the mount maps they will use. The default is
+.nh
+\fBauto.master\fP.
+.hy
+.RE
+.SH NOTES
+If the \fBautomount\fP daemon catches a USR1 signal, it will umount all
+currently unused autofs managed mounted file systems and continue running
+(forced expire).  If it catches the TERM signal it will umount
+all unused autofs managed mounted file systems and exit if there are
+no remaining busy file systems. If autofs has been compiled with the
+option to ignore busy mounts on exit it will exit leaving any busy
+mounts in place otherwise busy file systems will not be umounted
+and autofs will not exit.
+Alternatively, if autofs has been compiled with the option to enable
+forced shutdown then a USR2 signal to the daemon will cause all
+mounts to be umounted and any busy mounts to be forcibly umounted,
+including autofs mount point directories (summary execution). Note
+that the forced umount is an unlink operation and the actual umount
+will not happen in the kernel until active file handles are released.
+The daemon also responds to a HUP signal which triggers an update of
+the maps for each mount point.
+.P
+If any autofs mount point directories are busy when the daemon is sent
+an exit signal the daemon will not exit. The exception to this is
+if autofs has been built with configure options to either ignore busy
+mounts at exit or force umount at exit. If the ignore busy mounts at
+exit option is used the filesystems will be left in a catatonic
+(non-functional) state and can be manually umounted when they become
+unused. If the force umount at exit option is used the filesystems
+will be umounted but the mount will not be released by the kernel
+until they are no longer in use by the processes that held them busy.
+If automount managed filesystems are found mounted when autofs is
+started they will be recoverd unless they are no longer present in
+the map in which case they need to umounted manually.
+.SH "SEE ALSO"
+.BR autofs (5),
+.BR mount (8).
+.SH BUGS
+Don't know, I've fixed everything I know about.
+
+The documentation could be better.
+
+Please report other bugs along with a detailed description to
+<autofs@linux.kernel.org>. For instructions on how to join the list
+and for archives visit http://linux.kernel.org/mailman/listinfo/autofs
+.SH AUTHOR
+H. Peter Anvin <hpa@transmeta.com> and Ian Kent <raven@themaw.net>.
diff -Naur autofs-5.0.1/man/automount.8.in
autofs-5.0.1.fix-man-page/man/automount.8.in
--- autofs-5.0.1/man/automount.8.in	2006-07-13 10:11:39.000000000 +0200
+++ autofs-5.0.1.fix-man-page/man/automount.8.in	1970-01-01
01:00:00.000000000 +0100
@@ -1,107 +0,0 @@
-.\" Linux man page by B. James Phillippe, 1997 <bryan@Terran.ORG>
-.\"
-.\" This page was written to contribute to the Linux kernel autofs
-.\" implementation by H. Peter Anvin (1997).  It is loosly based on
-.\" the documentation for mount(8) and amd(8) Linux manpages.
-.\"
-.\" This is free documentation.
-.\"
-.\" $Id: automount.8,v 1.8 2004/11/20 13:54:39 raven Exp $
-.\"
-.TH AUTOMOUNT 8 "12 Apr 2006"
-.SH NAME
-automount \- manage autofs mount points
-.SH SYNOPSIS
-\fBautomount\fP [\fIoptions\fP] [\fImaster_map\fP]
-.SH DESCRIPTION
-The \fBautomount\fP program is used to manage mount points for
-autofs, the inlined Linux automounter.  \fBautomount\fP works by
-reading the
-.nh
-.BR auto.master (8)
-.hy
-map and sets up mount points for each entry in the master map allowing
-them to be automatically mounted when accessed. The file systems are
-then automatically umounted after a period of inactivity.
-.SH OPTIONS
-.TP
-.I "\-h, \-\-help"
-Print brief help on program usage.
-.TP
-.I "\-p, \-\-pid-file"
-Write the pid of the daemon to the specified file.
-.TP
-.I "\-t, \-\-timeout"
-Set the global minimum timeout, in seconds, until directories
-are unmounted. The default is 10 minutes. Setting the timeout
-to zero disables umounts completely.
-.TP
-.I "\-v, \-\-verbose"
-Enables logging of general status and progress messages for all
-autofs managed mounts.
-.TP
-.I "\-d, \-\-debug"
-Enables logging of general status and progress messages as well as
-debuging messages for all autofs managed mounts.
-.TP
-.I "\-Dvariable=value"
-Define a global macro substitution variable. Global definitions
-are over-ridden macro definitions of the same name specified in
-mount entries.
-.TP
-.I "\-V, \-\-version"
-Display the version number, then exit.
-.SH ARGUMENTS
-\fBautomount\fP takes one optional argument, the name of the master map to
-use.
-.TP
-\fBmaster_map\fP
-Location for autofs master map that defines autofs managed mount points
-and the mount maps they will use. The default is
-.nh
-\fB@@autofsmapdir@@/auto.master\fP.
-.hy
-.RE
-.SH NOTES
-If the \fBautomount\fP daemon catches a USR1 signal, it will umount all
-currently unused autofs managed mounted file systems and continue running
-(forced expire).  If it catches the TERM signal it will umount
-all unused autofs managed mounted file systems and exit if there are
-no remaining busy file systems. If autofs has been compiled with the
-option to ignore busy mounts on exit it will exit leaving any busy
-mounts in place otherwise busy file systems will not be umounted
-and autofs will not exit.
-Alternatively, if autofs has been compiled with the option to enable
-forced shutdown then a USR2 signal to the daemon will cause all
-mounts to be umounted and any busy mounts to be forcibly umounted,
-including autofs mount point directories (summary execution). Note
-that the forced umount is an unlink operation and the actual umount
-will not happen in the kernel until active file handles are released.
-The daemon also responds to a HUP signal which triggers an update of
-the maps for each mount point.
-.P
-If any autofs mount point directories are busy when the daemon is sent
-an exit signal the daemon will not exit. The exception to this is
-if autofs has been built with configure options to either ignore busy
-mounts at exit or force umount at exit. If the ignore busy mounts at
-exit option is used the filesystems will be left in a catatonic
-(non-functional) state and can be manually umounted when they become
-unused. If the force umount at exit option is used the filesystems
-will be umounted but the mount will not be released by the kernel
-until they are no longer in use by the processes that held them busy.
-If automount managed filesystems are found mounted when autofs is
-started they will be recoverd unless they are no longer present in
-the map in which case they need to umounted manually.
-.SH "SEE ALSO"
-.BR autofs (5),
-.BR mount (8).
-.SH BUGS
-Don't know, I've fixed everything I know about.
-
-The documentation could be better.
-
-Please report other bugs along with a detailed description to
-<autofs@linux.kernel.org>. For instructions on how to join the list
-and for archives visit http://linux.kernel.org/mailman/listinfo/autofs
-.SH AUTHOR
-H. Peter Anvin <hpa@transmeta.com> and Ian Kent <raven@themaw.net>.

Tested, it works.
-- 
Guillaume Rousse
Projet Estime, INRIA
Domaine de Voluceau
Rocquencourt - B.P. 105
78153 Le Chesnay Cedex - France

Re: autofs5: unable to locate ldap master map

[Guillaume Rousse]

Guillaume Rousse wrote:
>> I think the main issue being discussed here is the location of the
>> program configuration only. Hopefully the rest is ok.
Here is a first patch that just separate daemon configuration from
service configuration.

To minimize behaviour changes, service configuration location is found
as service script location, just by looking for potential targets
(/etc/sysconfig, /etc/defaults) and keeping the first found. I didn't
changed map and config location directories search.

However, as this kind of stuff is highly distribution-dependant, I'd
rather suggest to not bother installing in the default installation
procedure, and let each packager finish the job directly.

diff -Naur autofs-5.0.1-drop-default-profix-from-config/Makefile.conf.in
autofs-5.0.1-separate-config-files/Makefile.conf.in
--- autofs-5.0.1-drop-default-profix-from-config/Makefile.conf.in
2006-08-23 14:21:40.000000000 +0200
+++ autofs-5.0.1-separate-config-files/Makefile.conf.in	2006-08-23
14:36:23.000000000 +0200
@@ -80,3 +80,6 @@
 # Location for init.d files
 initdir = @initdir@

+# Location for init.d files configuration
+initconfdir = @initconfdir@
+
diff -Naur autofs-5.0.1-drop-default-profix-from-config/aclocal.m4
autofs-5.0.1-separate-config-files/aclocal.m4
--- autofs-5.0.1-drop-default-profix-from-config/aclocal.m4	2006-08-23
14:21:40.000000000 +0200
+++ autofs-5.0.1-separate-config-files/aclocal.m4	2006-08-23
14:53:15.000000000 +0200
@@ -75,7 +75,7 @@
 dnl
--------------------------------------------------------------------------
 dnl AF_INIT_D
 dnl
-dnl Check the location of the init.d directory
+dnl Check the location of the service script directory
 dnl
--------------------------------------------------------------------------
 AC_DEFUN(AF_INIT_D,
 [if test -z "$initdir"; then
@@ -91,6 +91,24 @@
 fi])

 dnl
--------------------------------------------------------------------------
+dnl AF_INITCONF_D
+dnl
+dnl Check the location of the service configuration directory
+dnl
--------------------------------------------------------------------------
+AC_DEFUN(AF_INITCONF_D,
+[if test -z "$initconfdir"; then
+  AC_MSG_CHECKING([location of the init.d configuration directory])
+  for initconf_d in /etc/sysconfig /etc/default; do
+    if test -z "$initconfdir"; then
+      if test -d "$initconf_d"; then
+	initconfdir="$initconf_d"
+	AC_MSG_RESULT($initconfdir)
+      fi
+    fi
+  done
+fi])
+
+dnl
--------------------------------------------------------------------------
 dnl AF_CONF_D
 dnl
 dnl Check the location of the configuration defaults directory
diff -Naur autofs-5.0.1-drop-default-profix-from-config/configure.in
autofs-5.0.1-separate-config-files/configure.in
--- autofs-5.0.1-drop-default-profix-from-config/configure.in	2006-08-23
14:21:40.000000000 +0200
+++ autofs-5.0.1-separate-config-files/configure.in	2006-08-23
14:53:14.000000000 +0200
@@ -41,12 +41,18 @@
 AF_LINUX_PROCFS()

 #
-# Location of init.d directory?
+# Location of service script directory?
 #
 AF_INIT_D()
 AC_SUBST(initdir)

 #
+# Location of service configuration directory?
+#
+AF_INITCONF_D()
+AC_SUBST(initconfdir)
+
+#
 # Location of system config script directory?
 #
 AF_CONF_D()
diff -Naur autofs-5.0.1-drop-default-profix-from-config/samples/Makefile
autofs-5.0.1-separate-config-files/samples/Makefile
--- autofs-5.0.1-drop-default-profix-from-config/samples/Makefile
2006-08-23 14:21:40.000000000 +0200
+++ autofs-5.0.1-separate-config-files/samples/Makefile	2006-08-23
15:04:37.000000000 +0200
@@ -10,9 +10,7 @@

 rc.autofs: rc.autofs.in
 	sed -e "s|@@sbindir@@|$(sbindir)|g" \
-	    -e "s|@@autofslibdir@@|$(autofslibdir)|g" \
-	    -e "s|@@autofsconfdir@@|$(autofsconfdir)|g" \
-	    -e "s|@@initdir@@|$(initdir)|g" < rc.autofs.in > rc.autofs
+	    -e "s|@@initconfdir@@|$(initconfdir)|g" < rc.autofs.in > rc.autofs

 autofs.conf.default: autofs.conf.default.in
 	sed -e "s|@@autofsmapdir@@|$(autofsmapdir)|g" \
@@ -25,16 +23,19 @@
 	install -d -m 755 $(INSTALLROOT)$(autofslibdir)
 	install -d -m 755 $(INSTALLROOT)/var/run/autofs

-.PHONY: autofs.init
+.PHONY: autofs.init autofs.initconf
 autofs.init:
 	@echo
 ifneq ($(initdir),)
 	install -d -m 755 $(INSTALLROOT)$(initdir)
 	install rc.autofs -m 755 $(INSTALLROOT)$(initdir)/autofs
-else
-	if test -d $(INSTALLROOT)/etc/rc.d ; then \
-		install -c rc.autofs -m 755 $(INSTALLROOT)/etc/rc.d ; \
-	fi
+endif
+
+autofs.initconf:
+	@echo
+ifneq ($(initconfdir),)
+	install -d -m 755 $(INSTALLROOT)$(initconfdir)
+	install sysconfig.autofs -m 644 $(INSTALLROOT)$(initconfdir)/autofs
 endif

 CONFIG = $(shell test -e $(INSTALLROOT)$(autofsconfdir)/autofs.orig ||
echo "-b --suffix=.orig")
@@ -175,7 +176,7 @@
 		fi ; \
 	fi

-install: rc.autofs autofs.conf.default dirs autofs.init autofs.conf \
+install: rc.autofs autofs.conf.default dirs autofs.init autofs.initconf
autofs.conf \
 		autofs_ldap_auth.conf $(SAMPLES)
 	@echo

diff -Naur
autofs-5.0.1-drop-default-profix-from-config/samples/autofs.conf.default.in
autofs-5.0.1-separate-config-files/samples/autofs.conf.default.in
---
autofs-5.0.1-drop-default-profix-from-config/samples/autofs.conf.default.in
2006-08-23 14:22:24.000000000 +0200
+++ autofs-5.0.1-separate-config-files/samples/autofs.conf.default.in
2006-08-23 14:26:19.000000000 +0200
@@ -45,12 +45,3 @@
 #			   authentication configuration file.
 #
 #AUTH_CONF_FILE="@@autofsmapdir@@/autofs_ldap_auth.conf"
-#
-# General global options
-#
-#OPTIONS=""
-#
-#
-#  UNDERSCORETODOT changes auto_home to auto.home and auto_mnt to auto.mnt
-UNDERSCORETODOT=1
-
diff -Naur
autofs-5.0.1-drop-default-profix-from-config/samples/rc.autofs.in
autofs-5.0.1-separate-config-files/samples/rc.autofs.in
--- autofs-5.0.1-drop-default-profix-from-config/samples/rc.autofs.in
2006-08-23 14:21:40.000000000 +0200
+++ autofs-5.0.1-separate-config-files/samples/rc.autofs.in	2006-08-23
14:32:00.000000000 +0200
@@ -14,7 +14,7 @@
 DAEMON=@@sbindir@@/automount
 prog=`basename $DAEMON`
 MODULE="autofs4"
-confdir=@@autofsconfdir@@
+confdir=@@initconfdir@@

 test -e $DAEMON || exit 0

diff -Naur
autofs-5.0.1-drop-default-profix-from-config/samples/sysconfig.autofs
autofs-5.0.1-separate-config-files/samples/sysconfig.autofs
---
autofs-5.0.1-drop-default-profix-from-config/samples/sysconfig.autofs
1970-01-01 01:00:00.000000000 +0100
+++ autofs-5.0.1-separate-config-files/samples/sysconfig.autofs
2006-08-23 14:25:40.000000000 +0200
@@ -0,0 +1,9 @@
+#
+# General global options
+#
+#OPTIONS=""
+#
+#
+#  UNDERSCORETODOT changes auto_home to auto.home and auto_mnt to auto.mnt
+UNDERSCORETODOT=1
+
-- 
Guillaume Rousse
Projet Estime, INRIA
Domaine de Voluceau
Rocquencourt - B.P. 105
78153 Le Chesnay Cedex - France

Re: autofs5: unable to locate ldap master map

[Guillaume Rousse]

Guillaume Rousse wrote:
> Guillaume Rousse wrote:
>>> I think the main issue being discussed here is the location of the
>>> program configuration only. Hopefully the rest is ok.
> Here is a first patch that just separate daemon configuration from
> service configuration.
And here another one that enhance consistency between main configuration
file and ldap autentification file:
1) both are installed as .conf file
2) both are named .conf in the archive (not .conf.default)
3) ldap autentification file is searched under same directory as main
configuration file, removing the need to give its full path in
configuration, hence removing the need for a subsitution before installation

BTW, I'm not even sure being able to define ldap autentification file
name is really useful. I'd just hardcode its location, as the main one.

I did test (ldap setup only, however) all my 3 configuration patches,
and I'm going to release a 5.0.1 rpm in imminent Mandriva 2007 beta 3.

diff -Naur autofs-5.0.1-separate-config-files/lib/defaults.c
autofs-5.0.1-rc1-cleanup-config-file-names/lib/defaults.c
--- autofs-5.0.1-separate-config-files/lib/defaults.c	2006-08-23
14:24:42.000000000 +0200
+++ autofs-5.0.1-rc1-cleanup-config-file-names/lib/defaults.c	2006-08-24
15:43:59.000000000 +0200
@@ -21,7 +21,7 @@
 #include "defaults.h"
 #include "log.h"

-#define DEFAULTS_CONFIG_FILE		AUTOFS_CONF_DIR "/autofs"
+#define DEFAULTS_CONFIG_FILE		AUTOFS_CONF_DIR "/autofs.conf"
 #define MAX_LINE_LEN			256

 #define ENV_NAME_MASTER_MAP		"MASTER_MAP_NAME"
diff -Naur autofs-5.0.1-separate-config-files/modules/lookup_ldap.c
autofs-5.0.1-rc1-cleanup-config-file-names/modules/lookup_ldap.c
--- autofs-5.0.1-separate-config-files/modules/lookup_ldap.c	2006-08-23
14:24:42.000000000 +0200
+++ autofs-5.0.1-rc1-cleanup-config-file-names/modules/lookup_ldap.c
2006-08-24 15:43:58.000000000 +0200
@@ -278,6 +278,10 @@
 		return 0;
 	}

+    /* prepend with configuration directory */
+    realloc(auth_conf, strlen(auth_conf) + strlen(AUTOFS_CONF_DIR) + 2);
+    sprintf(auth_conf, "%s/%s", AUTOFS_CONF_DIR, auth_conf);
+
 	/*
 	 *  Here we check that the config file exists, and that we have
 	 *  permission to read it.  The XML library does not specify why a
diff -Naur autofs-5.0.1-separate-config-files/samples/Makefile
autofs-5.0.1-rc1-cleanup-config-file-names/samples/Makefile
--- autofs-5.0.1-separate-config-files/samples/Makefile	2006-08-23
15:04:37.000000000 +0200
+++ autofs-5.0.1-rc1-cleanup-config-file-names/samples/Makefile
2006-08-24 16:13:31.000000000 +0200
@@ -6,16 +6,12 @@

 SAMPLES = auto.master auto.misc auto.net auto.smb

-all: rc.autofs autofs.conf.default
+all: rc.autofs

 rc.autofs: rc.autofs.in
 	sed -e "s|@@sbindir@@|$(sbindir)|g" \
 	    -e "s|@@initconfdir@@|$(initconfdir)|g" < rc.autofs.in > rc.autofs

-autofs.conf.default: autofs.conf.default.in
-	sed -e "s|@@autofsmapdir@@|$(autofsmapdir)|g" \
-		< autofs.conf.default.in > autofs.conf.default
-
 .PHONY: dirs
 dirs:
 	install -d -m 755 $(INSTALLROOT)$(autofsmapdir)
@@ -38,26 +34,26 @@
 	install sysconfig.autofs -m 644 $(INSTALLROOT)$(initconfdir)/autofs
 endif

-CONFIG = $(shell test -e $(INSTALLROOT)$(autofsconfdir)/autofs.orig ||
echo "-b --suffix=.orig")
-CEXISTS = $(shell test -e $(INSTALLROOT)$(autofsconfdir)/autofs || echo
"no")
+CONFIG = $(shell test -e
$(INSTALLROOT)$(autofsconfdir)/autofs.conf.orig || echo "-b --suffix=.orig")
+CEXISTS = $(shell test -e $(INSTALLROOT)$(autofsconfdir)/autofs.conf ||
echo "no")

 .PHONY: autofs.conf
-autofs.conf: autofs.conf.default
+autofs.conf:
 	@echo
 	@echo "Installing autofs default configuation in $(autofsconfdir)"
 	@if test -z "$(CONFIG)" ; \
 	then \
-		install -v autofs.conf.default -m 644 \
+		install -v autofs.conf -m 644 \
 			$(INSTALLROOT)$(autofsconfdir)/autofs.conf.new ; \
 		echo "Found existing backup of configuration file." ; \
 		echo "Installed package default configuration file as
\"autofs.conf.new\"." ; \
 	else \
-		install -v autofs.conf.default -m 644 $(CONFIG) \
-				$(INSTALLROOT)$(autofsconfdir)/autofs ; \
-		echo "Installed package configuration configuration as \"autofs\"." ; \
+		install -v autofs.conf -m 644 $(CONFIG) \
+				$(INSTALLROOT)$(autofsconfdir)/autofs.conf ; \
+		echo "Installed package configuration configuration as
\"autofs.conf\"." ; \
 		if test -z "$(CEXISTS)" ; \
 		then \
-			echo "Backup of existing configuration made to \"autofs.orig\"." ; \
+			echo "Backup of existing configuration made to
\"autofs.conf.orig\"." ; \
 		fi ; \
 	fi

@@ -80,7 +76,7 @@
 		echo "Installed package auth config as \"autofs_ldap_auth.conf\"." ; \
 		if test -z "$(SEXISTS)" ; \
 		then \
-			echo "Backup of existing auth config made to
\".utofs_ldap_auth.conf.orig\"." ; \
+			echo "Backup of existing auth config made to
\"autofs_ldap_auth.conf.orig\"." ; \
 		fi ; \
 	fi

@@ -176,7 +172,7 @@
 		fi ; \
 	fi

-install: rc.autofs autofs.conf.default dirs autofs.init autofs.initconf
autofs.conf \
+install: rc.autofs dirs autofs.init autofs.initconf autofs.conf \
 		autofs_ldap_auth.conf $(SAMPLES)
 	@echo

diff -Naur autofs-5.0.1-separate-config-files/samples/autofs.conf
autofs-5.0.1-rc1-cleanup-config-file-names/samples/autofs.conf
--- autofs-5.0.1-separate-config-files/samples/autofs.conf	1970-01-01
01:00:00.000000000 +0100
+++ autofs-5.0.1-rc1-cleanup-config-file-names/samples/autofs.conf
2006-08-24 15:11:03.000000000 +0200
@@ -0,0 +1,47 @@
+#
+# Define default options for autofs.
+#
+# MASTER_MAP_NAME - default map name for the master map.
+#
+#MASTER_MAP_NAME="auto.master"
+#
+# TIMEOUT - set the default mount timeout (default 600).
+#
+TIMEOUT=300
+#
+# BROWSE_MODE - maps are browsable by default.
+#
+BROWSE_MODE="no"
+#
+# LOGGING - set default log level "none", "verbose" or "debug"
+#
+#LOGGING="none"
+#
+# Define the default LDAP schema to use for lookups
+#
+# System default
+#
+#MAP_OBJECT_CLASS="nisMap"
+#ENTRY_OBJECT_CLASS="nisObject"
+#MAP_ATTRIBUTE="nisMapName"
+#ENTRY_ATTRIBUTE="cn"
+#VALUE_ATTRIBUTE="nisMapEntry"
+#
+# Other common LDAP nameing
+#
+#MAP_OBJECT_CLASS="automountMap"
+#ENTRY_OBJECT_CLASS="automount"
+#MAP_ATTRIBUTE="ou"
+#ENTRY_ATTRIBUTE="cn"
+#VALUE_ATTRIBUTE="automountInformation"
+#
+#MAP_OBJECT_CLASS="automountMap"
+#ENTRY_OBJECT_CLASS="automount"
+#MAP_ATTRIBUTE="automountMapName"
+#ENTRY_ATTRIBUTE="automountKey"
+#VALUE_ATTRIBUTE="automountInformation"
+#
+# AUTH_CONF_FILE - set the default location for the SASL
+#			   authentication configuration file.
+#
+#AUTH_CONF_FILE="autofs_ldap_auth.conf"
diff -Naur
autofs-5.0.1-separate-config-files/samples/autofs.conf.default.in
autofs-5.0.1-rc1-cleanup-config-file-names/samples/autofs.conf.default.in
--- autofs-5.0.1-separate-config-files/samples/autofs.conf.default.in
2006-08-23 14:26:19.000000000 +0200
+++
autofs-5.0.1-rc1-cleanup-config-file-names/samples/autofs.conf.default.in
1970-01-01 01:00:00.000000000 +0100
@@ -1,47 +0,0 @@
-#
-# Define default options for autofs.
-#
-# MASTER_MAP_NAME - default map name for the master map.
-#
-#MASTER_MAP_NAME="auto.master"
-#
-# TIMEOUT - set the default mount timeout (default 600).
-#
-TIMEOUT=300
-#
-# BROWSE_MODE - maps are browsable by default.
-#
-BROWSE_MODE="no"
-#
-# LOGGING - set default log level "none", "verbose" or "debug"
-#
-#LOGGING="none"
-#
-# Define the default LDAP schema to use for lookups
-#
-# System default
-#
-#MAP_OBJECT_CLASS="nisMap"
-#ENTRY_OBJECT_CLASS="nisObject"
-#MAP_ATTRIBUTE="nisMapName"
-#ENTRY_ATTRIBUTE="cn"
-#VALUE_ATTRIBUTE="nisMapEntry"
-#
-# Other common LDAP nameing
-#
-#MAP_OBJECT_CLASS="automountMap"
-#ENTRY_OBJECT_CLASS="automount"
-#MAP_ATTRIBUTE="ou"
-#ENTRY_ATTRIBUTE="cn"
-#VALUE_ATTRIBUTE="automountInformation"
-#
-#MAP_OBJECT_CLASS="automountMap"
-#ENTRY_OBJECT_CLASS="automount"
-#MAP_ATTRIBUTE="automountMapName"
-#ENTRY_ATTRIBUTE="automountKey"
-#VALUE_ATTRIBUTE="automountInformation"
-#
-# AUTH_CONF_FILE - set the default location for the SASL
-#			   authentication configuration file.
-#
-#AUTH_CONF_FILE="@@autofsmapdir@@/autofs_ldap_auth.conf"

-- 
Guillaume Rousse
Projet Estime, INRIA
Domaine de Voluceau
Rocquencourt - B.P. 105
78153 Le Chesnay Cedex - France

Re: autofs5: unable to locate ldap master map

[Piete.Brooks--autofs]

> BTW, I'm not even sure being able to define ldap autentification file
> name is really useful. I'd just hardcode its location, as the main one.

I'd really rather not!

I'd like to have a number of maps available for different classes of machines.


PS: LDAP failed for me too until I edited /etc/sysconfig/autofs to use the 
correct schema -- now it works fine!

ivatt:~: ldapsearch -LLL -x "(&(objectclass=automountMap)(ou=auto.master))"
dn: ou=auto.master,dc=cl,dc=cam,dc=ac,dc=uk
objectClass: top
objectClass: automountMap
automountMapName: auto.master
ou: auto.master

ivatt:~: ldapsearch -LLL -x "(&(objectclass=nisMap)(nisMapName=auto.master))"
ivatt:~: 

Any chance of it it defaulting to try the three example schemas?

Re: autofs5: unable to locate ldap master map

[Guillaume Rousse]

Piete.Brooks--autofs@cl.cam.ac.uk wrote:
>> BTW, I'm not even sure being able to define ldap autentification file
>> name is really useful. I'd just hardcode its location, as the main one.
> 
> I'd really rather not!
Do you really have an use to be able to define your ldap connection
settings in a file named differently from "autofs_ldap_auth.conf" ?

[..]
> PS: LDAP failed for me too until I edited /etc/sysconfig/autofs to use the 
> correct schema -- now it works fine!
Even without configuring the top dn explicitely ?


> ivatt:~: ldapsearch -LLL -x "(&(objectclass=automountMap)(ou=auto.master))"
> dn: ou=auto.master,dc=cl,dc=cam,dc=ac,dc=uk
> objectClass: top
> objectClass: automountMap
> automountMapName: auto.master
> ou: auto.master
> 
> ivatt:~: ldapsearch -LLL -x "(&(objectclass=nisMap)(nisMapName=auto.master))"
> ivatt:~: 
> 
> Any chance of it it defaulting to try the three example schemas?
Which would means having multiple default values for a configuration
directive that only accept one... It may be practical, but rather messy.

-- 
Guillaume Rousse
Projet Estime, INRIA
Domaine de Voluceau
Rocquencourt - B.P. 105
78153 Le Chesnay Cedex - France

Re: autofs5: unable to locate ldap master map

[Piete Brooks, Piete.Brooks--autofs]

> Do you really have an use to be able to define your ldap connection
> settings in a file named differently from "autofs_ldap_auth.conf" ?

Sorry -- misunderstood :-((

>> PS: LDAP failed for me too until I edited /etc/sysconfig/autofs to use the 
>> correct schema -- now it works fine!
> Even without configuring the top dn explicitely ?

I believe that to be the case.
I have been HACKing away to get it working, but I don't think I set it 
anywhere.
The change to the schema in /etc/sysconfig/autofs ws the bit which made it 
work, and that has no full name:

DEFAULT_MAP_OBJECT_CLASS="automountMap"
DEFAULT_ENTRY_OBJECT_CLASS="automount"
DEFAULT_MAP_ATTRIBUTE="ou"
DEFAULT_ENTRY_ATTRIBUTE="cn"
DEFAULT_VALUE_ATTRIBUTE="automountInformation"

Comparing the failing and working entries I have:

Aug 25 06:36:04 pbtest8 automount[32611]: do_connect: lookup(ldap): ldap 
anonymous bind returned 0
Aug 25 06:36:04 pbtest8 automount[32611]: get_query_dn: lookup(ldap): query 
succeeded, no matches for (&(objectclass=nisMap)(nisMapName=auto.master))
Aug 25 06:36:04 pbtest8 automount[32611]: unbind_ldap_connection: use_tls: 0

vs

Aug 25 06:51:23 pbtest8 automount[32657]: do_connect: lookup(ldap): ldap 
anonymous bind returned 0
Aug 25 06:51:23 pbtest8 automount[32657]: get_query_dn: lookup(ldap): query dn 
ou=auto.master,dc=cl,dc=cam,dc=ac,dc=uk
Aug 25 06:51:23 pbtest8 automount[32657]: unbind_ldap_connection: use_tls: 0

so my guess is that the "(&(objectclass=automountMap)(ou=auto.master))" worked 
(shame it only reports the search if it fails) and returned 
"ou=auto.master,dc=cl,dc=cam,dc=ac,dc=uk" -- that's what ldapsearch does:

ivatt:~: ldapsearch -LLL -x "(&(objectclass=automountMap)(ou=auto.master))"
dn: ou=auto.master,dc=cl,dc=cam,dc=ac,dc=uk
objectClass: top
objectClass: automountMap
automountMapName: auto.master
ou: auto.master

ivatt:~: 

What does your debug say just after "ldap anonymous bind returned 0"?
Do you have base set correctly?

>> Any chance of it it defaulting to try the three example schemas?
> Which would means having multiple default values for a configuration
> directive that only accept one... It may be practical, but rather messy.

OK -- put it down to a "simplistic user view of the problem" :-(
I was thinking you could do something equiv to

(|(&(objectclass=automountMap)(ou=auto.master))
  (&(objectclass=nisMap)(nisMapName=auto.master))
)

but I suspect I'm missing the actual workings of LDAP (e.g. where the value is)

Re: autofs5: unable to locate ldap master map

[Ian Kent]

On Fri, 25 Aug 2006, Piete.Brooks--autofs@cl.cam.ac.uk wrote:

> 
> ivatt:~: ldapsearch -LLL -x "(&(objectclass=automountMap)(ou=auto.master))"
> dn: ou=auto.master,dc=cl,dc=cam,dc=ac,dc=uk
> objectClass: top
> objectClass: automountMap
> automountMapName: auto.master
> ou: auto.master
> 
> ivatt:~: ldapsearch -LLL -x "(&(objectclass=nisMap)(nisMapName=auto.master))"
> ivatt:~: 
> 
> Any chance of it it defaulting to try the three example schemas?

I love democracy.

I could spend my life changing this back and forward.
Complains about doing too many queries to the server is why it's this way.

For people with large maps trying all three schema would be a killer.

Ian

Re: autofs5: unable to locate ldap master map

[Piete Brooks, Piete.Brooks--autofs]

> Complains about doing too many queries to the server is why it's this way.

Fine -- I can live with a single lookup.

> For people with large maps trying all three schema would be a killer.

As a naive LDAP user, I assumed that such a simple request would be trivial :-(

Re: autofs5: unable to locate ldap master map

[Ian Kent]

On Fri, 25 Aug 2006, Piete Brooks wrote:

> 
> OK -- put it down to a "simplistic user view of the problem" :-(
> I was thinking you could do something equiv to
> 
> (|(&(objectclass=automountMap)(ou=auto.master))
>   (&(objectclass=nisMap)(nisMapName=auto.master))
> )

That query would work but then we would no be able to use arbitary schema 
in the configuration.

Ian

Re: autofs5: unable to locate ldap master map

[Ian Kent]

On Fri, 25 Aug 2006, Piete Brooks wrote:

> > Complains about doing too many queries to the server is why it's this way.
> 
> Fine -- I can live with a single lookup.
> 
> > For people with large maps trying all three schema would be a killer.
> 
> As a naive LDAP user, I assumed that such a simple request would be trivial :-(

Sure, it's not hard to do but if you have a bunch of clients querying an 
LDAP server a times 3 work load isn't good.

Ian