OPSI Windows Client (win7sp1-x64) sieht Netzwerkfreigabe nicht
OPSI Windows Client (win7sp1-x64) sieht Netzwerkfreigabe nicht
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
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
Re: OPSI Windows Client (win7sp1-x64) sieht Netzwerkfreigabe nicht
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.
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.
opsi support - uib gmbh
For productive opsi installations we recommend support contracts.
http://www.uib.de
For productive opsi installations we recommend support contracts.
http://www.uib.de
Re: OPSI Windows Client (win7sp1-x64) sieht Netzwerkfreigabe nicht
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.
-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.
Re: OPSI Windows Client (win7sp1-x64) sieht Netzwerkfreigabe nicht
Und pcpatch?jensgw hat geschrieben: -Nutzer und Gruppen sind im AD
Gruss
Bardo Wolf
OPSICONF 2024
https://opsi.org/en/opsiconf/
Basisworkshop Mainz :
17. - 20. 06. 2024
opsi support - uib gmbh
For productive opsi installations we recommend maintainance + support contracts which are the base of opsi development.
http://www.uib.de
Re: OPSI Windows Client (win7sp1-x64) sieht Netzwerkfreigabe nicht
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.
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.
Re: OPSI Windows Client (win7sp1-x64) sieht Netzwerkfreigabe nicht
opsiconfd im AD ist nach meinem persoenlichen Geschmack exotisch.jensgw hat geschrieben:Die Nutzer opsiconfd und pcpatch sind auch im AD.
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
OPSICONF 2024
https://opsi.org/en/opsiconf/
Basisworkshop Mainz :
17. - 20. 06. 2024
opsi support - uib gmbh
For productive opsi installations we recommend maintainance + support contracts which are the base of opsi development.
http://www.uib.de
Re: OPSI Windows Client (win7sp1-x64) sieht Netzwerkfreigabe nicht
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?
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?
-
- Beiträge: 650
- Registriert: 21 Feb 2012, 12:03
- Wohnort: Mainz
Re: OPSI Windows Client (win7sp1-x64) sieht Netzwerkfreigabe nicht
>>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
Siehe hier: viewtopic.php?f=7&t=8513&p=37408&hilit= ... vel#p37408
Re: OPSI Windows Client (win7sp1-x64) sieht Netzwerkfreigabe nicht
ok, erstmal Asche auf mein Haupt.jensgw hat geschrieben:Nach dem opsi manual:...
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
Ja, in der opsiclientd.confjensgw hat geschrieben: Kann man den Loglevel fürs opsclientd.log noch höher stellen?
Gruss
Bardo Wolf
OPSICONF 2024
https://opsi.org/en/opsiconf/
Basisworkshop Mainz :
17. - 20. 06. 2024
opsi support - uib gmbh
For productive opsi installations we recommend maintainance + support contracts which are the base of opsi development.
http://www.uib.de
Re: OPSI Windows Client (win7sp1-x64) sieht Netzwerkfreigabe nicht
-Dateirechte passen, pcpatch und opsiconfd haben Zugriff auf die Freigaben.wolfbardo hat geschrieben: - 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
-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!