UCS 3.1 - opsi depotserver in anderem Subnet

[SirTux]

Hallo,

ich wollte zusätzlich zum Hauptopsi einen Depotserver installieren. Leider konnte er den Configserver wohl nicht finden und ist daher leider selber zu einem Configserver geworden. Ich vermute das liegt daran, daß sie nicht im selben Subnet sind?

Auszug aus join.log

Code: Alles auswählen

^[[0;32;40m[5] [Sep 24 19:17:37] Creating base path: '/var/lib/opsi/config' (File.py|222)^[[0;0;0m
^[[0;32;40m[5] [Sep 24 19:17:37] Try to find a Configserver. (opsi-setup|2687)^[[0;0;0m
^[[0;32;40m[5] [Sep 24 19:17:37] Getting current system config (opsi-setup|79)^[[0;0;0m
^[[0;33;40m[4] [Sep 24 19:17:37] Failed to get vendor/device id for network device eth0 (Posix.py|425)^[[0;0;0m
^[[0;32;40m[5] [Sep 24 19:17:37] System information: (opsi-setup|129)^[[0;0;0m

Wie kann man denn dem Depotserver bei seiner suche helfen?

[SirTux]

Ich hab mal eben das Joinscript überflogen. Die Suche scheint ja über den LDAP zu gehen. Der Haupt-Opsi hat aber wie es sein sollte die objectClass: opsiConfigserver.

[ueluekmen]

Hi,

welche Paket-Versionen von opsi setzt du ein (Configserver und neuer Server)? Hast du mal die join-Logs gecheckt? Welche Domain-Rolle hat der neue Server?

Beim Einsatz von UCS raten wir dringend zu einem entsprechenden Supportvertrag, da diese Installation immer eine besondere Herausforderung stellen. Aber ich habe dir das bestimmt schon ein paar mal geschrieben. Bitte nicht übel nehmen, aber Werbung machen, muss gestattet sein .

Grüße aus Mainz

[SirTux]

Hallo,

die Paketversionen sind bei beiden die aktuelle. Und beide sind DC Slave. Die Feststellung des Configservers geht wohl anscheinend über univentionService: OpsiConfigserver und nicht über die objectclass. Dies wurde bei dem neuen Opsi jetzt gesetzt, der alte hat diesen Eintrag nicht. Über UMC läßt sich dieser leider auch nicht vornehmen.

EDIT: Das liegt wohl daran, daß es kein univentionService-Object namens OpsiConfigserver cn=services,cn=univention gibt.

Was einen Support-Vertrag angeht, der ist bei dem Hobby leider nicht drin

Grüße

[ueluekmen]

Hi,

das klingt aber so, als ob du den "echten" Configserver erst später aktualsiert hast. Das sollte man bei UCS nie machen. Es ist immer wichtig, dass der Configserver immer als erstes aktualisiert wird. Und wenn man den Configserver auf einem Slave betreibt, muss man immer

Code: Alles auswählen

univention-run-join-scripts

ausführen, deshalb verwenden die meisten nach wie vor eher den Backup-Server als Opsi-Configserver, die verhalten sich ja bekanntlich anders als Slaves.

Dieser service-Eintrag wurde eingeführt, damit trotz eines eigenen opsi-Backends (Abkündigung von opsi-ucs-ldap-backend) eine automatische Registrierung der Depots beim Join möglich ist.

Am einfachsten ist, du versuchst per udm delete erst mal den kaputten Eintrag raus zu löschen.

Wenn dir das geglückt ist, würde ich auf den "echten" Configserver das univention-run-join-scripts ausführen und danach kontrollieren, ob er sich selber als Configserver fühlt. Danach würde ich das selbe beim neuen Depotserver versuchen, dass sollte dein Problem beheben.

[SirTux]

Also beim Configserver wurden eigentlich alle Joinscripts ausgeführt. Nach dem Upgrade auf UCS 3.1 wurde er sogar rejoint. Und er lief bis jetzt eigentlich tadellos und ist seitdem immer aktuell gehalten worden.
Also ich habe jetzt schon diesen Weg eingeschlagen: Ich hab einen Service-Eintrag angelegt, dann hab icch mit udm den Configserver-Eintrag am neuen Server entfernt und bei dem richtigen hinzugefügt. Momentan läuft ein rejoin des neuen Servers.

[SirTux]

Also jetzt läuft der neue Server als Depotserver

Was mich jetzt noch interessiieren würde, ist ob überhaupt unter univention/services so ein Service--Objekt angelegt wird. Denn wenn dies nicht vorhanden ist sieht man in der UMC nur ein leeres Feld, was dann vielleicht ausversehen mal gelöscht wird.

Auf jeden Fall vielen Dank für die Unterstützung

[SirTux]

Hm leider hat der Depotserver noch Probleme mit den Netbootprodukten. Zum einen friert die Opsi-GUI ein, wenn ich ein Netbootprodukt auf setuo setze (nur bei diesem Depotserver, beim Configserver nicht). Nach einem Neustart der GUI setht das Produkt auf setup. Die pxe-Konfiguration existiert dann erst nach einem Reboot des Servers.
Egal wie dann ein Netbootprodukt ausgewählt wird, sobald dieses gestartet wird passiert nichts weiter. Zumindest hwinvent sollte ja nicht länger als 10 min dauern. Und bei win7-x64 kommt sogar nur bis zu "Öffne Depotserver--Verzeichnis". hwinvent kommt ja wenigsten noch weiter bis zu "starte hwinvent.py"

[n.wenselowski]

Hallo SirTux,

welche Version des Configed wird verwendet, welche Java-Version wird verwendet und wie wird der Configed geöffnet?

Das Depot-Server-Verzeichnis sollte er dann ja über de Depot-Server bekommen.
Kommt bei dem denn eine Anfrage an?

ich würde vermuten, dass die Netzkonfiguration den Clients Probleme macht.


Gruß

N. Wenselowski

[SirTux]

Hm genutzt wird vermutlich openjdk 6 und gestartet wird der aktuelle Configed über Webstart.
Aber ich denke, daß zumindest der erfolglose Netinstall an den Berechtigungen liegt. Denn es gibt ebenfalls Probleme bei Localboot-Produkten. Und diese sind darauf zurückzuführen, daß sich Dateien im Opsi-Share unter Windows nicht ausführen lassen. Ein "opsi-setup --set-rights" bringt da leider auch keine Linderung. Ich werd mir mal die Freigabe-Optionen in der UMC näher anschauen