[GELÖST] HWINVENT PXE-Boot bleibt hängen im Boot-Menu

[luckystriker]

EDIT: Ich habe alternativ jetzt einfach das Log-Level in /etc/opsi/opsipxeconfd.conf auf 7 gesetzt. Jetzt wird mir in /var/log/opsi/opsipxeconfd.log auch alles angezeigt.

Folgendes ist die Ausgabe:
Alles wie oben, bis auf jene Stellen, welche das Backend "opsipxeconfd" dispatchen sollten.. hier steht:

[Timestamp] Ignoring backend u'opsipxeconfd': backend not available (BackendManager.py|468)

Fehlerursache gefunden!
Woran kann es denn liegen, dass er das Backend nicht findet, wenn er die anderen anscheinend doch findet? :O

VG,
Lucky

[n.wenselowski]

Hi,

Also: Ich habe den Beispielcode in mein Programm eingefügt, bekomme jedoch nur die Ausgabe des Loggers in der Console. Über den Webbrowser erhalte ich keine Ausgabe...

Du musst das Logging in eine Datei auch aktivieren: http://download.uib.de/opsi4.0/doc/html ... setLogFile
Also einmal die Ausgabedatei setzen und dann mit setFileLevel das entsprechende Log-Level.

dabei ist mir jedoch aufgefallen, dass wenn ich über die Konsole (also als Root / su) das Skript über

Code: Alles auswählen

python /path/to/magic/cgi-bin/script.py 

aufrufe, ebenfalls alles problemlos durchläuft.. also die PIPE wird erstellt, der Client inventarisiert sich komplett selbstständig.

root darf alles, www-data (oder wie er bei deinem Webserver auch heißen mag) eben nicht.
Das Getting Started zeigt wie neue User berechtigt werden können.

Falls es nicht hilft:
Was taucht im Log nach dispatching to backends auf, wenn es an das opsipxeconfd-Backend weitergeleitet wird? Schau da mal ins Log und suche nach Fehlern!

Das opsipxeconfd-Log ist hier mit 99%iger Wahrscheinlichkeit nicht die richtige Anlaufstelle, wenn es mit root-Rechten funktioniert.


Gruß

Niko

[luckystriker]

Hallo Zusammen,

meine jüngst als vergangen betrachtete Erkrankung hat mich leider wieder eingeholt. Deshalb der große Delay. Entschuldigung!

Also ich habe jetzt wie im Getting Started beschrieben einmal die Nutzer-Konfiguration nachgeschaut, und habe alles so eingerichtet wie im PDF beschrieben. Sofern ich das Script über den User root oder auch opsiconfd aufrufe, funktioniert alles... Um sicher zu gehen, habe ich testweise (! ^^) auch den Nutzer www-data in sämtliche relevanten Gruppen gesteckt... Das schafft leider auch keine Abhilfe.
Nachdem ich dann mal mein Skript mit dem korrekten Logging angepasst habe, findet sich nun ganz am Ende des Logs (der einzige ersichtliche Fehler, der Rest sieht gut aus)

Updating pxe boot configuration for client 'einClient.eine.domäne'
Sending command 'update einClient.eine.domäne'
Creating unix socket '/var/run/opsipxeconfd/opsipxeconfd.socket'
Failed to update PXE boot configuration for client 'einClient.eine.Domäne': Failed to connect to socket '/var/run/opsipxeconfd/opsipxeconfd.socket': [Errno 13] Permission denied

Das sind die letzten Zeilen... Ich tippe sehr sehr stark auf ein Berechtigungsproblem, wenn es mit nahezu allen relevanten Nutzern funktioniert bis auf den www-data Benutzer. Aber welche Berechtigung für was genau fehlt noch bzgl. des Sockets? Die "Datei" als solches wird erstellt, ist aber leer, sofern man sie mit VIM versucht zu öffnen... Hat das seine Richtigkeit, oder hat er hier schon Probleme beim schreiben/erstellen des Sockets?

Im opsipxeconfd.log sind alle das Opsipxeconfd-Backend betreffende Geschichten, die auf jenes Backend dispatchen wollen, mit bereits erwähntem

[Timestamp] Ignoring backend u'opsipxeconfd': backend not available (BackendManager.py|468)

verzeichnet, zusammen mit der Meldung, dass nun deshalb Methoden überschrieben werden und das File-Backend genutzt wird... Deshalb funktioniert es ja auch glaub ich, wenn ich den Dienst nach dem Anlegen durch das Skript neustarte... dass er dann die Backends "synchronisiert" oder so?

Bin bald echt verzweifelt..

Vielen Dank, wie immer, im Voraus, und viele Grüße!
Luckystriker


EDIT:
Vllt wäre auch noch die Information hilfreich, dass generell nach einem Neustart des opsipxeconfd-services folgendes im Log ausgegeben wird:

[Timestamp] Starting opsipxeconfd main thread (opsipxeconfd|168)
[Timestamp] Creating backend instance (opsipxeconfd|112)
[Timestamp] * BackendManager is creating BackendDispatcher (BackendManager.py|264)
[Timestamp] Backend context was set to <BackendManager()> (BackendManager.py|195)
[Timestamp] Loading dispatch config file '/etc/opsi/backendManager/dispatch.conf' (BackendManager.py|371)
[Timestamp] Trying to lock file '/etc/opsi/backendManager/dispatch.conf' (0/2000) (__init__.py|216)
[Timestamp] File '/etc/opsi/backendManager/dispatch.conf' locked after 0 millis (__init__.py|237)
[Timestamp] Trying to lock file '/etc/opsi/backendManager/dispatch.conf' (0/2000) (__init__.py|216)
[Timestamp] File '/etc/opsi/backendManager/dispatch.conf' locked after 0 millis (__init__.py|237)
[Timestamp] Read dispatch config from file u'/etc/opsi/backendManager/dispatch.conf': [[u'backend_.*', [u'file', u'mysql', u'opsipxeconfd', u'dhcpd']], [u'host_.*', [u'file', u'opsipxeconfd', u'dhcpd']], [u'productOnClient_.*', [u'file', u'opsipxeconfd']], [u'configState_.*', [u'file', u'opsipxeconfd']], [u'license.*', [u'mysql']], [u'softwareLicense.*', [u'mysql']], [u'audit.*', [u'mysql']], [u'.*', [u'file']]] (BackendManager.py|408)
[Timestamp] Loading backend config '/etc/opsi/backends/opsipxeconfd.conf' (BackendManager.py|433)
[Timestamp] Ignoring module 'OpsiPXEConfd', backend 'opsipxeconfd' (BackendManager.py|438)
[Timestamp] Loading backend config '/etc/opsi/backends/dhcpd.conf' (BackendManager.py|433)
[Timestamp] Backend context was set to <BackendDispatcher(dispatchIgnoreModules=['OpsiPXEConfd'], dispatchConfigFile=u'/etc/opsi/backendManager/dispatch-conf', context=<BackendManager()>)> (Backend.py|195)
[........]

Also schon bevor irgendetwas geschieht, scheint er sich schon vom Backend zu verabschieden, sofern ich den Log richtig interpretiere...

[luckystriker]

Keiner mehr eine Idee?

[n.wenselowski]

Hi,

Updating pxe boot configuration for client 'einClient.eine.domäne'
Sending command 'update einClient.eine.domäne'
Creating unix socket '/var/run/opsipxeconfd/opsipxeconfd.socket'
Failed to update PXE boot configuration for client 'einClient.eine.Domäne': Failed to connect to socket '/var/run/opsipxeconfd/opsipxeconfd.socket': [Errno 13] Permission denied

Das sind die letzten Zeilen... Ich tippe sehr sehr stark auf ein Berechtigungsproblem, wenn es mit nahezu allen relevanten Nutzern funktioniert bis auf den www-data Benutzer. Aber welche Berechtigung für was genau fehlt noch bzgl. des Sockets? Die "Datei" als solches wird erstellt, ist aber leer, sofern man sie mit VIM versucht zu öffnen... Hat das seine Richtigkeit, oder hat er hier schon Probleme beim schreiben/erstellen des Sockets?

Wir haben hier einen Socket - kein einfaches File. Schau dir seine Berechtigung an - darf dein User darauf zugreifen?

Alternativ: wie erstellst du das Backend? Du könntest auch mit dem API-Endpunkt des Servers kommunizieren, dann handelt opsiconfd alles für dich.
Was ist in deinem Code backend und wie instanziierst du es?

Vllt wäre auch noch die Information hilfreich, dass generell nach einem Neustart des opsipxeconfd-services folgendes im Log ausgegeben wird:

[Timestamp] Ignoring module 'OpsiPXEConfd', backend 'opsipxeconfd' (BackendManager.py|438)

Also schon bevor irgendetwas geschieht, scheint er sich schon vom Backend zu verabschieden, sofern ich den Log richtig interpretiere...

Das ist im Log des opsipxeconfd normal, damit keine Aktionen, die er ausführt, wieder an ihn weitergeleitet werden. Das würde zu einer Endlosschleife führen, weshalb das opsipxeconfd-Backend im opsipxeconfd ausgenommen wird.


Gruß

Niko

[luckystriker]

Guten Morgen,

Also die Files im Ordner /var/run/opsipxeconfd/ haben folgende Berechtigungen:

drwxrwxrwx 2 root root 80 Aug 14 08:58 .
drwxr-xr-x 33 root root 980 Aug 14 09:00 ..
-rw------- 1 root root 4 Aug 14 08:58 opsipxeconfd.pid
srwx---rw- 1 root root 0 Aug 14 08:58 opsipxeconfd.socket

Ich habe testweise probiert beide über ein chmod 777 erstmal jedem zugänglich zu machen, was bei dem .pid-File geklappt hat, jedoch bei dem .socket-File nicht. Hier blieben die Berechtigungen trotz Befehls gleich wie gezeigt.
Leider ist das Endergebnis nach wie vor ein Feststecken im Boot-Screen, die Log-Files identisch. :/
EDIT:

Hier blieben die Berechtigungen trotz Befehls gleich wie gezeigt.

Habe gerade gesehen, dass dies nach einem Neustart von "opsipxeconfd" anscheinend normal ist... ohne den Dienst neuzustarten bleiben die Berechtigungen mit "chmod 777" gesetzt und es funktioniert alles reibungslos!!! Wie schaffe ich es nun, dass die Berechtigungen nach einem Neustart des Servers nicht wieder zurückgesetzt werden?



In meinem Skript findet sich Folgendes:

Code: Alles auswählen

backend = BackendManager(dispatchConfigFile=u'/etc/opsi/backendManager/dispatch.conf', backendConfigDir='/etc/opsi/backends', extensionConfigDir=u'/etc/opsi/backendManager/extend.d')
[...]
for i in z:
    p   = p + 1
    backend.host_createOpsiClient(id=someID + '.opsi.local', ipAddress=str(p), hardwareAddress=i)
    backend.setProductActionRequest(productId="hwinvent", clientId=""+someID+".opsi.local", actionRequest="setup")

Ich weiß nicht ob es zu viel verlangt ist, aber wie müsste eine solche Kommunikation für genannten Zweck mit dem API-Endpunkt aussehen? ._.

Vielen Dank für den netten Support hier!!!
Viele Grüße
Lucky

[n.wenselowski]

Hi,

es wäre auch möglich über den Service den Zugriff zu machen, aber das hat natürlich etwas overhead.
Bevor wir diesen Weg gehen, versuche bitte mal den opsipxeconfd 4.0.7.9 aus experimental zu verwenden.
Dieser setzt Zugriffsrechte für die opsiadmin-Gruppe auf den Socket.
Wie üblich bitte auf einem Test-System probieren und am besten nicht direkt in Prod. Und nach dem Test die Repos wieder deaktivieren!


Gruß

Niko

[luckystriker]

Hallo Herr Wenselowski,

Sie und ihre Kollegen sind wahre Schätze! Es funktioniert nun alles ganz genau so wie es soll!!! Vielen vielen Dank für die nette und rasche Hilfe! Stark!

Ich setze dann den Thread auf "gelöst".

Beste Grüße
Luckystriker

[n.wenselowski]

Hallo Luckstriker,

Sie und ihre Kollegen sind wahre Schätze! Es funktioniert nun alles ganz genau so wie es soll!!! Vielen vielen Dank für die nette und rasche Hilfe! Stark!

Vielen Dank dafür

Es freut mich, dass es nun wie gewünscht klappt


Viele Grüße

Niko

[luckystriker]

Hi Niko,

Vielen Dank dafür

Nicht dafür! Ich habe zu danken.

Beste Grüße
Lucky