OPSI Windows Client (win7sp1-x64) sieht Netzwerkfreigabe nicht

[jensgw]

Moin Zusammen,

OPSI scheint sehr vielversprechend zu sein um einem Admin viel Arbeit abzunehmen. Leider lässt es sich nicht richtig testen, denn der Windows Client sieht beim Ausführen von Events die Netzwerkfreigabe die er eigentlich einbinden sollte nicht (zumindest bei mir) und somit schlägt die Ausführung fehl.

Ein manuelles Starten von Opsiscripts auf einem manuell eingebunden Depot, funktioniert erst wenn ein Setting in der Registry geändert wird - vorher zeigt wins32.exe keine verbundenen Netzlaufwerke (mit Open Script). (Setting http://www.winability.com/how-to-make-e ... rk-drives/). Jedoch ist das auch keine Lösung, da das automatische Starten nach wie vor fehlschlägt.

Auszug aus clientconnect:
(582) [3] [Mar 08 15:55:23] [ event processing gui_startup ] Failed to update action processor: [Error 5] Zugriff verweigert (EventProcessing.pyo|531)

Auszug aus instlog:
(57) [4] [Mrz 08 16:36:51:848] [swaudit] Warning: file not found :p:\swaudit\swaudit.opsiscript - giving up
(58) [4] [Mrz 08 16:36:51:849] [swaudit] Script p:\swaudit\swaudit.opsiscript not found File Err. No. 5 (Zugriff verweigert<) - retrying

In den Logs steht "Zugriff verweigert" das ist nicht ganz richtig. Der selbe Eintrag kam bei dem Versuch ein Opsiscript zu starten ohne das Registry setting zu setzen. Daher gehe ich eher davon aus, dass der automatische Prozess die Freigabe nicht sieht. (Zugriffsrechte stimmen, von Hand geht's ja dann mit den Registryfix)...

Grüß Jens

[ueluekmen]

Hallo Jens,

nutzt du unsere VM oder hast du den Server manuell installiert? Schon mal ein:

sudo opsi-set-rights

auf dem Server probiert? Als root kannst du sudo weglassen.

[jensgw]

Der Server ist selber aufgesetzt:
-Debian Jessie
-mitglied im AD
-Nutzer und Gruppen sind im AD
-#getent group|grep opspi liefert
opsifileadmins10006:opsiconfd,pcpatch
opsiadmin10007:opsiconfd,pcpatch

Netboot mit hwaudit geht.

Hab nochmal opspi-set-rights ausgeführt - keine Änderung im Verhalten.
Skripte selber starten geht (nach registry fix) - über den opsiclient nicht.

Wenn ich samba auf die finger schaue, klappt die Anmeldung des opsiclients auch:
- check_ntlm_password: Checking password for unmapped user [MEGABOOK]\[pcpatch]@[MEGABOOK] with the new password interface
- check_ntlm_password: mapped user is: [OPSI]\[pcpatch]@[MEGABOOK]
- Forcing Primary Group to 'Domain Users' for pcpatch
- check_ntlm_password: sam authentication for user [pcpatch] succeeded
- check_ntlm_password: authentication for user [pcpatch] -> [pcpatch] -> [pcpatch] succeeded
Das wars dann aber schon, nach dateien fragt er nicht mehr - was sich damit deckt, dass der Client das Mapping nicht sieht ...
Manuelles einbinden des Mappings über GPO oder alternativ batch Datei (net use) des Depots beim Systemstart bringt auch keine Änderung.

[wolfbardo]

-Nutzer und Gruppen sind im AD

Und pcpatch?

Gruss
Bardo Wolf

[jensgw]

Die Nutzer opsiconfd und pcpatch sind auch im AD.

Mal ein größerer Auszug aus der Logdatei - hie fängts ja schon an bevor er zum scripte ausführen kommt.
(2381) [5] [Mar 09 12:41:50] [ event processing on_demand{user_logged_in}] Updating action processor (EventProcessing.pyo|398)
(2382) [5] [Mar 09 12:41:50] [ event processing on_demand{user_logged_in}] Mounting depot share smb://opsi/opsi_depot (EventProcessing.pyo|366)
(2383) [6] [Mar 09 12:41:50] [ event processing on_demand{user_logged_in}] Added depot 'opsi' to trusted domains (EventProcessing.pyo|375)
(2384) [5] [Mar 09 12:41:50] [ event processing on_demand{user_logged_in}] Mounting '\\opsi\opsi_depot' to 'p:' (Windows.pyo|775)
(2385) [5] [Mar 09 12:41:50] [ event processing on_demand{user_logged_in}] Updating action processor from depot dir 'p:\opsi-winst\\files\\opsi-winst' (EventProcessing.pyo|445)
(2386) [3] [Mar 09 12:41:50] [ event processing on_demand{user_logged_in}] Failed to update action processor: [Error 5] Zugriff verweigert (EventProcessing.pyo|531)
(2387) [5] [Mar 09 12:41:50] [ event processing on_demand{user_logged_in}] Starting action processor in session '1' on desktop 'default' (EventProcessing.pyo|819)

Den Zugriff aufs Depot hab ich dann manuell getestet mit den usern pcpatch und opsiconfd - das funktionierte.

[wolfbardo]

Die Nutzer opsiconfd und pcpatch sind auch im AD.

opsiconfd im AD ist nach meinem persoenlichen Geschmack exotisch.

pcpatch wuerde ich ohne Not auch nicht ins AD setzen.

Ach so: Was fuer eine AD ? (Samba 4 oder ...)

Evtl hilft die Anpassung von

clientconfig.depot.user

auf

[<domaene>\pcpatch]

Gruss
Bardo Wolf

[jensgw]

Der AD ist ein Samba 4. Nach dem opsi manual: "Furthermore, the user pcpatch has to be created as a fully-fledged domain user and not as a system user anymore." Das Einbauen des Domänenennamens in clientconfig.depot.user hat leider auch nichts gebracht. Was opsiconfd betrifft, damit der User in der Gruppe opsiadmin sein kann muss er ja auch in der Domäne sein.

Wenn ich mich als pcpatch am Client anmelde und z.B. das Skript für swaudit oder opsi-winpe starte funktioniert das. Die gleiche Aktion gestartet über "on-demand" funktioniert nicht.

Kann man den Loglevel fürs opsclientd.log noch höher stellen?

[uncle_scrooge]

>>Kann man den Loglevel fürs opsclientd.log noch höher stellen?
Siehe hier: viewtopic.php?f=7&t=8513&p=37408&hilit= ... vel#p37408

[wolfbardo]

Nach dem opsi manual:...

ok, erstmal Asche auf mein Haupt.

Nichtsdestotrotz wuerde ich mir beim Testen die AD-Anbindung sparen.

Was alles schief laufen kann:

- Dateirechte auf dem depot_share (Da hwinvent als Netboot klappt, koennte hier der Hund begraben sein)
- gibts noch die lokalen user opsiconfd und pcpatch
- pcpatch passwoerter mussen sambs-seitig und opsi-seitig gesetzt sein

Kann man den Loglevel fürs opsclientd.log noch höher stellen?

Ja, in der opsiclientd.conf

Gruss
Bardo Wolf

[jensgw]

- Dateirechte auf dem depot_share (Da hwinvent als Netboot klappt, koennte hier der Hund begraben sein)
- gibts noch die lokalen user opsiconfd und pcpatch
- pcpatch passwoerter mussen sambs-seitig und opsi-seitig gesetzt sein

-Dateirechte passen, pcpatch und opsiconfd haben Zugriff auf die Freigaben.
-Lokale Nutzer gibt's keine, hab extra nochmal den OPSI-Server neu aufgesetzt, und OPSI nach dem Domain join installiert (fai, wers nicht kennt, geht voll ab -> http://fai-project.org/).
-pcpatch Passwort wurde gesetzt im AD und mit opsi-admin auf dem Server.

So, jetzt aber: ERFOLG!!1elf
Danke für den Tipp wo die opsiconfd config rumliegt - dort stand als User nur pcpatch drin. Nachdem ich dort auch die Domäne hinzugefügt hab geht's jetzt. Yeah! Man darf also den Client Agent erst installieren nachdem man clientconfig.depot.user auf dem Server mit Domäne gesetzt hat.
Von selber wird das wohl nicht aktualisiert?

Danke für eure schnelle Hilfe!