UCC 2.1 - 3.0 upgrade failing due to missing public key for packages

Linux Clients
,
7

I can get slapd to start on the DC backup by removing “univentionCorporateClientCurrentBootImage” from line 189 of slapd.conf ACL, however any future updates (eg with 4.1 errata 435 today) seem to try and reinstall that attribute and slapd fails on startup again during the postinstall scripts in dpkg.

Edited: Some more details:

  • /usr/share/univention-corporate-client-schema/univention-corporate-client.schema exists on the master but does not contain attribute “univentionCorporateClientCurrentBootImage”.

  • The above schema is getting replicated to the DC backup in /var/lib/univention-ldap/schema.conf but as it does not contain “univentionCorporateClientCurrentBootImage” I get the error.

  • Running dpkg --configure slapd on the DC backup attempts to re-introduce the slapd.conf containing “univentionCorporateClientCurrentBootImage”

  • /usr/share/univention-corporate-client-schema/univention-corporate-client.schema exists on the DC backup and contains the “univentionCorporateClientCurrentBootImage” attribute

  • dpkg shows that univention-corporate-client-schema is at version 3.0.1-8.91.201507141444 on the DC master and 4.0.0-6.98.201608151412 on the DC backup.

  • running univention-upgrade on all systems (master/backup/member) says nothing to do now.

So the timeline seems to be:

  1. upgrade UCC 2.1 to 3.0 on member server (it asks for passwords for DC master and backup - I assume to update LDAP and copy files?)
  2. Upgrade fails due to incorrect package signatures
  3. LDAP left in half configured state on DC backup. Is DC Master not configured at all (hence old UCC schema replicating from the master)?

I guess I could replace the /usr/share/univention-corporate-client-schema/univention-corporate-client.schema manually on the master, but I’m unsure of the state of the directory between the master and backup.

By this point should I be uninstalling and reinstalling the UCC app to ensure the LDAP schema is consistent on both DCs?

Are the removal scripts likely to encounter issues due to this inconsistent state?

Hope the signing mistake won’t happen again, this has been frustrating!