Bill Hacker wrote:
> Stumped here:
No longer.
"BDOS Error on B:" syndrome. An irrelevant error message, see below.
>
> - I have two PGSQL-driven Exim 4.43+28 installs, near-as-dammit
> identical (both are still in testing mode) as to build, environment,
> users in the DB, directory structure, perms, etc. They differ primarily
> in domain names & IP numbers.
>
> - Both were built "WITH_PGSQL", found the relevant dependencies (lbpq)
> and reflect that in the lookup capability list as output from the 'Exim
> -bV' command.
>
> - ~/exim/configure is identical, save for IP & domain name.
>
> - The one built a few days ago works fine. The one built today throws
> an error I cannot find on Google, in docs, or in the 32,000+ message
> archive I conveniently keep of this very mailing list:
>
> - The error message is:
>
> Exim configuration error in line 14 of /usr/local/etc/exim/configure:
> main option "pgsql_server" unknown.
>
> - The line cited is one or the other of (never both at the same time) of:
>
> hide pgsql_servers = (/tmp/.s.PGSQL.5432)/<dbname>/<dbuser>/<dbuserpwd>
>
> OR
>
> hide pgsql_servers = localhost/<dbname>/<dbuser>/<dbuserpwd>
>
> PGSQL is responding to ZPsycopgDA on *both* the IP port and the Unix
> socket, so it doesn't appear to be a DB issue.
>
And it was not - I could 'see' the open connection from Exim to PG.
>
>
> Syntactically, it sounds as if Exim is telling me it was not compiled to
> understand the "psql_server" call - yet it was.
>
> exim -bV so confirms.
>
> Plenty of 'evidence' available if no one has a QNDA.
>
> Stumped here...................................
>
>
> Bill Hacker
>
Quick 'N Dirty Answer it was not, but for future reference:
'psql_servers' were only 'unknown' in a special case.
- The 'daemonized' exim instance was running fine, and able to make its
DB lookups, as the logs showed once I pointed some actual inbound
traffic onto the box.
The problem came about 'coz (lazy me!) I had been doing inital testing
from an 'on box' shell account su'ed to root.
mail -s Test(n) <valid on-box OR off-box address><Newline>
Test(n)<Newline>
.
<full-stop><Newline> or <Ctrl-D>
- ail/Sendmail style, invoked a separate *non daemon* instance of exim.
But not with the UID:GID.
- While this one was able to read the /usr/local/etc/exim/configure
file, and permitted to ignore the 'never_user=root', it was NOT able to
hide its identity when attempting the connection to postgres - which
refused it, as pg won't speak to root.
- su'ing to pgsql reversed the situation - now the DB call would have
been acceptable, but user:group pgsql:pgsql had no right to read the
exim configure file, (inciting a quite explicit error message) - so
events never reached that stage.
- dropping to an ordinary 'wheel' user, with rights to neither the
configure file, nor the DB socket confirmed it.
Good news, I suppose, is that the security model seems to be QED... <g>
Bill Hacker
