Finalement, nous ne comptons plus proposer LIAM pour la remontée des configurations machines
voici un résumé des raisons : - les fichiers perl de traitement des mails recu avec la configuration en XML ont besoin de légèrement trop de dépendances (31 archives installées pour faire tourner le truc)... - les scripts perl en question se trouvent dans un sous répertoire d'un des 2 users qu'on doit créer, et vu l'architecture du truc, ca risque fort de tomber terre si on installe les scripts dans /usr/local/bin - le fichier de conf qui permet d'accéder au serveur postgres contient le mot passe de l'administrateur de la base de donnée en clair, et ce fichier est lisible par tout le monde (d'après ce que j'ai pu remarquer) du coté de l'interface web : - le serveur apache doit tourner sous l'uid d'un des 2 utilisateurs créés. - il est proposé ce faire tourner le serveur apache dédié à liam sur le port 5050. de fait, pour le faire tourner sur le port 80 sous l'uid d'un user autre que root, il faut ajouter celui-ci au groupe root, en priant que personne ne choppe le mot de passe du user quelques "légers" problèmes de sécurité donc... On préfère donc attendre la fusion des OCS4all et OCSInventory en espérant que ca prenne pas trop de temps, sinon il se pourrait que l'on code la remontée des config nous meme, en utilisant simplement les scripts de récupération déja écrits, et en gérant autrement l'envoie client -> serveur, et la gestion des infos dans la DB Voila notre nouveau point de vue après avoir passé 2h à installer les modules perl, configuré le serveur et essayé de voir ce que donnait la partie web avant d'abandonné face aux choses bizarres trouvées dans le code... nicodache On Tue, 15 Mar 2005 12:35:19 +0100, JMD <[EMAIL PROTECTED]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > nicodache a écrit : > | Bonjour, > (...) > | Suite à des demandes de la part de nos clients, nous sommes > | actuellement en train d'étudier la possibilité d'intégrer un outil de > | remontée automatique de configuration qui est compatible Windows, > | Linux et Mac OS X. > > C'est même une demande forte de la communauté d'utilisateurs de GLPI. > > | Nommé Liam, et développé par des étudiants dans le cadre de leur > | travail de fin d'étude, c'est écrit en perl et ca fonctionne comme > | ceci : > (...) > | (plus d'info sur http://cri.univ-mlv.fr/liam/index.html). > > Nous avons déjà étudié Liam qui nous semblait prometteur sur le papier > mais aprés réflexion ce n'est pas l'outil que nous avons retenu pour le > moment pour les raisons suivantes : > > - - Depuis 1 an le projet Liam a l'air en stand by. Il semblerait que ce > projet soit le résultat du travail de stagiaires ce qui expliquerait > désormais l'absence de suivi... > De plus la communauté d'utilisateur semble extrèmement réduite. > > - - L'utilisation de protocoles multiples ne facilitent pas l'installation. > > - - Liam necessite nécessite Perl avec Qq extensions (pricipe PAR) > > - - Liam necessite PostgreSql > > Nos reflexions porte actuellement sur deux autres outils qui vont > d'ailleurs normalement fusionner : OCSinventory et OCS4all. > > http://ocsinventory.sourceforge.net/fr/index.php > http://ocs4all.sourceforge.net/ > > Nous avons de trés bons contacts avec la trés sympathique et performante > ~ équipe d'OCS4all et ces derniers souhaitent véritablement interfacer > OCS avec GLPI. > > Certaines discussions à ce sujet sont disponibles sur le forum de glpi. > > Hasard du calendrier la fusion OCSinventory et OCS4all devrait > correspondre avec la sortie de la 0.5 de GLPI. Ce qui nous permettra de > nous atteler à l'interfaçage OCS-GLPI en collaboration avec l'équipe > élargie d'OCS pour la version 0.6 de GLPI. > > Cordialement, > > > - -- > JMD / Jean-Mathieu Doléans > Association Indepnet > http://indepnet.net > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.5 (GNU/Linux) > > iD8DBQFCNsh3yQar2dfQ77ARAkFsAJ4jSa7mfhbImcdcf5mreS7rvzTvhwCeKr8X > Z9T2LjfaGEY7jqIL3FSLJEU= > =tdIS > -----END PGP SIGNATURE----- > > _______________________________________________ > Glpi-dev mailing list > Glpi-dev@gna.org > https://mail.gna.org/listinfo/glpi-dev >
