Fragen zu UCS 3.0 für opsi 4.0.1 integration

german

#1

Hallo zusammen,

wir versuchen opsi 4.0.1 für UCS 3.0 zu integrieren und sind auf diverse Probleme gestoßen, die wir ohne Unterstützung für UCS nicht alleine gelöst bekommen. Um diesen Thread zu verstehen, braucht man etwas Hintergrundwissen, für alle die opsi bzw. opsi4ucs interressant ist, gibt es nähere Informationen unter: opsi.org

Nun zu den angesprochenen Problemen, die wir bei unseren ersten ausgeweiteten Tests mit einem UCS 3.0 System festgestellt haben (Das UCS ist ein UCS 3.0 Master System mit univention-samba4, so ziemlich Out-Of-The-Box nach der Installation über die DVD.):

Problem 1:
Wir benötigen einen user pcpatch welche die uid 992 und die primäre Gruppe pcpatch und das Heimatverzeichnis /var/lib/opsi hat.
Dieser user muss sich sowohl per ssh einloggen können als auch (und vor allem) samba shares mounten können.

Auf UCS 2.x haben wir diesen user so eingerichtet (natürlich nicht mit festen passwort):

udm users/user create $@ \ --position="cn=users,$ROOT_DN" \ --set username="pcpatch" \ --set description="opsi-pseudo user" \ --set unixhome="/var/lib/opsi" \ --set uidNumber="992" \ --set primaryGroup="cn=pcpatch,cn=groups,$ROOT_DN" \ --set lastname="pcpatch" \ --set password="linux123" \ --set overridePWLength=1 \ --ignore_exists

Auf einem UCS 3.0 mit samba4 ist der user dann zwar sichtbar, kann sich aber weder per ssh einloggen noch einen samba share mounten.

Mit welchen Kommandozeilen Befehl(en) können wir den user unter UCS 3 einrichten, so das er die benötigten Rechte hat ?

Problem 2:
Der opsiconfd Benutzer (Benutzer des opsi-Webservice) muss Abfragen ins LDAP stellen dürfen. Dies wird benötigt, um die opsiadmin-Gruppe und Ihre Mitglieder fest zu stellen, da ansonsten kein Login ermöglicht werden kann.

Bei UCS 2.x war das LDAP noch für jeden (zumindest teilweise) lesbar. Dies wurde in UCS 3 Defaultmäßig verboten. Wir haben auf unserem Testsystem erst mal folgenden Quickfix realisiert:

ucr set ldap/acl/read/anonymous=yes

Dies sollte aber durch eine richtige Lösung ersetzt werden.
Frage: Wie kann man über die Kommandozeile, zum Beispiel über ucr den opsiconfd Benutzer (Systemuser) dieses Recht geben und die oben genannte Option auf Default (no) zu belassen?

Weitere Anregungen zur Diskussion:
Im Zuge der Tests und mit Hintergrund auf die Abkündigung des LDAP-Backends von opsi, wird aus unserer Sicht das join-Skript-Verfahren nicht mehr benötigt. Unser Ziel ist es aus Abwärtskompatibilität das 99opsi4ucs.inst Skript für UCS < 3 zu behalten und für UCS 3 Systeme ein neues Verfahren, welches sich an das eigentliche opsi-depotserver Paket anlehnt. Vorstellbar wäre dann eine Funktion wie:
opsi-setup --auto-configure-ucs, welches gezielt nur auf UCS >= 3 Servern ausgeführt wird. Das Integrationspaket opsi4ucs würde es dann aber trotzdem nach wie vor geben. Das opsi4ucs-ldap-schema Paket würden wir so bauen, dass es sich auf einem UCS >= 3 System nicht mehr installieren lässt. Es sei denn, aus Ihrer Sicht spricht etwas dagegen so einen Umbau durch zu führen.

Und zum Schluss noch eine Frage: Ist es vorgesehen, dass ein direktes Upgrade von UCS 2.4.x nach UCS 3.0 möglich ist? Wenn ja, wie sieht dort der genaue Weg aus? Diese Frage ist für uns wichtig, da wir das Upgrade mit Blick auf eine laufende opsi-Installation testen und verifizieren müssen, bevor wir die neuen Integrationspakete freigeben können.

Wir bedanken uns schon mal im voraus für die Beantwortung unserer Fragen bzw. Anfragen.
Grüße
Das uib-opsi4ucs-Team


#2

Hallo,

Problem 1:
Die SSH Anmeldung auf Domain Controllern ist “normalen” Benutzern in UCS 3.0 Neuinstallationen standardmäßig verboten. Hier könnten Sie über die “auth/” UCR-Variablen generellen Zugriff erlauben oder alternativ nur den “pcpatch” Benutzer freischalten, z.B.:

ucr set auth/sshd/user/pcpatch=yes

Die Samba-Anmeldung ist nicht möglich da es sich bei dem Benutzer “pcpatch” um einen standard AD-Benutzer handelt der derzeit vom Samba4-Connector nicht synchronisiert wird . Eine entsprechende Erweiterung des ignore_filter wurde mit [bug]17756[/bug] umgesetzt.

Generell sollten Sie hier noch einmal die Verwendung einer uidNumber < 1000 überdenken. Da diese UIDs für Systembenutzer reserviert sind (adduser --system), kann der UDM nicht prüfen ob bereits ein Benutzer mit der angegebenen uidNumber auf einem System der UCS-Domäne existiert. Tendenziell ist es daher nicht unwahrscheinlich dass Sie dadurch auf einem System die UID doppelt belegen.

Problem 2:
Hier könnte entweder der Account eines LDAP-Benutzers für die Abfragen verwendet werden, alternativ könnte der Dienst den Host-Account des Rechners (UCR ldap/hostdn) verwenden auf dem er ausgeführt wird. Dazu müsste er Zugriff auf die Datei /etc/machine.secret erhalten.

Bzgl. der Anpassungen am Join-Script finden Sie unter [wiki]Join-Skript-Bibliothek[/wiki] in unserem Wiki einige Hinweise wie Sie die Versionen der Join-Scripte auswerten können um so z.B. bei einem Update entsprechend reagieren zu können. Die UCS-Version kann wie gewohnt über die entsprechenden UCR-Variablen abgefragt werden (version/version, version/patchlevel, version/security-patchlevel, version/erratalevel).
Wie bei UCS üblich ist natürlich auch ein direktes Update von UCS 2.4-4 nach UCS 3.0 möglich und müsste durch Ihre Integrationspakete entsprechend abgewickelt werden können.

Mit freundlichen Grüßen
Janis Meybohm


#3

Hallo,

zunächst mal Danke für die Antwort.

Zur Frage 1:
Den Teil der Antwort

habe ich nicht verstanden.
[bug]17756[/bug] bezieht sich doch auf UCS 2.x.
Also was muss ich auf UCS 3.0 mit Samba 4 tun damit ich auf der Kommandozeile einen user pcpatch als Mitglied der Gruppe pcpatch anlegen kann der einen samba share mounten kann ?
Auch wenn wir pcpatch eindeutig als system user sehen und er deshalb üblicherweise eine uid < 1000 habe sollte suchen wir nach einer Lösung. D.h. wir sind für jeden Vorschlag der das Problem löst aufgeschlossen.

Wir bedanken uns schon mal im voraus für die Beantwortung unserer Fragen bzw. Anfragen.
Grüße
Das uib-opsi4ucs-Team


#4

Genau, der Bug bezieht sich auf UCS 2.4. Dort wurde die Konfigurationsdatei für die AD Connector Synchronisation so erweitert, dass der Benutzer pcpatch nicht von UCS nach AD synchronisiert, sondern ignoriert wird. Wenn ich den Bug richtig verstehe, dann gab es ein Problem beim Anlegen des Benutzer pcpatch auf AD Seite.

In UCS 3.0 basiert die Synchronisation der Daten zwischen dem Samba 4 LDAP und OpenLDAP auf dem AD Connector. Damit wird der Benutzer pcpatch auch nicht im Samba 4 LDAP angelegt und Sie können sich nicht an Samba 4 mit diesem Benutzer authentifizieren.

Eine Möglichkeit wäre, dass Sie testen, ob Sie das Connector Mapping so anpassen können, dass der Benutzer nicht mehr ignoriert wird. In der Datei /etc/univention/connector/s4/mapping können Sie die folgende Zeile

ignore_filter='(|(uid=root)(uid=pcpatch)(cn=pcpatch)(CN=pcpatch)(uid=ucs-s4sync)(CN=ucs-s4sync))'

durch diese ersetzen:

ignore_filter='(|(uid=root)(uid=ucs-s4sync)(CN=ucs-s4sync))'

Anschließend können Sie den univention-s4-connector neu starten und den Benutzer anlegen. Sollte das funktionieren, so können wir die Anpassung für eine nächste UCS Version vorsehen.

Ja, problematisch ist nur, dass Sie die Nummer hart vorgeben. Wenn der Benutzer im LDAP angelegt wird, dann wird er auf alle Systeme repliziert und somit gibt es potentiell doppelte Nummern. Einfacher ist es aus meiner Sicht keine uidNumber vorzugeben, dann sucht der UDM die nächste freie und es gibt keine Konflikte.

Viele Grüße
Stefan Gohmann