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=yesDies 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