opsiconfd Fehler (Not authorized) und Configed hängt bei größeren Aktionen

[pago]

Liebe Gemeinde,
wir haben auf unserem OPSI Server leider mal wieder ein Problem:

In unregelmäßigen Abständen kommt es zu dem Fehler bei der Anmeldung im "OPSI-Configed / 4.3.4.3) zu dem Problem, dass sich Admins nicht mehr Anmelden können. Die erscheinende Meldung lautet dann "Unauthorized".
Was wir bisher feststellen konnten, ist dass die Anmeldung nach dem Neustart des Dienstes "opsiconfd.service" über Systemctl wieder funktioniert.
Unser Workaround ist aktuell alle halbe Stunde den Dienst über einen Cronjob Neuzustarten.

Im Logfile unter /var/log/opsi/opsiconfd.log sind keine aktuellen Fehler zu sehen.
In den Logfiles der einzelnen Clients sind folgende Meldungen zu finden:

Code: Alles auswählen

Traceback (most recent call last):
  File "opsiconfd/session.py", line 416, in __call__
  File "opsiconfd/session.py", line 292, in handle_request
  File "starlette/middleware/exceptions.py", line 62, in __call__
  File "starlette/_exception_handler.py", line 63, in wrapped_app
  File "starlette/responses.py", line 148, in __call__
  File "starlette/_exception_handler.py", line 39, in sender
  File "opsiconfd/session.py", line 290, in send_wrapper
  File "opsiconfd/metrics/statistics.py", line 236, in send_wrapper
  File "opsiconfd/application/middleware.py", line 197, in send_wrapper
  File "uvicorn/protocols/websockets/wsproto_impl.py", line 347, in send
RuntimeError: Expected ASGI message 'websocket.send' or 'websocket.close', but got 'websocket.http.response.start'.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "uvicorn/protocols/websockets/wsproto_impl.py", line 234, in run_asgi
  File "uvicorn/middleware/proxy_headers.py", line 60, in __call__
  File "fastapi/applications.py", line 1054, in __call__
  File "starlette/applications.py", line 113, in __call__
  File "starlette/middleware/errors.py", line 152, in __call__
  File "opsiconfd/application/middleware.py", line 199, in __call__
  File "opsiconfd/metrics/statistics.py", line 252, in __call__
  File "opsiconfd/session.py", line 418, in __call__
  File "opsiconfd/session.py", line 354, in handle_request_exception
  File "opsiconfd/metrics/statistics.py", line 236, in send_wrapper
  File "opsiconfd/application/middleware.py", line 197, in send_wrapper
  File "uvicorn/protocols/websockets/wsproto_impl.py", line 347, in send
RuntimeError: Expected ASGI message 'websocket.send' or 'websocket.close', but got 'websocket.http.response.start'.

Leider gibt mir das Log keinen wirklichen Hinweis darauf, was hier schieflaufen sollte.

Weiterhin ist mir aufgefallen, dass wenn man über mehrere Clients (ca. 3000 Stk.) eine Aktion starten (z.B. setzen einer Anwendung auf "Setup"),
sich der OPSI-Configed komplett Aufhängt und auch nach einer halben Stunde keine weitere Nutzung des Configed mehr möglich ist.
In Windows nutzt der Configed dann knapp 2Gb RAM. CPU Auslastung ist unauffällig.

Hatte diesen Fehler bereits jemand und wenn ja, was war die Lösung, bzw. wo könnte ich hier noch nach Fehlern suchen?

[wolfbardo]

Weiterhin ist mir aufgefallen, dass wenn man über mehrere Clients (ca. 3000 Stk.) eine Aktion starten (z.B. setzen einer Anwendung auf "Setup"),

Wird das Modul Scalabilty mit mehreren Workern verwendet?

Gruss
Bardo Wolf

[pago]

Wir nutzen das Scalability Tool nicht, daher verwenden wir keine weiteren Worker.

[j.schneider]

Hallo,

der opsi-configed ist hierbei nicht das Problem.
Mit einem Worker kann man etwa 500-1000 Clients versorgen.
Für mehr Clients reicht die Anzahl der möglichen Sockets des Workers nicht aus und es kann zu allen möglichen Fehler kommen.
Z.B. diesem:

RuntimeError: Expected ASGI message 'websocket.send' or 'websocket.close', but got 'websocket.http.response.start'.

Wir stellen gerne eine Test-Lizenz für das Scalability-Modul aus.
Mit Scalability läuft es auch mit mehreren Tausend Clients performant.

Grüße
Jan Schneider

[pago]

Guten Tag Jan,

erst einmal vielen Dank für die Testlizenz. Wir haben nun "Scalability" im Test.

Die oben Beschriebenen Fehlermeldungen sind allerdings im Log File verschwunden, nach dem es auf "Ubuntu" ein SQL Update gab.

Jetzt testen wir noch das Anmeldeverhalten der User mit den aktivierten "Scalability" und 8 Workern.
Leider ist, so zumindest aktuell mein Gefühl, das Anmeldeverhalten und auch das Arbeiten im OPSI-Configed weiterhin sehr träge.

[j.schneider]

Hallo,

normalerweise müsste die Performance mit 8 Workern sehr gut sein.
Ich vermute, dass es nur ein Konfigurationsproblem ist.
In der Größenordnung sollte man auch Optimierungen in der Redis- und MySQL-Konfiguration prüfen.
Wir können uns das im Rahmen der Scalability-Evaluation gerne anschauen.
Dafür bitte einfach eine kurze Mail schicken, wir melden uns dann.

Grüße
Jan Schneider

[pago]

Hallo Jan,

vielen Dank schon mal für den netten Support.
Wo du gerade MySQL erwähnst, gibt es hier von der UIB aus scripte zur Bereinigung der DB?
Mir ist z.B. aufgefallen, dass in der Tabelle "ProductOnClient" noch Einträge von Software enthalten sind, die über "opsi-package-manager -r PRODUKTNAME" entfernt worden.

Bei MySQL haben wir aktuell 2500 Verbindungen zugelassen.

Bezüglich der Evaluation wäre noch die Frage, welche Kosten würden da ca. auf uns zukommen?

Lg

[j.schneider]

Hallo!

Die Datenbank wird bei jedem opsiconfd-Start oder "opsiconfd setup" automatisch bereinigt.
Die verwaisten ProductOnClient-Einträge können mittels "opsi-package-manager --purge" entfernt werden.

Eine Test-Lizenz für Scalability habt ihr ja bereits erhalten, oder?
Wenn ihr ein Problem mit dem Scalability-Modul habt, können wir gerne einen Termin vereinbaren.
Für euch entstehen dadurch keine Kosten.

Grüße
Jan Schneider