> I think it'd be reasonable to refuse starting if the config is *known
> broken* (such as containing lines that are unparseable, or that contain
> completely invalid tokens), whereas you'd start if they just contain
> things that are "probably wrong". But picking from your previous
> examples of "more advanced checks", there are lots of cases where
> things like overlapping CIDR address ranges are perfectly valid, so I
> don't think we could even throw a warning for that - unless there's a
> separate flag to enable/disable warnings for such a thing.
Agreed. Making sure the config can parse is different from parsable but
non-sensible. It's ridiculously easy to mistakenly add a line w/ a
single character on it or something equally bad when saving a file
that's being modified by hand. That's a simple check that should be
done on re-hup and the broken config shouldn't be put in place.
I certainly agree that we should *also* have a way to just check the
config, so that can be built into init scripts and whatnot. I don't
think having one precludes having the other, and I'm pretty confident we
could find a way to not duplicate the code and have things be clean.
Thanks,
Stephen
No comments:
Post a Comment