Thread: Add a test to ldapbindpasswd
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. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
Attachment
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
Attachment
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
Attachment
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
Attachment
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
Attachment
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