Re: Parsing of pg_hba.conf and authentication inconsistencies

Tom Lane wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>>> The good way to solve this would be to have independant command line
>>> utilities which check pg_hba.conf, pg_ident.conf and postgresql.conf for
>>> errors. Then DBAs could run a check *before* restarting the server.
>
>> While clearly useful, it'd still leave the fairly large foot-gun that is
>> editing the hba file and HUPing things which can leave you with a
>> completely un-connectable database because of a small typo.
>
> That will *always* be possible, just because software is finite and
> human foolishness is not ;-).

Certainly - been bitten by that more than once. But we can make it
harder or easier to make the mistakes..

> Now, we could ameliorate it a bit given a "postgres --check-config"
> mode by having pg_ctl automatically run that mode before any start,
> restart, or reload command, and then refusing to proceed if the check
> detects any indubitable errors. On the other hand, that would leave
> us with the scenario where the checking code warns about stuff that it
> can't be sure is wrong, but then we go ahead and install the borked
> config anyway. (Nobody is going to put up with code that refuses
> to install config settings that aren't 100% clean, unless the checks
> are so weak that they miss a lot of possibly-useful warnings.)
>
> Seems a lot better to me to just train people to run the check-config
> code by hand before pulling the trigger to load the settings for real.

It's certainly easier for us, but that means a whole lot of people are
never going to do it. And initscripts might end up using it anyway,
forcing the issue.

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.

//Magnus