opsiconfd-Absturz nach Netboot-Änderung

phorms · Beitrag von **phorms** » 20 Nov 2015, 13:36

Hallo,

in unserer OPSI-Umgebung haben wir das Problem, dass jede Netboot-Produkte-Änderung zum Absturz des Dienstes "opsiconfd" führt, wenn über "configed" des Depotservers ein Client auf dem gleichen Depot verändert wird. Auf anderen Depotservern kann man problemlos Änderungen vornehmen. Ob es eine Fehlkonfiguration oder ein Bug ist, können hoffentlich die Experten klären.

Kurz zu unserer OPSI-Umgebung:
- 9 Depotserver auf Ubuntu 14.04, opsiconfd version 4.0.6.10, opsi-depotserver 4.0.6.4-1
- Masterserver auf Ubuntu 12.04, opsiconfd version 4.0.6.10, opsi-depotserver 4.0.6.4-1
- MySQL Modul erworben
- überall die Standard-Ports
- Jeder Server hat sein eigens IP-Netz, welche über VPN-Tunnel mit dem Masterserver verbunden sind
- Alles wurde nach Handbuch installiert
- Auf dem Depotservern gibt es OPSI-Administratoren, welche auf dem Masterserver keinen Account besitzen (zwecks Fehlersuche Duplikat mit identischen Daten auf dem Master erstellt)

Fehlerauslösung:
- Nutzung eines Depotservers mit "java web start" oder "java applet"
- Ändern von "Angefordert" eines beliebigen Netboot-Produktes (setup oder none)
- Speichern
- Depotserver nicht mehr nutzbar

Fehlersuche:
Der Dienst "opsiconfd" stürzt nicht wirklich ab, der Dienst läuft und der Port bleibt geöffnet, aber es sind keine Verbindungen mehr zu "configed" möglich. Der Browser bekommt ein Timeout. Aufgrund der Log-Dateien vermute ich eine Endlosschleife beim Warten auf eine Antwort.

Die Änderung, welche zum Absturz führt, wird im Backend erfolgreich gespeichert. Der Client bekommt aber keine Verbindung mehr zu "opsiconfd" und wartet endlos. Der Dienst muss dann neugestartet werden oder sogar der ganze Server, da manchmal trotz laufendem Dienst kein Port 4447 in Benutzung ist.

Vom Masterserver aus kann man jedes Depot erfolgreich bearbeiten. Jeder Depotserver kann andere Depots bearbeiten. Das Problem tritt nur auf, wenn von einem Depotserver die eigenen Clients bearbeitet werden.

In den Logs sieht man, dass der Depotserver A vom Masterserver keine Antwort erhält, wenn Clients von Depotserver A betroffen sind.
Ändert der Depotserver A einen Client von Depotserver B, dann erhält er eine Antwort vom Masterserver. In der Logs sieht man auch die unterschiedliche Backend-Abarbeitung. Ist eventuell das Backend falsch einstellt?

dispatch.conf Master:

Code: Alles auswählen

backend_.*         : mysql, opsipxeconfd
host_.*            : mysql, opsipxeconfd
productOnClient_.* : mysql, opsipxeconfd
configState_.*     : mysql, opsipxeconfd
.*                 : mysql

dispatch.conf Depots

Code: Alles auswählen

backend_.* : jsonrpc, opsipxeconfd
.*         : jsonrpc

Über Hinweise würde ich mich freuen. Für Rückfragen stehe ich gerne zur Verfügung.

Log:
Eigenes Depot: A ; fremdes Depot: B

Log vom Depot A mit erfolgreicher Änderung in Depot B:

Code: Alles auswählen

[7] [Nov 18 14:22:48] Got productOnClients (Backend.py|3122)
[6] [Nov 18 14:22:48] ProductOnClient <ProductOnClient(clientId=u'CLIENT_DEPOT_B', productId=u'win7-x64', installationStatus=None, actionRequest=u'none')> exist, updating (Backend.py|3290)
[7] [Nov 18 14:22:48] Dispatching method 'productOnClient_getObjects' to backends: [u'jsonrpc'] (BackendManager.py|414)
[7] [Nov 18 14:22:48] Dispatching method 'productOnClient_insertObject' to backends: [u'jsonrpc'] (BackendManager.py|414)
[6] [Nov 18 14:22:48] Got result (JsonRpc.py|136)
[8] [Nov 18 14:22:48] RPC ID 1: [] (JsonRpc.py|137)

Log vom Masterserver zur erfolgreichen Änderung in Depot B:

Code: Alles auswählen

[5] [Nov 18 14:22:44] -----> Executing: productOnClient_insertObject(<ProductOnClient(clientId=u'CLIENT_DEPOT_B', productId=u'win7-x64', installationStatus=u'installed', actionRequest=u'none')>) (JsonRpc.py|128)
[7] [Nov 18 14:22:44] ExtendedBackend <BackendManager(name=None)>: executing 'productOnClient_insertObject' on backend '<BackendExtender(name=None)>' (Backend.py|478)
[7] [Nov 18 14:22:44] ExtendedBackend <BackendExtender(name=None)>: executing 'productOnClient_insertObject' on backend '<OPSI.Backend.BackendManager.BackendAccessControl object at 0x7fea7fc28190>' (Backend.py|478)
[7] [Nov 18 14:22:44] Access control for method 'productOnClient_insertObject' params {'productOnClient': <ProductOnClient(clientId=u'CLIENT_DEPOT_B', productId=u'win7-x64', installationStatus=u'installed', actionRequest=u'none')>} (BackendManager.py|817)
[7] [Nov 18 14:22:44] Found matching acl [{'denyAttributes': [], 'type': u'sys_group', 'ids': [u'opsiadmin'], 'allowAttributes': []}, {'denyAttributes': [], 'type': u'opsi_depotserver', 'ids': [], 'allowAttributes': []}, {'denyAttributes': [], 'type': u'self', 'ids': [], 'allowAttributes': []}] for method 'productOnClient_insertObject' (BackendManager.py|822)
[7] [Nov 18 14:22:44] Method: productOnClient_insertObject, using acls: [{'denyAttributes': [], 'type': u'opsi_depotserver', 'ids': [], 'allowAttributes': []}] (BackendManager.py|857)
[7] [Nov 18 14:22:44] Full access to method 'productOnClient_insertObject' granted to user 'DEPOT_A' by acl {'denyAttributes': [], 'type': u'opsi_depotserver', 'ids': [], 'allowAttributes': []} (BackendManager.py|859)
[7] [Nov 18 14:22:44] newKwargs: {'productOnClient': <ProductOnClient(clientId=u'CLIENT_DEPOT_B', productId=u'win7-x64', installationStatus=u'installed', actionRequest=u'none')>} (BackendManager.py|874)
[7] [Nov 18 14:22:44] ExtendedBackend <HostControlSafeBackend(name=None)>: executing 'productOnClient_insertObject' on backend '<HostControlBackend(name=None)>' (Backend.py|478)
[6] [Nov 18 14:22:44] Got result (JsonRpc.py|136)

Log vom Depot A mit Absturz-Änderung in Depot A:

Code: Alles auswählen

[7] [Nov 18 14:26:10] Got productOnClients (Backend.py|3122)
[6] [Nov 18 14:26:10] ProductOnClient <ProductOnClient(clientId=u'CLIENT_DEPOT_A', productId=u'win7-x64', installationStatus=None, actionRequest=u'setup')> exist, updating (Backend.py|3290)
[7] [Nov 18 14:26:10] Dispatching method 'productOnClient_getObjects' to backends: [u'jsonrpc'] (BackendManager.py|414)
[7] [Nov 18 14:26:10] Dispatching method 'productOnClient_insertObject' to backends: [u'jsonrpc'] (BackendManager.py|414)

Log vom Masterserver zur Absturz-Änderung in Depot A:

Code: Alles auswählen

[5] [Nov 18 14:26:07] -----> Executing: productOnClient_insertObject(<ProductOnClient(clientId=u'CLIENT_DEPOT_A', productId=u'win7-x64', installationStatus=u'installed', actionRequest=u'setup')>) (JsonRpc.py|128)
[7] [Nov 18 14:26:07] ExtendedBackend <BackendManager(name=None)>: executing 'productOnClient_insertObject' on backend '<BackendExtender(name=None)>' (Backend.py|478)
[7] [Nov 18 14:26:07] ExtendedBackend <BackendExtender(name=None)>: executing 'productOnClient_insertObject' on backend '<OPSI.Backend.BackendManager.BackendAccessControl object at 0x7fea7f8fd250>' (Backend.py|478)
[7] [Nov 18 14:26:07] Access control for method 'productOnClient_insertObject' params {'productOnClient': <ProductOnClient(clientId=u'CLIENT_DEPOT_A', productId=u'win7-x64', installationStatus=u'installed', actionRequest=u'setup')>} (BackendManager.py|817)
[7] [Nov 18 14:26:07] Found matching acl [{'denyAttributes': [], 'type': u'sys_group', 'ids': [u'opsiadmin'], 'allowAttributes': []}, {'denyAttributes': [], 'type': u'opsi_depotserver', 'ids': [], 'allowAttributes': []}, {'denyAttributes': [], 'type': u'self', 'ids': [], 'allowAttributes': []}] for method 'productOnClient_insertObject' (BackendManager.py|822)
[7] [Nov 18 14:26:07] Method: productOnClient_insertObject, using acls: [{'denyAttributes': [], 'type': u'opsi_depotserver', 'ids': [], 'allowAttributes': []}] (BackendManager.py|857)
[7] [Nov 18 14:26:07] Full access to method 'productOnClient_insertObject' granted to user 'DEPOT_A' by acl {'denyAttributes': [], 'type': u'opsi_depotserver', 'ids': [], 'allowAttributes': []} (BackendManager.py|859)
[7] [Nov 18 14:26:07] newKwargs: {'productOnClient': <ProductOnClient(clientId=u'CLIENT_DEPOT_A', productId=u'win7-x64', installationStatus=u'installed', actionRequest=u'setup')>} (BackendManager.py|874)
[7] [Nov 18 14:26:07] ExtendedBackend <HostControlSafeBackend(name=None)>: executing 'productOnClient_insertObject' on backend '<HostControlBackend(name=None)>' (Backend.py|478)
[7] [Nov 18 14:26:07] ExtendedBackend <HostControlBackend(name=None)>: executing 'productOnClient_insertObject' on backend '<DepotserverBackend(name=None)>' (Backend.py|478)
[7] [Nov 18 14:26:07] ExtendedBackend <DepotserverBackend(name=None)>: executing 'productOnClient_insertObject' on backend '<ExtendedConfigDataBackend(configDataBackend=<BackendDispatcher(name=None)>)>' (Backend.py|478)
[7] [Nov 18 14:26:07] Dispatching method 'productOnClient_getObjects' to backends: [u'mysql', u'opsipxeconfd'] (BackendManager.py|414)
[6] [Nov 18 14:26:07] Getting productOnClients, filter: {'clientId': u'CLIENT_DEPOT_A', 'productId': u'win7-x64'} (SQL.py|1514)
[7] [Nov 18 14:26:07] Created query: 'select * from `PRODUCT_ON_CLIENT` where (`clientId` = 'CLIENT_DEPOT_A') and (`productId` = 'win7-x64')' (SQL.py|284)
[6] [Nov 18 14:26:07] Updating productOnClient <ProductOnClient(clientId=u'CLIENT_DEPOT_A', productId=u'win7-x64', installationStatus=u'installed', actionRequest=u'none')> instead of creating a new one (Backend.py|3215)
[7] [Nov 18 14:26:07] Dispatching method 'productOnClient_insertObject' to backends: [u'mysql', u'opsipxeconfd'] (BackendManager.py|414)
[7] [Nov 18 14:26:07] Dispatching method 'configState_getObjects' to backends: [u'mysql', u'opsipxeconfd'] (BackendManager.py|414)
[6] [Nov 18 14:26:07] Getting configStates, filter: {'configId': u'clientconfig.depot.id', 'objectId': u'CLIENT_DEPOT_A'} (SQL.py|1193)
[7] [Nov 18 14:26:07] Created query: 'select * from `CONFIG_STATE` where (`configId` = 'clientconfig.depot.id') and (`objectId` = 'CLIENT_DEPOT_A')' (SQL.py|284)
[6] [Nov 18 14:26:07] Not responsible for client 'CLIENT_DEPOT_A', forwarding request to depot 'DEPOT_A' (OpsiPXEConfd.py|148)
[7] [Nov 18 14:26:07] Dispatching method 'host_getObjects' to backends: [u'mysql', u'opsipxeconfd'] (BackendManager.py|414)
[6] [Nov 18 14:26:07] Getting hosts, filter: {'id': u'MASTERSERVER'} (SQL.py|1023)
[7] [Nov 18 14:26:07] Created query: 'select * from `HOST` where (`hostId` = 'MASTERSERVER')' (SQL.py|284)

phorms · Beitrag von **phorms** » 19 Jan 2016, 13:47

Beitrag von **wolfbardo** » 19 Jan 2016, 16:20

- dpkg -l | grep opsi prüfen
- Namensauflösung der Server vorwärts/rückwärts prüfen
- Supportvertrag prüfen

Gruss
Bardo Wolf

s.ehrenfeld · Beitrag von **s.ehrenfeld** » 02 Nov 2016, 15:17

Hallo,

wir haben genau das selbe Problem nach dem Update auf Version 4.0.7. Alles Depot-Server haben den selben Stand.

Gruß

Sebastian

Beitrag von **ueluekmen** » 03 Nov 2016, 12:11

Hi,

verstehe ich das richtig, dass du dich auf den Depotserver mit dem configed verbindest und dann versuchst etwas darauf zu ändern? Das ist so nicht vorgesehen. Die Multidepotumgebung geht davon aus, dass alles vom Zentralen Configserver aus gemacht werden muss und das der die Infos an die Depots weiterleiten soll. Genausowenig kannst du aus einem laufenden Bootimage dich mit dem Depotserver direkt verbinden, du musst immer über den configserver gehen. Alle anderen Wege werden von uns nicht geprüft, da du ansonsten gefahr läufsft in einem Communication-Loop zu Enden.

Wenn es beim normalen Betrieb der Multidepot-Umgebung zu Problemen kommt, hilft auch meistens ein neu-Registrieren der Depotserver am Configserver.

forum.opsi.org