Mismatched packages on Master and Backup after failed UCC upgrade

Hi all, I started this topic in the UCC forum but have not had a response on my last posts questions. I think my issues are more relevant to the UCS forum now in any case as it relates to LDAP schema issues.

Let me know if I’ve committed a faux pas posting here.

Short story is that UCC 3.0 packages were signed with wrong GPG key from previous version and I just happened to download and try the upgrade during that time (UCC server on member server, with a single Master and Backup).

It seems the debian packages upgraded successfully on the Domain Backup but failed on the Domain Master.

So now as per last post in the other thread I have the following packages on the Master:

ii  univention-corporate-client-schema      3.0.1-8.91.201507141444      all     Univention Corporate Client - LDAP schema
ii  python-univention-directory-manager-ucc 3.0.1-9.92.201507201331      all     Univention Corporate Client - UDM module
ii  ucc-management-integration              3.0.1-9.92.201507201331      all     Univention Corporate Client - integration in management system

And the following on the Backup:

ii  univention-corporate-client-schema      4.0.0-6.98.201608151412      all     Univention Corporate Client - LDAP schema
ii  python-univention-directory-manager-ucc 4.0.0-6.98.201608151412      all     Univention Corporate Client - UDM module
ii  ucc-management-integration              4.0.0-6.98.201608151412      all     Univention Corporate Client - integration in management system

Leading to one result that the Master LDAP is missing the new UCC 3.0 schema attributes (univentionCorporateClientCurrentBootImage) which fail to replicate to the Backup and slapd fails to start up on any upgrade or after any dpkg --configure slapd.

Running univention-upgrade on the Master does not bring the packages up to version 4 - it seems to think there is nothing to be done. Re-running joinscripts seems to not change anything either.

Queries:
As this is production and I’m not an LDAP expert, my main concern has been not to wreck the Master Directory.

  1. Is there a way to safely force a re-install of the UCC app across all UCS DCs? Or do I have to uninstall and reinstall the app?
  2. Is a removal likely to hit issues given the differing directory info on each DC?
  3. Or, is all I need to do to manually use univention-install to try and upgrade the packages on the Master?

Hope someone can help or give me the yay or nay on removal and reinstall of UCC.

Thanks.

Hello,

please execute the following on the UCS Master and every Backup server, that does not have to correct packages installed:

univention-app install ucc=3.0 --only-master-packages

Thanks damrose, that seems to have proceeded, and I have the same version of the packages on both systems now.

Only thing of concern was towards the end of the install I got a python traceback in red on the screen.

Will that have affected anything? Or is it as the log says only a warning? Got the same message on the DC Backup.

Thanks again.

appcenter.log shows:

5231 actions.install                  17-07-06 21:26:52 [    INFO]: done.
  5231 actions.install                  17-07-06 21:26:55 [    INFO]: Starting univention-s4-connector daemon.
  5231 actions.install                  17-07-06 21:26:59 [    INFO]: done.
  5231 actions.install.progress         17-07-06 21:26:59 [   DEBUG]: 100.0
  5231 actions.install                  17-07-06 21:26:59 [    INFO]: Processing triggers for python-support ...
  5231 actions.install.progress         17-07-06 21:26:59 [   DEBUG]: 100.0
  5231 actions.install                  17-07-06 21:27:00 [ WARNING]: Traceback (most recent call last):
  5231 actions.install                  17-07-06 21:27:00 [ WARNING]:   File "/usr/sbin/univention-pkgdb-scan", line 37, in <module>
  5231 actions.install                  17-07-06 21:27:00 [ WARNING]:     univention.pkgdb.main()
  5231 actions.install                  17-07-06 21:27:00 [ WARNING]:   File "/usr/lib/pymodules/python2.7/univention/pkgdb.py", line 577, in main
  5231 actions.install                  17-07-06 21:27:00 [ WARNING]:     return action_scan(connection, cursor, config_registry)
  5231 actions.install                  17-07-06 21:27:00 [ WARNING]:   File "/usr/lib/pymodules/python2.7/univention/pkgdb.py", line 482, in action_scan
  5231 actions.install                  17-07-06 21:27:00 [ WARNING]:     scan_and_store_packages(cursor, sysname, fake_null)
  5231 actions.install                  17-07-06 21:27:00 [ WARNING]:   File "/usr/lib/pymodules/python2.7/univention/pkgdb.py", line 417, in scan_and_store_packages
  5231 actions.install                  17-07-06 21:27:00 [ WARNING]:     cursor.execute(delete_packages, {'sysname': sysname, })
  5231 actions.install                  17-07-06 21:27:00 [ WARNING]:   File "/usr/lib/python2.7/dist-packages/pgdb.py", line 259, in execute
  5231 actions.install                  17-07-06 21:27:00 [ WARNING]:     self.executemany(operation, (params,))
  5231 actions.install                  17-07-06 21:27:00 [ WARNING]:   File "/usr/lib/python2.7/dist-packages/pgdb.py", line 291, in executemany
  5231 actions.install                  17-07-06 21:27:00 [ WARNING]:     raise OperationalError("internal error in '%s': %s" % (sql, err))
  5231 actions.install                  17-07-06 21:27:00 [ WARNING]: pg.OperationalError: internal error in '
  5231 actions.install                  17-07-06 21:27:00 [ WARNING]:   DELETE FROM packages_on_systems
  5231 actions.install                  17-07-06 21:27:00 [ WARNING]:          WHERE sysname = 'dcm1'
  5231 actions.install                  17-07-06 21:27:00 [ WARNING]:   ': SSL error: tlsv1 alert protocol version
  5231 actions.install                  17-07-06 21:27:00 [ WARNING]:
  5231 actions.install                  17-07-06 21:27:00 [ WARNING]: close failed in file object destructor:
  5231 actions.install                  17-07-06 21:27:00 [ WARNING]: sys.excepthook is missing
  5231 actions.install                  17-07-06 21:27:00 [ WARNING]: lost sys.stderr
  5231 actions.install                  17-07-06 21:27:00 [    INFO]: Unregistering component for ucc=3.0
  5231 actions.install                  17-07-06 21:27:00 [   DEBUG]: Removing repository/online/component/ucc_20160811170611
  5231 actions.install                  17-07-06 21:27:00 [   DEBUG]: Removing repository/online/component/ucc_20160811170611/localmirror
  5231 actions.install                  17-07-06 21:27:00 [   DEBUG]: Removing repository/online/component/ucc_20160811170611/server
  5231 actions.install                  17-07-06 21:27:00 [   DEBUG]: Removing repository/online/component/ucc_20160811170611/version

We have a bug report about that traceback, but it is a bit unclear to me. The logline about unregistering the component for UCC seems strange.

Is the app installed correctly on your servers by now? Is the package state in order?
univention-app info
dpkg --audit
If these show the app is installed correctly, and no packages are in a bad state, everything should be fine.

Hi damrose, it’s looking good

Master:

# univention-app info
UCS: 4.1-4 errata439
App Center compatibility: 4
Installed: dhcp-server=10.0.1 pkgdb=9 samba4=4.5 self-service=1.0 uvmm=5 uvmm-ec2=1.0
Upgradable:
root@dcm1:~# dpkg --audit
root@dcm1:~#

Backup:

root@dcb:~# univention-app info
UCS: 4.1-4 errata439
App Center compatibility: 4
Installed: radius=3.0 samba4=4.5
Upgradable:
root@dcb:~# dpkg --audit
root@dcb:~#

Member (UCC server):

root@member:~# univention-app info
UCS: 4.1-4 errata439
App Center compatibility: 4
Installed: cups=1.5.3 dhcp-server=10.0.1 samba-memberserver=4.3 ucc=3.0
Upgradable:
root@member:~# dpkg --audit
root@member:~#

Thanks again for the help. This was the blocker for a 4.2 upgrade.

Mastodon