• 08621 - 9 88 30 88

Master did not mark the extension object active within 180 seconds univention

Voncubewerk

Master did not mark the extension object active within 180 seconds univention

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-0

DN: 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.

Über den Autor

cubewerk administrator