Hi - the upgrade worked for my primary and backup DC. Just on the primary I had to follow the following article to get the upgrade stared → Remove legacy UDM / LDAP objects with upgrade to UCS-5.2.
In a nut-shell - I just downloaded the “chech.sh” file and:
sudo bash check.sh update_check_legacy_objects
sudo bash check.sh delete_legacy_objects
On the backup it was not needed to follow this step.
Now on the replica server, I got asked to delete as well the same “objects”:
legacy_objects:
The following objects are no longer supported with UCS 5.2:
dn: cn=24x7,cn=nagios,dc=privat-net,dc=intranet
dn: cn=WorkHours,cn=nagios,dc=privat-net,dc=intranet
dn: cn=NonWorkHours,cn=nagios,dc=privat-net,dc=intranet
They must be removed before the update can be done.
On the replica server the script “sudo bash check.sh delete_legacy_objects” is forcing an error → check.sh: Cannot get LDAP credentials from ‘/etc/ldap.secret’
I have just basic understand of linux - so no idea what is needed to get that fixed.
If you know the right commands - you will be my hero for one day
Hi @Best : The primary is already on 5.2.1 and I checked again with the check.sh script if there is anything left with “sudo bash check.sh update_check_legacy_objects” - and it is not.
Than I checked you “script” as well on the primary → univention-ldapsearch -LLL ‘objectClass=univentionNagiosTimeperiodClass’ 1.1 | sed -rne ‘s#^dn: ##p’ | while read -r dn; do udm nagios/timeperiod remove --dn “$dn”; done
Result is → unknown module nagios/timeperiod (more details below):
I tried it as root (univention-ldapsearch -LLL ‘objectClass=univentionNagiosTimeperiodClass’ 1.1 | sed -rne ‘s#^dn: ##p’ | while read -r dn; do udm nagios/timeperiod remove --dn “$dn”; done) as well on the replica-server - but I got the following message:
# sudo univention-ldapsearch -LLL 'objectClass=univentionNagiosTimeperiodClass' 1.1 | sed -rne 's#^dn: ##p' | while read -r dn; do udm nagios/timeperiod remove --dn "$dn"; done
Permission denied.
Permission denied.
Permission denied.
if the primary is already on UCS 5.2 you can instead run the following on the primary (to be able to upgrade the replica): univention-ldapsearch -LLL 'objectClass=univentionNagiosTimeperiodClass' 1.1 | sed -rne 's#^dn: ##p' | while read -r dn; do ldapdelete -D "cn=admin,$(ucr get ldap/base)" -y /etc/ldap.secret "$dn"; done
THX - looks like the blocking point is gone.
I excluded “univention-ldapsearch -LLL ‘objectClass=univentionNagiosTimeperiodClass’ 1.1 | sed -rne ‘s#^dn: ##p’ | while read -r dn; do ldapdelete -D “cn=admin,$(ucr get ldap/base)” -y /etc/ldap.secret “$dn”; done” on the primary.
I checked on the replica “sudo bash check.sh update_check_legacy_objects”.
yes always as root on UCS systems - but based on my very basic skills with linux I’m using sudo very time
FYI: Also the seconds one is currently upgrading. It looks like, that with your code (univention-ldapsearch -LLL ‘objectClass=univentionNagiosTimeperiodClass’ 1.1 | sed -rne ‘s#^dn: ##p’ | while read -r dn; do ldapdelete -D “cn=admin,$(ucr get ldap/base)” -y /etc/ldap.secret “$dn”) the blocking bits has also been removed to the second replica. Nothing came up by using “sudo bash check.sh update_check_legacy_objects”.
I have to re-join now and I beleave that also the final diagnostic check on all systems will be OK.
If yo - I will close this post here - and as mentioned above - you @Best are my hero for one day
FYI: The re-join via web-interface failed - I had to do it via root on the command line.
