On Fri, Apr 6, 2018 at 4:54 PM, Willy Tarreau <w...@1wt.eu> wrote:

> On Fri, Apr 06, 2018 at 04:50:54PM +0200, Lukas Tribus wrote:
> > > Well, sometimes when you're debugging a configuration, it's nice to be
> > > able to disable some elements. Same for those manipulating/building
> > > configs by assembling elements and iteratively pass them through
> > > "haproxy -c". That's exactly the reason why we relaxed a few checks in
> > > the past, like accepting a frontend with no bind line or accepting a
> > > backend with a "cookie" directive with no cookie on server lines. In
> > > fact we could simply emit a warning when a resolvers section has no
> > > resolver nor resolv.conf enabled, but at least accept to start.
> >
> > Understood; however in this specific case I would argue one would
> > remove the "resolver" directive from the server-line(s), instead of
> > dropping the nameservers from the global nameserver declaration.
> No, because in order to do this, you also have to remove all references
> on all "server" lines, which is quite a pain, and error-prone when you
> want to reactivate them.
> > Maybe a config warning would be a compromise for this case?
> Yes, that's what I mentionned above, I'm all in favor of this given that
> we can't objectively find a valid use case for an empty resolvers section
> in production.
> Cheers,
> Willy

Ok, so just to summarize:
- we should enable parsing of resolv.conf with a configuration statement in
the resolvers section
- only nameserver directives from resolv.conf will be parsed for now
- parsing of resolv.conf can be used in conjunction with nameserver
directives in the resolvers section
- HAProxy should emit a warning message when parsing a configuration which
has no resolv.conf neither nameserver directives enabled

Is that correct?


Reply via email to