Add a test to ldapbindpasswd

On 2022-12-19 Mo 11:16, Andrew Dunstan wrote:

There is currently no test for the use of ldapbindpasswd in the
pg_hba.conf file. This patch, mostly the work of John Naylor, remedies that.

This currently has failures on the cfbot for meson builds on FBSD13 and
Debian Bullseye, but it's not at all clear why. In both cases it fails
where the ldap server is started.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

On Mon, Jan 2, 2023 at 3:04 AM Andrew Dunstan <andrew@dunslane.net> wrote:

On 2022-12-19 Mo 11:16, Andrew Dunstan wrote:

There is currently no test for the use of ldapbindpasswd in the
pg_hba.conf file. This patch, mostly the work of John Naylor, remedies that.

This currently has failures on the cfbot for meson builds on FBSD13 and
Debian Bullseye, but it's not at all clear why. In both cases it fails
where the ldap server is started.

I think it's failing when using meson. I guess it fails to fail on
macOS only because you need to add a new path for Homebrew/ARM like
commit 14d63dd2, so it's skipping (it'd be nice if we didn't need
another copy of all that logic). Trying locally... it looks like
slapd is failing silently, and with some tracing I can see it's
sending an error message to my syslog daemon, which logged:

2023-01-02T07:50:20.853019+13:00 x1 slapd[153599]: main: TLS init def
ctx failed: -1

Ah, it looks like this test is relying on "slapd-certs", which doesn't exist:

tmunro@x1:~/projects/postgresql/build$ ls testrun/ldap/001_auth/data/
ldap.conf ldappassword openldap-data portlock slapd-certs slapd.conf
tmunro@x1:~/projects/postgresql/build$ ls testrun/ldap/002_bindpasswd/data/
portlock slapd.conf

I didn't look closely, but apparently there is something wrong in the
part that copies certs from the ssl test? Not sure why it works for
autoconf...

On Jan 1, 2023, at 2:03 PM, Thomas Munro <thomas.munro@gmail.com> wrote:

On Mon, Jan 2, 2023 at 3:04 AM Andrew Dunstan <andrew@dunslane.net> wrote:

On 2022-12-19 Mo 11:16, Andrew Dunstan wrote:
There is currently no test for the use of ldapbindpasswd in the
pg_hba.conf file. This patch, mostly the work of John Naylor, remedies that.

This currently has failures on the cfbot for meson builds on FBSD13 and
Debian Bullseye, but it's not at all clear why. In both cases it fails
where the ldap server is started.

I think it's failing when using meson. I guess it fails to fail on
macOS only because you need to add a new path for Homebrew/ARM like
commit 14d63dd2, so it's skipping (it'd be nice if we didn't need
another copy of all that logic). Trying locally... it looks like
slapd is failing silently, and with some tracing I can see it's
sending an error message to my syslog daemon, which logged:

2023-01-02T07:50:20.853019+13:00 x1 slapd[153599]: main: TLS init def
ctx failed: -1

Ah, it looks like this test is relying on "slapd-certs", which doesn't exist:

tmunro@x1:~/projects/postgresql/build$ ls testrun/ldap/001_auth/data/
ldap.conf ldappassword openldap-data portlock slapd-certs slapd.conf
tmunro@x1:~/projects/postgresql/build$ ls testrun/ldap/002_bindpasswd/data/
portlock slapd.conf

I didn't look closely, but apparently there is something wrong in the
part that copies certs from the ssl test? Not sure why it works for
autoconf...

Thanks, I see the problem. Will post a revised patch shortly

Cheers

Andrew

On 2023-01-01 Su 14:02, Thomas Munro wrote:

On Mon, Jan 2, 2023 at 3:04 AM Andrew Dunstan <andrew@dunslane.net> wrote:

On 2022-12-19 Mo 11:16, Andrew Dunstan wrote:

There is currently no test for the use of ldapbindpasswd in the
pg_hba.conf file. This patch, mostly the work of John Naylor, remedies that.

This currently has failures on the cfbot for meson builds on FBSD13 and
Debian Bullseye, but it's not at all clear why. In both cases it fails
where the ldap server is started.

I think it's failing when using meson. I guess it fails to fail on
macOS only because you need to add a new path for Homebrew/ARM like
commit 14d63dd2, so it's skipping (it'd be nice if we didn't need
another copy of all that logic). Trying locally... it looks like
slapd is failing silently, and with some tracing I can see it's
sending an error message to my syslog daemon, which logged:

2023-01-02T07:50:20.853019+13:00 x1 slapd[153599]: main: TLS init def
ctx failed: -1

Ah, it looks like this test is relying on "slapd-certs", which doesn't exist:

tmunro@x1:~/projects/postgresql/build$ ls testrun/ldap/001_auth/data/
ldap.conf ldappassword openldap-data portlock slapd-certs slapd.conf
tmunro@x1:~/projects/postgresql/build$ ls testrun/ldap/002_bindpasswd/data/
portlock slapd.conf

I didn't look closely, but apparently there is something wrong in the
part that copies certs from the ssl test? Not sure why it works for
autoconf...

Let's see how we fare with this patch.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

On 2023-01-01 Su 18:31, Andrew Dunstan wrote:

On 2023-01-01 Su 14:02, Thomas Munro wrote:

On Mon, Jan 2, 2023 at 3:04 AM Andrew Dunstan <andrew@dunslane.net> wrote:

On 2022-12-19 Mo 11:16, Andrew Dunstan wrote:

There is currently no test for the use of ldapbindpasswd in the
pg_hba.conf file. This patch, mostly the work of John Naylor, remedies that.

This currently has failures on the cfbot for meson builds on FBSD13 and
Debian Bullseye, but it's not at all clear why. In both cases it fails
where the ldap server is started.

I think it's failing when using meson. I guess it fails to fail on
macOS only because you need to add a new path for Homebrew/ARM like
commit 14d63dd2, so it's skipping (it'd be nice if we didn't need
another copy of all that logic). Trying locally... it looks like
slapd is failing silently, and with some tracing I can see it's
sending an error message to my syslog daemon, which logged:

2023-01-02T07:50:20.853019+13:00 x1 slapd[153599]: main: TLS init def
ctx failed: -1

Ah, it looks like this test is relying on "slapd-certs", which doesn't exist:

tmunro@x1:~/projects/postgresql/build$ ls testrun/ldap/001_auth/data/
ldap.conf ldappassword openldap-data portlock slapd-certs slapd.conf
tmunro@x1:~/projects/postgresql/build$ ls testrun/ldap/002_bindpasswd/data/
portlock slapd.conf

I didn't look closely, but apparently there is something wrong in the
part that copies certs from the ssl test? Not sure why it works for
autoconf...

Let's see how we fare with this patch.

Not so well :-(. This version tries to make the tests totally
independent, as they should be. That's an attempt to get the cfbot to go
green, but I am intending to refactor this code substantially so the
common bits are in a module each test file will load.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Hi,

On Mon, Jan 02, 2023 at 09:45:27AM -0500, Andrew Dunstan wrote:

On 2023-01-01 Su 18:31, Andrew Dunstan wrote:

Let's see how we fare with this patch.

Not so well :-(. This version tries to make the tests totally
independent, as they should be. That's an attempt to get the cfbot to go
green, but I am intending to refactor this code substantially so the
common bits are in a module each test file will load.

FTR you can run the same set of CI tests using your own GH account rather than
sedning patches, see src/tools/ci/README/

On 2023-01-02 Mo 09:45, Andrew Dunstan wrote:

On 2023-01-01 Su 18:31, Andrew Dunstan wrote:

On 2023-01-01 Su 14:02, Thomas Munro wrote:

On Mon, Jan 2, 2023 at 3:04 AM Andrew Dunstan <andrew@dunslane.net> wrote:

On 2022-12-19 Mo 11:16, Andrew Dunstan wrote:

There is currently no test for the use of ldapbindpasswd in the
pg_hba.conf file. This patch, mostly the work of John Naylor, remedies that.

This currently has failures on the cfbot for meson builds on FBSD13 and
Debian Bullseye, but it's not at all clear why. In both cases it fails
where the ldap server is started.

I think it's failing when using meson. I guess it fails to fail on
macOS only because you need to add a new path for Homebrew/ARM like
commit 14d63dd2, so it's skipping (it'd be nice if we didn't need
another copy of all that logic). Trying locally... it looks like
slapd is failing silently, and with some tracing I can see it's
sending an error message to my syslog daemon, which logged:

2023-01-02T07:50:20.853019+13:00 x1 slapd[153599]: main: TLS init def
ctx failed: -1

Ah, it looks like this test is relying on "slapd-certs", which doesn't exist:

tmunro@x1:~/projects/postgresql/build$ ls testrun/ldap/001_auth/data/
ldap.conf ldappassword openldap-data portlock slapd-certs slapd.conf
tmunro@x1:~/projects/postgresql/build$ ls testrun/ldap/002_bindpasswd/data/
portlock slapd.conf

I didn't look closely, but apparently there is something wrong in the
part that copies certs from the ssl test? Not sure why it works for
autoconf...

Let's see how we fare with this patch.

Not so well :-(. This version tries to make the tests totally
independent, as they should be. That's an attempt to get the cfbot to go
green, but I am intending to refactor this code substantially so the
common bits are in a module each test file will load.

This version factors out the creation of the LDAP server into a separate
perl Module. That makes both the existing test script and the new test
script a lot shorter, and will be useful for the nearby patch for a hook
for the ldapbindpassword.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

On 2023-01-04 We 16:26, Andrew Dunstan wrote:

On 2023-01-02 Mo 09:45, Andrew Dunstan wrote:

On 2023-01-01 Su 18:31, Andrew Dunstan wrote:

On 2023-01-01 Su 14:02, Thomas Munro wrote:

On Mon, Jan 2, 2023 at 3:04 AM Andrew Dunstan <andrew@dunslane.net> wrote:

On 2022-12-19 Mo 11:16, Andrew Dunstan wrote:

There is currently no test for the use of ldapbindpasswd in the
pg_hba.conf file. This patch, mostly the work of John Naylor, remedies that.

This currently has failures on the cfbot for meson builds on FBSD13 and
Debian Bullseye, but it's not at all clear why. In both cases it fails
where the ldap server is started.

I think it's failing when using meson. I guess it fails to fail on
macOS only because you need to add a new path for Homebrew/ARM like
commit 14d63dd2, so it's skipping (it'd be nice if we didn't need
another copy of all that logic). Trying locally... it looks like
slapd is failing silently, and with some tracing I can see it's
sending an error message to my syslog daemon, which logged:

2023-01-02T07:50:20.853019+13:00 x1 slapd[153599]: main: TLS init def
ctx failed: -1

Ah, it looks like this test is relying on "slapd-certs", which doesn't exist:

tmunro@x1:~/projects/postgresql/build$ ls testrun/ldap/001_auth/data/
ldap.conf ldappassword openldap-data portlock slapd-certs slapd.conf
tmunro@x1:~/projects/postgresql/build$ ls testrun/ldap/002_bindpasswd/data/
portlock slapd.conf

I didn't look closely, but apparently there is something wrong in the
part that copies certs from the ssl test? Not sure why it works for
autoconf...

Let's see how we fare with this patch.

Not so well :-(. This version tries to make the tests totally
independent, as they should be. That's an attempt to get the cfbot to go
green, but I am intending to refactor this code substantially so the
common bits are in a module each test file will load.

This version factors out the creation of the LDAP server into a separate
perl Module. That makes both the existing test script and the new test
script a lot shorter, and will be useful for the nearby patch for a hook
for the ldapbindpassword.

Looks like I fat fingered this. Here's a version that works.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

On 2023-01-04 We 17:33, Andrew Dunstan wrote:

This version factors out the creation of the LDAP server into a separate
perl Module. That makes both the existing test script and the new test
script a lot shorter, and will be useful for the nearby patch for a hook
for the ldapbindpassword.

Looks like I fat fingered this. Here's a version that works.

pushed.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com