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
