System diagnostic: LDAP schema files are not properly registered

[pp303]

Hi all.

Thinking about the future upgrade to 5.2 I’ve looked at an old system diagnostic that has hung around for a long time. It is “LDAP schema files are not properly registered”.

Old packages and Apps registered schema files by copying the files locally into a certain directory.
The preferred way now is to register them in LDAP; this is less error prone in situations like backup2master.
The following files seem to be registered in the old way:
 * /var/lib/univention-ldap/local-schema/univention-corporate-client.schema

There is a button to register the single missing schema file however, given its an old UCC schema from when we had that installed back around the v3-v4 transition I don’t actually want to keep it.

I can find the following wiki around removing schema extensions that look to already be registered in LDAP.

Remove LDAP schema extensions

Abstract Several apps include their own LDAP schema extensions. They are automatically registered with the UCS LDAP servers on installation. On de-installation they are not removed automatically. They can be only removed if no LDAP objects use definitions from the schema extensions any longer. Warning The following procedure should be done by experienced administrators only. An error may severely damage your domain. The procedure should be performed in a test environment before working in the…

I can’t find any UCC attributes in the LDAP. Should be safe to remove the .schema file given it was never ‘properly registered’ (taking backups/snapshots of course).

[pmhahn]

@pp303

I can’t find any UCC attributes in the LDAP. Should be safe to remove the .schema file given it was never ‘properly registered’ (taking backups/snapshots of course).

Nothing in UCS references UCC, so you can probably just delete the file after checking that no objectClass and attribute from that schema file is still used by running this command as user root:

slapcat | grep -i \
  -e univentionCorporateClient \
  -e univentionPolicyCorporateClient \
  -e univentionPolicySoftwareupdates

Also make sure that the file is no longer sourced from you main LDAP server configuration file:

grep -F -e univention-corporate-client.schema /etc/ldap/slapd.conf

As always make backups first and follow the referenced article for more details.

[pp303]

Hi pmhahn

Coming back to this after a long time. Followed your suggestions and the linked schema removal instructions.

At step 8 of the linked schema removal guide I get the following errors running slapschema:

# slapschema
66cee445 UNKNOWN attributeDescription "UNIVENTIONCORPORATECLIENTUSERWINDOWSTERMINALSERVER" inserted.
66cee445 UNKNOWN attributeDescription "UNIVENTIONCORPORATECLIENTSESSIONSCRIPT" inserted.
66cee445 UNKNOWN attributeDescription "UNIVENTIONCORPORATECLIENTSESSIONNAME" inserted.
66cee445 UNKNOWN attributeDescription "UNIVENTIONCORPORATECLIENTIMAGENAME" inserted.
66cee445 UNKNOWN attributeDescription "UNIVENTIONCORPORATECLIENTIMAGESERVER" inserted.
66cee445 UNKNOWN attributeDescription "UNIVENTIONCORPORATECLIENTSOFTWAREUPDATEINSTALLLIST" inserted.
66cee445 UNKNOWN attributeDescription "UNIVENTIONCORPORATECLIENTBOOTIMAGE" inserted.
66cee445 UNKNOWN attributeDescription "UNIVENTIONCORPORATECLIENTBOOTVARIANT" inserted.
66cee445 UNKNOWN attributeDescription "UNIVENTIONCORPORATECLIENTBOOTREPARTITIONING" inserted.

Definitely there are no LDAP entries using any objectclasses or attributes. The steps 2,3,4 show nothing remaining.

Looking around for that error I see there is this UCS bug from a while ago regarding MDB storage:

https://forge.univention.org/bugzilla/show_bug.cgi?id=45571

(Edit: hah I see that is your bug report now)

As suggested near the end is it because there are still references in the MDB file? Would a full dump/reload therefore be the only way to remove the schema attributes?

Given my original issue was the diagnostic error, its suggested solution was to “register the schema files” (see screenshot below) I’m now wondering if its easier to register that to clear the error and carry the schema forward.

With the future 5.2 upgrade I don’t suppose there should be an issue bringing the schemas along for the ride? AD/S4 won’t let you remove schemas for example.

[pp303]

Just a final update on the thread so it isn’t left dangling, I registered the schema files as per the diagnostic as I didn’t feel like messing with the MDB and will see how the upgrade goes.