Version 1.20.x

Version 1.20.x#

This page shows the changelog for Nubus for Kubernetes 1.20.x:

Version 1.20.0 - 2026-05-22#

This is the thirtieth production release of Nubus for Kubernetes.

Upgrade path

For the upgrade to version 1.20.0, your deployment must run on version 1.19.x. For the general steps to upgrade an existing Nubus for Kubernetes deployment, see Upgrade in Univention Nubus for Kubernetes - Operation Manual [1].

Release highlights#

Nubus metrics

A new metrics endpoint has been introduced to the UDM REST API. It allows operators to retrieve basic metrics about Nubus including number of users, software version and license status to include them in standard tooling like Prometheus and Grafana to simplify the observability.

Technical details of UDM objects in UMC

The technical details of objects management in the Univention Directory Manager are now visible in a new section of the Web UI. Administrators can now read or search for technical identifiers or get the creation and modification timestamps for all objects.

LDAP Server storage configuration

The LDAP server deployments can now be configured to use different storage configurations for the LDAP database and runtime volumes, allowing operators to significantly reduce storage costs by moving the runtime data to smaller and cheaper storage.

Structured logging

This will be the last release with “old style” plain logging as default. The next Nubus for Kubernetes release 1.21 will change the default to structured logging. If you need to prevent this change in your deployment we recommend to explicitly set all structured-logging configuration options to false as documented in Logging in Univention Nubus for Kubernetes - Operation Manual [1]. Please be aware that we will mark the the old plain logging as deprecated and will remove it at some point in the future.

Migration steps#

This section lists necessary migration steps that may apply to you. You need to run them before the upgrade.

  1. Refactor the LDAP server persistence values to support granular PVC configuration. Operators that customize any of the following Helm Chart values, need to migrate their values to the new structure.

    LDAP Server

Changes#

This section lists the changes in 1.20.0 grouped by component in Nubus for Kubernetes.

LDAP Server#

The LDAP Server Helm Chart now allows you to configure storage independently for the LDAP database and for the slapd runtime state. Previously, both shared the same PVC settings, which forced operators to pay for high-performance storage even for transient runtime files.

You can now independently assign different storage classes to the two volumes:

shared-data:

Holds the LDAP database and requires a storage class that provides the performance and data consistency and reliability guarantees expected of a database backend. Configure it through nubusLdapServer.persistence.volumes.sharedData.

shared-run:

Holds transient slapd runtime state, such as the socket and PID file, which the LDAP Notifier requires. This volume can be small and doesn’t need a high-performance storage class, so operators can point it at a cheaper storage class to reduce cost. Configure it through nubusLdapServer.persistence.volumes.sharedRun.

The nubusLdapServer.persistence.enabled flag now controls only the shared-data volume. The shared-run volume is always provisioned as a PVC, regardless of this setting, because the slapd socket must be shared with the LDAP Notifier.

For the required value migration, see Migration steps.

UMC Server#

A file descriptor leak caused during PAM authentication through SSS has been fixed.

In affected versions, each authentication attempt could leave an open UNIX domain socket to the SSSD PAM service. Over time, this caused the number of open file descriptors in the UMC server process to grow linearly with the total number of logins, not concurrent sessions.

After the process reached the system limit, further authentication attempts failed with the message: OSError: [Errno 24] Too many open files

PAM handles across multiple threads caused the issue, preventing proper cleanup of SSSD client sockets.

Operators don’t need to take action. Affected systems may have required periodic service restarts to recover prior to this fix.

Included errata updates#

The errata updates contain fixes for the following CVEs:

Genshi
apache2-bin
axios
bcpkix-jdk18on
bcprov-jdk18on
brace-expansion
dompurify
follow-redirects
future
gson
iputils-ping
js-yaml
jwcrypto
keycloak-js
keycloak-model-storage-services
keycloak-quarkus-server
keycloak-services
kotlin-stdlib
libasound2
libasound2-data
libavahi-client3
libavahi-common-data
libavahi-common3
libc-ares2
libc-bin
libc-dev-bin
libc-l10n
libc6
libc6-dev
libcups2
libfreetype6
libgnutls30
liblcms2-2
libnfsidmap1
libnss-sss
libnss-sudo
libnss3
libpam-sss
libpng16-16
libssl3
libsss-certmap0
libsss-idmap0
libsss-nss-idmap0
libsss-sudo
libtiff6
locales
lodash
lodash-es
loguru
netty-codec
netty-codec-dns
netty-codec-http
netty-codec-http2
netty-handler-proxy
netty-transport-native-epoll
nginx
nginx-common
openjdk-17-jre-headless
openssh-client
openssl
opentelemetry-api
poetry
postgresql
prismjs
python-ldap
python3-ldap
python3-sss
python3-tornado
quarkus-vertx-http
sssd-common
sssd-krb5-common
sssd-ldap
tornado
vertx-core
On this page