And here is the log. On Sat, Apr 30, 2016 at 01:36:00PM +0200, Christof Koehler wrote: > Hello. > > On Sat, Apr 30, 2016 at 11:21:11AM +0800, Ian Kent wrote: > > On Fri, 2016-04-29 at 16:10 +0200, Christof Koehler wrote: > > > Hello, > > > > > > > > > > > Would that approach help with what you're trying to achieve? > > > > > > > > > > I am not sure of anything right now anymore after noticing what mount > > > does. On top, I am not sure if I understand what you are proposing :-) > > > > I'll need to review what we've said already for the problem with > > mount.nfs(8). > Just to be clear: I am not refering to the fallback to IPv4, that has > indeed been covered, see below. I am refering to its stand alone, i.e. called > by hand on the command line, behaviour to alternate between available IPv6 > addresses. I did not observe this before and it makes me unsure if my > initial request for autofs's behaviour might have been unreasonable. > > > > > > > Independent of that maybe a) fixing the situation where > > > autofs/mount falls back to IPv4, which I understand is a bug, and b) > > > > Partly, the situation I described so far is, IPv6 won't work at all if > > not using libtirpc, that's fixed by building autofs with libtirpc > > support, no big deal there, we have that already. > > > > I believe we originally started talking about IPv4 fall back because of > > the lack of libtirpc support in Ubuntu autofs. > Yes. > > Eventually the current behaviour could be documented as "working for > now, not guaranteed to work at all without libtirpc in future releases" > as a compromise ? > > It would have been helpful if the man page would have included a hint that > libtirpc is a prerequisite for IPv6, similar to its mentioning in nfs(5) > (search "TI-RPC"). > > > There was also uncertainty about how mount.nfs(8) ends with an address. > > Lets leave that alone for the moment. > This is clearly not an autofs issue. I will probably ask > somewhere else if I cannot find an answer myselves. > > mount.nfs4(8) does not mentions IPv6 at all, and nfs(5) does not give > any information about a possible address selection process. > > > > > So I went looking and found that the order of addresses returned by > > getaddrinfo(3) is in fact a modified rfc 3484 ordering. > > > > I then responded saying this ordering may be sufficient, and a fairly > > simple way to implement the needed address selection (and I mostly > > ignored IPv4 with this suggestion). > My problem is that I did/do not fully understand the details of the > sorting process you decribed. Now just reading getaddrinfo(3) saying "The > sorting function used within getaddrinfo() is defined in RFC 3484" I would > say that the list as returned by getaddrinfo should be what I wanted (I am not > sure what you mean with "modified", the tweaking of gai.conf ?). > > That is why I tried to explain the big picture. For me it is important that it > consistently selects the ULA unless specifically instructed to do otherwise. > > > Having done that adding an autofs configuration option to not use IPv4 > > addresses for hosts with multiple addresses should be sufficient to > > force IPv6 only use. Also not difficult but I Think will have some > > special cases to consider. I didn't mention this before because I > > thought the first thing to resolve was address selection. > For me the actual selection of an existing ULA above IPv4 and GUA is > "the big thing". > > If I can pass the right IPv6 address via an executable map bypassing > autofs's own selection mechanims (Why should it use that mechanism if it > gets an IP instead of a hostname ? Would it do it ? Have to try.) I guess that > is all I really need, as an alternative (or kludge) to changing the selection > code. > > > > > As I say, I'll need to re-read what we have said and compare again to > > the rfc ordering to work out if that is close to what you need but I had > > the impression it was. > I am now also thinking it is. > > I will do the tests I promised (IPv6 address in map, with and without the binaries > form your ppa) in the meantime. > > > The remaining problem is that autofs will remove host addresses from the > > list if it thinks they are not responding. > That is a new one to me. You see how ignorant I unfortunately am of what is > actually happening in the machinery used to mount. > > > Availability really must be checked because trying to mount from a host > > that isn't responding can result in lengthy delays which is really bad > > for interactive use. > > > > > This is the main reason for lengthy waits, the kernel RPC can't afford > > to give up just because an RPC call takes longer than expected for fear > > of causing file system corruption for NFS mounts. > I never had to think about this, noticing only the final result which > simply works (thanks to all people who developed the software involved). > If the server is really down it does not work of course, but with current > kernels and soft mounts for non-homes that is only a minor problem (as > opposed to the lockups with nfs2/3 on 2.x kernels), provided that it is not > the users home which is gone :-) > > I use autofs primarily just as an abstraction layer when moving data around, > not for failover or similar. > > > > > But having said that, the availability check can be bypassed, if > > required, by setting single autofs configuration option. > Which option would that be ? I cannot find it ? > > > > > Umm .. am I in close to what we've discussed or have I misunderstood? > Today I think you are. > > > > > > having the possibility to pass IPv6 addresses as a result of an > > > exectutable map lookup (as is possible with IPv4 adresses) is what I > > > really > > > need. I assume these two might be easier to do ? If I can pass IPv6 > > > addresses > > > from the exectuable map I can shell script what I think I need > > > myselves. Of > > > course I still have to check if passing IPv6 is actually not possible > > > as > > > I speculated earlier. > > > > Right, but AFAIK (and there might be problems with it) I think that is a > > mater of address specification. > > > > The brackets vs. without brackets usage for example. > Even nfs(5) and exports(5) disagree. Pick one and document the > choice you like ? > > > There's also the question of whether autofs handles link local addresses > > properly, I think they can (or are required to) specify an interface as > > well. > Due to the fact that a host might present the same fe80:: address > on multiple or all of its interfaces most of all times an interface > specifier must be included so that routing selects the right link. Quite some > tools and programs are broken or confusing from a users perspective handling > this [1,2]. > > I understand that people will run autofs on link local addresses, though. > ping6(8) and nfs(5) suggest "%interface" (with out without square brackets). > So if the syntax is documented it should be less of a problem. > > That is why I ignored link local in my previous mail, they should be > left alone (reserved for internal use by the network stack) IMO. You can > use ULAs if you do not have/want GUAs, that is one of their legitimate use > cases IMO ! > > > > > I haven't yet had a chance to study the logs you sent so I may get more > > information from them. Was there an example of this in those? > Only demonstrating the nfs(5) square bracket convention calling mount and no > brackets in other debug output: > > Apr 27 16:27:21 core400 automount[2764]: get_nfs_info: called with host > core330(2001:638:708:1261:2000::118) proto 6 version 0x40 > ... > Apr 27 16:28:00 core400 automount[2764]: mount_mount: mount(nfs): > calling mount -t nfs4 -s -o rw,intr,nosuid,soft,nodev > [2001:638:708:1261:2000::118]:/locals /local/core330 > ... > Apr 27 16:28:00 core400 automount[2764]: mount_mount: mount(nfs): > mounted [2001:638:708:1261:2000::118]:/locals on /local/core330 > > > > I'm going to stop here because I think sorting out these two things > > needs to be done before re-assessing what the remaining situation is. > > > > I will do the tests, rethink my approach and try to understand mounts > behaviour then. > > Thank you very much ! > > > Best Regards > > Christof > > [1] > https://blogs.gentoo.org/eva/2010/12/17/things-you-didnt-known-about-ipv6-link-local-address/ > https://bugzilla.redhat.com/show_bug.cgi?id=136852 > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=700999 > http://forums.mozillazine.org/viewtopic.php?f=38&t=513822&start=0 > > -- > Dr. rer. nat. Christof Köhler email: c.koehler@xxxxxxxxxxxxxxxxxxx > Universitaet Bremen/ BCCMS phone: +49-(0)421-218-62334 > Am Fallturm 1/ TAB/ Raum 3.12 fax: +49-(0)421-218-62770 > 28359 Bremen > > PGP: http://www.bccms.uni-bremen.de/cms/people/c_koehler/ > -- > To unsubscribe from this list: send the line "unsubscribe autofs" in -- Dr. rer. nat. Christof Köhler email: c.koehler@xxxxxxxxxxxxxxxxxxx Universitaet Bremen/ BCCMS phone: +49-(0)421-218-62334 Am Fallturm 1/ TAB/ Raum 3.12 fax: +49-(0)421-218-62770 28359 Bremen PGP: http://www.bccms.uni-bremen.de/cms/people/c_koehler/
Attachment:
pp.gz
Description: Binary data
