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:
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 
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
(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
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):
(the search result found something - but pakets are not installed)
Via command:
(so was installed - just config has been left over)
BDC (UCS 2):
(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
Thank you in advance
I’m unable to install Kopano WebApp again via the store:
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:
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
Since you have asked in several Threads @Pepe … I just checked, and the problem that was reported to us was fixed by an App update for kopano-core with Version 8.7.25.0-2 in September 2023. If you still experience issues, it might be a different problem.
Hi DAMROSE - thank you for coming back to me.
I’m not facing an issue with the Kopano Core server - the issue is with Kopano WebApp. The server is running on Version (8.7.25.0-2) - but that does not fixed the issue on the server where the WebApp is running.
Feel free to see more details in my other post:
Anyway - but let’s assume it would be something on the Server where Kopano Core is installed - what is it that can do to get it fixed?
I’m happy for every solution.
Kind regards
You need to get in contact with the App Provider, they have to provide an update which Univention then releases to the App Center
THX for feedback - that is an interesting answer.
I asked already in the past Kopano support as well if they can assist. There answer was - I have to contact Univention support. Sound a bit like "support Ping - Pong.
If I would be Univention - I would have an interest to have the primary announced apps up and running as announced on my own webside.
I take the answer (officially or not) as - Univention will not support Kopano any longer. If you have an issue - help yourself.
Comparing the support at the time I started with Univention (2017) to today - degraded
I’m missing the customer focus and solution orientation.
Anyway
I am sorry that you had bad experiences with UCS.
I could confirm that the installation of Kopano Core and Webapp work on a testsystem. I do not have time to debug your problem here in the forum. If you have a support contract, please get in contact with our support.