Racktable bien pour la gestion DC, baies, machines, vps, plan adressage, vlan, connexions, il est extensible par tes propres classes genre ajouter un champs SLA a appliquer sur l'équipement ou pourquoi pas licence. Par contre on a été un peu coincé dans l'adressage ipv6, certaines attribution de vps, mais ça fait bien 3 ans qu'on l'a pas touché.
GLPI et FusionInventory, bien sur le principe car on y voyait un racktable associé à un outil de ticketing. Néanmoins c'est trop orienté gestion de parc bureautique et on a pas réussi à trouver le modèle que l'on voulait. Autre point agaçant, l'application des SLA doit se faire suivant des règles à définir, une simple liste déroulante nous aurait suffit en fait. Pour la partie ticketing, choix entre interface complète ou interface simple. On a pas pu faire la vue que l'on voulait pour les clients à savoir sujet, importance, élément concerné (vps, serveur, ...) et message en vue simple. En vue complète si on enlevait des champs vu pour le client ça nous les enlevait aussi genre la SLA (on va pas laisser le choix de la sla au client ...) Bref on a arrêté de l'utiliser.
Du coup on a recapitalisé sur la supervision et on a rendu dépendant nos outils à la supervision. Ainsi impossible de se connecter sur une vps ou serveur ou équipement sur l'accès centralisé si l'élément n'est pas présent en supervision. L'avantage c'est qu'on a plus d'oubli, les sauvegardes configurent automatiquement les nouveaux éléments, la métrologie aussi, il nous manque plus que l'association avec Redmine qu'on utilise pour le ticketing mais qui a l'énorme inconvénient d'être en Ruby. On a beau essayé de faire des modules, ça ne va pas dans la direction que l'on souhaite. Pire Ruby n'est pas du tout sysadm friendly, quand on met à jour Redmine le nombre de dépendance à mettre à jour par gem est tel qu'il est impossible d'avoir plusieurs projets Ruby sur la même plate-forme sauf à faire un chroot ...