Comparision PDC (Master) and BDC (Backup) for possible Backup-2-Master migration

Hi - I’m a bit behind the migration from 4.x to 5.x - based on the dependency of a Mattermost migration to an non UCS system.

So last weekend I started with the migration.

First system was the Master (PDC) (original based on UCS 4.2), Upgrade to the latest 4.x version (all fine) and than start of the migration to 5.0.4 (latest version).
First of all the migration was not starting based on several dependencies to unsupported 5.x UCS versions:

default_master_packages:
The Kopano App is installed in your domain.
In order to update to UCS 5.0 the Kopano Apps have to be updated to
the latest version available in UCS 4.4. Once all systems are updated
the package kopano4ucs-udm has to be removed from this server:
univention-remove --purge kopano4ucs-udm

minimum_ucs_version_of_all_systems_in_domain:
The following extensions are incompatible with UCS 5.0:
cn=63openvpn-sitetosite,cn=ldapacl,cn=univention,dc=dreger-net,dc=local: [unspecified…unspecified)
cn=univention-openvpn-schema,cn=udm_syntax,cn=univention,dc=dreger-net,dc=local: [unspecified…unspecified)
cn=univention-openvpn,cn=udm_hook,cn=univention,dc=dreger-net,dc=local: [unspecified…unspecified)

After I removed all the packets - the installation was running fine.

I tried to get the Backup (BDC) (same base-line as PDC) migrated as well - but no way. So I decided to install a fresh BDC - based on 5.x image.

The installation itself was fine - as well as the upgrade to the latest version 5.0.4.

The communication between the 5.x systems and the other UCS servers (still version 4.x) was also fine.

There are still some error messages (selftest) on PDC and BDC where I have to look into it - but in general fine.

Now I’m thinking about installating as well a second fresh 5.x UCS backup and to make the current backup to the master.

I found the following KB How To: backup2master

So I started with the first task - compare the installed packets

Command: COLUMNS=200 dpkg --list

The KB mentioned - some differences are OK - but should not be some many. I’m not a pro and have no idea what difference is OK and what not. So i started to write down the differences.
Just 5% of the list is compared - but more than 30 differences already (I will put the differences in a separate post - as mentioned 95% comparison is missing right now).

As mentioned - I have no idea what happens if I delete the differences.

FYI: Both systems are running on the same VM-host - so hardware is the same.

My present question is - what can I do to reduce the differences without killing the current PDC.

Thank you in advance

Here is the list I mentioned from PDC and BDC.

deleted - please see new diff list below

Here is the list of the second comparission:

univention-app info

PDC:

UCS: 5.0-4 errata751
Installed: dhcp-server=12.0 samba4=4.16
Upgradable:

BDC:

UCS: 5.0-4 errata753
Installed:
Upgradable:

Question: Should the apps been on the PDC installed on the BDC as well? Can’t remember how it was on the old BDC.

Hi,

concerning the difference in the packages: Most of them look like benign differences. I would have a closer look at

  • apparmor
  • debian-archive-keyring
  • gnupg

It is very much possible that you don’t need any of them. If you are not sure whether you do, then you can save the list for now, and come back to it if you find something to be missing in the future.
You can automate the comparison with the diff command.

diff --side-by-side --suppress-common-lines  file1 file2

You may have to sort the lists beforehand.

Concerning the installed apps from the app-center: It would be wise to have samba installed on the backup (if you use samba) and make a note about the dhcp server, just because it can become problematic to have multiple dhcp servers on at once.
What concerns me is that the errata level is higher on the BDC than on the PDC. As a rule of thumb the PDC should always be kept on the highest version in the domain. This is easily fixed with an upgrade on the PDC.

THX for feedback.

PDC is now on version 5.0-4 errata753.
BDC is on version 5.0-4 errata771.

Before I will continue to compare all the installed packets I would like to get away some packets/apps/fragments that are no longer uses - but still visible on the web-interface and menues.

  1. Mattermost (was installed on a member server)

  2. OpenVPN (was installed on a member server)

  3. Let’s Encrypt (was installed on a member server)

Is there an easy way (for non pros) to get these fragmenst removed?

Example:
grafik

Current diff-list based on command: diff --side-by-side --suppress-common-lines BDCList.txt PDCList.txt > PDCBDC_Dif1.txt

PDCBDC_Dif1.txt (32,5 KB)

I powered up my old BDC to see what apps/services has been installed there - and I added these apps/services to the new BDC.

BDC:

UCS: 5.0-4 errata753
Installed: dhcp-server=12.0 samba4=4.16
Upgradable:

After installation I created a new diff between the two servers PDC and BDC - but just 17 differenzen less ;-(

diff --side-by-side --suppress-common-lines BDCList.txt PDCList.txt > PDCBDC_Dif2.txt
PDCBDC_Dif2.txt (31,5 KB)

382 differnces is from my point a lot

Any idea how to reduce the differences?

Thank you in advance

I started today the systemdiganostic on PDC and BDC.
Both are comming up with the following error message:
grafik

Zertifikat https://192.168.56.114/simplesamlphp/saml2/idp/certificate konnte nicht geladen werden: HTTPSConnectionPool(host=‘192.168.56.114’, port=443): Max retries exceeded with url: /simplesamlphp/saml2/idp/certificate (Caused by NewConnectionError(’: Failed to establish a new connection: [Errno 113] Keine Route zum Zielrechner’)) Führen Sie das Join-Skript 92univention-management-console-web-server via [Modul “Domänenbeitritt”](javascript:void(0)) oder univention-run-join-scripts --force --run-scripts 92univention-management-console-web-server auf der Befehlszeile as Benutzer root aus.

The mistury is, there is no server from UCS or any other server who is using IP 192.168.56.114. Running the JOIN script didn’t fixed the issues.

Someone any idea where these message comes from and even better - how to get these massge away :wink:

Thank you in advance

Let me start with the fragments that you see from Mattermost, OpenVPN and Let’s Encrypt.
If i understand your problem correctly you see them as categories when editing some objects (users, for example). While it is possible to clean this up, it is not what i would call “easy (for non pros)”. The good thing is that this is benign. While it does not look clean, there is likely little to no functionality still active.

Regarding your diff of the installed packages. I had a quick look, and while there are a lot of packages, i would say you can savely ignore most. The following are of interest tough.

  • kopano4ucs
  • univention-s4-connector
  • univention-keycloak-client

Those indicate that the apps kopano, s4-connector, and keycloak are not yet installed on the backup. Kopano is an interesting case here. The important package is kopano-schema. Schema packages are purposefully left installed event after the removal of a package, because without them some data in the LDAP that might be left there could not be interpreted. This is why it might be that you had kopano installed at some point in the past, dont have it installed any more, but now should install its schema files on the backup anyways.

Concerning your SAML certificate:
It might be some UCR setting that points to that IP. Please run

ucr search 192.168.56.114

It searches for any apearace of the IP in either the key or the value of any UCR variable.

Also please run

univention-ldapsearch -LLL aRecord=192.168.56.114 dn

it searches for any computer object in the LDAP with the IP and prints only its DN (distinguished name).

Thank you for support - and sorry for the late feedback - I was sick.

I tested:

univention-ldapsearch -LLL aRecord=192.168.56.114 dn

on each of the UCS servers (PDC, BDC and all other UCS servers) - but with new results (blank line)

Next step was:

univention-ldapsearch -LLL aRecord=192.168.56.114 dn

grafik

(also tested on PDC and BDC - but not on the other UCS servers)

I tested it as well with a real IP and get back some more lines with a real server name. So the request (lookup) worked - just not with the relevat IP (192.168.56.114)

Any more ideas to find the “link” on the server - or in the UCS domain?

Thank you in advance

Pepe

I’m not sure if I’m getting the proint - or maybe I missed to explain something.

Kopano is used since years. Setup is as follow. Dedicated Kopano Core server (UCS 3) and a dedicated Kopano web-access server (UCS 4). Both servers are still on UCS 4.x (latest possible).
My plan was first to clean up the PDC and BDC issues and than swap BDC into PDC - or maybe first upgrade UCS 3 and UCS 4 to UCS version 5 and do the BDC to PDC switch after upgrade.

If the upgrade of the two Kopano systems would force as well the installation of all packets to PDC and BDC - I’m happy to do this task first.

You are the PROs - feel free to advice

Thank you in advance

Pepe

Concerning kobano4ucs:
Before you perform the failover (ranking your BDC up to become the PDC in the domain) please make sure that the schema package of kopano is installed. Without it it might happen that you can not start the LDAP server.

For the other packages it does not matter if you install them before or after the failover takes place.

Concerning the SAML certificate:
Please check the following

ucr search umc/saml/sp/server
ucr search ucs/server/sso/fqdn
udm saml/serviceprovider list

In non of the the 3 commands came something up who refelcted the IP 192.168.56.114
grafik
Serviceprovider_List.txt (47,3 KB)

I tried as well as mentioned in the diagnostic feedback:

univention-run-join-scripts --force --run-scripts 92univention-management-console-web-server

But nothing changed

I did an upgrade on the Kopano-Core server (UCS 3):

UCS: 5.0-4 errata798
Installed: fetchmail=6.3.26 kopano-core=8.7.25.0-1 z-push-kopano=2.6.4

But even the upgrade didn’t triggered anything on the BDC. NOTE: But the upgrade itself look good at present.

So I upgraded as well the Kopano-WebApp server (UCS 4):

UCS: 5.0-4 errata798
Installed:
(NOTE: Looks like Kopano WebApp is no longer installed - and yes - the webpage has disapeared)
But even the upgrade didn’t triggered anything on the BDC. NOTE: Kopano WebApp has been automaticly removed.

I still have no idea what paket or script I have to install to get that part fixed - so I tried to see if pakets related to “kopano4ucs” are installed on the PDC and BDC.

PDC (UCS 1):
grafik
(the search result found something - but pakets are not installed)
Via command:
grafik
(so was installed - just config has been left over)

BDC (UCS 2):
grafik
(nothing found)
Same for the cammand search - nothing found

Question 1: Do I have to "re-install the two kopano packets on the PDC again?
Question 2: Do I have to install the two kopano packets on the BDC - and if yes - how?

Sorry for all the maybe so simple questions - I’m no Linux pro :wink:

Thank you in advance

I’m unable to install Kopano WebApp again via the store:
image

grafik

What can I do?

FYI: Roll-Back via Snapshot to:

UCS: 4.4-9 errata1371
Installed: kopano-webapp=5.3.0.0-1

Hi - I installed today a fresh new UCS server based direkctly on a 5.x ISO

UCS: 5.0-4 errata803
Installed:
Upgradable:

But even there, I’m unable to installe Kopano WebApp:
image

Same error message as with the upgraded 4.x server.

Means for me - something central is blocking the installation.

Any help is more than welcome.

Looks like it is not a new issue - and the mentioned fix is not realy working:

The problems with the update from UCS 4 to UCS 5 was completely different.

As far as i understood, the Kopano maintainers prepared an App update, which is currently reviewed.

Fingers crossed that it will sooner than later fix the issue. Would like to get a server to version 5.x.

Hi - any updates to the mentioned Kopano patch? Is the patch now available?
THX

Mastodon