Opsi4ucs problem auf einem UCS 3.1 master

german

#1

Hallo,

wir haben ein kleines Problem bei der Integration von opsi4ucs auf UCS 3.1 Systemen. Das Problem zeigt sich wie folgt:

Es wird im Join-Skript eine Gruppe per udm angelegt. Diese Gruppe wird etwas weiter im Skript auch schon zum Anlegen von Service-Usern verwendet, dort als PrimaryGroup Attribut.

Soweit funktioniert das Skript noch ganz gut, etwas weiter untern brechen dann weiterführende Skripte ab, da es angeblich diese Gruppe nicht gibt. Führt man das selbe Join-Skript noch mal aus, läuft es sauber durch.

Dieses Phänomen hatten wir schon mal.

UCS 2.2.x -> kein Problem
UCS 2.3.x -> gleiches Problem mit der Gruppe
UCS 2.4.x -> kein Problem
UCS 3.0.x -> kein Problem
UCS 3.1.x -> gleiches Problem mit der Gruppe

Wir haben versucht diese Sache näher zu untersuchen. Wir haben zunächst mal angenommen, dass es eventuell am nscd Serivce liegen könnte. Dort werden aber in der Standardkonfiguration nur User und Hosts gecached, nicht aber die Gruppen. Auch ein Flush auf nscd brachte keine Besserung.

Also haben wir folgenden Dirty-Hack ins join-Skript gebaut:

set +e $VERBOSE && echo "Check for opsi fileadmingroup." getent group $fileadmingroup >/dev/null 2>/dev/null if [ $? != 0 ]; then for i in 1 2 3 do getent group $fileadmingroup >/dev/null 2>/dev/null if [ $? == 0 ]; then break else $VERBOSE && echo "Check for opsi fileadmingroup failed, Waiting 5 sec to retry." sleep 5 fi done getent group $fileadmingroup >/dev/null 2>/dev/null if [ $? != 0 ]; then $VERBOSE && echo "Check for opsi fileadmingroup failed. Join-Script will be fail." fi fi set -e

Ergebnis dieses Hacks auf UCS 3.0 sieht man keinen einzigen retry, bei UCS 3.1 sieht die Ausgabe so aus:

Check for opsi fileadmingroup. Check for opsi fileadmingroup failed, Waiting 5 sec to retry. Check for opsi fileadmingroup failed, Waiting 5 sec to retry. Check for opsi fileadmingroup failed, Waiting 5 sec to retry. [5] [Feb 04 15:23:11] Creating base path: '/var/lib/opsi/config' (File.py|222) ...

Das ist nicht nur unschön, sondern wahrscheinlich auch nicht 100% zuverlässig. Wir bitten daher um Unterstützung, woran könnte das liegen und wie können wir dieser Sache entgegenwirken? Das Testsystem ist ein UCS3.1 Master mit dem letzten Software (Errata) Stand, der momentan verfügbar ist.

Viele Grüße
opsi4ucs-Team


#2

Ab UCS 3.1 verwenden wir aufgrund von diversen Problemen keinen nscd mehr für die Gruppenauflösung. Ein Skript sorgt für den Dump der Daten in eine lokale Datei: /usr/lib/univention-pam/ldap-group-to-file.py und /var/lib/extrausers/group.

Das Skript wird vom listener aufgerufen, nachdem die Gruppe aufgerufen wurde. Das dauert anschließend ca. 15 Sekunden, bis die Gruppe per getent group aufgelöst werden kann.

Sie können entweder die 15 Sekunden warten oder das Tool /usr/lib/univention-pam/ldap-group-to-file.py einmal aufrufen.

Ich hoffe das hilft weiter.

Viele Grüße
Stefan Gohmann


#3

Hallo Herr Gohmann,

vielen Dank für die prompte Antwort. Das erklärt an der Stelle zwar nicht, warum das mal bei der einen UCS Version klappt und mal bei einer anderen nicht. Aber ein Skript auf zu rufen gefällt mir persönlich besser, als mit sleeps zu hoffen, dass es klappt.

Ich werde das join-Skript für die neuen Pakete noch mal umbauen und melde mich ggf. nochmal. Dennoch würde mich hier gerade interessieren, ob das ein Skript ist, welches nur auf dem Master existiert/funktioniert oder ob man das auf einem Backup- und einem Slave-Server genauso machen kann. Denn opsi4ucs lässt sich auf allen diesen Server-Rollen installieren.

Grüße aus Mainz


#4

[quote=“opsi4ucs”]
vielen Dank für die prompte Antwort. Das erklärt an der Stelle zwar nicht, warum das mal bei der einen UCS Version klappt und mal bei einer anderen nicht. Aber ein Skript auf zu rufen gefällt mir persönlich besser, als mit sleeps zu hoffen, dass es klappt.[/quote]

Meine Vermutung ist, dass es vorher ein “zufälliges” NSCD Problem war.

[quote=“opsi4ucs”]
Ich werde das join-Skript für die neuen Pakete noch mal umbauen und melde mich ggf. nochmal. Dennoch würde mich hier gerade interessieren, ob das ein Skript ist, welches nur auf dem Master existiert/funktioniert oder ob man das auf einem Backup- und einem Slave-Server genauso machen kann. Denn opsi4ucs lässt sich auf allen diesen Server-Rollen installieren.[/quote]

Das Skript kann auf allen Systemrollen ausgeführt werden.

Viele Grüße
Stefan Gohmann