You are not logged in.
Bonjour,
J'ai juste quelques petites questions:
Premierement, informations sur le parc:
70 sites physiques / 7000 U.C. repartient sur tous les sites / Connexion SDSL 5M UP&Down / Serveur Intel Xeon 3Ghz x4 et 6Go de Ram / Nécéssité d'avoir un seul serveur GLPI globalisant toutes les infos / Il n'y a pas de données sensibles et 0€ pour mener ce projet à bien.
Maintenant que le decor est planté :-( voici la question:
Quelles sont les solutions qui ne fonctionneront pas dans l'état actuel et quelles sont celle qui sont réalisables sans devoir profondement modifier glpi et ocs parmi les propositions suivantes:
Solution 1:
Un serveur centrale avec GLPI et OCS sur celui-ci et chaque U.C. envoie les informations via le web (mise en place d'une solution gérant les imports/exports pour éviter la surcharge)
Solution 2:
Un serveur externe avec GLPI et 70 "serveurs"* OCS qui renvoyent les informations toujours via internet à GLPI.
Solution 3:
Un "serveur"* GLPI/OCS et export import automatique des 70 BDD GLPI vers un GLPI central.
Solution 4:
Un "serveur"* GLPI/OCS par site et visualisation des informations via 70 adresses web...
*Possibilité de récup un poste par site ayant pour config., Intel 1Ghz et 128Mo voir 256Mo de Ram maximum.
Pour être sur que personne ne se méprenne, je ne demande pas comment mettre en place telle ou telle solution!
Je souhaite juste l'avis d'expert et savoir quelle sont les solutions possible à mettre en place ou non.
De fait, si vous ne savez pas, ne perdez pas de temps sur ma question et si vous savez, indiqué juste "Solution 2 et 4" par exemple.
Si vous pouvez également préciser pour les solutions 2 et 3 si il y a de grosse modifs à réaliser pour la mise en relation des deux solutions ou de GLPI à GLPI.
Amicalement
Offline
=> Solution 1
3 => impossible (trop de développement : pas de solution de fusion actuellement)
+
Dév. Fedora 29 - PHP 5.6/7.0/7.1/7.2/7.3/7.4 - MariaDB 10.3 - GLPI master
Certifié ITILv3 - RPM pour Fedora, RHEL et CentOS sur https://blog.remirepo.net/
Offline
Solution 1 également (la 2 ça va être pareil sauf que tu vas avoir pleins de serveurs ocs à maintenir, donc sur ce point, c'est moins bien)
Offline
Je dirais solution 1 aussi, sachant que la surcharge il ne devrais pas y en avoir avec OCS, vu que les agents OCS ne remonte pas tous en même temps les infos. Donc même pas besoin de gérer des imports/export.
Offline
Idem ! C'est un plébiscite pour la 1
C'est clairement la solution la mieux, la 2 marcherait mais une vrai galere lors des mises a jour d'OCS
La 3 fonctionnerait pas et la 4 est encore pire que la 2
Offline
Bonjour ,
je repond IDEM la 1 comme CedricR et les autres .
"Je dirais solution 1 aussi, sachant que la surcharge il ne devrais pas y en avoir avec OCS, vu que les agents OCS ne remonte pas tous en même temps les infos. Donc même pas besoin de gérer des imports/export." parole de Maitre CedricR
Systeme : GLPI 0.91 - DEBIAN 7 - APACHE
Offline
Bonjour ,
parole de Maitre CedricR
Merci c'est trop d'honneur, mais faut pas en faire trop quand même
Offline
Solution 1 (mise en place chez nous avec 336 entités distantes)
Un serveur pour OCS et un pour GLPI avec synchro entre les 2 avec le plugin massocsimport (cela permet de bien suivre la synchro)
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline
Solution 1 mise en place au boulot avec plus de 300 entités et 30 000 UC.
Aucun problème de surcharge.
JMD / Jean-Mathieu Doléans - Glpi-project.org - Association Indepnet
Apportez votre pierre au projet GLPI : Soutenir
Offline
Un énorme merci à vous tous!..
La solution1 est celle que je préfère aussi. Merci à yllen aussi pour le nom du plugin massocsimport ;-)
Je vous tiendrais informé lorsque la mise en place sera opérationnelle.
Si vous pouviez juste me dire combien de temps vous a pris le deploiement sur votre parc avec le nombre d'entités?
Encore merci à vous pour votre retour d'expérience ;-)
Offline
Cela peut être très rapide ou un peu plus long , tout dépend de la rapidité du déploiement des agents ocs sur les UC.
JMD / Jean-Mathieu Doléans - Glpi-project.org - Association Indepnet
Apportez votre pierre au projet GLPI : Soutenir
Offline
SI vous êtes capable à distance de deployer automatiquement l'agent ocs, alors je dirais que c'est rapide.
Sachant qu'il existe "l'OCS Inventory NG Agent Deployment Tool" qui permet de definir une plage d'adresse ip sur lesquel installé l'agent ocs sur des machines windows ou linux.Ce qui permet de gagner du temps. Ensuite la remontée des informations et plus ou moins longue suivant quand se declanche l'agent ocs sur la machine.
Offline
Juste un petit truc qui m'intrigue, lorsque OCS est installé dans une entité, il récupère les information sur les périphériques réseaux comme les imprimantes etc... En étant hébergé à l'exterieur des sites, recupère-t-il toujours ces infos ou faut-il installer un plugin ou autre?
Merci
Offline
idem que les auttres solution 1 les yeux fermés
Ocs-ng 2.2
Glpi 9.1.1
Offline
quand c'est possible, un seul serveur OCS et un seul GLPI c'est forcément mieux
ça évite des scripts, des synchros multiples, et forcément des risques de désynchronisations
donc je vote solution 1 moi aussi
Offline
Juste un petit truc qui m'intrigue, lorsque OCS est installé dans une entité, il récupère les information sur les périphériques réseaux comme les imprimantes etc... En étant hébergé à l'exterieur des sites, recupère-t-il toujours ces infos ou faut-il installer un plugin ou autre?
Merci
l'agent OCS recupere tout les infos de la machine sur lequel il est installé. Il permet aussi si vous avez des imprimantes reseaux conncetée sur la machine de les importés, mais il ne recuperera que le nom et pas l'ip, il faudra passer un peu à la main pour ça. Mais je crois qu'il est prevu dans les evolutions de l'agent que ce soit possible.
Sachant aussi que certain agent peuvent servir à decouvrir du materiel connecté au reseau.
Pour ce qui est des switch ou des petites choses dans le genres ocs ne les interroge pas, par contre il est possible de recuperer des informations avec le plugin tracker.
Pour cela il faut au minimum saisir (ou importer) les switch avec un nom est une adresse ip. et que le snmp soit activé sur les switch et vous pourrez recuperer quelques informations. D'ailleur le plugin tracker peux aussi être utiliser pour recupérer des informations sur les imprimantes
J'espère ne pas être trop confus
Offline
Aucun soucis et merci CédricR, tout est parfaitement compréhensible.
Peut être pas la dernière question mais pas loin:
JMD et yllen, vos entité communique entre elle via VPN ou internet simplement?
Merci.
Offline
Les 2 sont possibles, en général c'est par VPN
Offline
Par internet ca signifie laisser le serveur OCS accessible depuis le net
je suis pas ultra fan
Offline
Je suis d'accord que c'est à ch... question securité mais cela fait partie des contraintes du projet pour le moment. Vais voir si l'on ne peu pas résoudre ce problème mais sans réel espoir.
En tous cas, encore merci, vos conseils me sont très utiles.
Si jamais il y a quelques chose qui vous semblerait bien que je sache avant la mise en place, n'hésitez pas
Offline
Si tu passe par internet faut le HTTPS avec certificat SSL
Offline
Si tu passe par internet faut le HTTPS avec certificat SSL
qui ne marche pas avec l'agent ocs windows...
Offline
Oui pas encore (mais très bientôt) ^^
Offline
... lol merci d'avoir prévenu sinon me serait rendu fou ^^
Offline