(In reply to comment #0)
> I can only work around this by editing /etc/sysconfig/autofs to replace
>     #DEFAULT_MASTER_MAP_NAME="/etc/auto.master"
> with
>     DEFAULT_MASTER_MAP_NAME="auto.master"
> _and_ removing /etc/auto.master.

Your correct, however, changing the config should be all that is
needed. You shouldn't need to remove /etc/auto.master.

I'll check what's going on with that.

This was done to better align with the Solaris automount behaviour
but perhaps I still haven't got this quite right.

I expect that, if /etc/auto.master doesn't exist I don't
automatically go to the nsswitch to find it. I'll check
that also.

Ian

OK, but surely it's more important to align with *our* prior behaviour than
Solaris's?  Until recently, setting up a NIS master on a host was sufficient to
allow autofs to Just Work right, fetching the master and mount maps over NIS.

Note that I've had a lot of problem with the new autofs, so it's possible that
some of the other problems were confusing the debugging and that the
/etc/auto.master removal may not be strictly necessary; I'll go back and
double-check that.

Thanks!

Yes, confirmed --- even with

    DEFAULT_MASTER_MAP_NAME="auto.master"

the /etc/auto.master is picked up first.

Note that nsswitch contains

    automount:  files nis

ie. preferring files to nis.  Indeed, if I switch it to

    automount:  nis files

then it does pick up the NIS map first.  But my old nsswitch.conf has been in
service for months unchanged, so this is still a change in behaviour; I guess we
need to decide whether setting up NIS should automatically pick up the NIS
auto.master or not, and then decide whether that indicates changing the nsswitch
is appropriate.

(In reply to comment #2)

Before I start talking about the goal of Solaris compatibility
let me say that I've put some time into this today and I believe
that the version I submitted this afternoon will be closer to
the previous behaviour.

However, with the introduction of the nsswitch I'm faced with a
bit of a catch 22. Anyway, to cut a short story shorter I'm going
to ignore the "files" nsswitch entry if present because the default
is a file anyway. You'll still need to change the autofs config but,
in my defense, it's marked as noreplace in the spec file so it should
be a once only change. I've also added a note to the release notes in
the tarball about this.

Sorry.

> OK, but surely it's more important to align with *our* prior behaviour than
> Solaris's?  Until recently, setting up a NIS master on a host was sufficient to
> allow autofs to Just Work right, fetching the master and mount maps over NIS.

The focus for version 5 has been 100% Solaris compatibility to facilitate
integration into data centers that already have a considerable Solaris
presence.

I dougbt we will get all the way there, especially since we need to
maintain as much backward compatability as we can. Yours is a case
in point.

All I can do is appologise and urge you to continue to help iron
out the bugs. I'll do whatever I can to make autofs fit in both
camps but inevitably there will be some consessions on both sides.

Sigh..

> 
> Note that I've had a lot of problem with the new autofs, so it's possible that
> some of the other problems were confusing the debugging and that the
> /etc/auto.master removal may not be strictly necessary; I'll go back and
> double-check that.

Sorry you wasted your time on this.
I wasn't quick enough to reply.

As I said above I have pushed a new version that I believe addresses
the problems you reported.

Please let me know how it goes.
Look for autofs-5.0.0_beta4-1 or grab the srpm from CVS.

Ian

OK, I've built 5.0.0_beta4-1 locally from distCVS, and my wildcard problems are
fixed.  I'll know about the /net map reload shortly once the initial mounts expire.

... No, that bit is still broken.  Will report against the specific bugs concerned.

Regarding the Solaris compatibility, do we just want to aim for the same level
of functionality, or do we actually want to change our default configurations
too to match Solaris's?

If we are willing to change defaults, then using simply "auto.master" as the
default master map name, and "nis files" ordering in nsswitch, may be desirable.
 I certainly find it extremely convenient that new hosts pick up these maps from
NIS by default on current distros; and unlike autofs, NIS has its own pages on
firstboot and can be configured via dhcp, so the old defaults really did make it
trivial to set up new boxes to simply drop into an existing NIS+autofs environment.

(In reply to comment #6)
> Regarding the Solaris compatibility, do we just want to aim for the same level
> of functionality, or do we actually want to change our default configurations
> too to match Solaris's?
> 
> If we are willing to change defaults, then using simply "auto.master" as the
> default master map name, and "nis files" ordering in nsswitch, may be desirable.
>  I certainly find it extremely convenient that new hosts pick up these maps from
> NIS by default on current distros; and unlike autofs, NIS has its own pages on
> firstboot and can be configured via dhcp, so the old defaults really did make it
> trivial to set up new boxes to simply drop into an existing NIS+autofs
environment.

Good point.
I'll think about it and we'll get Jeff Moyer to comment when
he returns.

Ian

You should *not* default to files first for the master map;  always use nsswitch.

The default master map in solaris reads:

+auto_master

If we did this, then sct's configuration would just work.  Of course, I'm
assuming you'll replace the '_' with a '.' in the above.

(In reply to comment #8)
> You should *not* default to files first for the master map;  always use nsswitch.
> 
> The default master map in solaris reads:
> 
> +auto_master

So your suggesting we replace the default auto.master (or
auto_master) in the v5 install with this one and use nsswitch
always. Correct?

Sounds simple enough.

> 
> If we did this, then sct's configuration would just work.  Of course, I'm
> assuming you'll replace the '_' with a '.' in the above.

Yep. I added that in recently, the nis module will replace "_" with
"." if the map has them and redo the lookup are per the Sun doco.

Ian

That sounds like it would address one part of the problem.  My *current*
configuration would work; but a default out-of-the-box one would still fail to
read the NIS auto.master, because nsswitch still lists files first.

So the second question is whether nsswitch should default to files first, or nis
first.  The latter behaviour is extremely convenient for reasons described in
comment #6.  And previous behaviour of autofs implicitly read nis first.

Ian Wrote:
> So your suggesting we replace the default auto.master (or
> auto_master) in the v5 install with this one and use nsswitch
> always. Correct?

Right.

> Yep. I added that in recently, the nis module will replace "_" with
> "." if the map has them and redo the lookup are per the Sun doco.

Hmm.  I'll have to take a look at the code.  This sounds dubious.  ;)

sct wrote:
> but a default out-of-the-box one would still fail to
> read the NIS auto.master, because nsswitch still lists files first.

Not quite.  If the only entry in the auto.master is +auto.master, and
/etc/nsswitch.conf is configured as "automount: files nis", then the nis map
*will* be read since the file map includes the nis map.

re comment #11:

The default config has "auto.net" and "auto.misc" in /etc/auto.master, _not_
"+auto.master".  So the default config will still ignore NIS, which is a change
from previous releases.

(In reply to comment #11)
> 
> > Yep. I added that in recently, the nis module will replace "_" with
> > "." if the map has them and redo the lookup are per the Sun doco.
> 
> Hmm.  I'll have to take a look at the code.  This sounds dubious.  ;)

Got you thinking now.
That's what the Sun doco says so that's what I did.

> 
> sct wrote:
> > but a default out-of-the-box one would still fail to
> > read the NIS auto.master, because nsswitch still lists files first.
> 
> Not quite.  If the only entry in the auto.master is +auto.master, and
> /etc/nsswitch.conf is configured as "automount: files nis", then the nis map
> *will* be read since the file map includes the nis map.

OK.

So no changes to the map name (ie "." to "_").
Make autofs.master the internal default instead of /etc/auto.master
and add a +auto.master line to the default installed auto.master.
Then the rest just happens.

That will fit in with v4.

Refering to Stephens comment following this one we could simply add
the + entry below auto.misc and auto.net which would merge the maps.
Of course if there are common keys the first read map kays would
take precedence.

Yes, that should work, at least for /net, which basically can't be a NIS map
because it is scripted.  And I can easily work around /net and /misc being
reserved for local maps.

(In reply to comment #14)
> Yes, that should work, at least for /net, which basically can't be a NIS map
> because it is scripted.  And I can easily work around /net and /misc being
> reserved for local maps.

Hi Stephen,

I'm going through my bzs and was wondering if there is anything
further I need to do to resolve this?

Ian

(In reply to comment #15)
> (In reply to comment #14)
> > Yes, that should work, at least for /net, which basically can't be a NIS map
> > because it is scripted.  And I can easily work around /net and /misc being
> > reserved for local maps.
> 
> Hi Stephen,
> 
> I'm going through my bzs and was wondering if there is anything
> further I need to do to resolve this?
> 

I'm closing this as I haven't heard anything.
Stephen, reopen if this isn't correct.