Ubuntu
openldap package

TIMEOUT and NETWORK_TIMEOUT don't work when SSL is involved

  1. Noble (24.04)
  2. Bug #2090806
Bug #2090806 reported by Matthew Ruffell
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
openldap (Ubuntu)
Status tracked in Plucky
Focal
Won't Fix
Medium
Matthew Ruffell
Jammy
Fix Released
Medium
Matthew Ruffell
Noble
Fix Released
Medium
Matthew Ruffell
Oracular
Fix Released
Medium
Matthew Ruffell
Plucky
Fix Released
Medium
Sergio Durigan Junior

Bug Description

[Impact]

If you connect to a slapd server using TLS and for some reason, the connection
hangs or fails to completely establish, TIMEOUT and NETWORK_TIMEOUT values
do not function as they are intended. They get ignored, and the connecting
process e.g. ldapsearch just sits there at 100% CPU waiting forever.

If slapd is set up in High Availability with servers to failover to, the
failover will never occur, due to the connecting processes sitting there at
100% CPU waiting for the connection that will never succeed, leading to outages.

You can simulate this easily with:

$ ldapsearch -x -H ldaps://example.com
$ sudo kill -STOP <slapd pid>
$ ldapsearch -x -H ldaps://example.com

and the last call will hang forever.

There doesn't seem to be any workaround for this, apart from not using SSL.

[Testcase]

You can get away with just the one VM for this.

Set up the ldap server (from server docs):
https://ubuntu.com/server/docs/install-and-configure-ldap

$ sudo apt install slapd ldap-utils
$ sudo dpkg-reconfigure slapd
Set DNS to example.com
$ ldapsearch -x -LLL -H ldap:/// -b dc=example,dc=com dn
dn: dc=example,dc=com
$ vim add_content.ldif
dn: ou=People,dc=example,dc=com
objectClass: organizationalUnit
ou: People

dn: ou=Groups,dc=example,dc=com
objectClass: organizationalUnit
ou: Groups

dn: cn=miners,ou=Groups,dc=example,dc=com
objectClass: posixGroup
cn: miners
gidNumber: 5000

dn: uid=john,ou=People,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: john
sn: Doe
givenName: John
cn: John Doe
displayName: John Doe
uidNumber: 10000
gidNumber: 5000
userPassword: {CRYPT}x
gecos: John Doe
loginShell: /bin/bash
homeDirectory: /home/john
$ ldapadd -x -D cn=admin,dc=example,dc=com -W -f add_content.ldif
$ ldapsearch -x -LLL -b dc=example,dc=com '(uid=john)' cn gidNumber
dn: uid=john,ou=People,dc=example,dc=com
cn: John Doe
gidNumber: 5000
$ ldappasswd -x -D cn=admin,dc=example,dc=com -W -S uid=john,ou=people,dc=example,dc=com
New password:
Re-enter new password:
Enter LDAP Password:

Configure the server for SSL (from server docs):
https://ubuntu.com/server/docs/ldap-and-transport-layer-security-tls

$ sudo apt install gnutls-bin ssl-cert
$ sudo certtool --generate-privkey --bits 4096 --outfile /etc/ssl/private/mycakey.pem
$ sudo vim /etc/ssl/ca.info
cn = Example Company
ca
cert_signing_key
expiration_days = 3650
$ sudo certtool --generate-self-signed \
--load-privkey /etc/ssl/private/mycakey.pem \
--template /etc/ssl/ca.info \
--outfile /usr/local/share/ca-certificates/mycacert.crt
$ sudo update-ca-certificates
$ sudo certtool --generate-privkey \
--bits 2048 \
--outfile /etc/ldap/ldap01_slapd_key.pem
$ sudo vim /etc/ssl/ldap01.info
organization = Example Company
cn = example.com
tls_www_server
encryption_key
signing_key
expiration_days = 365
$ sudo certtool --generate-certificate \
--load-privkey /etc/ldap/ldap01_slapd_key.pem \
--load-ca-certificate /etc/ssl/certs/mycacert.pem \
--load-ca-privkey /etc/ssl/private/mycakey.pem \
--template /etc/ssl/ldap01.info \
--outfile /etc/ldap/ldap01_slapd_cert.pem
$ sudo chgrp openldap /etc/ldap/ldap01_slapd_key.pem
$ sudo chmod 0640 /etc/ldap/ldap01_slapd_key.pem
$ sudo vim certinfo.ldif
dn: cn=config
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/mycacert.pem
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ldap/ldap01_slapd_cert.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ldap/ldap01_slapd_key.pem
$ sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f certinfo.ldif
$ sudo vim /etc/default/slapd
Change
LAPD_SERVICES="ldap:/// ldapi:///"
to
SLAPD_SERVICES="ldap:/// ldapi:/// ldaps:///"

Next add TIMEOUT and NETWORK_TIMEOUT to the config file.

$ sudo vim /etc/ldap/ldap.conf
NETWORK_TIMEOUT 30
TIMEOUT 30
$ sudo systemctl restart slapd

Reproduce the problem:

$ ldapsearch -x -H ldaps://example.com
# extended LDIF
#
# LDAPv3
# base <> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 32 No such object

# numResponses: 1

$ ps aux | grep slapd
openldap 4097 0.0 0.1 1224136 7876 ? Ssl 02:22 0:00 /usr/sbin/slapd -h ldap:/// ldapi:/// ldaps:/// -g openldap -u openldap -F /etc/ldap/slapd.d
$ sudo kill -STOP 4097
$ ldapsearch -x -H ldaps://example.com

Check top:

    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
   4237 ubuntu 20 0 20724 10956 6656 R 100.0 0.3 0:35.70 ldapsearch

wait for 30 seconds, see nothing changes.

If you install packages from proposed, you should see the timeout work as expected, and the ldapsearch process will give up after 30 seconds.

[Where problems could occur]

We are changing how connections are tracked within openldap to better accurately
say what state we are in, and for the timeouts to work when the connection
doesn't make any progress.

This will cause TIMEOUT and NETWORK_TIMEOUT to start working as intended, which
might surprise some sysadmins who configured it, and likely forgot about it
when they never had any timeout issues.

If a regression were to occur, it would affect initial connections to openldap
servers, or even long running commands that might exceed the TIMEOUT on queries
over large ldap databases.

[Other info]

Upstream issues:
https://bugs.openldap.org/show_bug.cgi?id=8047
https://bugs.openldap.org/show_bug.cgi?id=10141

This was fixed in 2.6.9 upstream by:

commit d143f7a2dc82fb66e7741b93a1ae9e874ce2ac46
Author: Ondřej Kuzník <email address hidden>
Date: Mon, 21 Oct 2024 11:50:11 +0100
Subject: ITS#8047 Fix TLS connection timeout handling
Link: https://git.openldap.org/openldap/openldap/-/commit/d143f7a2dc82fb66e7741b93a1ae9e874ce2ac46

This fix is required in all releases.

See original description
Matthew Ruffell (mruffell)
Changed in openldap (Ubuntu Focal):
status: New → In Progress
Changed in openldap (Ubuntu Jammy):
status: New → In Progress
Changed in openldap (Ubuntu Noble):
status: New → In Progress
Changed in openldap (Ubuntu Oracular):
status: New → In Progress
Changed in openldap (Ubuntu Plucky):
status: New → In Progress
Changed in openldap (Ubuntu Focal):
importance: Undecided → Medium
Changed in openldap (Ubuntu Jammy):
importance: Undecided → Medium
Changed in openldap (Ubuntu Noble):
importance: Undecided → Medium
Changed in openldap (Ubuntu Oracular):
importance: Undecided → Medium
Changed in openldap (Ubuntu Plucky):
importance: Undecided → Medium
Changed in openldap (Ubuntu Focal):
assignee: nobody → Matthew Ruffell (mruffell)
Changed in openldap (Ubuntu Jammy):
assignee: nobody → Matthew Ruffell (mruffell)
Changed in openldap (Ubuntu Noble):
assignee: nobody → Matthew Ruffell (mruffell)
Changed in openldap (Ubuntu Oracular):
assignee: nobody → Matthew Ruffell (mruffell)
tags: added: sts
Revision history for this message
Matthew Ruffell (mruffell) wrote :

Attached is a debdiff for oracular which fixes this issue.

Revision history for this message
Matthew Ruffell (mruffell) wrote :

Attached is a debdiff for openldap on noble which fixes this issue

Revision history for this message
Matthew Ruffell (mruffell) wrote :

Attached is a debdiff for openldap on jammy which fixes this issue

Revision history for this message
Matthew Ruffell (mruffell) wrote :

Attached is a debdiff for openldap on focal which fixes this issue

Ubuntu Foundations Team Bug Bot (crichton)
tags: added: patch
Sergio Durigan Junior (sergiodj)
Changed in openldap (Ubuntu Plucky):
status: In Progress → Fix Committed
assignee: nobody → Sergio Durigan Junior (sergiodj)
Matthew Ruffell (mruffell)
Changed in openldap (Ubuntu Plucky):
status: Fix Committed → Fix Released
Matthew Ruffell (mruffell)
Changed in openldap (Ubuntu Focal):
status: In Progress → Won't Fix
Revision history for this message
Andreas Hasenack (ahasenack) wrote : Please test proposed package

Hello Matthew, or anyone else affected,

Accepted openldap into oracular-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/openldap/2.6.8+dfsg-1~exp4ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-oracular to verification-done-oracular. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-oracular. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

description: updated
Changed in openldap (Ubuntu Oracular):
status: In Progress → Fix Committed
tags: added: verification-needed verification-needed-oracular
Revision history for this message
Andreas Hasenack (ahasenack) wrote :

Hello Matthew, or anyone else affected,

Accepted openldap into noble-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/openldap/2.6.7+dfsg-1~exp1ubuntu8.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-noble to verification-done-noble. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-noble. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in openldap (Ubuntu Noble):
status: In Progress → Fix Committed
tags: added: verification-needed-noble
Changed in openldap (Ubuntu Jammy):
status: In Progress → Fix Committed
tags: added: verification-needed-jammy
Revision history for this message
Andreas Hasenack (ahasenack) wrote :

Hello Matthew, or anyone else affected,

Accepted openldap into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/openldap/2.5.18+dfsg-0ubuntu0.22.04.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Revision history for this message
Ubuntu SRU Bot (ubuntu-sru-bot) wrote : Autopkgtest regression report (openldap/2.5.18+dfsg-0ubuntu0.22.04.3)

All autopkgtests for the newly accepted openldap (2.5.18+dfsg-0ubuntu0.22.04.3) for jammy have finished running.
The following regressions have been reported in tests triggered by the package:

dovecot/1:2.3.16+dfsg1-3ubuntu2.4 (s390x)
libreoffice/1:7.3.7-0ubuntu0.22.04.7 (ppc64el)
samba/2:4.15.13+dfsg-0ubuntu1.6 (s390x)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/jammy/update_excuses.html#openldap

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

Revision history for this message
Ubuntu SRU Bot (ubuntu-sru-bot) wrote : Autopkgtest regression report (openldap/2.6.8+dfsg-1~exp4ubuntu1.1)

All autopkgtests for the newly accepted openldap (2.6.8+dfsg-1~exp4ubuntu1.1) for oracular have finished running.
The following regressions have been reported in tests triggered by the package:

balsa/unknown (amd64)
curl/8.9.1-2ubuntu2.2 (s390x)
freedombox/unknown (i386)
gnupg2/unknown (i386)
libreoffice/4:24.8.4-0ubuntu0.24.10.1 (armhf, ppc64el)
mingw-w64/unknown (i386)
openvpn-auth-ldap/unknown (amd64)
phpldapadmin/1.2.6.7-1 (amd64, i386)
python-bonsai/unknown (amd64)
samba/unknown (amd64)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/oracular/update_excuses.html#openldap

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

Revision history for this message
Ubuntu SRU Bot (ubuntu-sru-bot) wrote : Autopkgtest regression report (openldap/2.6.7+dfsg-1~exp1ubuntu8.2)

All autopkgtests for the newly accepted openldap (2.6.7+dfsg-1~exp1ubuntu8.2) for noble have finished running.
The following regressions have been reported in tests triggered by the package:

dovecot/1:2.3.21+dfsg1-2ubuntu6 (s390x)
exim4/4.97-4ubuntu4.2 (ppc64el)
libreoffice/4:24.2.7-0ubuntu0.24.04.1 (amd64)
phpldapadmin/1.2.6.7-1 (amd64, arm64, i386)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/noble/update_excuses.html#openldap

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

Revision history for this message
Matthew Ruffell (mruffell) wrote :

Performing verification for oracular.

I setup a fresh oracular VM according to the testcase. The opendlap version
is:

$ sudo apt-cache policy slapd | grep Installed
  Installed: 2.6.8+dfsg-1~exp4ubuntu1

from -updates.

Running the reproducer:

$ ldapsearch -x -H ldaps://example.com
# extended LDIF
#
# LDAPv3
# base <> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 32 No such object

# numResponses: 1
$ ps aux | grep slapd
openldap 4257 0.0 0.2 1225544 8236 ? Ssl 02:27 0:00 /usr/sbin/slapd -h ldap:/// ldapi:/// ldaps:/// -g openldap -u openldap -F /etc/ldap/slapd.d
$ sudo kill -STOP 4257
$ ldapsearch -x -H ldaps://example.com

top shows ldapsearch running at 100% CPU for over a minute now, so much for the
30 second timeout.

    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
   4343 ubuntu 20 0 22092 11388 7048 R 100.0 0.3 1:27.62 ldapsearch

If you leave ldapsearch running, it will never timeout, and stay constantly
at 100% CPU.

I then sent SIGCONT to the slapd process:

$ sudo kill -CONT 4257

and we are back to normal:

$ ldapsearch -x -H ldaps://example.com
# extended LDIF
#
# LDAPv3
# base <> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 32 No such object

# numResponses: 1

I then enabled -proposed, and installed openldap 2.6.8+dfsg-1~exp4ubuntu1.1.

Re-running the reproducer:

I added a time to the second ldapsearch, to show the timeout working effectively.

$ ldapsearch -x -H ldaps://example.com
# extended LDIF
#
# LDAPv3
# base <> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 32 No such object

# numResponses: 1
$ ps aux | grep slapd
openldap 5246 0.0 0.2 1225548 8200 ? Ssl 02:33 0:00 /usr/sbin/slapd -h ldap:/// ldapi:/// ldaps:/// -g openldap -u openldap -F /etc/ldap/slapd.d
ubuntu 5337 0.0 0.0 7152 2148 pts/0 S+ 02:34 0:00 grep --color=auto slapd
$ sudo kill -STOP 5246
$ time ldapsearch -x -H ldaps://example.com
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

real 0m30.040s
user 0m0.007s
sys 0m0.009s

A perfect 30 second timeout, with appropriate error message. top shows 0% CPU
the whole time.

The package in -proposed fixes the issue. Happy to mark verified for oracular.

tags: added: verification-done-oracular
removed: verification-needed-oracular
Revision history for this message
Matthew Ruffell (mruffell) wrote :

Performing verification for noble.

I setup a fresh noble VM according to the testcase. The opendlap version
is:

$ sudo apt-cache policy slapd | grep Installed
  Installed: 2.6.7+dfsg-1~exp1ubuntu8.1

from -updates.

Running the reproducer:

$ ldapsearch -x -H ldaps://example.com
# extended LDIF
#
# LDAPv3
# base <> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 32 No such object

# numResponses: 1
$ ps aux | grep slapd
openldap 7851 0.0 0.1 1224136 7988 ? Ssl 03:06 0:00 /usr/sbin/slapd -h ldap:/// ldapi:/// ldaps:/// -g openldap -u openldap -F /etc/ldap/slapd.d
$ sudo kill -STOP 7851
$ ldapsearch -x -H ldaps://example.com

top shows ldapsearch running at 100% CPU for over a minute now, so much for the
30 second timeout.

    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
   7869 ubuntu 20 0 20724 11084 6784 R 99.7 0.3 1:08.92 ldapsearch

If you leave ldapsearch running, it will never timeout, and stay constantly
at 100% CPU.

I then sent SIGCONT to the slapd process:

$ sudo kill -CONT 7851

and we are back to normal:

$ ldapsearch -x -H ldaps://example.com
# extended LDIF
#
# LDAPv3
# base <> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 32 No such object

# numResponses: 1

I then enabled -proposed, and installed openldap 2.6.7+dfsg-1~exp1ubuntu8.2

Re-running the reproducer:

I added a time to the second ldapsearch, to show the timeout working effectively.

$ ldapsearch -x -H ldaps://example.com
# extended LDIF
#
# LDAPv3
# base <> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 32 No such object

# numResponses: 1
$ ps aux | grep slapd
openldap 8559 0.0 0.2 1224140 8344 ? Ssl 03:10 0:00 /usr/sbin/slapd -h ldap:/// ldapi:/// ldaps:/// -g openldap -u openldap -F /etc/ldap/slapd.d
$ sudo kill -STOP 8559
$ time ldapsearch -x -H ldaps://example.com
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

real 0m30.040s
user 0m0.012s
sys 0m0.007s

A perfect 30 second timeout, with appropriate error message. top shows 0% CPU
the whole time.

The package in -proposed fixes the issue. Happy to mark verified for noble.

tags: added: verification-done-noble
removed: verification-needed-noble
Revision history for this message
Matthew Ruffell (mruffell) wrote :

Performing verification for jammy.

I setup a fresh jammy VM according to the testcase. The opendlap version
is:

$ sudo apt-cache policy slapd | grep Installed
 Installed: 2.5.18+dfsg-0ubuntu0.22.04.2

from -updates.

Running the reproducer:

$ ldapsearch -x -H ldaps://example.com
# extended LDIF
#
# LDAPv3
# base <> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 32 No such object

# numResponses: 1
$ ps aux | grep slapd
openldap 2784 0.0 0.1 1223580 7688 ? Ssl 03:52 0:00 /usr/sbin/slapd -h ldap:/// ldapi:/// ldaps:/// -g openldap -u openldap -F /etc/ldap/slapd.d
$ sudo kill -STOP 2784
$ ldapsearch -x -H ldaps://example.com

top shows ldapsearch running at 100% CPU for over a minute now, so much for the
30 second timeout.

    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
   2802 ubuntu 20 0 19428 10556 6312 R 100.0 0.3 1:04.33 ldapsearch

If you leave ldapsearch running, it will never timeout, and stay constantly
at 100% CPU.

I then sent SIGCONT to the slapd process:

$ sudo kill -CONT 2784

and we are back to normal:

$ ldapsearch -x -H ldaps://example.com
# extended LDIF
#
# LDAPv3
# base <> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 32 No such object

# numResponses: 1

I then enabled -proposed, and installed openldap 2.5.18+dfsg-0ubuntu0.22.04.3

Re-running the reproducer:

I added a time to the second ldapsearch, to show the timeout working effectively.

$ ldapsearch -x -H ldaps://example.com
# extended LDIF
#
# LDAPv3
# base <> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 32 No such object

# numResponses: 1
$ ps aux | grep slapd
openldap 3532 0.0 0.1 1223580 7700 ? Ssl 03:56 0:00 /usr/sbin/slapd -h ldap:/// ldapi:/// ldaps:/// -g openldap -u openldap -F /etc/ldap/slapd.d
$ sudo kill -STOP 3532
$ time ldapsearch -x -H ldaps://example.com
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

real 0m30.043s
user 0m0.013s
sys 0m0.009s

A perfect 30 second timeout, with appropriate error message. top shows 0% CPU
the whole time.

The package in -proposed fixes the issue. Happy to mark verified for jammy.

tags: added: verification-done-jammy
removed: verification-needed verification-needed-jammy
Sergio Durigan Junior (sergiodj)
tags: added: verification-done
Revision history for this message
Matthew Ruffell (mruffell) wrote :

The autopkgtests for oracular and noble are just failing on phpldapadmin, due to bug 2097403. The tests themselves pass, it just fails due to that error output to stderr by chromium-driver.

Revision history for this message
Andreas Hasenack (ahasenack) wrote : Update Released

The verification of the Stable Release Update for openldap has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package openldap - 2.6.8+dfsg-1~exp4ubuntu1.1

---------------
openldap (2.6.8+dfsg-1~exp4ubuntu1.1) oracular; urgency=medium

  * Fixup TIMEOUT and NETWORK_TIMEOUT options so they work correctly
    when SSL is involved. Before they would never timeout, causing
    hangs on connection failure. Now they timeout as expected.
    (LP: #2090806)
    - d/p/lp2090806-ITS-8047-Fix-TLS-connection-timeout-handling.patch

 -- Matthew Ruffell <email address hidden> Mon, 09 Dec 2024 15:41:30 +1300

Changed in openldap (Ubuntu Oracular):
status: Fix Committed → Fix Released
Revision history for this message
Andreas Hasenack (ahasenack) wrote :

For noble and older, I'm waiting for the noble SRU freeze to be lifted (today is 24.04.2 day).

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

Noble 24.04.2 is out!

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package openldap - 2.6.7+dfsg-1~exp1ubuntu8.2

---------------
openldap (2.6.7+dfsg-1~exp1ubuntu8.2) noble; urgency=medium

  * Fixup TIMEOUT and NETWORK_TIMEOUT options so they work correctly
    when SSL is involved. Before they would never timeout, causing
    hangs on connection failure. Now they timeout as expected.
    (LP: #2090806)
    - d/p/lp2090806-ITS-8047-Fix-TLS-connection-timeout-handling.patch

 -- Matthew Ruffell <email address hidden> Mon, 09 Dec 2024 15:50:18 +1300

Changed in openldap (Ubuntu Noble):
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package openldap - 2.5.18+dfsg-0ubuntu0.22.04.3

---------------
openldap (2.5.18+dfsg-0ubuntu0.22.04.3) jammy; urgency=medium

  * Fixup TIMEOUT and NETWORK_TIMEOUT options so they work correctly
    when SSL is involved. Before they would never timeout, causing
    hangs on connection failure. Now they timeout as expected.
    (LP: #2090806)
    - d/p/lp2090806-ITS-8047-Fix-TLS-connection-timeout-handling.patch

 -- Matthew Ruffell <email address hidden> Mon, 09 Dec 2024 15:54:19 +1300

Changed in openldap (Ubuntu Jammy):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.