Agent Deployment per opsi-deploy-client-agent

[matze502]

Hallo,

vielleicht könnt ihr mir bei meinem Problem weiterhelfen. Ich nutze OPSI in der freien Variante in der derzeit aktuellen Version. Nun gebe ich folgenden Befehl ein um das Deployment des Agents zu starten:

Code: Alles auswählen

/var/lib/opsi/depot/opsi-client-agent/opsi-deploy-client-agent -u "[DOMAIN\\BENUTZERNAME]" -p F[rest vom passwort] -v -o [hostname]

Folgende Fehlermeldung erscheint:

Code: Alles auswählen

[notice] Modules file signature verified (customer: opsi community)
[notice] Starting deployment to host '[FQDN]'
[notice] Querying for ip address of host '[FQDN]'
[notice] Got ip address '10.2.12.25' from syscall
[notice] Pinging host 10.2.12.25 ...
[notice] Host 10.2.12.25 is up
[notice] Getting hardware ethernet address of host '[FQDN]'
[warning] Failed to get hardware ethernet address for host '[HOSTNAME]'
[notice] Creating client '[FQDN]'
[notice] Testing winexe
[error] Deployment to 'pcw0014.[DOMAIN]' failed: Failed to execute command on host 'pcw0014': winexe error: Command '/usr/bin/winexe -U 'DOMAIN\BENUTZERNAMEopsi-deploy-client-agent[rest vom passwort' //[hostname] 'cmd.exe /C "del /s /q c:\tmp\opsi-client-agent_inst && rmdir /s /q c:\tmp\opsi-client-agent_inst || echo not found"'' failed (1):
Unknown parameter encountered: "max log size"
Ignoring unknown parameter "max log size"
Unknown parameter encountered: "passdb backend"
Ignoring unknown parameter "passdb backend"
Unknown parameter encountered: "load printers"
Ignoring unknown parameter "load printers"
Unknown parameter encountered: "cups options"
Ignoring unknown parameter "cups options"
Unknown parameter encountered: "follow symlinks"
Ignoring unknown parameter "follow symlinks"
Unknown parameter encountered: "level2 oplocks"
Ignoring unknown parameter "level2 oplocks"
Unknown parameter encountered: "writeable"
Ignoring unknown parameter "writeable"
Unknown parameter encountered: "invalid users"
Ignoring unknown parameter "invalid users"
Unknown parameter encountered: "follow symlinks"
Ignoring unknown parameter "follow symlinks"
Unknown parameter encountered: "level2 oplocks"
Ignoring unknown parameter "level2 oplocks"
Unknown parameter encountered: "writeable"
Ignoring unknown parameter "writeable"
Unknown parameter encountered: "invalid users"
Ignoring unknown parameter "invalid users"
Unknown parameter encountered: "level2 oplocks"
Ignoring unknown parameter "level2 oplocks"
Unknown parameter encountered: "writeable"
Ignoring unknown parameter "writeable"
Unknown parameter encountered: "invalid users"
Ignoring unknown parameter "invalid users"
Unknown parameter encountered: "writeable"
Ignoring unknown parameter "writeable"
Unknown parameter encountered: "invalid users"
Ignoring unknown parameter "invalid users"
Unknown parameter encountered: "writeable"
Ignoring unknown parameter "writeable"
Unknown parameter encountered: "invalid users"
Ignoring unknown parameter "invalid users"
ERROR: Failed to install service winexesvc - NT_STATUS_BAD_INITIAL_PC

Dieser Fehler war mir auch schon bekannt. Offenbar interpretiert das Python Script %F als was anderes und nicht als den Trenner zwischen Benutzername und Kennwort für winexe.
Umgehen konnte ich das ganze bis gestern noch indem ich einfach im Befehl ein -p \F[....] benutze. Und nein, seit gestern habe ich keine Änderung am Server vorgenommen. Das Script und die winexe sind auch original noch.

Nun geht das auch nicht mehr. Ich bekomme seit heute die selbe Meldung wie oben. Wenn ich es in "" setze wird das Passwort ebenfalls nicht als Passwort erkannt und wenn ich "\F[...]" benutze bekomme ich endlich ERROR: Failed to open connection - NT_STATUS_LOGON_FAILURE wobei das Passwort 100% stimmt. Lustigerweise wird es auch nach dem 3. Versuch im AD gesperrt, was mir anzeigt, dass er zumindest irgendein Passwort zur Authentifizierung übergibt, welches auch immer hinter ***confidential*** letztenendes nun steht.

Der Client selbst wurde frisch aufgesetzt und die genutzten Credentials funktionieren, wenn ich mich direkt per Remote Desktop anmelde, einwandfrei.

Ich weiss mir leider keinen Rat mehr und hoffe, hier kann mir noch jemand einen hilfreichen Tip geben.

[mhaegele]

Hallo,

vielleicht könnt ihr mir bei meinem Problem weiterhelfen. Ich nutze OPSI in der freien Variante in der derzeit aktuellen Version. Nun gebe ich folgenden Befehl ein um das Deployment des Agents zu starten:

Code: Alles auswählen

/var/lib/opsi/depot/opsi-client-agent/opsi-deploy-client-agent -u "[DOMAIN\\BENUTZERNAME]" -p F[rest vom passwort] -v -o [hostname]

Folgende Fehlermeldung erscheint:

Code: Alles auswählen

[notice] Modules file signature verified (customer: opsi community)
[notice] Starting deployment to host '[FQDN]'
[notice] Querying for ip address of host '[FQDN]'
[notice] Got ip address '10.2.12.25' from syscall
[notice] Pinging host 10.2.12.25 ...
[notice] Host 10.2.12.25 is up
[notice] Getting hardware ethernet address of host '[FQDN]'
[warning] Failed to get hardware ethernet address for host '[HOSTNAME]'
[notice] Creating client '[FQDN]'
[notice] Testing winexe
[error] Deployment to 'pcw0014.net.local' failed: Failed to execute command on host 'pcw0014': winexe error: Command '/usr/bin/winexe -U 'DOMAIN\BENUTZERNAMEopsi-deploy-client-agent[rest vom passwort' //[hostname] 'cmd.exe /C "del /s /q c:\tmp\opsi-client-agent_inst && rmdir /s /q c:\tmp\opsi-client-agent_inst || echo not found"'' failed (1):
Unknown parameter encountered: "max log size"
Ignoring unknown parameter "max log size"
Unknown parameter encountered: "passdb backend"
Ignoring unknown parameter "passdb backend"
Unknown parameter encountered: "load printers"
Ignoring unknown parameter "load printers"
Unknown parameter encountered: "cups options"
Ignoring unknown parameter "cups options"
Unknown parameter encountered: "follow symlinks"
Ignoring unknown parameter "follow symlinks"
Unknown parameter encountered: "level2 oplocks"
Ignoring unknown parameter "level2 oplocks"
Unknown parameter encountered: "writeable"
Ignoring unknown parameter "writeable"
Unknown parameter encountered: "invalid users"
Ignoring unknown parameter "invalid users"
Unknown parameter encountered: "follow symlinks"
Ignoring unknown parameter "follow symlinks"
Unknown parameter encountered: "level2 oplocks"
Ignoring unknown parameter "level2 oplocks"
Unknown parameter encountered: "writeable"
Ignoring unknown parameter "writeable"
Unknown parameter encountered: "invalid users"
Ignoring unknown parameter "invalid users"
Unknown parameter encountered: "level2 oplocks"
Ignoring unknown parameter "level2 oplocks"
Unknown parameter encountered: "writeable"
Ignoring unknown parameter "writeable"
Unknown parameter encountered: "invalid users"
Ignoring unknown parameter "invalid users"
Unknown parameter encountered: "writeable"
Ignoring unknown parameter "writeable"
Unknown parameter encountered: "invalid users"
Ignoring unknown parameter "invalid users"
Unknown parameter encountered: "writeable"
Ignoring unknown parameter "writeable"
Unknown parameter encountered: "invalid users"
Ignoring unknown parameter "invalid users"
ERROR: Failed to install service winexesvc - NT_STATUS_BAD_INITIAL_PC

Dieser Fehler war mir auch schon bekannt. Offenbar interpretiert das Python Script %F als was anderes und nicht als den Trenner zwischen Benutzername und Kennwort für winexe.
Umgehen konnte ich das ganze bis gestern noch indem ich einfach im Befehl ein -p \F[....] benutze. Und nein, seit gestern habe ich keine Änderung am Server vorgenommen. Das Script und die winexe sind auch original noch.

Nun geht das auch nicht mehr. Ich bekomme seit heute die selbe Meldung wie oben. Wenn ich es in "" setze wird das Passwort ebenfalls nicht als Passwort erkannt und wenn ich "\F[...]" benutze bekomme ich endlich ERROR: Failed to open connection - NT_STATUS_LOGON_FAILURE wobei das Passwort 100% stimmt. Lustigerweise wird es auch nach dem 3. Versuch im AD gesperrt, was mir anzeigt, dass er zumindest irgendein Passwort zur Authentifizierung übergibt, welches auch immer hinter ***confidential*** letztenendes nun steht.

Der Client selbst wurde frisch aufgesetzt und die genutzten Credentials funktionieren, wenn ich mich direkt per Remote Desktop anmelde, einwandfrei.

Ich weiss mir leider keinen Rat mehr und hoffe, hier kann mir noch jemand einen hilfreichen Tip geben.

Hallo!

Was für ein Clientbetriebssystem ist das?
Funktioniert es wenn das Passwort nicht direkt mitgegeben wird, also dies manuell bei "Rückfrage" eingegeben wird?

hth
MH

[n.wenselowski]

Hallo,

Offenbar interpretiert das Python Script %F als was anderes und nicht als den Trenner zwischen Benutzername und Kennwort für winexe.
Umgehen konnte ich das ganze bis gestern noch indem ich einfach im Befehl ein -p \F[....] benutze.

Es gibt für die String-Formatierung tatsächlich eine Bedeutung für %F - fixed point. (Dazu Python Doku)
Das greift in der Regel nur, wenn ein String mit einem % drin entsprechend formatiert wird.

Nun geht das auch nicht mehr. Ich bekomme seit heute die selbe Meldung wie oben. Wenn ich es in "" setze wird das Passwort ebenfalls nicht als Passwort erkannt und wenn ich "\F[...]" benutze bekomme ich endlich ERROR: Failed to open connection - NT_STATUS_LOGON_FAILURE wobei das Passwort 100% stimmt. Lustigerweise wird es auch nach dem 3. Versuch im AD gesperrt, was mir anzeigt, dass er zumindest irgendein Passwort zur Authentifizierung übergibt, welches auch immer hinter ***confidential*** letztenendes nun steht.

Was sich hinter confidential verbirgt sollte sich durch den Parameter -vvvvv beim Deploy-Script einsehen lassen. Achtung, das gibt viele Ausgaben!
Falls das Passwort Sonderzeichen enthält würde ich temporär versuchen das ganze ohne Sonderzeichen zu verwenden.

Ist das Zielsystem Windows 8 oder neuer?


Gruß

Niko

[matze502]

Hallo und vielen Dank erstmal für die Antwort.

Ich werde das mit dem -vvvvv mal ausprobieren wenn ich den nächsten Client ausrolle. Musste mir nun erstmal so helfen, das ich den Client manuell auf dem Client installiert habe.

Das Zielsystem ist in jedem Fall ein Windows 7 SP1 pro x64 frisch installiert. Danach wird nur die IP angepasst und der Client in die Domäne aufgenommen. Mehr wird bis zum Agent Rollout nicht gemacht.

[matze502]

Hallo!

Was für ein Clientbetriebssystem ist das?
Funktioniert es wenn das Passwort nicht direkt mitgegeben wird, also dies manuell bei "Rückfrage" eingegeben wird?

hth
MH

Hallo mhaegele,

nein, in diesem Fall wird das Passwort ebenfalls falsch verarbeitet. Der erste Buchstabe vom Passwort wird samt dem Trenner % für winexe durch "opsi-deploy-client-agent" ersetzt.

Gruß

[n.wenselowski]

Hallo matze502,

mich würde gerade noch interessieren, ob vielleicht folgendes hilft.
Bitte sichere dir das deploy-Script weg und dann ersetze im Script die Zeile (müsste 102 sein):

Code: Alles auswählen

return execute( u"%s -U '%s' //%s '%s'" % (winexe, username + '%' + password.replace("'", "'\"'\"'"), host, cmd) )

durch:

Code: Alles auswählen

return execute(u"{winexe} -U '{credentials}' //{client} '{command}'".format(winexe=winexe, credentials=u'%'.join((username, password.replace("'", "'\"'\"'"))), client=host, command=cmd))

Ändert sich dadurch etwas?


Gruß

Niko

[matze502]

Hallo n.wenselowski,

danke für den Tip, aber ich fürchte, das funktioniert ebenfalls nicht. Mit dem -vvvvv habe ich allerdings folgenden Eintrag entdeckt gerade:

Code: Alles auswählen

[info] Executing: /usr/bin/winexe -U '[DOMAIN]\[USERNAME]Posix.py[Rest vom Passwort]' //[HOSTNAME] 'cmd.exe /C "del /s /q c:\tmp\opsi-client-agent_inst && rmdir /s /q c:\tmp\opsi-client-agent_inst || echo not found"'

Das heisst, er hat an der Stelle, wo eigentlich das %F hängt, Posix.py eingefügt.

Gruß Matze

[n.wenselowski]

Hallo matze,

ich glaube, wir haben momentan zwei Probleme.
Das eine ist die Meldung im Log. Spezialität des opsi-Loggers ist, dass er %F (mit großem F) durch den Dateinamen ersetzt, wenn er eine Logmeldung ausgibt. Das sorgt in Zusammenhang mit dem Passwort für die merkwürdige Logmeldung. Das scheint kosmetischer Natur zu sein. Daran habe ich im ersten Moment gar nicht weiter gedacht

Das zweite Problem ist die Meldung NT_STATUS_BAD_INITIAL_PC. Das ist das eigentliche Problem.
Stimmen die Vorbedingungen für die Integration?
Welche Version der winexe wird eingesetzt?


Gruß

Niko

[matze502]

Guten Morgen Niko,

die Voraussetzungen stimmen soweit. Wie o.g. ist der Client ein frisch aufgesetztes Windows 7 pro und wurde nur in die Domäne aufgenommen sowie IP-Adresse festgelegt. Der Account, mit dem der Agent installiert wird, hat lokale Admin-Rechte und an den Freigaben wurde nichts verändert.
Die Winexe fürs deployment ist die, welche mit OPSI geliefert wird.

Code: Alles auswählen

# /var/lib/opsi/depot/opsi-client-agent/winexe -V
Version 4.0.0tp4-SVN-build-10231

Gruß Matze

[opsi.simi]

Hi,
versuch es doch mal damit:

Code: Alles auswählen

/var/lib/opsi/depot/opsi-client-agent# ./opsi-deploy-client-agent -u Administrator -p Password. -c -s pc16.domain

so hat es bei mir zumindest funktioniert

freu mich auf eine Info ob es geklappt hat

VLG Opsi.Simi