[SOLVED] register-depot unattended scheitert

[NorbertKoch]

Hallo zusammen,
ich bin gerade beim Einrichten eines Depotservers.
Ubuntu 20.04 LTS,opsi ist installiert und die mysql-Datenbank eingerichtet.
Jetzt bin ich am Punkt den Depot-Server mit unserem Config-Server zu verbinden.

Der Aufruf der unattended-Registrierung läuft anfangs gut, solpert dann aber beim Verbinden über 4447/rpc:

[5] [2021-09-30 13:37:22.211] [ ] Getting current system config (opsisetup.py:95)
[5] [2021-09-30 13:37:22.305] [ ] System information: (opsisetup.py:111)
[5] [2021-09-30 13:37:22.306] [ ] distributor : Ubuntu (opsisetup.py:112)
[5] [2021-09-30 13:37:22.306] [ ] distribution : Ubuntu 20.04.3 LTS (opsisetup.py:113)
[5] [2021-09-30 13:37:22.306] [ ] ip address : 192.168.150.125 (opsisetup.py:114)
[5] [2021-09-30 13:37:22.306] [ ] netmask : 255.255.255.0 (opsisetup.py:115)
[5] [2021-09-30 13:37:22.306] [ ] subnet : 192.168.150.0 (opsisetup.py:116)
[5] [2021-09-30 13:37:22.306] [ ] broadcast : 192.168.150.255 (opsisetup.py:117)
[5] [2021-09-30 13:37:22.306] [ ] fqdn : opsidepot-sylt.opsi.intern.zz (opsisetup.py:118)
[5] [2021-09-30 13:37:22.306] [ ] hostname : opsidepot-sylt (opsisetup.py:119)
[5] [2021-09-30 13:37:22.306] [ ] domain : opsi.intern.zz (opsisetup.py:120)
[5] [2021-09-30 13:37:22.306] [ ] win domain : WORKGROUP (opsisetup.py:121)
[5] [2021-09-30 13:37:22.306] [ ] Connecting to config server '192.168.10.121:4447/rpc' as user 'adminuser' (opsisetup.py:459)
[4] [2021-09-30 13:37:27.322] [ ] Connecting to '4447/rpc' did not succeed after retrying. (HTTP.py:446)
[3] [2021-09-30 13:37:27.322] [ ] [Errno -2] Name or service not known (opsisetup.py:1031)

Die Firewallregeln zwischen den Subnetzen (192.168.150.0/23=Das Netz in dem der Depotserver ist UND 192.168.10.0/23=Das Netz in dem der Config-Server steht) passen: Ich erreiche von einer Windows-VM im 150er Subnetz ohne Probleme die 192.168.10.121.4447 (des opsi-Server) und kann mich einloggen. Der Port ist also offen.
Versuche ich mich auf dem externen Depotserver aus dem 150er Subnet zu verbinden sehe ich zwar auch die Loginfelder, kann mich aber nicht einloggen; ich denke, die Useraccounts passen noch nicht.

Kann das sein?

Was dagegen spricht: Ich melde mich ja beim registrieren am opsi-Server im 10er Subnet an; und das funktioniert ja auch. Oder findet ein Handshakre der beiden Server über den 4447er-Port statt und alle User müssen auf allen Seiten existieren?

[mattiasmab]

Versuche ich mich auf dem externen Depotserver aus dem 150er Subnet zu verbinden sehe ich zwar auch die Loginfelder, kann mich aber nicht einloggen; ich denke, die Useraccounts passen noch nicht.

Dies verstehe ich gar nicht, denn man loggt sich stets beim Configserver ein und nicht an den Depots?!

Wenn ich dich richtig verstehe, hast du irgendwas alla

Code: Alles auswählen

opsi-setup --register-depot --unattended '{"address": "config.server.address:4447/rpc", "username": "adminuserinopsi", "password": "pwoftheuser"}'

probiert und das lieferte die Logeinträge, die gelistet worden sind? Schon einmal manuell probiert - ohne unattendet? Ohne das ":4447/rpc" probiert (mich irritiert die vorletzte Zeile und in der GUI gibt man das auch ohne an und auch im Code steht an der Stelle nur FQDN - lediglich im JSONRPCBackend wird die übergebene Adresse analysiert was mangels zu niedrigem Loglevel nicht sichtbar ist und in der HTTP.py wird eigentlich der Host und nicht Port/Baseurl in der Meldung ausgegeben - also sehr sehr verdächtig)?

Ansonsten - kann der Configserver auch von dem Depotserver aus aufgerufen werden (curl, wget, ...)? Da OPSI eigentlich fast überall FQDNs nutzt - auch wenn es diese nicht wirklich immer nutzt - wäre auch interessant, ob der FQDN des ConfigServers vom neuen Depotserver aufgelöst werden kann (reine Spektulation). Widerspricht zwar der Windows-VM-Aussage, aber sind "networks" oder "admin-networks" am Config-Server eingestellt?

Am besten wird es übrigens sein, das ganze mit einem höheren Loglevel zu starten (z.B. "-l 7" ergänzen), damit die diversen Debug-Meldungen einen genaueren Einblick liefern wann es evtl. schief lief.
P.S. Schuldige die vielen Fragen als "Antwort"...

[NorbertKoch]

Hallo Mattias,
klar muss man viel fragen um zu helfen. Insofern überhaupt kein Problem; außerdem hilft es auch mir weiter, denn durch gezielte Fragen kann man auch viel dazulernen.
Also, der Reihe nach:
Ja, der String sieht so (ähnlich) aus.
Auch beim manuellen bzw. grafisch gesteuerten Registrieren lieferte mir die Prozedur Fehler. Auch 4447/rpc.
Deine Idee mit der Übergabe des Ports war Gold wert. Dazu gleich mehr...

Der Configserver erreicht den Depot-Server in opsi-configed wurde er mir auch schon gelistet, da ja zumindest teilweise der Registrierungsprozess lief.
Meine FQDN-Namen für die Server passen auch und sind gegenseitig auflösbar.
Beim Config-Server habe ich keine gesonderten Settings für Networks eingetragen.

Auf die Idee, den Prozess zu loggen kam ich bisher nicht. Doof eigentlich, denn Logfiles sind allemal die vernünftigste Möglichkeit zum Debuggen. Allerdings kannte ich die Syntax zum loggen bisher nicht. Danke dafür!

So: Und jetzt zu dem, was ich getan habe:
Ich habe alle User und Gruppen angeglichen; also das, was auf dem Configserver existiert, gibt es nun auch auf dem Depotserver. Inkl. identischer Passwörter.
Heute morgen habe ich dann aufgrund Deines Tipps die unattended-Syntax ohne den Port gestartet. Und voilá: Es lief ohne Fehler durch.

Um es kurz zu machen: You made my day!
Tausend dank dafür.
Jetzt kann ich die Konfiguration des Depots vornehmen und testen.

Und wenn das klappt, gehen wir mit opsi produktiv und werden die Einweisung, mindestens das UEFI-Paket kaufen und wohl auch einen Supportvertrag abschließen.
Ich kann es nur immer wieder wiederholen: Wenn ich bedenke, wie zäh mein Einstieg in Matrix42 war (trotz dreitägiger Installation und Einweisung) und wie weit ich alleine schon im Umgang mit opsi ohne Einweisung mit Hilfe dieses Forums bin: Da liegen welten dazwischen!