Ce n'est pas l'installation de l'agent le soucis. C'est si j'installe un paquet, n'importe lequel, j'utilise une technique en deux couches :
- paquet zip ayant un script install.bat à l'intérieur qui s'occupe de tout
- copie du zip via ocs.
Le soucis est qu'OCS me lance le script install.bat avec une fenetre cmd.exe donc visible par l'utilisateur. Donc je met un cmdow en début de ce script. Il y a peut être mieux à faire mais c'est la seule méthode que j'ai trouvé fiable et maintenable.
Pourquoi cette méthode ? Ainsi, les tests sont très facile à faire et je ne dépends pas d'OCS trop fortement. De plus, si un utilisateur veut installer sur sa machine perso un paquet, il copie le zip et se débrouille tout seul (c'est sa machine après tout !).
Pour ce qui est de la gestion via les priorités, c'est ce que l'on fait, notamment pour LaTeX ou il y avait un ordre d'installation à suivre. Le principal soucis et de pouvoir sélectionner plusieurs paquets d'un coup pour ne pas en oublier, donc pas trop cliquer ;-)
Pour le retour des messages lors d'une installation, c'est vrai que si cela pouvait remonter sur le serveur, ce serait bien. Ces Windows, c'est incroyable, ca marche avec 49 postes mais il y en a toujours un qui merde...
J'ai eu un seul gros soucis avec OCS, c'était il y a quelques années, le certificat est arrivé a expiration (Certificat CNRS = 2 ans, cela passe vite). La, je me suis dis que le truc était merdique car on ne pouvait pas mettre 6 mois avant deux certificats dans l'agent pour préparer la transition. Au final, je me suis retrouvé coincé. Je m'en suis sortis par une entourloupette, au démarrage de la session utilisateur, j'ai balancé une commande en runas sur un compte admin pour modifier le certificat sous Program_Files... crade et pas sécurisé pour un sous mais en ne disant rien, les utilisateurs n'ont rien vu !
Autres idées dans le futur, l'agent OCS pourrait tourner sur un compte d'admin et non sous le compte SYSTEM, ou les installations pourrait se faire sous un compte d'admin (comme cela, il y a une sandbox par installation). Pourquoi ? En fait, le compte SYSTEM n'a pas de ruche donc il y a parfois des programmes qui marchent pas sous ce compte et il faut bidouiller. Un exemple simple qui me vient en tête est psexec par exemple qui depuis qu'il a été repris par Crosoft demande un EULA. L'acceptation de cet EULA est stocké dans la base de registre de la personne, chose impossible pour le compte SYSTEM. C'est pas forcément l'exemple le plus typique pour OCS mais je sais que de temps en temps, on doit bidouiller car nos scripts marchent en interactif sous l'administrateur du domaine mais pas via OCS sous le compte SYSTEM.
[^] # Re: FusionInventory
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche OCS Inventory NG 2.0 RC1. Évalué à 2.
- paquet zip ayant un script install.bat à l'intérieur qui s'occupe de tout
- copie du zip via ocs.
Le soucis est qu'OCS me lance le script install.bat avec une fenetre cmd.exe donc visible par l'utilisateur. Donc je met un cmdow en début de ce script. Il y a peut être mieux à faire mais c'est la seule méthode que j'ai trouvé fiable et maintenable.
Pourquoi cette méthode ? Ainsi, les tests sont très facile à faire et je ne dépends pas d'OCS trop fortement. De plus, si un utilisateur veut installer sur sa machine perso un paquet, il copie le zip et se débrouille tout seul (c'est sa machine après tout !).
Pour ce qui est de la gestion via les priorités, c'est ce que l'on fait, notamment pour LaTeX ou il y avait un ordre d'installation à suivre. Le principal soucis et de pouvoir sélectionner plusieurs paquets d'un coup pour ne pas en oublier, donc pas trop cliquer ;-)
Pour le retour des messages lors d'une installation, c'est vrai que si cela pouvait remonter sur le serveur, ce serait bien. Ces Windows, c'est incroyable, ca marche avec 49 postes mais il y en a toujours un qui merde...
J'ai eu un seul gros soucis avec OCS, c'était il y a quelques années, le certificat est arrivé a expiration (Certificat CNRS = 2 ans, cela passe vite). La, je me suis dis que le truc était merdique car on ne pouvait pas mettre 6 mois avant deux certificats dans l'agent pour préparer la transition. Au final, je me suis retrouvé coincé. Je m'en suis sortis par une entourloupette, au démarrage de la session utilisateur, j'ai balancé une commande en runas sur un compte admin pour modifier le certificat sous Program_Files... crade et pas sécurisé pour un sous mais en ne disant rien, les utilisateurs n'ont rien vu !
Autres idées dans le futur, l'agent OCS pourrait tourner sur un compte d'admin et non sous le compte SYSTEM, ou les installations pourrait se faire sous un compte d'admin (comme cela, il y a une sandbox par installation). Pourquoi ? En fait, le compte SYSTEM n'a pas de ruche donc il y a parfois des programmes qui marchent pas sous ce compte et il faut bidouiller. Un exemple simple qui me vient en tête est psexec par exemple qui depuis qu'il a été repris par Crosoft demande un EULA. L'acceptation de cet EULA est stocké dans la base de registre de la personne, chose impossible pour le compte SYSTEM. C'est pas forcément l'exemple le plus typique pour OCS mais je sais que de temps en temps, on doit bidouiller car nos scripts marchent en interactif sous l'administrateur du domaine mais pas via OCS sous le compte SYSTEM.
En tout cas, merci pour tout.