small patch for documenting weighted maps

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

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

_______________________________________________
autofs mailing list
[email protected]
http://linux.kernel.org/mailman/listinfo/autofs

Thanks Chris

I'll apply this as well.

Ian

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

ugh, sorry for thread hijacking :-(

Francesco P. Lovergine

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

==> Regarding [autofs] NIS maps loading.; "Francesco P. Lovergine" <[email protected]> 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

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

Francesco P. Lovergine

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

Francesco P. Lovergine

==> Regarding Re: [autofs] NIS maps loading.; "Francesco P. Lovergine" <[email protected]> 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.

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

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/

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.

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

Once please test the beta.

Ian

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

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.

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/

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