forum.opsi.org

Hallo,
Danke für die Infos.
Es ist egal, ob ich den Parameter zu der Ciphersuite weglasse oder nicht. Der Loginprozess stockt immer an dieser Stelle:

[3] (INFO) [Juni 29 09:02:23.086 2020] [Thread[HandshakeCompletedNotify-Thread,6,main]] de.uib.opsicommand.JSONthroughHTTPS$MyHandshakeCompletedListener cipher suite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Nur das dann eben eine andere Suite benutzt wird.

Mehr als das der ganze Login-Prozess an dieser Stelle halt stehenbleibt sieht man nicht. Das Logging stoppt einfach dort ohne weitere Ausgabe.

Viele Grüße, Ralf

Auf welcher Distribution laeuft der opsi-Server?

Gruss
Bardo Wolf

Debian 9

Jetzt wird es spannend, zu erkunden, was da Server und Client treiben. Am besten mal aus der opsiconfd-Logdatei, die zum Host gehört, auf dem der configed läuft, und eventuell auch der Server-Logdatei die Zeilen herausfischen, die zum betreffenden Vorgang gehören.

VG
Rupert Röder

In /var/log/opsi/opsiconfd/10.80.94.77.log


[5] [Jun 30 08:13:12] New session created (session.py|77)
[5] [Jun 30 08:13:12] Authorization request from r.muenz@10.80.94.77 (application: opsi config editor 4.1.9.3.3) (workers.py|217)
[5] [Jun 30 08:14:11] -----> Executing: authenticated() (JsonRpc.py|133)
[5] [Jun 30 08:14:11] -----> Executing: getRawData(u'select * from SOFTWARE_CONFIG LIMIT 1 ') (JsonRpc.py|133)
[3] [Jun 30 08:14:11] Execution error: Backend configuration error: You have tried to execute a method, that will not work with filebackend. (JsonRpc.py|145)
[4] [Jun 30 08:14:11] Failed RPC on u'getRawData' with params [u'select * from SOFTWARE_CONFIG LIMIT 1 ']: <BackendConfigurationError(u'You have tried to execute a method, that will not work with filebackend.')> (statistics.py|427)
[5] [Jun 30 08:14:11] Application 'opsi config editor 4.1.9.3.3' on client '10.80.94.77' did not send cookie (workers.py|185)
[5] [Jun 30 08:14:11] New session created (session.py|77)

Die /etc/opsi/backendManager/dispatch.conf:
backend_.* : file, mysql, opsipxeconfd
host_.* : file, opsipxeconfd
productOnClient_.* : file, opsipxeconfd
configState_.* : file, opsipxeconfd
audit.* : mysql
.* : file

Fast 1 Minute zwischen dem Authorization Request und …"authenticated". Ab da läuft es dann recht zügig.

Hi

ist dein Problem immer noch das gleiche?
Ist dein Name Tatsächlich der untenstehende oder ist der Anonymisiert?
Wenn beides Ja - Nimm mal einen Benutzer ohne Punkt im Namen - evtl ist das die Ursache.

RMuenz hat geschrieben:In /var/log/opsi/opsiconfd/10.80.94.77.log

[5] [Jun 30 08:13:12] New session created (session.py|77)
[5] [Jun 30 08:13:12] Authorization request from r.muenz@10.80.94.77 (application: opsi config editor 4.1.9.3.3) (workers.py|217)
Fast 1 Minute zwischen dem Authorization Request und …"authenticated". Ab da läuft es dann recht zügig.

Hallo Jan,
der Configed verhält sich nach wie vor so. An dem Punkt im Loginnamen scheint es nicht zu liegen: Mit "opsiadmin" ist das nicht anders.
Somit kann man auch die Authentifizizerung gegen die AD ausschließen, weil der opsiadmin ja ein lokaler User ist ....

Danke für die Idee!