Forum Tranquil IT

Bonjour,

je suis en train de développer un paquet "Template-setup" qui viendrait simplet exécuter un script python dans le setup.py (sans installation de logiciel ni rien).
Ce script permet de chercher des différences entre l'arborescence du paquet et l'arborescence d'un logiciel déjà installé sur la machine utilisateur et d'effectuer un simple "copyto".
Le problème : exécuté en local via PyScripter, le script fonctionne parfaitement avec les chemins correctement déclarés etc... Mais une fois uploadé en tant que paquet et déployé sur les machines utilisateurs, celui-ci ne s'exécute pas et retourne un "error" dans le statut du paquet.

Est-ce un problème de droits d'accès, de case à cocher ou juste d'emplacement d'exécution ?

Merci d'avance,
Cordialement


----------
WAPTConsole Entreprise version 2.6.0.17392

à tester :
subprocess.Popen([r"C:\Program Files (x86)\wapt\waptpythonw.exe", makepath(basedir,'script_externe.py')])

Merci pour votre réponse mais je ne pense pas que ce soit ça.
Je m'explique : je cherche à faire de la manipulation de fichier/dossier dans la machine utilisateur. Cette manipulation s'effectuerait via un script écrit dans le setup.py
Vraisemblablement, il y a quelque chose qui bloque l'initialisation du paquet uploadé sur les machines :-/

D'ailleurs, j'ai tester avec un setup.py complètement vide et... le paquet se déclare en "ERROR" aussi

Bonjour,
Quels sont les chemins déclarés ? Des chemins utilisateurs ?
Il faut savoir que les paquets WAPT sont installés en compte système contrairement à PyScripter que vous devez probablement lancer en tant qu'administrateur.

Bonne journée,
Bertrand

Bonjour,

je déclare le chemin comme à l'intérieur du "C:".
Quand vous dites qu'il se lance en tant que compte système, il y a un moyen de lui donner des droits?

Merci beaucoup d'avance,

Bonjour Lazare,

comme le disait Bertrand, l'agent Wapt s'exécute en compte LOCAL SYSTEM de la machine. Il y a quelques différence par rapport à un fonctionnement dans une session utilisateur, notamment à la présence d'un bureau ou des différents chemin de fichier par défaut, et sur les accès à des ressources distantes (SYSTEM a accès au credentials du compte machine, mais pas ceux d'un utilisateur de la machine).

Les droits sont ceux de S-1-5-18 (NT Authority\System), qui s'affiche en tant que "Système" dans un explorateur sur un Windows en Français.

Vous pouvez tester votre script en le faisant tourner en PSExec pour voir le problème. La commande suivante permet d'ouvrir un shell en tant que local system (vous pouvez installer psexec avec le paquet tis-ms-pstools), bien sûr il faut la lancer avec un compte qui a les droits admin local et dans un context sécurité élevé.
Cordialement,

Denis