Heutiges Problem – UCS nach Update meldet fehlgeschlagene Join-Skripts.
Mögliche Maßnahmen in der Reihenfolge der Schwere:
Mit
udm settings/udm_syntax list
prüfen wir mal den Zustand:
root@kopano01:~# udm settings/udm_syntax list
DN: cn=app_syntax,cn=udm_syntax,cn=univention,dc=test,dc=local
active: TRUE
data: langer-wert
filename: app_syntax.py
name: app_syntax
package: univention-appcenter
packageversion: 8.0.11-146A~4.4.0.202103041132
ucsversionend: 5.99-0
ucsversionstart: 4.4-0DN: cn=univention-virtual-machine-manager-schema,cn=udm_syntax,cn=univention,dc=test,dc=local
active: FALSE
data: langer-wert
filename: univention-virtual-machine-manager-schema.py
name: univention-virtual-machine-manager-schema
package: univention-virtual-machine-manager-schema
packageversion: 9.0.2-15A~4.4.0.202103041346
ucsversionend: 5.0-99
ucsversionstart: 4.4-0
prüfen, ob Module nicht registriert wurden. Das deckt sich in der Regel mit der Übersicht der nicht erfolgreichen Join-Skripts aus der UCS-Oberfläche:
udm settings/udm_syntax modify –dn=“cn=app_syntax,cn=udm_syntax,cn=univention,dc=test,dc=local“ –set active=TRUE
Mit diesem Befehl wird manuell das Modul auf aktiv gesetzt. Reicht oft und join-script läuft dann durch. Wenn nicht
udm settings/udm_syntax remove –dn=“cn=app_syntax,cn=udm_syntax,cn=univention,dc=test,dc=local“
Wenn das auch noch nicht hilft, im LDAP-Baum, die faulen Einträge löschen.
Faul sind jene, die beim ausführen des Skripts, angemeckert werden. Z.B:
cn=univention-app,cn=ldapschema,cn=univention
cn=66univention-appcenter_app,cn=ldapacl,cn=univention
cn=appcenter/app,cn=udm_module,cn=univention
Zusätzlich kann im jeweiligen Modul usw, ein Haken gesetzt werden für „aktiv“.
Falls das auch nichts bringt, im LDAP prüfen, ob vll. das Skript zwar erfolgreich war, aber „nur“ am Ende die Aktivierung scheitert.
univention-ldapsearch -b cn=univention-virtual-machine-manager,cn=ldapschema,cn=univention,$(ucr get ldap/base)
Ausgabe muss jeweils die infos im groben enthalten, die man in der UCS-Gui, auch pro Modul sieht. Also SchemaData, Versionen, und der wichtige Haken, aktiviert.
Sind alle Daten dort, hat es das Join-Script nur nicht geschafft , im LDAP das Attribut
univentionLDAPSchemaActive: FALSE
auf univentionLDAPSchemaActive: TRUE zu setzen.
Das lässt sich manuell nachholen, wenn man sich 100% sicher ist, dass die Daten im LDAP auch schon wirklich vorhanden sind. Textdatei anlegen auf dem UCS-System per SSH/Konsole mit folgendem Namen und Inhalt:
testme.ldap (…)
dn: cn=univention-virtual-machine-manager,cn=ldapschema,cn=univention,dc=test,dc=local
changetype: modify
replace: univentionLDAPSchemaActive
univentionLDAPSchemaActive: TRUE
Finale Änderung dann durchführen mit
ldapmodify -h $(ucr get ldap/master) -p $(ucr get ldap/master/port) -D cn=admin,$(ucr get ldap/base) -y /etc/ldap.secret -f testme.ldif
Jetzt ist das LDAP auf dem aktuellen Stand. Abschließend muss nur noch in den Join-Skripten der Block auskommentiert werden, der das ständig versucht und immer scheitert. In /usr/lib/univention-install/
jeweilige Datei schnappen und mit Rautezeichen Blöcke auskommentieren. Z.B:
@page { size: 21cm 29.7cm; margin: 2cm } p { margin-bottom: 0.25cm; line-height: 115%; background: transparent }
#ucs_registerLDAPExtension „$@“ \
# –ucsversionstart „4.4-0“ –ucsversionend „5.99-0“ \
# –schema /usr/share/univention-appcenter/univention-app.schema \
# –acl /usr/share/univention-appcenter/66univention-appcenter_app.acl \
# –udm_module /usr/share/univention-appcenter/app.py \
# –udm_syntax /usr/share/univention-appcenter/app_syntax.py || die
Abschließend das Join-Skript erneut ausführen.