ntpd couldn't resolve host name on system boot
freebsd at jdc.parodius.com
Tue Oct 25 12:51:10 UTC 2011
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
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:
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.
Others will need to test IPv6 support -- I do not use it/have it
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:
(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
184.108.40.206 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
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 |
More information about the freebsd-stable