[R] Conseil de sécurité pour Autoit - Mysql(gestion de logs)
Règles du forum
- Merci de consulter la section "Règles du forum" et plus particulièrement "Règles et Mentions Légales du site autoitscript.fr" avant d'écrire un message.
-
Piloupilou
- Niveau 2

- Messages : 27
- Enregistré le : sam. 26 févr. 2011 13:42
- Status : Hors ligne
[R] Conseil de sécurité pour Autoit - Mysql(gestion de logs)
Bonjour, en ce moment, j'utilise autoit et ocs pour déployer des applications.
Ocs me sert à déposer le paquet sur la(les) machine ciblées, puis execute le script autoit en tant que system.
Le probleme c'est que pour OCS si le paquet est bien exécute il est forcément réussis (succes)
Par exemple : J'ai mis à jour un programme sur 60 machines, ocs m'a donné 60 succés, puis j'ai recherché parmis les 60, lesquels ont réellement le logiciel (l'agent ocs le sait)
et 50 en sont ressortis
Ce qui veut dire que 10 sont passés à la trappe.
Pour affiner plus précisément ces 10 j'ai fait une base de données, avec une table "uc", une table "paquet" et
une table "évènement" qui a "uc" et "paquet" comme clef primaire, et en plus qui renseigne la date et l'heure de l'installation du paquet sur l'uc et SURTOUT l'etat du log (succes ou erreur) ET le détail du log.
Ainsi je peux savoir que à 10:30 le xx/xx/xxxx le paquet xxx s'est installé sur la machine xxx et le script a sortie le log suivant : xxxxxxxxx
En phase de test ca marche. Le driver odbc permet à une machine distante de se connecter à la base et d'y faire des requetes...
Par contre si je veux faire ca en production, je ne peux pas me permettre que tout les postent interrogent directement le serveur de base de donnée.
Auriez vous des conseils ou idées pour faire ça de façon plus sécurisées. De rajouter un intermédiaire ?
J'espere que je n'étais pas trop flou dans mes explications, bonne journée
Ocs me sert à déposer le paquet sur la(les) machine ciblées, puis execute le script autoit en tant que system.
Le probleme c'est que pour OCS si le paquet est bien exécute il est forcément réussis (succes)
Par exemple : J'ai mis à jour un programme sur 60 machines, ocs m'a donné 60 succés, puis j'ai recherché parmis les 60, lesquels ont réellement le logiciel (l'agent ocs le sait)
et 50 en sont ressortis
Ce qui veut dire que 10 sont passés à la trappe.
Pour affiner plus précisément ces 10 j'ai fait une base de données, avec une table "uc", une table "paquet" et
une table "évènement" qui a "uc" et "paquet" comme clef primaire, et en plus qui renseigne la date et l'heure de l'installation du paquet sur l'uc et SURTOUT l'etat du log (succes ou erreur) ET le détail du log.
Ainsi je peux savoir que à 10:30 le xx/xx/xxxx le paquet xxx s'est installé sur la machine xxx et le script a sortie le log suivant : xxxxxxxxx
En phase de test ca marche. Le driver odbc permet à une machine distante de se connecter à la base et d'y faire des requetes...
Par contre si je veux faire ca en production, je ne peux pas me permettre que tout les postent interrogent directement le serveur de base de donnée.
Auriez vous des conseils ou idées pour faire ça de façon plus sécurisées. De rajouter un intermédiaire ?
J'espere que je n'étais pas trop flou dans mes explications, bonne journée
Modifié en dernier par Piloupilou le dim. 10 avr. 2011 11:32, modifié 1 fois.
- zeshrek
- Niveau 10

- Messages : 984
- Enregistré le : mer. 17 nov. 2010 09:31
- Localisation : Sur ma chaise
- Status : Hors ligne
Re: [..] Conseil de sécurité pour Autoit - Mysql
Si j'ai bien compris, c'est en fait ton script autoit qui effectue l'installation proprement dite.
Donc 2 solutions, soit c'est ton script qui ne sait pas identifier que l'installation a échouée, soit il ne sait pas renvoyer cette information d'échec a OCS
Soit, bien sur, les deux.
Donc la question que je vais te poser, c'est comment fonctionne ton script d'install ?
Renvoie t il en sortie un code d'erreur ?
Pour que l'inventaire fonctionne d'apres ce que j'en ai vu il faut que ton appli soit présente dans add/remove programs. Donc si la remontée d'inventaire l'indique présente alors que l'install est un echec, c'est que ton script dépose les clés de registre dans HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall avant l'echec du script, ou bien que ton script ne s'arrete pas sur l'erreur qui bloque l'install, et donc qu'il se termine et rend la main avec un code erreur OK.
Bref, dans tous les cas de figure, a priori je dirais qu'il faut creuser du coté de ton script...
Donc 2 solutions, soit c'est ton script qui ne sait pas identifier que l'installation a échouée, soit il ne sait pas renvoyer cette information d'échec a OCS
Soit, bien sur, les deux.
Donc la question que je vais te poser, c'est comment fonctionne ton script d'install ?
Renvoie t il en sortie un code d'erreur ?
Pour que l'inventaire fonctionne d'apres ce que j'en ai vu il faut que ton appli soit présente dans add/remove programs. Donc si la remontée d'inventaire l'indique présente alors que l'install est un echec, c'est que ton script dépose les clés de registre dans HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall avant l'echec du script, ou bien que ton script ne s'arrete pas sur l'erreur qui bloque l'install, et donc qu'il se termine et rend la main avec un code erreur OK.
Bref, dans tous les cas de figure, a priori je dirais qu'il faut creuser du coté de ton script...
Si vis pacem para bellum
-
Piloupilou
- Niveau 2

- Messages : 27
- Enregistré le : sam. 26 févr. 2011 13:42
- Status : Hors ligne
Re: [..] Conseil de sécurité pour Autoit - Mysql
Alors on a decouvert une fonction d'ocs qui nous evite de passer par une base de donnée externe.
Ocs permet de dire aux agents d'aller lire une clef de registre et de la remonter.
Du coup serait il possible et pas trop degueu de créér une ruche de registre (je sais pas encore precisement l'emplacement) dans laquelle chaque script d'installation y concatenerai ses erreurs de log.
Le resultat attendu serait :
- je deploie un paquet via ocs
- le script ocs contient une variable "détail_erreur_log" qui concatene les differentes erreurs
qui peuvent se produire
- il place cette valeur dans le registre "fictif" que l'on créé pour l'occasion
- l'agent se synchronise avec le serveur
et enfin
- en faisant une recherche multicritere contenant le paquet XXX et la clef de registre XXXX
j'obtiendrai (peut etre
) le pourquoi des pc dont l'install a foiré
Est ce que tu penses qu'il y a possibilité ?
ou alors il est dangereux de créér des registres fictif ?
merci
Ocs permet de dire aux agents d'aller lire une clef de registre et de la remonter.
Du coup serait il possible et pas trop degueu de créér une ruche de registre (je sais pas encore precisement l'emplacement) dans laquelle chaque script d'installation y concatenerai ses erreurs de log.
Le resultat attendu serait :
- je deploie un paquet via ocs
- le script ocs contient une variable "détail_erreur_log" qui concatene les differentes erreurs
qui peuvent se produire
- il place cette valeur dans le registre "fictif" que l'on créé pour l'occasion
- l'agent se synchronise avec le serveur
et enfin
- en faisant une recherche multicritere contenant le paquet XXX et la clef de registre XXXX
j'obtiendrai (peut etre
Est ce que tu penses qu'il y a possibilité ?
ou alors il est dangereux de créér des registres fictif ?
merci
- sksbir
- Niveau 7

- Messages : 384
- Enregistré le : lun. 26 oct. 2009 17:57
- Localisation : Lyon
- Status : Hors ligne
Re: [..] Conseil de sécurité pour Autoit - Mysql
bonjour
si on travaille sur ajout/suppression de programme, alors le script peut aller lire l'entrée dans ajout/suppression de programme après avoir installé le programme. Si le programme est présent, c'est OK, sinon, c'est qu'il y a eu un soucis.
Sinon, pourquoi avoir utilisé OCS pour déployer ? Il existe d'autres solutions...
si on travaille sur ajout/suppression de programme, alors le script peut aller lire l'entrée dans ajout/suppression de programme après avoir installé le programme. Si le programme est présent, c'est OK, sinon, c'est qu'il y a eu un soucis.
Sinon, pourquoi avoir utilisé OCS pour déployer ? Il existe d'autres solutions...
-
Piloupilou
- Niveau 2

- Messages : 27
- Enregistré le : sam. 26 févr. 2011 13:42
- Status : Hors ligne
Re: [..] Conseil de sécurité pour Autoit - Mysql
on utilise ocs car on pas totalement la main sur les gpo et l'AD,
il est tres pratique pour certaine choses (encore faut il savoir quelles existent
)
A l'aide des OU d'active directory on peut déployer des agents dont le tag correspond au service ou a la salle.
- Donc on peut selectionner les pc par service ou salle etc
- le déploiement de paquet se fait assez facilement, et les retour de stat sont tres complet, (sauf pour le rappatriement de l'erreur specifique du log d'erreur)
- pas eu encore le temps d'explorer trop d'autres solutions
- la base d'ocs est tres accessible et nous permet de le coupler à d'autres infrastructures, pour par exemple croiser les donnees d'un inventaire manuel, d'un annuaire ...
etc
je suis d'accord mais ma question c'est :
est ce que ce OK ou erreur, on peut l'inscrire dans une base de registre "fictive" pour que OCS puisse le consulter aisement
il est tres pratique pour certaine choses (encore faut il savoir quelles existent
A l'aide des OU d'active directory on peut déployer des agents dont le tag correspond au service ou a la salle.
- Donc on peut selectionner les pc par service ou salle etc
- le déploiement de paquet se fait assez facilement, et les retour de stat sont tres complet, (sauf pour le rappatriement de l'erreur specifique du log d'erreur)
- pas eu encore le temps d'explorer trop d'autres solutions
- la base d'ocs est tres accessible et nous permet de le coupler à d'autres infrastructures, pour par exemple croiser les donnees d'un inventaire manuel, d'un annuaire ...
etc
si on travaille sur ajout/suppression de programme, alors le script peut aller lire l'entrée dans ajout/suppression de programme après avoir installé le programme. Si le programme est présent, c'est OK, sinon, c'est qu'il y a eu un soucis.
je suis d'accord mais ma question c'est :
est ce que ce OK ou erreur, on peut l'inscrire dans une base de registre "fictive" pour que OCS puisse le consulter aisement
- zeshrek
- Niveau 10

- Messages : 984
- Enregistré le : mer. 17 nov. 2010 09:31
- Localisation : Sur ma chaise
- Status : Hors ligne
Re: [..] Conseil de sécurité pour Autoit - Mysql
tu aurais meilleur compte de faire sortir ton script avec un code erreur <> 0 quand il rencontre un pb, ce qui (normalement) devrait permettre a OCS de detecter que la sortie de ce qu'il install n'est pas OK et donc de le mentionner dans son rapport de télédistribution
Tu peux aussi en profiter pour faire loguer les actions a ton script d'install de facon a ensuite (plus)facilement trouver la source du pb.
Si tu veux je peux te filer le template d'installeur que j'ai fait pour le client ou je suis.
(et par pitié laisse tomber ton histoire de registry 'fictive'. la registry n'est pas faite pour stocker des infos de ce gnere, pour ca il y a les fichiers de log !)
Tu peux aussi en profiter pour faire loguer les actions a ton script d'install de facon a ensuite (plus)facilement trouver la source du pb.
Si tu veux je peux te filer le template d'installeur que j'ai fait pour le client ou je suis.
(et par pitié laisse tomber ton histoire de registry 'fictive'. la registry n'est pas faite pour stocker des infos de ce gnere, pour ca il y a les fichiers de log !)
Si vis pacem para bellum
-
Piloupilou
- Niveau 2

- Messages : 27
- Enregistré le : sam. 26 févr. 2011 13:42
- Status : Hors ligne
Re: [..] Conseil de sécurité pour Autoit - Mysql
(et par pitié laisse tomber ton histoire de registry 'fictive'. la registry n'est pas faite pour stocker des infos de ce gnere, pour ca il y a les fichiers de log !)
Code : Tout sélectionner
tu aurais meilleur compte de faire sortir ton script avec un code erreur <> 0 quand il rencontre un pb, ce qui (normalement) devrait permettre a OCS de detecter que la sortie de ce qu'il install n'est pas OK et donc de le mentionner dans son rapport de télédistribution
exemple dans ocs : parmis les uc qui ont eu le paquet XXXX lesquel ont (ou n'ont pas) le logiciel XXXX version XXX
....
c'est ce que tu dis apres qui m'interesse car je m'interesse au pourquoi ca n'a pas marché
alors je comprend pas trop ce que tu veux direTu peux aussi en profiter pour faire loguer les actions a ton script d'install de facon a ensuite (plus)facilement trouver la source du pb.
dans mes scripts, je créé un fichier de log avec le détail des erreurs, mais le problème c'est qu'il reste sur la machine.... et du coup c'est dommage de devoir aller sur chaque machine pour voir l'erreur en question
Si tu veux je peux te filer le template d'installeur que j'ai fait pour le client ou je suis.
je veux bien merchi
- zeshrek
- Niveau 10

- Messages : 984
- Enregistré le : mer. 17 nov. 2010 09:31
- Localisation : Sur ma chaise
- Status : Hors ligne
Re: [..] Conseil de sécurité pour Autoit - Mysql
je confirmePiloupilou a écrit :(et par pitié laisse tomber ton histoire de registry 'fictive'. la registry n'est pas faite pour stocker des infos de ce gnere, pour ca il y a les fichiers de log !)je suis convaincu que ce n'est pas la bonne solution
Non, ce que je te dis c'est que ton installeur sorte avec un code X au lieu de 0Piloupilou a écrit :la ça n'est pas nécessaire car pour le "1 ça marche et 0 ca marche pas" je peux déja le faire avec ocs,Code : Tout sélectionner
tu aurais meilleur compte de faire sortir ton script avec un code erreur <> 0 quand il rencontre un pb, ce qui (normalement) devrait permettre a OCS de detecter que la sortie de ce qu'il install n'est pas OK et donc de le mentionner dans son rapport de télédistribution
exemple dans ocs : parmis les uc qui ont eu le paquet XXXX lesquel ont (ou n'ont pas) le logiciel XXXX version XXX
....
Du coup OCS (normalement) en déduit que comme le code de retour qu'il récupere n'est pas zero (qui veut dire que tout s'est bien passé) l'install a échoué.
Ce qui fait que le pb que tu évoquais dans ton premier post ne se poserait pas. Sur les 60 machines le rapport indiquerait 50 réussites et 10 echecs.
Je m'en doutePiloupilou a écrit :c'est ce que tu dis apres qui m'interesse car je m'interesse au pourquoi ca n'a pas marché
Ce que je veux dire c'est que apres chaque action dans le script (copie d'un fichier, création d'une clé de registre, execution d'une commande...etc) tu dois vérifier que tu n'as pas d'erreur, et si tu en as une, l'indiquer dans le log, et sortir de ton script en retournant a ton tour un code erreur pour OCS.Piloupilou a écrit :alors je comprend pas trop ce que tu veux direTu peux aussi en profiter pour faire loguer les actions a ton script d'install de facon a ensuite (plus)facilement trouver la source du pb.
dans mes scripts, je créé un fichier de log avec le détail des erreurs, mais le problème c'est qu'il reste sur la machine.... et du coup c'est dommage de devoir aller sur chaque machine pour voir l'erreur en question
pour le fichier de log, rien ne t'empeche de le mettre ailleur que sur la machine, tu peux le déposer sur un UNC par exemple, ou dans un dossier partagé.
Moi je le dépose en local (apres je mappe la machine si je veux le consulter), mais là c'est toi qui vois.
Cadeau :Piloupilou a écrit :je veux bien merchiSi tu veux je peux te filer le template d'installeur que j'ai fait pour le client ou je suis.
► Afficher le texte
Si vis pacem para bellum
-
Piloupilou
- Niveau 2

- Messages : 27
- Enregistré le : sam. 26 févr. 2011 13:42
- Status : Hors ligne
Re: [..] Conseil de sécurité pour Autoit - Mysql
AAAhhh bin oui je comprend mieux. ExactNon, ce que je te dis c'est que ton installeur sorte avec un code X au lieu de 0
Du coup OCS (normalement) en déduit que comme le code de retour qu'il récupere n'est pas zero (qui veut dire que tout s'est bien passé) l'install a échoué.
Ce qui fait que le pb que tu évoquais dans ton premier post ne se poserait pas. Sur les 60 machines le rapport indiquerait 50 réussites et 10 echecs.
Ensuite je regarde ton script, je crois qu'il a l'air bien mais qu'il me faudra quelques jours pour l'assimiler
Je vais essayer de decrypter le debut, attention il y aura surement des grosses boulettes
- Tu commence par des autoit wrapper (alors deja je ne sais pas encore a quoi ca sert ... desolé
- declaration de variables en tout genre ( dont le chemin du script)
- et la que voisje !!! une clef de registre "logiciel compagnie ??" elle existait avant ou cest topi qui l'a créé ?
- si l'apprealease existe tu donne la valeur correspondante a la clef de registre
- ensuite tu compte la taille de la variable apname + "install" ...
- et la un "main()" je sais pas ce quil vient faire ici
- ensuite ca a lair de lancer une interface graphique pour choisir les argument d'installation
- puis tu créé un fichier de log et apres ca on met le script d'install désiré
et apres tu fais plein de truc avec les registres alors que tu m'a dit de pas en créér, snif, j'ai le cerveau qui fume
------------------------
question a part, tes utilisateurs ne ralent pas quand tu leur envoi cette fenêtre d'install ? est ce que ils sont prévenus avant ?
(ou alors cest fait que pour des techniciens?)
- zeshrek
- Niveau 10

- Messages : 984
- Enregistré le : mer. 17 nov. 2010 09:31
- Localisation : Sur ma chaise
- Status : Hors ligne
Re: [..] Conseil de sécurité pour Autoit - Mysql
Principe de base : l'ogre a toujours raisonPiloupilou a écrit :AAAhhh bin oui je comprend mieux. ExactNon, ce que je te dis c'est que ton installeur sorte avec un code X au lieu de 0
Du coup OCS (normalement) en déduit que comme le code de retour qu'il récupere n'est pas zero (qui veut dire que tout s'est bien passé) l'install a échoué.
Ce qui fait que le pb que tu évoquais dans ton premier post ne se poserait pas. Sur les 60 machines le rapport indiquerait 50 réussites et 10 echecs.
meuh non, tu vas voir, c'est tout simplePiloupilou a écrit :Ensuite je regarde ton script, je crois qu'il a l'air bien mais qu'il me faudra quelques jours pour l'assimiler
Ca sert au moment de la compilation. ca permet de mettre un icone (celui du logo du client en l'occurence), et a faire apparaitre qq infos quand tu fais un clic droit / propriétés sur l'exe.Piloupilou a écrit :Je vais essayer de decrypter le debut, attention il y aura surement des grosses boulettes![]()
- Tu commence par des autoit wrapper (alors deja je ne sais pas encore a quoi ca sert ... desolé)
Pas du tout indispensable.
Tu oublies le cartouche de commentaires, bien pratique pour celui qui reprendra mon script quand ma mission sera finie (je ne suis que prestataire...), et les includes.Piloupilou a écrit :- declaration de variables en tout genre ( dont le chemin du script)
Sinon, je ne déclare pas le chemin du script, mais :
- le chemin ou seront déposés les fichiers ($Destinationpath) qui est un sous répertoire de l'endroit ou est déposé le script
- le chemin vers le fichier de log ($CheminFichierlog)
C'est moi qui l'ai créée.Piloupilou a écrit :- et la que voisje !!! une clef de registre "logiciel compagnie ??" elle existait avant ou cest topi qui l'a créé ?
C'est cette clé qui sert pour l'inventaire. Toutes les applis qu'on installe créent une entrée dans cette clé. Et l'entrée est supprimée a la désinstall.
Oui, par défaut (release 1) la clé de registre ne mentionne pas de release. par contre si on refait une release, on la modifie.Piloupilou a écrit :- si l'apprealease existe tu donne la valeur correspondante a la clef de registre
Non, en fait je prépare le texte de la GUI, et cette petite bidouille qui consiste a prendre les 24 derniers caracteres d'unc chaine de X espaces + "install " + $Appname me permet de centrer a peu pres le nom de l'install dans le champs a l'affichage (je sais j'aurai pu utiliser la fonction de centrage, mais a ce moment là le reste du contenu de la gui aurait été centré)Piloupilou a écrit :- ensuite tu compte la taille de la variable apname + "install" ...
le main() appelle la fonction principale (main en anglais), c'est elle qui fait tout, puisque apres, on quitte le programmePiloupilou a écrit :- et la un "main()" je sais pas ce quil vient faire ici
Presque.Piloupilou a écrit :- ensuite ca a lair de lancer une interface graphique pour choisir les argument d'installation
Avant je check si il y a des paramettres passé au script. Par exemple (en admetant que mon script compilé s'apelle toto.exe)
toto.exe /i
toto.exe -install
toto-exe /remove
Si les parametres sont "I", "/I", "-I", "INSTALL", "/INSTALL", "-INSTALL", on part sur la fonction d'installation, si ils sont "X", "/X", "X", "R", "/R", "R", "REMOVE", "/REMOVE", "U", "/U", "UNINSTALL", "/UNINSTALL", on part sur la fonction de désinstallation, si c'est autre chose ou rien, on part sur la gui
Bien sur dans tous les cas il y a création d'une entrée dans le fichier de log
En fait le fichier de log est créé bien avant, puisque apres les initialisations de variables, c'est la premiere chose qui est faite (1ere ligne de main() )Piloupilou a écrit :- puis tu créé un fichier de log et apres ca on met le script d'install désiré
je ne t'ai jamais dit de pas créer de clés de registre, juste qu'y stocker des logs c'est pas la bonne idée.Piloupilou a écrit :et apres tu fais plein de truc avec les registres alors que tu m'a dit de pas en créér, snif, j'ai le cerveau qui fume
Bon, tu as donc du partir sur le cas d'une install.
Tiens en relisant le script je me rend compte qu'il ya une clé que j''ai pas fait créer via la fonction faite pour. mais peu importe.
Les clés en question sont celles qui seront mises dans le fameux Logiciels compagnie de tout a l'heure, qui nous serviront pour l'inventaire
Bin en fait quand c'est télédistribué, le soft de télédistrib passe un parametre donc uas de pb, c'est silencieux, par contre si un tech doit faire une intervention de réinstallation a la main, il double clique sur l'exe et il a l'interface.Piloupilou a écrit : question a part, tes utilisateurs ne ralent pas quand tu leur envoi cette fenêtre d'install ? est ce que ils sont prévenus avant ?
(ou alors cest fait que pour des techniciens?)
Si vis pacem para bellum
-
Piloupilou
- Niveau 2

- Messages : 27
- Enregistré le : sam. 26 févr. 2011 13:42
- Status : Hors ligne
Re: [..] Conseil de sécurité pour Autoit - Mysql
chouette, merci pour tes explications ca va beaucoup nous aider.
Par contre tu dis plusieurs fois "inventaire"
Merci et bonne journée
(et j'imagine que votre appli de télédéploiement est propriétaire? Mais bon avec ocs on peut deposer le script et executer avec argument donc ca devrait pouvoir fonctionner aussi)
Par contre tu dis plusieurs fois "inventaire"
Tu parle d'un inventaire qui te fait remonter l'info comme quoi le programme est bien installé ?C'est cette clé qui sert pour l'inventaire. Toutes les applis qu'on installe créent une entrée dans cette clé. Et l'entrée est supprimée a la désinstall.
Merci et bonne journée
(et j'imagine que votre appli de télédéploiement est propriétaire? Mais bon avec ocs on peut deposer le script et executer avec argument donc ca devrait pouvoir fonctionner aussi)
- zeshrek
- Niveau 10

- Messages : 984
- Enregistré le : mer. 17 nov. 2010 09:31
- Localisation : Sur ma chaise
- Status : Hors ligne
Re: [..] Conseil de sécurité pour Autoit - Mysql
oui l'inventaire c'est un script qui tourne sur les machines toutes les x heures et qui compare ce qu'il trouve dans logiciel compagnie et ce qu'il avait avant. Quand il y a une différence (donc qu'une install a été faite depuis la dernière fois) il envoie la mise a jour au serveur qui gere le parc de logiciels, celui ci compare avec ce qui devrait etre la liste des applis du poste, et si il faut il envoie les commandes d'installations complémentaire ou de désinstallations si il y a un truc qui est la alors qu'il devrait pas.
Ca c'est la théorie, dans la pratique, je sais pas exactement comment ca tourne au détail pres vu que c'est un dev interne qui date de bien avant mon arrivée
Ca c'est la théorie, dans la pratique, je sais pas exactement comment ca tourne au détail pres vu que c'est un dev interne qui date de bien avant mon arrivée
Si vis pacem para bellum
-
Piloupilou
- Niveau 2

- Messages : 27
- Enregistré le : sam. 26 févr. 2011 13:42
- Status : Hors ligne
Re: [R] Conseil de sécurité pour Autoit - Mysql(gestion de l
Je passe le sujet en résolu et je le renomme car on a un peu dévié. Et merci car ce que tu m'a dis me fais avancer .... à mon rythme ! mais avancer tout de meme 
- zeshrek
- Niveau 10

- Messages : 984
- Enregistré le : mer. 17 nov. 2010 09:31
- Localisation : Sur ma chaise
- Status : Hors ligne
Re: [R] Conseil de sécurité pour Autoit - Mysql(gestion de l
No problemo.
Il y a juste un détail, tu peux combiner le script que je t'ai donné avec DirInstall. J'utilise les 2 quasi quotidiennement au bureau (pas toujours envie/besoin de faire un MSI, c'est pour ca qu eje les ai faits) et c'est plutot pratique.
pas encore 100% au point, mais si tu dois faire un script qui dépose pas mal de fichier, ca devrait bien te simplifier la vie...
Il y a juste un détail, tu peux combiner le script que je t'ai donné avec DirInstall. J'utilise les 2 quasi quotidiennement au bureau (pas toujours envie/besoin de faire un MSI, c'est pour ca qu eje les ai faits) et c'est plutot pratique.
pas encore 100% au point, mais si tu dois faire un script qui dépose pas mal de fichier, ca devrait bien te simplifier la vie...
Si vis pacem para bellum
Re: [R] Conseil de sécurité pour Autoit - Mysql(gestion de l
Salut
Pour ton histoire de logs d'erreurs... je remonte également des infos d'installation dans ma base OCS, sans passer par la base de registre ni par une source ODBC.
L'exécutable Autoit qui s'exécute sur le poste client envoie directement les logs au serveur en passant par l'appel d'un script PHP que j'ai créé sur le serveur OCS.
En gros :
Du côté du serveur OCS, le fichier PHP monScript.php récupère les variables $_GET["poste"], $_GET["package"] et $_GET["log"] et exécute une requête SQL pour insérer les logs dans la table LOGS que j'ai créé.
Il faut par contre éviter d'utiliser des caractère spéciaux (accents, espaces, sauts de lignes), ou alors les convertir en code HTML (espace = %20 par exemple)
J'espère avoir pu t'aider dans ta réflexion
Pour ton histoire de logs d'erreurs... je remonte également des infos d'installation dans ma base OCS, sans passer par la base de registre ni par une source ODBC.
L'exécutable Autoit qui s'exécute sur le poste client envoie directement les logs au serveur en passant par l'appel d'un script PHP que j'ai créé sur le serveur OCS.
En gros :
Code : Tout sélectionner
$erreur = 0
_logOCS("Demarrage_Installation")
; Code ....
; .....
If $erreur = 1 Then _logOCS("Echec_installation")
Func _logOCS($texte)
InetGet("http://serveurOCS/monScript.php?poste=" & @ComputerName & "&package=" & @ScriptName & "&log=" & $text , @TempDir & "\requeteOCS.txt", 1 )
EndFuncIl faut par contre éviter d'utiliser des caractère spéciaux (accents, espaces, sauts de lignes), ou alors les convertir en code HTML (espace = %20 par exemple)
J'espère avoir pu t'aider dans ta réflexion
Le script, ça fait gagner beaucoup de temps... à condition d'en avoir beaucoup devant soi !

