Re: [exim] Solved: Encrypted SSL Postgres Connection

トップ ページ
このメッセージを削除
このメッセージに返信
著者: Pat
日付:  
To: exim-users@exim.org
題目: Re: [exim] Solved: Encrypted SSL Postgres Connection
(Apologies to Jasen for the inadvertent direct reply)

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, September 17, 2021 1:06 PM, Jasen Betts via Exim-users <exim-users@???> wrote:

> On 2021-09-16, Pat via Exim-users exim-users@??? wrote:
>
> > That failed with:
> > Failed: lookup of "select generate_series(1,10) " gave DEFER: PGSQL connection failed: root certificate file "root.crt" does not exist
> > Either provide the file or change sslmode to disable server certificate verification.
> > I was a little stumped at that point. I was testing from
> > /usr/local/etc/exim, and the certificate was indeed present. I tried a
> > few different things to the DB_NAME value, such as quoting the redefined
> > contents, wrapping some and then all in parenthesis, doing both, etc. but
> > nothing changed the output. Then I ran /usr/local/sbin/exim -d +all -be
> > '${lookup pgsql{ select generate_series(1,10) }}' which didn't really
> > give me anything. However in looking over the output I noticed several
> > references to /var/spool/exim, such as:
> > lock name: /var/spool/exim/eximuser.lock.
> > So I moved the two certificates and the key file to /var/spool/exim. Bingo!
>
> This is interesting. it will be hard (impossible) to use slashes in
> the database parameters, so yes, you will need to put the key file (or
> a symlink that points to it) in the spool directory.


That does fit with what I observed. The only reason I didn't try links
was because I recently saw an authentication issue that "seemed" to be
related to a symbolic link to a certificate. That doesn't sound too
plausible but pointing to the actual file resolved the issue. We did
not dig too deep into the root cause after that.

>
> This explains why the bug report is also asking for the option to use
> URL style connection strings. that would allow slashes.
>
> > I am assuming at this point that the DB_PW portion is noise that the
> > PG cluster ignores (or at least doesn't parse) because it is set to
> > an invalid value but I see no sign of it in the PG log. In fact the
> > thepguser role has no password in the cluster.
>
> Exim passes it to libpq. what libpq does with the parameters it gets
> from exim is up to the postgresql developers.


That is what I surmised, and it looks like from there libpq maybe quits
paying attention once it receives a full, syntatically correct connection
string? I could try looking through the code, or maybe even turning
up the PG logging to see if that shows it, but knowing where and how
that part gets consumed doesn't help much so I probably won't, or not
until I'm bored enough to re-visit that. :)

Appreciate the pointer that got this working, as well as Jeremy's help.

>
>
> ----------------------------------------------------------------------------------------------------------------------
>
> Jasen.
>
> -------
>
> List details at https://lists.exim.org/mailman/listinfo/exim-users
>
> -------------------------------------------------------------------
>
> Exim details at http://www.exim.org/
>
> -------------------------------------
>
> Please use the Wiki with this list - http://wiki.exim.org/
>
> -----------------------------------------------------------