[PATCH] small patch for documenting weighted maps

[PATCH] small patch for documenting weighted maps

[Chris Feist]

[-- Attachment #1: Type: text/plain, Size: 380 bytes --]

In the linux automounter if you have something like this in a map file:

/test  hosta(10):/export localhost(20):/export hostb(30):/export

the automounter will ignore the weighting and always pick the localhost. 
The Sun automounter also behaves in this way.  The patch I'm submitted 
just clarifies the documentation so the user is not surprised when it 
happens.

Thanks,
Chris

[-- Attachment #2: autofs-4.1.3-replicated-server-doc.patch --]
[-- Type: text/x-patch, Size: 718 bytes --]

--- autofs-4.1.3/README.replicated-server.orig	2005-01-24 15:26:28.609436878 -0600
+++ autofs-4.1.3/README.replicated-server	2005-01-24 15:27:57.592082878 -0600
@@ -27,7 +27,10 @@ Mutliple weighted, replicated hosts same
 Will pick lowest weighted host that responds to RPC call.  
 RPC time is not counted, only whether the call got a reply 
 at all.  Initially does a .1 second timeout, if all hosts 
-fail this, moves to 10 second timeout.
+fail this, moves to 10 second timeout.  If one of the hosts
+is localhost, the automounter will choose that regardless of
+its weight.  (This has been done to remain compatible with
+Sun's automounter)
 
 Multiple weighted, replicated hosts different (potentially) 
 paths:

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs

Re: [PATCH] small patch for documenting weighted maps

[Ian Kent]

On Mon, 24 Jan 2005, Chris Feist wrote:

> In the linux automounter if you have something like this in a map file:
> 
> /test  hosta(10):/export localhost(20):/export hostb(30):/export
> 
> the automounter will ignore the weighting and always pick the localhost. 
> The Sun automounter also behaves in this way.  The patch I'm submitted 
> just clarifies the documentation so the user is not surprised when it 
> happens.
>

Thanks Chris

I'll apply this as well.

Ian

NIS maps loading.

[Francesco P. Lovergine]

Changes in indirect maps such as auto.home
distributed via NIS are ignored until all daemons are killed and 
restarted.
That's of course not always possible or practical (it requires all 
users logout). This behavior is not present in other *nix such as 
Solaris or True64, so it can be considered a true bug.

-- 
Francesco P. Lovergine

Re: NIS maps loading.

[Francesco P. Lovergine]

On Tue, Jan 25, 2005 at 01:18:27PM +0100, Francesco P. Lovergine wrote:
> Changes in indirect maps such as auto.home
> distributed via NIS are ignored until all daemons are killed and 
> restarted.
> That's of course not always possible or practical (it requires all 
> users logout). This behavior is not present in other *nix such as 
> Solaris or True64, so it can be considered a true bug.
> 

ugh, sorry for thread hijacking :-(

-- 
Francesco P. Lovergine

Re: NIS maps loading.

[Michael Blandford]

Francesco P. Lovergine wrote:

>Changes in indirect maps such as auto.home
>distributed via NIS are ignored until all daemons are killed and 
>restarted.
>That's of course not always possible or practical (it requires all 
>users logout). This behavior is not present in other *nix such as 
>Solaris or True64, so it can be considered a true bug.
>
>  
>

What version of autofs are you using?  Have you applied the kernel 
patches at kernel.org ( if you aren't using 2.6.10 )

Michael

Re: NIS maps loading.

[Francesco P. Lovergine]

On Tue, Jan 25, 2005 at 08:24:13AM -0700, Michael Blandford wrote:
> Francesco P. Lovergine wrote:
> 
> >Changes in indirect maps such as auto.home
> >distributed via NIS are ignored until all daemons are killed and 
> >restarted.
> >That's of course not always possible or practical (it requires all 
> >users logout). This behavior is not present in other *nix such as 
> >Solaris or True64, so it can be considered a true bug.
> >
> > 
> >
> 
> What version of autofs are you using?  Have you applied the kernel 
> patches at kernel.org ( if you aren't using 2.6.10 )
> 
> Michael

Autofs 4.1.3-8 in Debian testing. That's with stock debian kernel 2.6.8
(which is a patched 2.6.8.1). I suspect that has nothing to do with
kernel space, anyway. It's a mere missing invalidation of NIS maps. 
Note that ypcat returns correctly the new map, but autofs continues
to use the wrong obsolete one. I can try 2.6.10 if you will feel better 
with that :) In fact, if the old map auto.home contains something like

frankie	hostA:/pathA

and the new map in the same file

frankie	hostB:/pathB

autofs will mount hostA:/pathA for user frankie instead of the new one.
The only workaround is restarting autofs daemon. That's obviuosly
true even if user home was not mounted previously.
BTW, I have the same problem with FC3. That's quite annoying, also
considering that other unices behaves correctly.

-- 
Francesco P. Lovergine

Re: NIS maps loading.

[Jeff Moyer]

==> Regarding [autofs] NIS maps loading.; "Francesco P. Lovergine" <frankie@debian.org> adds:

frankie> Changes in indirect maps such as auto.home distributed via NIS are
frankie> ignored until all daemons are killed and restarted.  That's of
frankie> course not always possible or practical (it requires all users
frankie> logout). This behavior is not present in other *nix such as
frankie> Solaris or True64, so it can be considered a true bug.

This is a known issue, and there are patches to address it.  Depending on
what kernel you are running, you may also have to patch that as well.

Unfortunately, I can't find the map update patch in the usual place.  You
can get it from the srpms here:

     http://people.redhat.com/jmoyer/

Grab the latest srpm, and extract these two patches:

     autofs-4.1.3-ian-map-expiry-1.patch
     autofs-4.1.3-ian-map-expiry-multimount-fix.patch

The kernel patch you want is also listed on the website above.  You could
also just wait for 4.1.4 (or the beta version thereof).

Hope this helps.

Jeff

Re: NIS maps loading.

[Francesco P. Lovergine]

On Tue, Jan 25, 2005 at 10:37:33AM -0500, Jeff Moyer wrote:
> ==> Regarding [autofs] NIS maps loading.; "Francesco P. Lovergine" <frankie@debian.org> adds:
> 
> frankie> Changes in indirect maps such as auto.home distributed via NIS are
> frankie> ignored until all daemons are killed and restarted.  That's of
> frankie> course not always possible or practical (it requires all users
> frankie> logout). This behavior is not present in other *nix such as
> frankie> Solaris or True64, so it can be considered a true bug.
> 
> This is a known issue, and there are patches to address it.  Depending on
> what kernel you are running, you may also have to patch that as well.
> 
> Unfortunately, I can't find the map update patch in the usual place.  You
> can get it from the srpms here:
> 
>      http://people.redhat.com/jmoyer/
> 
> Grab the latest srpm, and extract these two patches:
> 
>      autofs-4.1.3-ian-map-expiry-1.patch
>      autofs-4.1.3-ian-map-expiry-multimount-fix.patch
> 
> The kernel patch you want is also listed on the website above.  You could
> also just wait for 4.1.4 (or the beta version thereof).

Uhm, probably we missed that in current debian. Isn't it the same of FC3?

-- 
Francesco P. Lovergine

Re: NIS maps loading.

[Francesco P. Lovergine]

On Tue, Jan 25, 2005 at 04:50:21PM +0100, Francesco P. Lovergine wrote:
> > 
> > Grab the latest srpm, and extract these two patches:
> > 
> >      autofs-4.1.3-ian-map-expiry-1.patch
> >      autofs-4.1.3-ian-map-expiry-multimount-fix.patch
> > 
> > The kernel patch you want is also listed on the website above.  You could
> > also just wait for 4.1.4 (or the beta version thereof).
> 
> Uhm, probably we missed that in current debian. Isn't it the same of FC3?
> 

I meant if those patches are currently in the FC3 edition...

-- 
Francesco P. Lovergine

Re: NIS maps loading.

[Jeff Moyer]

==> Regarding Re: [autofs] NIS maps loading.; "Francesco P. Lovergine" <f.lovergine@ba.issia.cnr.it> adds:

f.lovergine> On Tue, Jan 25, 2005 at 10:37:33AM -0500, Jeff Moyer wrote:
>> ==> Regarding [autofs] NIS maps loading.; "Francesco P. Lovergine"
>> <frankie@debian.org> adds:
>> 
frankie> Changes in indirect maps such as auto.home distributed via NIS are
frankie> ignored until all daemons are killed and restarted.  That's of
frankie> course not always possible or practical (it requires all users
frankie> logout). This behavior is not present in other *nix such as
frankie> Solaris or True64, so it can be considered a true bug.
>> This is a known issue, and there are patches to address it.  Depending
>> on what kernel you are running, you may also have to patch that as well.
>> 
>> Unfortunately, I can't find the map update patch in the usual place.
>> You can get it from the srpms here:
>> 
>> http://people.redhat.com/jmoyer/
>> 
>> Grab the latest srpm, and extract these two patches:
>> 
>> autofs-4.1.3-ian-map-expiry-1.patch
>> autofs-4.1.3-ian-map-expiry-multimount-fix.patch
>> 
>> The kernel patch you want is also listed on the website above.  You
>> could also just wait for 4.1.4 (or the beta version thereof).

f.lovergine> Uhm, probably we missed that in current debian. Isn't it the
f.lovergine> same of FC3?

The fc3 tree I'm looking at has this change.  If it isn't out there right
now, it will be available in the next update (which I think is coming
soon).  FWIW, RHEL 4 also has this change.

-Jeff

Re: NIS maps loading.

[Steinar H. Gunderson]

On Tue, Jan 25, 2005 at 04:50:21PM +0100, Francesco P. Lovergine wrote:
>> The kernel patch you want is also listed on the website above.  You could
>> also just wait for 4.1.4 (or the beta version thereof).
> Uhm, probably we missed that in current debian. Isn't it the same of FC3?

Probably we missed it, yes. I'm still on semi-vacation (although I'm home from
the USA, it's hard to do extensive testing without a Linux system :-) ), so I
guess I'll simply wait for 4.1.4, which should be a largely problem-free
update for us anyhow.

BTW, current Debian versions has fixes for whitespace in parse_sun.c (also
for non-multimaps); are those fused upstream yet?

/* Steinar */
-- 
Homepage: http://www.sesse.net/

Re: NIS maps loading.

[raven]

On Tue, 25 Jan 2005, Steinar H. Gunderson wrote:

> On Tue, Jan 25, 2005 at 04:50:21PM +0100, Francesco P. Lovergine wrote:
>>> The kernel patch you want is also listed on the website above.  You could
>>> also just wait for 4.1.4 (or the beta version thereof).
>> Uhm, probably we missed that in current debian. Isn't it the same of FC3?
>
> Probably we missed it, yes. I'm still on semi-vacation (although I'm home from
> the USA, it's hard to do extensive testing without a Linux system :-) ), so I
> guess I'll simply wait for 4.1.4, which should be a largely problem-free
> update for us anyhow.

Umm ... I hope I haven't made life difficult for you with 4.1.4 beta.
There are a dswag of changes.

I've worked through and applied as many of the Debian patches as I could.
Please let me know if there's more that I can do to help.

>
> BTW, current Debian versions has fixes for whitespace in parse_sun.c (also
> for non-multimaps); are those fused upstream yet?

As I said above.
I also had white space handling patches that I applied.

Once please test the beta.

Ian

Re: NIS maps loading.

[Steinar H. Gunderson]

(No need to send directly to me anymore, I'm on the list :-) )

On Wed, Jan 26, 2005 at 10:53:02PM +0800, raven@themaw.net wrote:
> Umm ... I hope I haven't made life difficult for you with 4.1.4 beta.
> There are a dswag of changes.

Yes, I noticed -- I'll probably let it live in experimental for a while
before uploading to unstable, as we're quite near a freeze now.

> I've worked through and applied as many of the Debian patches as I could.
> Please let me know if there's more that I can do to help.

See my last mail to the list; I guess most of the points should be in there.
Overall, you're making my work a lot easier :-)

/* Steinar */
-- 
Homepage: http://www.sesse.net/

Re: NIS maps loading.

[raven]

On Tue, 25 Jan 2005, Francesco P. Lovergine wrote:

> Changes in indirect maps such as auto.home
> distributed via NIS are ignored until all daemons are killed and
> restarted.
> That's of course not always possible or practical (it requires all
> users logout). This behavior is not present in other *nix such as
> Solaris or True64, so it can be considered a true bug.

Umm ... thats been discussed quite a bit on the list. You must have missed 
it. It was a fair while ago.

As is mentioned later in this thread, I did create patches for this but as 
it was added funtionality (and was under test) it wasn't placed on kernel.org.

It is however in the 4.1.4 beta and I've made some additional fixes 
during testing the last couple of days. Please test this out in the beta.

Ian