forum.opsi.org

opsi support forum
https://forum.opsi.org/

opsiservicecall phenomen.

https://forum.opsi.org/viewtopic.php?t=2053

Seite 1 von 1

opsiservicecall phenomen.

Verfasst: 11 Nov 2010, 08:52
von jcconnor
Hallo zusammen.

Wir haben ein Problem beim Ausführen eines opsiservicecall aus einem *.ins Script.
z.B. beim Ausführen eines setProductInstallationStatus setzt er die $ClientId$ richtig
durch Abfragen beim OPSI-Server. Beim Ausführen des servicecall's hat er aber ein
völlig falschen PC-Namen, wie aus den beiden Logfiles ersichtlich ist. Ich habe die
Key's der Rechner im pckeys file angeschaut, die sind nicht identisch. Hat jemand
eine Idee woran das liegen könnte? Besten Dank für eure Hilfe!

Mfg. jcconnor.

INST-Log:

[5] [10.11.2010 13:28:03] Set $InstallationStatus$ = 'not_installed'
[6] [10.11.2010 13:28:03] The value of the variable "$InstallationStatus$" is now: "not_installed"
[5] [10.11.2010 13:28:03]
[5] [10.11.2010 13:28:03] Set $ActionRequest$ = 'setup'
[6] [10.11.2010 13:28:03] The value of the variable "$ActionRequest$" is now: "setup"
[5] [10.11.2010 13:28:03]
[5] [10.11.2010 13:28:03] Set $InstallProductId$ = '001-xpw7-upgrade'
[6] [10.11.2010 13:28:03] The value of the variable "$InstallProductId$" is now: "001-xpw7-upgrade"
[5] [10.11.2010 13:28:03]
[5] [10.11.2010 13:28:03] Set $ServiceResult$ = getReturnListFromSection('opsiServiceCall_getDomain')
[5] [10.11.2010 13:28:03]
[5] [10.11.2010 13:28:03] Execution of opsiServiceCall_getDomain
[6] [10.11.2010 13:28:03] "method": "getDomain"
[6] [10.11.2010 13:28:03] Calling opsi service at https://192.168.1.46:4447
[6] [10.11.2010 13:28:03] JSON service request https://192.168.1.46:4447/rpc getDomain
[6] [10.11.2010 13:28:03] JSON result:
[6] [10.11.2010 13:28:03] test.com
[6] [10.11.2010 13:28:03]
[6] [10.11.2010 13:28:03] retrieving strings from getReturnListFromSection [switch to loglevel 7 for debugging]
[5] [10.11.2010 13:28:03]
[5] [10.11.2010 13:28:03] Set $DnsDomainName$ = takestring(0, $ServiceResult$)
[6] [10.11.2010 13:28:03] retrieving strings from $ServiceResult$ [switch to loglevel 7 for debugging]
[6] [10.11.2010 13:28:03] The value of the variable "$DnsDomainName$" is now: "test.com"
[5] [10.11.2010 13:28:03]
[5] [10.11.2010 13:28:03] Set $ClientId$ = lower(EnvVar("COMPUTERNAME")) + "." + $DnsDomainName$
[6] [10.11.2010 13:28:03] The value of the variable "$ClientId$" is now: "pc7143.test.com"
[5] [10.11.2010 13:28:03]
[5] [10.11.2010 13:28:03] Execution of opsiServiceCall_setProductInstallationStatus
[6] [10.11.2010 13:28:03] "method": "setProductInstallationStatus"
[6] [10.11.2010 13:28:03] Calling opsi service at https://192.168.1.46:4447
[6] [10.11.2010 13:28:03] JSON service request https://192.168.1.46:4447/rpc setProductInstallationStatus
[3] [10.11.2010 13:28:05] Error: --- opsi service problem ---{"message":"u'pc7269.test.com'","class":"KeyError"}
[3] [10.11.2010 13:28:05] Error: {"message":"u'pc7269.test.com'","class":"KeyError"}
[5] [10.11.2010 13:28:05]
[5] [10.11.2010 13:28:05] Execution of opsiServiceCall_setProductActionRequest
[6] [10.11.2010 13:28:05] "method": "setProductActionRequest"
[6] [10.11.2010 13:28:05] Calling opsi service at https://192.168.1.46:4447
[6] [10.11.2010 13:28:05] JSON service request https://192.168.1.46:4447/rpc setProductActionRequest
[3] [10.11.2010 13:28:06] Error: --- opsi service problem ---{"message":"u'pc7269.test.com'","class":"KeyError"}
[3] [10.11.2010 13:28:06] Error: {"message":"u'pc7269.test.com'","class":"KeyError"}
[5] [10.11.2010 13:28:06]
[5] [10.11.2010 13:28:06] Set $InstallationStatus$ = 'not_installed'
[6] [10.11.2010 13:28:06] The value of the variable "$InstallationStatus$" is now: "not_installed"
[5] [10.11.2010 13:28:06]
[5] [10.11.2010 13:28:06] Set $ActionRequest$ = 'setup'
[6] [10.11.2010 13:28:06] The value of the variable "$ActionRequest$" is now: "setup"
[5] [10.11.2010 13:28:06]
[5] [10.11.2010 13:28:06] Set $InstallProductId$ = 'win7-x64'
[6] [10.11.2010 13:28:06] The value of the variable "$InstallProductId$" is now: "win7-x64"
[5] [10.11.2010 13:28:06]
[5] [10.11.2010 13:28:06] Set $ServiceResult$ = getReturnListFromSection('opsiServiceCall_getDomain')
[5] [10.11.2010 13:28:06]
[5] [10.11.2010 13:28:06] Execution of opsiServiceCall_getDomain
[6] [10.11.2010 13:28:06] "method": "getDomain"
[6] [10.11.2010 13:28:06] Calling opsi service at https://192.168.1.46:4447
[6] [10.11.2010 13:28:06] JSON service request https://192.168.1.46:4447/rpc getDomain
[6] [10.11.2010 13:28:06] JSON result:
[6] [10.11.2010 13:28:06] test.com
[6] [10.11.2010 13:28:06]
[6] [10.11.2010 13:28:06] retrieving strings from getReturnListFromSection [switch to loglevel 7 for debugging]
[5] [10.11.2010 13:28:06]
[5] [10.11.2010 13:28:06] Set $DnsDomainName$ = takestring(0, $ServiceResult$)
[6] [10.11.2010 13:28:06] retrieving strings from $ServiceResult$ [switch to loglevel 7 for debugging]
[6] [10.11.2010 13:28:06] The value of the variable "$DnsDomainName$" is now: "test.com"
[5] [10.11.2010 13:28:06]
[5] [10.11.2010 13:28:06] Set $ClientId$ = lower(EnvVar("COMPUTERNAME")) + "." + $DnsDomainName$
[6] [10.11.2010 13:28:06] The value of the variable "$ClientId$" is now: "pc7143.test.com"
[5] [10.11.2010 13:28:06]
[5] [10.11.2010 13:28:06] Execution of opsiServiceCall_setProductInstallationStatus
[6] [10.11.2010 13:28:06] "method": "setProductInstallationStatus"
[6] [10.11.2010 13:28:06] Calling opsi service at https://192.168.1.46:4447
[6] [10.11.2010 13:28:06] JSON service request https://192.168.1.46:4447/rpc setProductInstallationStatus
[3] [10.11.2010 13:28:08] Error: --- opsi service problem ---{"message":"u'pc7269.test.com'","class":"KeyError"}
[3] [10.11.2010 13:28:08] Error: {"message":"u'pc7269.test.com'","class":"KeyError"}
[5] [10.11.2010 13:28:08]
[5] [10.11.2010 13:28:08] Execution of opsiServiceCall_setProductActionRequest
[6] [10.11.2010 13:28:08] "method": "setProductActionRequest"
[6] [10.11.2010 13:28:08] Calling opsi service at https://192.168.1.46:4447
[6] [10.11.2010 13:28:08] JSON service request https://192.168.1.46:4447/rpc setProductActionRequest
[3] [10.11.2010 13:28:09] Error: --- opsi service problem ---{"message":"u'pc7269.test.com'","class":"KeyError"}
[3] [10.11.2010 13:28:09] Error: {"message":"u'pc7269.test.com'","class":"KeyError"}
[5] [10.11.2010 13:28:09]
[5] [10.11.2010 13:28:09] ExitWindows set to Reboot

OPSICONFD-Log:

[5] [Nov 10 13:28:33] New session created (opsiconfd.py|1526)
[5] [Nov 10 13:28:33] Authorization request from pc7143.test.com@192.168.3.87 (application: opsi-winst 4.10.8.6) (opsiconfd.py|560)
[5] [Nov 10 13:28:34] Backend created: <OPSI.Backend.BackendManager.BackendManager instance at 0x1aef3f8> (opsiconfd.py|676)
[5] [Nov 10 13:28:34] -----> Executing: authenticated() (opsiconfd.py|785)
[5] [Nov 10 13:28:34] -----> Executing: getDepotId(u'pc7143.test.com') (opsiconfd.py|785)
[5] [Nov 10 13:28:34] -----> Executing: backend_setOptions({u'processProductOnClientSequence': True}) (opsiconfd.py|785)
[5] [Nov 10 13:28:34] -----> Executing: productOnClient_getObjects(u'', {'productType': u'LocalbootProduct', 'clientId': u'pc7143.test.com'}) (opsiconfd.py|785)
[5] [Nov 10 13:28:35] -----> Executing: getProductProperties_hash(u'000-usmt-backup', u'pc7143.test.com') (opsiconfd.py|785)
[5] [Nov 10 13:28:35] -----> Executing: getProduct_hash(u'000-usmt-backup', u'opsi40.test.com') (opsiconfd.py|785)
[5] [Nov 10 13:28:35] -----> Executing: productOnClient_getObjects(u'', {'productType': u'LocalbootProduct', 'clientId': u'pc7143.test.com', 'productId': u'000-usmt-backup'}) (opsiconfd.py|785)
[5] [Nov 10 13:28:35] -----> Executing: productOnClient_updateObject(<ProductOnClient clientId 'pc7143.test.com', productId '000-usmt-backup', installationStatus 'unknown', actionRequest 'setup'>) (opsiconfd.py|785)
[5] [Nov 10 13:28:36] -----> Executing: getDomain() (opsiconfd.py|785)
[5] [Nov 10 13:28:36] -----> Executing: setProductInstallationStatus(u'001-xpw7-upgrade', u'pc7143.test.com', u'not_installed') (opsiconfd.py|785)
[3] [Nov 10 13:28:38] Execution error: u'pc7269.test.com' (opsiconfd.py|798)
[5] [Nov 10 13:28:38] -----> Executing: setProductActionRequest(u'001-xpw7-upgrade', u'pc7143.test.com', u'setup') (opsiconfd.py|785)
[3] [Nov 10 13:28:39] Execution error: u'pc7269.test.com' (opsiconfd.py|798)
[5] [Nov 10 13:28:39] -----> Executing: getDomain() (opsiconfd.py|785)
[5] [Nov 10 13:28:39] -----> Executing: setProductInstallationStatus(u'win7-x64', u'pc7143.test.com', u'not_installed') (opsiconfd.py|785)
[3] [Nov 10 13:28:40] Execution error: u'pc7269.test.com' (opsiconfd.py|798)
[5] [Nov 10 13:28:40] -----> Executing: setProductActionRequest(u'win7-x64', u'pc7143.test.com', u'setup') (opsiconfd.py|785)
[3] [Nov 10 13:28:42] Execution error: u'pc7269.test.com' (opsiconfd.py|798)
[5] [Nov 10 13:28:42] -----> Executing: productOnClient_updateObject(<ProductOnClient clientId 'pc7143.test.com', productId '000-usmt-backup', installationStatus 'installed', actionRequest 'none'>) (opsiconfd.py|785)
[5] [Nov 10 13:28:43] -----> Executing: writeLog(u'instlog', u'\n[1] [10.11.2010 12:07:57] opsi-winst 4.10.8.6 started at 10.11.2010 12:07:55\n[6] [10.11.2010 12:07:57] JSON service request https://192.168.1.46:4447/rpc getDepotId\n[6] [10.11.2010 12:...) (opsiconfd.py|785)
[5] [Nov 10 13:28:48] -----> Executing: backend_setOptions({u'addConfigStateDefaults': True}) (opsiconfd.py|785)
[5] [Nov 10 13:28:48] -----> Executing: log_write(u'clientconnect', u'[6] [Nov 10 13:27:50] [opsiclientd] Setting config value action_processor.delete_user (Opsiclientd.pyo|229)\r\n[6] [Nov 10 13:27:50] [opsiclientd] Setting config value acti...) (opsiconfd.py|785)
[5] [Nov 10 13:28:48] User 'pc7143.test.com' asked to close the session (opsiconfd.py|886)
[5] [Nov 10 13:28:48] Session '1zyRUJ671i0JtcpB85D7eHXi4CgIIyHb' from ip '192.168.3.87', application 'opsiclientd version 4.0.2' deleted (opsiconfd.py|1559)
[5] [Nov 10 13:30:28] Application 'opsiclientd version 4.0.2' on client '192.168.3.87' did not send cookie (opsiconfd.py|462)

Re: opsiservicecall phenomen.

Verfasst: 12 Nov 2010, 15:40
von d.oertel
Hi,

wie sieht es mit der vorwärts und Rückwärts namensauflösung von pc7143.test.com aus ?

In der
/etc/opsi/opsiconfd.conf
Welche Werte haben die Parameter
verify ip
update ip

gruss
d.oertel

Re: opsiservicecall phenomen.

Verfasst: 15 Nov 2010, 09:11
von jcconnor
Hallo Herr Oertel.

Die beiden Parameter stehen beide auf "no", ich habe sie zum Test auf "yes" gesetzt und
opsi neu gestartet. Das Paket nochmal geschickt, leider mit dem selben Ergebnis. Ich hab
mal den Client "pc7269" aus dem Inventar gelöscht, hilft nicht, dann nimmt er einfach einen
anderen Client z.B. "pcxxxx". :-(

Gruß. jcconnor

Re: opsiservicecall phenomen.

Verfasst: 16 Nov 2010, 16:05
von d.oertel
Hi,

wie sieht es mit der vorwärts und Rückwärts namensauflösung von pc7143.test.com aus ?

gruss
d.oertel

Re: opsiservicecall phenomen.

Verfasst: 19 Nov 2010, 11:03
von jcconnor
Hallo Herr Oertel.

Die Namensauflösung ist Konsistent:
--------------------------------------------------------------------------------------------------------------------------------------------------
opsi40:~# nslookup
> pc7143
Server: 192.168.1.24
Address: 192.168.1.24#53

Name: pc7143.test.com
Address: 192.168.3.90
> 192.168.3.90
Server: 192.168.1.24
Address: 192.168.1.24#53

90.3.168.192.in-addr.arpa name = pc7143.test.com.
> exit
--------------------------------------------------------------------------------------------------------------------------------------------------
Opsiconfd-Log bei "update ip = yes" und "verify ip = yes":
--------------------------------------------------------------------------------------------------------------------------------------------------
[5] [Nov 19 10:41:56] Application 'opsiclientd version 4.0.2' on client '192.168.3.90' did not send cookie (opsiconfd.py|462)
[5] [Nov 19 10:41:56] New session created (opsiconfd.py|1526)
[5] [Nov 19 10:41:56] Authorization request from pc7143.test.com@192.168.3.90 (application: opsiclientd version 4.0.2) (opsiconfd.py|560)
[5] [Nov 19 10:41:56] Backend created: <OPSI.Backend.BackendManager.BackendManager instance at 0x222b9e0> (opsiconfd.py|676)
[5] [Nov 19 10:41:56] -----> Executing: backend_getInterface() (opsiconfd.py|785)
[5] [Nov 19 10:41:56] -----> Executing: backend_info() (opsiconfd.py|785)
[4] [Nov 19 10:41:56] Failed to read opsi modules file '/etc/opsi/modules': Signature expired (Backend.py|345)
[5] [Nov 19 10:41:56] -----> Executing: dispatcher_getConfig() (opsiconfd.py|785)
[5] [Nov 19 10:41:56] -----> Executing: accessControl_authenticated() (opsiconfd.py|785)
[5] [Nov 19 10:41:57] -----> Executing: backend_setOptions({u'addConfigStateDefaults': True}) (opsiconfd.py|785)
[5] [Nov 19 10:41:58] -----> Executing: configState_getObjects([], {'objectId': u'pc7143.test.com'}) (opsiconfd.py|785)
[5] [Nov 19 10:41:58] -----> Executing: productOnClient_getObjects([u'actionRequest'], {'actionRequest': [u'setup', u'uninstall', u'update', u'always', u'once', u'custom'], 'clientId': u'pc7143.test.com', 'productType': u'LocalbootProduct'}) (opsiconfd.py|785)
[5] [Nov 19 10:42:01] -----> Executing: log_write(u'clientconnect', u'[6] [Nov 19 10:41:58] [opsiclientd] Setting config value action_processor.delete_user (Opsiclientd.pyo|229)\r\n[6] [Nov 19 10:41:58] [opsiclientd] Setting config value acti...) (opsiconfd.py|785)
[5] [Nov 19 10:42:01] User 'pc7143.test.com' asked to close the session (opsiconfd.py|886)
[5] [Nov 19 10:42:01] Session 'aWgWam18S5PFt3LREP0cCIS0ET1KwPAl' from ip '192.168.3.90', application 'opsiclientd version 4.0.2' deleted (opsiconfd.py|1559)
--------------------------------------------------------------------------------------------------------------------------------------------------

Ich habe bis jetzt 4 Rechner getestet, bei zwei davon setzt er den ProductActionRequest einwandfrei, bei den anderen beiden passiert eben der Fehler wie
im ersten Posting beschrieben. Ein Asynchroner DNS ist natürlich nicht jederzeit auszuschließen, in diesem Fall hier schon.

Ist es möglich das es mit dem BETA-Release zusammenhängt?

Gruss, jcconnor.

Re: opsiservicecall phenomen.

Verfasst: 19 Nov 2010, 21:56
von d.oertel
Hi,

ich konnte etwas ähnliches auch bei uns entdecken.

Wenn Sie das bei sich reproduzieren können,
würde ich darum bitten im Script den Loglevel auf 8 zu setzen und die entstehende instlog.txt
plus log des opsiconfd an d.oertel (at) uib.de zu senden.

gruss
d.oertel

Re: opsiservicecall phenomen.

Verfasst: 23 Nov 2010, 12:44
von j.schneider
Hallo!

Wir haben soeben ein testing-Paket freigegeben (python-opsi 4.0.0.12-1), welches das Problem beheben sollte.
Das Testing-Repository ist hier zu finden:
http://download.opensuse.org/repositori ... 40-testing
Bitte das Paket für die entsprechende Distribution herunterladen und mittes dpkg/rpm einspielen.

Gruß,
Jan Schneider
Alle Zeiten sind UTC+02:00
Seite 1 von 1

Powered by phpBB® Forum Software © phpBB Limited

Deutsche Übersetzung durch phpBB.de