Date: Tue, 25 Oct 2011 05:51:08 -0700 From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: Paul Schenkeveld <freebsd@psconsult.nl> Cc: freebsd-stable@freebsd.org Subject: Re: ntpd couldn't resolve host name on system boot Message-ID: <20111025125108.GA87567@icarus.home.lan> In-Reply-To: <20111025092012.GA41065@psconsult.nl> References: <4EA5EBB5.3090101@quip.cz> <20111024232750.GA74032@icarus.home.lan> <B26B1B7BC38B4479B103B78B2175234D@multiplay.co.uk> <20111025010327.GA75437@icarus.home.lan> <20111025092012.GA41065@psconsult.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 25, 2011 at 11:20:12AM +0200, Paul Schenkeveld wrote:
> On Mon, Oct 24, 2011 at 06:03:27PM -0700, Jeremy Chadwick wrote:
> > The one shortcoming of netwait is that it doesn't support waiting for
> > multiple NICs. Some people have dual-homed environments where they
> > really would like to wait for both, say, em0 and em1, to come up and be
> > functional before any more scripts are started. I left that as a
> > project for someone else, but it's something that should be added given
> > its importance.
>
> How would you like to see multiple interfaces implemented:
>
> - All interfaces must be up at the same time
> - Probe interfaces one by one, proceed to the next when an interface
> up or bail out when any interface stays down until the loop times
> out
1) Each interface should be checked in the order specified.
2) Each ping probe should be done using that interface (ping -I).
3) In the case of success, the next interface should be checked (e.g. go
back to step #1 but for the next interface defined.
4) In the case of failure, output a message on-screen (similar to what
we already do) and continue on with the next interface check.
So I imagine the variables for this would need to become something like:
netwait_em0_ip="4.2.2.1 4.2.2.2"
netwait_em1_ip="192.168.1.1 192.168.1.2"
You get the idea -- think ifconfig_* in style.
> Another shortcoming: ipv6 support...
>
> The patch below adds ipv6.
>
> One caveat, ping6 is used if a word in netwait_ip contains at least a
> colon so hostnames in netwait_ip are always pinged using ipv4.
>
> {snip}
Others will need to test IPv6 support -- I do not use it/have it
available.
It's a matter of opinion, but for IPv6 hosts/addresses, there should be
a separate variable, probably netwait_ipv6 (or netwait_XXX_ipv6 if you
go with the above ideal). The problem is that our existing ipv6
variables in rc.conf all conform with ipv6_*, so I'm not sure what
people prefer. But then maybe the netwait_ip variable should be named
netwait_*_ipv4... I'll let others hash this out, but I would prefer the
former, since then you end up with something like this:
netwait_em0_ipv4="4.2.2.1 4.2.2.2"
netwait_em0_ipv6="fe80::202:b3ff:fe1e:8329"
(And in this case you would want to test IPv4 connectivity *as well* as
IPv6; two separate IP layers, thus both be tested separately; e.g. if
4.2.2.1 responds, don't just consider em0 working necessarily, because
there may be daemons that are IPv6-centric that depend on packets flowing
through em0. Those using tunnel brokers, however, probably won't
benefit from this since netwait starts before such brokers/daemons).
You get the idea.
The problem is that this breaks the existing variable syntax and will
upset a lot of existing users. Hmm... Not sure about this one. Gosh,
I could really go either way.
One final point, regarding ping6:
ping6 lacks the -t argument that ping has. This is bad bad bad. In
fact, I have to state up front that adding IPv6 support **should not**
be done to this script until ping6 supports -t. I cannot stress this
enough. The -t 1 piece is *very* important for proper behaviour. The
nuances of the flag often come as a surprise to people. I can look at
the ping code to figure out how -t works internally and probably submit
a patch for ping6 that does this, but of course I have no way to test
it. :-)
IPv6 support is something that others will need to work on in general
though -- I do not use it, so others are better-suited.
--
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, US |
| Making life hard for others since 1977. PGP 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111025125108.GA87567>