Subject: | vos loopback address behavior |
Date: | Mon, 9 Dec 2013 14:08:20 -0600 |
To: | openafs-bugs@openafs.org |
From: | Andrew Deason <adeason@sinenomine.net> |
This thread brought up some stuff where "vos"'s behavior with loopback
addresses should probably be changed:
<https://lists.openafs.org/pipermail/openafs-info/2013-December/040283.html>
- vos should give some indication when it re-resolves loopback
addresses to the hostname-resolved address. This is currently
completely invisible, and thus is confusing if it ever does the wrong
thing. Making this slightly more visible would also give a slight
nudge to administrators to not be using 'localhost'
- Maybe 'vos' should error out if it does this re-resolving, and it
still gets back a 127.0.x.x address? This would make it impossible to
allow such an address to be specified, except:
- Allow 'vos' to actually specify 127.0.x.x addresses if we really
really mean it (such as, if we want to remsite a 127.0.x.x address in
the vldb). We could allow -noresolv to do this, or maybe another flag
specifically for this purpose, to definitely avoid false-positives.
--
Andrew Deason
adeason@sinenomine.net
addresses should probably be changed:
<https://lists.openafs.org/pipermail/openafs-info/2013-December/040283.html>
- vos should give some indication when it re-resolves loopback
addresses to the hostname-resolved address. This is currently
completely invisible, and thus is confusing if it ever does the wrong
thing. Making this slightly more visible would also give a slight
nudge to administrators to not be using 'localhost'
- Maybe 'vos' should error out if it does this re-resolving, and it
still gets back a 127.0.x.x address? This would make it impossible to
allow such an address to be specified, except:
- Allow 'vos' to actually specify 127.0.x.x addresses if we really
really mean it (such as, if we want to remsite a 127.0.x.x address in
the vldb). We could allow -noresolv to do this, or maybe another flag
specifically for this purpose, to definitely avoid false-positives.
--
Andrew Deason
adeason@sinenomine.net