Pre-update checks for UCS 5.0-0 aborts warning about a very large Samba TDB database

Knowledge Base Supported
, , , , , ,
#1

Situation:

The pre-checks for the update to UCS 5.0 fail, telling you that the Samba SAM database is very large and that this may result in Samba not starting after the update.

Solution:

Download the python script migrate-samldb-from-tdb-to-mdb (from UCS version 5.2 on this script is part of UCS as /usr/share/univention-samba4/scripts/migrate-samldb-from-tdb-to-mdb.py) and arrange a maintenance window for the conversion of the Samba SAM database backend from TDB to LMDB. While TDB has a hard limit of 4GB, the LMBD database format can be adjusted to accommodate larger amounts of data. The LMDB database technology is also used by OpenLDAP, so we consider it to be fit for the job. The script will run a samba-tool dbcheck --cross-ncs before and after the migration, which will take the largest time. If the check detects a problem, then the migration script will abort to avoid damage. You can attempt to fix the problems by running samba-tool dbcheck --cross-ncs --fix --yes . In case you want to reduce the downtime you could consider performing the dbcheck separately before the migration and start the script with the option migrate-samldb-from-tdb-to-mdb --skip-dbcheck. This is considered to be safe, because the migration treats all the data as opaque blobs, but we prefer being safe rather than sorry. The dbcheck issues would be on a higher level than where the script operates. Please note that the script needs to be run on all UCS Samba/AD DCs individually, as it’s really just about the local backend storage technology.

Since UCS 5.0-5 Errata 811 two new UCR variables samba/database/backend/store and samba/database/backend/store/size have been added to configure the samba database backend (tdb or mdb) before the initial setup, join or re-join. When starting to migrate from tdb to mdb it is recommended to aim for a consistent configuration of these variables on all UCS Samba/AD domain controllers. E.g. choosing mdb for the UCS Primary Directory Node but staying with tdb on a replicating node will cause trouble when the data size in one of the Samba/AD SAM backend stores (i.e. naming contexts) grows beyond the limits possible with tdb. The errata update was released explicitly to help customers to avoid that, e.g. by setting these UCR variables uniformly with a UDM policy. The size limit given in samba/database/backend/store/size (default 8GB) is effecting the individual backend store files in /var/lib/samba/private/sam.ldb.d/*.ldb. Since there are typically 5 naming contexts (domain, configuration, schema, DomainDNSZones and ForestDNSZones), care should be taken that the storage has enough room for the total size. The size limit given in samba/database/backend/store/size can be raised at any time by adjusting the UCR variable and then restarting samba. It must never be decreased though (that’s how LMDB works).

To summarize a plan for migration of a UCS domain could look like this:

  • set samba/database/backend/store=mdb via UCR on all UCS Directory Nodes that run Samba/AD services (e.g. via UDM policy)

  • Pick one UCS Backup and Replica Directory Node that runs Samba/AD as the first candidate for migration. Depending on the amount of data, a service window should be scheduled for that. A full re-join is not even necessary, it’s enough to re-run the samba4 related joinscripts like this: univention-run-join-scripts --run-scripts 96univention-samba4.inst 97univention-s4-connector.inst 98univention-samba4-dns.inst 98univention-samba4-saml-kerberos.inst --force

  • Verify that the system runs normally.

  • Continue with other DCs one by one.

  • Finally, on the Primary use migrate-samldb-from-tdb-to-mdb (from UCS version 5.2 on /usr/share/univention-samba4/scripts/migrate-samldb-from-tdb-to-mdb.py) to migrate it to mdb.

Mastodon