Guten Morgen,
ich betreibe insgesamt drei OPSI-Server.
Zwei von diesen haben morgens das merkwürdige Problem, dass der erste Admin-Login in einem "Keine Verbindung - Internal Server Error" endet.
Ein sofortiger Neuversuch resultiert immer in einem Erfolg.
Leider, da ich nicht alle Clients überblicke, ist mir nicht klar, ob dies nur die Admin-Configed-Loginmethode betrifft oder aber auch den Client Connect.
Weder im MYSQL-Error-Log, noch im Syslog, noch in den anderen Server-OPSI-Logs finde ich Hinweise auf das Problem. Es scheint, als würde ein Dienst/DB schlafen und erst dann geweckt werden.
Einziger Unterschied zwischen den zwei OPSI-Servern mit Problemen und dem einen ohne: IPTABLES STATEFULL-Firewall dazwischen mit den typischen "NEW, ESTABLISHED,RELATED" Regeln. Dieses Setup lief mit einem älteren OPSI für Windows 7 Clients ohne Probleme.
Umgebung:
- Latest OPSI-Stable Server, Configed und Clients
- Debian Stretch
Vielen Dank für Tipps
Erste morgendlicher Configed-Editor-Connect endet in "Keine Verbindung - Internal Server Error"
Re: Erste morgendlicher Configed-Editor-Connect endet in "Keine Verbindung - Internal Server Error"
Hallo
im Configed im Hilfe Menü findest du den aktuellen Logfile. Vielleicht steht dort was hilfreiches drin.
An der selben Stelle kann auch der Loglevel erhöht werden.
Hoffe das bringt dich weiter
Schönen Tag
Karsten Köpke
im Configed im Hilfe Menü findest du den aktuellen Logfile. Vielleicht steht dort was hilfreiches drin.
An der selben Stelle kann auch der Loglevel erhöht werden.
Hoffe das bringt dich weiter
Schönen Tag
Karsten Köpke
opsi support - uib gmbh
For productive opsi installations we recommend support contracts.
http://uib.de
http://opsi.org
For productive opsi installations we recommend support contracts.
http://uib.de
http://opsi.org
Re: Erste morgendlicher Configed-Editor-Connect endet in "Keine Verbindung - Internal Server Error"
nur noch ein Tipp: wenn der configed meldet "Internal Server Error", dann erhält er vom Server nicht die erbetenen Infos, sondern halt nur die Nachricht, dass etwas schief läuft im Server. Das können z.B. defekte Daten im Backend sein oder sonst so eklige Dinge.
Also beim Server in dessen Logs schauen (/var/log/opsi/opsiconfd und eventuell in der opsiconfd.conf das Log level hochdrehen)
Viel Erfolg
Also beim Server in dessen Logs schauen (/var/log/opsi/opsiconfd und eventuell in der opsiconfd.conf das Log level hochdrehen)
Viel Erfolg
opsi support - uib gmbh
For productive opsi installations we recommend maintainance + support contracts which are the base of opsi development.
Wondering who's using opsi? Have a look at the opsi map: http://opsi.org/opsi-map/.
For productive opsi installations we recommend maintainance + support contracts which are the base of opsi development.
Wondering who's using opsi? Have a look at the opsi map: http://opsi.org/opsi-map/.
Re: Erste morgendlicher Configed-Editor-Connect endet in "Keine Verbindung - Internal Server Error"
Vielen Dank für die TIpps.
Ich konnte, so glaube ich, folgende Regelmäßigkeit erkennen:
MySql im Standardconfigverhalten schließt DB-Connections nach 8 Stunden idle-Verhalten.
Ich bin mir jedoch nicht sicher, ob der erste Client morgens dieses Problem nicht zeigt, sondern nur die Configed-Editor-Requests - es müsste jedoch doch analog ein Gone-Away-Fehler geben, da die DB-Connection ja vom auf dem Server laufenden OPSI-Dienst Richtung MySQL getriggert wird.
Die Frage lautet ja eher: warum ist der Connection-Request nicht erfolgreich - ist nur ein Reconnect.
Den Mysql-Idle-Timeout auf sehr hohe Werte zu setzen, könnte Nebenwirkungen haben - mit welchen Werten arbeitet ihr?
Vielen Dank!
Ich konnte, so glaube ich, folgende Regelmäßigkeit erkennen:
Code: Alles auswählen
[3] [Jan 23 04:07:09] File "/usr/lib/python2.7/dist-packages/OPSI/Service/Worker.py", line 289, in _errback
failure.raiseException()
(Logger.py|798)
[3] [Jan 23 04:07:09] File "<string>", line 2, in raiseException
(Logger.py|798)
[3] [Jan 23 04:07:09] ==>>> (2006, 'MySQL server has gone away') (Worker.py|298)
[3] [Jan 23 04:07:09] [Failure instance: Traceback: <class '_mysql_exceptions.OperationalError'>: (2006, 'MySQL server has gone away')
/usr/lib/python2.7/dist-packages/twisted/internet/defer.py:651:_runCallbacks
/usr/lib/python2.7/dist-packages/opsiconfd/workers.py:421:_getCallInstance
/usr/lib/python2.7/dist-packages/twisted/internet/defer.py:150:maybeDeferred
/usr/lib/python2.7/dist-packages/opsiconfd/workers.py:341:_getBackend
--- <exception caught here> ---
/usr/lib/python2.7/dist-packages/twisted/internet/defer.py:150:maybeDeferred
/usr/lib/python2.7/dist-packages/opsiconfd/workers.py:338:_createBackend
/usr/lib/python2.7/dist-packages/OPSI/Backend/BackendManager.py:1049:backendManagerFactory
/usr/lib/python2.7/dist-packages/OPSI/Backend/BackendManager.py:238:__init__
/usr/lib/python2.7/dist-packages/OPSI/Backend/Depotserver.py:64:__init__
/usr/lib/python2.7/dist-packages/OPSI/Backend/Backend.py:1933:host_getIdents
<string>:1:host_getObjects
/usr/lib/python2.7/dist-packages/OPSI/Backend/Backend.py:524:_executeMethod
<string>:1:host_getObjects
/usr/lib/python2.7/dist-packages/OPSI/Backend/BackendManager.py:437:_dispatchMethod
/usr/lib/python2.7/dist-packages/OPSI/Backend/SQL.py:1088:host_getObjects
/usr/lib/python2.7/dist-packages/OPSI/Backend/MySQL.py:315:getSet
/usr/lib/python2.7/dist-packages/OPSI/Backend/MySQL.py:514:execute
/usr/lib/python2.7/dist-packages/MySQLdb/cursors.py:226:execute
/usr/lib/python2.7/dist-packages/MySQLdb/connections.py:36:defaulterrorhandler
] (Worker.py|299)
[5] [Jan 23 04:07:29] Application 'opsi config editor 4.1.9.3.3' on client '192.168.1.116' did not send cookie (workers.py|185)
[2] [Jan 23 04:07:29] Traceback: (Logger.py|798)
[2] [Jan 23 04:07:30] File "/usr/lib/python2.7/dist-packages/OPSI/Service/Worker.py", line 289, in _errback
failure.raiseException()
(Logger.py|798)
[2] [Jan 23 04:07:30] File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 651, in _runCallbacks
current.result = callback(current.result, *args, **kw)
(Logger.py|798)
[2] [Jan 23 04:07:30] File "/usr/lib/python2.7/dist-packages/opsiconfd/workers.py", line 193, in _getSession
WorkerOpsi._getSession(self, result)
(Logger.py|798)
[2] [Jan 23 04:07:30] File "/usr/lib/python2.7/dist-packages/OPSI/Service/Worker.py", line 389, in _getSession
sessionId = self._getSessionId()
(Logger.py|798)
[2] [Jan 23 04:07:30] File "/usr/lib/python2.7/dist-packages/opsiconfd/workers.py", line 432, in _getSessionId
return WorkerOpsiconfd._getSessionId(self)
(Logger.py|798)
[2] [Jan 23 04:07:30] File "/usr/lib/python2.7/dist-packages/opsiconfd/workers.py", line 188, in _getSessionId
raise OpsiAuthenticationError(u"Application '%s' on client '%s' did neither supply session id nor password" % (self._getUserAgent(), self.request.remoteAddr.host))
Ich bin mir jedoch nicht sicher, ob der erste Client morgens dieses Problem nicht zeigt, sondern nur die Configed-Editor-Requests - es müsste jedoch doch analog ein Gone-Away-Fehler geben, da die DB-Connection ja vom auf dem Server laufenden OPSI-Dienst Richtung MySQL getriggert wird.
Die Frage lautet ja eher: warum ist der Connection-Request nicht erfolgreich - ist nur ein Reconnect.
Den Mysql-Idle-Timeout auf sehr hohe Werte zu setzen, könnte Nebenwirkungen haben - mit welchen Werten arbeitet ihr?
Vielen Dank!
Re: Erste morgendlicher Configed-Editor-Connect endet in "Keine Verbindung - Internal Server Error"
Gerade gefunden und werden den Fix mal testen - danke für das tolle Handbuch - man muss es nur lesen....
Manualle Konfiguration
Manuelle Konfiguration kann über die Backend-Konfigurations-Datei erfolgen. Diese ist standardmäßig /etc/opsi/backends/mysql.conf.
Seit python-opsi 4.1.1.76 ist es möglich die Erstellung neuer Verbindungen nach einer bestimmten Zeit zu forcieren, um Probleme mit Timeouts zu vermeiden. Ein Indikator für solche Timeouts kann die Meldung mysql server has gone away sein.
Sie können einen Timeout setzen, indem Sie für connectionPoolRecycling angeben nach wievielen Sekunden eine neue Verbindung erstellt werden soll. Der Standardwert ist -1, welcher keine erzwungene Neu-Erstellung von Verbindungen bedeutet. Wird diesert Wert gesetzt, sollte er in der Regel niedriger als der auf dem Server konfigurierte Wert für Verbindungs-Timeouts (wait_timeout) sein.
Manualle Konfiguration
Manuelle Konfiguration kann über die Backend-Konfigurations-Datei erfolgen. Diese ist standardmäßig /etc/opsi/backends/mysql.conf.
Seit python-opsi 4.1.1.76 ist es möglich die Erstellung neuer Verbindungen nach einer bestimmten Zeit zu forcieren, um Probleme mit Timeouts zu vermeiden. Ein Indikator für solche Timeouts kann die Meldung mysql server has gone away sein.
Sie können einen Timeout setzen, indem Sie für connectionPoolRecycling angeben nach wievielen Sekunden eine neue Verbindung erstellt werden soll. Der Standardwert ist -1, welcher keine erzwungene Neu-Erstellung von Verbindungen bedeutet. Wird diesert Wert gesetzt, sollte er in der Regel niedriger als der auf dem Server konfigurierte Wert für Verbindungs-Timeouts (wait_timeout) sein.