Monitoring et Gestion réseau unifiée: Z-Eye 1.2

Posté par  (site web personnel) . Édité par Xavier Teyssier, palm123, NeoX, Pierre Jarillon et rewind. Modéré par Pierre Jarillon. Licence CC By‑SA.
Étiquettes :
17
1
août
2013
Supervision

Z-Eye est une solution libre basée sur plusieurs autres outils libres (netdisco, MRTG, icinga…) destinée à offrir une solution de supervision système, réseau et sécurité unifiée, tout en permettant la gestion complète d'un réseau.

En avril dernier était présenté la version 1.0 de Z-Eye. Depuis, elle a fait un bon bout de chemin, que ce soit en amélioration de code ou en modernisation de l'interface. De nouvelles fonctionnalités sont apparues afin d'améliorer le quotidien des techniciens et administrateurs gérant l'outil.

Mercredi 31 juillet Z-Eye est sortie dans sa version 1.2.

Le developpeur a choisi de zapper la présentation de la 1.1, qui n'est au final qu'une version de modernisation, n'apportant pas de nouveautés fonctionnelles importantes.

Pour rappel, Z-Eye s'appuie sur FreeBSD 9.1 et est codée à l'origine en PHP

Sommaire

Beaucoup d'améliorations ont été apportées durant ces deux dernières versions, visant à alléger la charge de l'interface web, mais également à moderniser le code, améliorer les performances globales et l'expérience utilisateur.

Service Z-Eye

Un nouveau service expérimental est apparu dans la version 1.1 destiné à remplacer les tâches cron faisant appel à divers scripts PHP. Ce service est développé en python (2.7). Bénéficiant ainsi des technologies de python telles que le multithreading, il a été possible de paralléliser beaucoup de tâches, augmentant la charge CPU sur le serveur mais diminuant énormément les temps de collecte (suivant les tâches cela peut aller de 1/2 à 1/50).
En 1.2 le service Z-Eye s'est étoffé puisqu'on lui a permis de faire disparaître 80% des tâches cron en service, et intègre deux nouveaux composants:

  • DatabaseUpgrader: un outil qui permet de mettre automatiquement la base de données à jour lors du lancement du service (après une mise à jour de la solution), ou bien de la demander à tout moment sans relancer un service en cours
  • DHCPManager: un outil de distribution de configuration DHCP, j'y reviendrai plus loin

Modernisation du code

PHP5

Beaucoup de code était écrit en PHP 4, basé sur mon expérience personnelle du PHP. Les constructeurs et classes ont été modernisées afin d'utiliser les constructeurs PHP5, classes abstraites et finales

Le code a été également aéré, et des commentaires ont été ajoutés là où cela s'avère nécessaire pour la compréhension du code. Un gros travail de normalisation de l'écriture est en cours, continuant pour la prochaine version 1.3. La libFSS (le coeur de développement de Z-Eye) a déjà été normalisée en profondeur, mais le plus gros reste à faire, sur la couche Z-Eye. Cela ne veut pas pour autant dire que le code est incompréhensible, bien au contraire !

Ajax, jQueryUI

jQuery et jQueryUI ont conquis le coeur du développement de Z-Eye. L'ancien code statique a été basculé sur une version dynamique, apportant plus de modernisme à l'application et allégeant le contenu des requêtes échangées entre serveur et clients.

On retrouve beaucoup de modules basés sur des onglets de type jQueryUI, mais également beaucoup de fenêtres de formulaires basées sur les popup jQueryUI.

Gestionnaire IP

Le gestionnaire IP est un tout nouveau module basé sur l'ancien module de collecte DHCP, permettant de gérer des DHCP UNIX de type ISC-DHCP.

Ce type de DHCP étant le plus répandu, il a été nécessaire d'apporter un soin tout particulier à sa configuration. Z-Eye sait gérer la majorité des configurations DHCP, mais ne gère pas leur partie générique (options globales).

En termes de fonctionnalités, on retrouvera dans l'IPM Z-Eye les fonctionnalités suivantes:

  • déclaration de serveurs DHCP : par le biais connexion SSH, hérité des version 1.0 et 1.1 ;
  • déclaration de clusters DHCP : notion propre à Z-Eye permettant de regrouper la configuration par ensemble. Pour ISC-DHCP, seuls deux membres sont autorisés, dû à la notion de failover peer ;
  • déclaration d'options DHCP : personnalisées, valuées et groupées, avec possibilité de les relier à des sous-réseaux ou des hôtes ;
  • déclaration de sous-réseaux DHCP : routeur, DNS principal, secondaire, durée de baux… avec ajout de quelques données administratives (vlan ID, alias et description) ;
  • gestion des IP par sous-réseaux : possibilité d'ajouter/exclure des plages d'adresses IP à la volée, possibiliter de mettre des données administratives sur les adresses IP (commentaire), réserver une adresse IP (nom d'hôte, adresse MAC) et lui attribuer des groupes d'options DHCP. Lors d'une réservation dans une plage dynamique, la plage est automatiquement coupée afin de respecter les best practices ISC ;
  • gestion fine des droits : suivant le même modèle que pour le gestionnaire de commutateurs, on retrouvera les droits suivants : lecture, gestion des serveurs, utilisation des outils avancés, gestion des (groupes d') options DHCP, gestion des ranges, des IP, des subnets… Ces droits peuvent être attribués de manière globale, et, pour certains, par sous-réseau.

Le service Z-Eye intègre également la partie permettant de pousser les configurations DHCP provenant de Z-Eye. Le service se connecte en SSH à chacun des serveurs et pousse la configuration dans des fichiers dédiés (chemin personnalisable). Il écrit également la valeur 1 dans un fichier de /tmp afin qu'un script puisse redémarrer le service DHCP local. Afin de ne pas redémarrer le service toutes les minutes, la configuration est comparée (hash md5) afin de savoir si elle doit être modifiée ou non.

Le délai de développement n'a malheureusement pas permis d'éliminer la tâche cron de collecte des données DHCP, néanmoins celle-ci devrait être éliminée pour la version 1.3, et intégrée au service Z-Eye (DHCPManager), permettant d'assurer une meilleur cohérence dans la collecte des données.

Plus d'informations sur le gestionnaire IP

Mises à jour logicielles

Entre temps, les logiciels libres utilisés ont évolué, apportant leurs lots de nouveautés et de fixes. On notera surtout:

  • Netdisco 1.3.1
  • Icinga 1.9.3
  • PERL 5.16.3
  • Apache 2.4.6

Le plus compliqué dans ces upgrades a été de devoir patcher netdisco afin de l'obliger à se construire avec Apache 2.4 (bien que mod_perl ne soit pas utilisé car pas compatible avec Apache 2.4), et de revoir le système de droits d'Apache, qui a changé depuis la version 2.2. L'upgrade a néanmoins permis de bénéficier de l'unification d'Apache MPM au sein d'Apache. Apache2.4 et MPM ont permis une amélioration notable des performances en terme de temps de réponse.

Vous trouverez la liste complète des logiciels utilisés dans cette version ici: http://z-eye.org/Liste_des_ports_%281.2%29

Correctifs

Hormis quelques correctifs d'affichage, Z-Eye était pénalisé par peu de bugs gênants :

  • quelques corrections sur les info-bulles ;
  • des corrections de stabilité sur différents modules ;
  • quelques problèmes de droits résolus ;
  • d'autres corrections plus ou moins intéressantes.

Performances

Plusieurs correctifs ont été ajoutés afin de mettre en cache divers éléments et améliorer ainsi les performances:

  • Les communautés SNMP sont désormais mises en cache au lieu d'être demandées pour chaque appel à une MIB ;
  • Le speed reporting lit le fichier de statut icinga au lieu de parser l'interface web ;
  • La modification d'un port de commutateur (via SNMP) ne modifie que les données nécessaires (excepté le trunk allowed vlan) ;
  • Les groupes de l'utilisateur sont mis en cache (optimisation système de droits) ;
  • Un appel SQL a été optimisé afin de ne demander que le strict minimum à la base de données.
  • Les performances de mise en cache SNMP ont été améliorées entre la version 1.1 et 1.2

Chiffres

Quelques chiffres concernant Z-Eye:

  • Nombre de fichiers PHP: 120
  • Nombre de fichiers Python: 18
  • Nombre de lignes de code totales: 33373 (sans lignes vide: 30564)
  • Nombre de lignes de code Python: 2183 (sans lignes vide: 1944)
  • Nombre de lignes de code PHP: 28471 (sans lignes vide: 26247)
  • Nombre de lignes de code CSS: 975 (sans lignes vide: 849)
  • Nombre de lignes de code JS: 1744 (sans lignes vides: 1524, environ 3/4 sont des JS externes)

Nombre de différences entre la version 1.0 et 1.2:

git diff --shortstat cd647fa2ce50b7c02d9337abce3e2d8379693fe1 126f982325f9aa18fee18021bdc1464cb47f31dd
 267 files changed, 29991 insertions(+), 22871 deletions(-)

Nombre de différences entre la version 1.1 et 1.2

git diff --shortstat 9fc3334bcba6c276105c2bd7e29a8bdbdbf90648 126f982325f9aa18fee18021bdc1464cb47f31dd
 141 files changed, 10998 insertions(+), 4455 deletions(-)

C'est à vous !

Toute suggestion, remarque ou idée est bienvenue, afin que chacun puisse apporter sa pierre à l'édifice.

Je cherche toujours quelques contributeurs au développement de l'outil (PHP/Python), ayant encore énormément d'idée afin d'étendre la portée de Z-Eye sur un réseau (j'insiste bien sur l'aspect réseau). Le développement devrait s'accélérer dans les prochains mois, ayant un peu plus de temps libre. Que ce soit un correctif, une fonction, une amélioration de code existant, toute contribution est la bienvenue !

Aller plus loin

  • # Correctif

    Posté par  (site web personnel) . Évalué à 4.

    Le plus compliqué dans ces upgrades a été de devoir patcher netdisco afin de l'obliger à se construire avec Apache 2.4 (bien que mod_perl ne soit pas utilisé car pas compatible avec Apache 2.4), et de revoir le système de droits d'Apache, qui a changé depuis la version 2.2.

    mod_perl est compatible avec apache 2.4 grâce au travail de RedHat rejoint par Debian. L'avenir n'est pas encore assuré pour mod_perl mais pour le moment il continu de fonctionner très bien.

    • [^] # Re: Correctif

      Posté par  (site web personnel) . Évalué à 2. Dernière modification le 01 août 2013 à 14:55.

      D'accord, il faudra que je le signale aux mainteneurs de l'arbre de ports de FreeBSD, et que je voie si le port n'est pas trop ancien, ce qui expliquerait le problème.

      Merci de la précision

      Veepee & UNIX-Experience

  • # Beau travail

    Posté par  (Mastodon) . Évalué à 2.

    Le projet semble intéressant, je vois sur le site qu’il est prévu d’ajouter la gestion de DNS bind, ça me permettrait peut-être à terme de fusionner netdisco et dynamic-dnsupdate que j’utilise aujourd’hui séparément. D’ailleurs, si tu ne connais pas, la bibliothèque utilisée par ce projet doit permettre de faire à peut-près toutes les récupérations et mises à jour de zones utilise.

    Est-il possible d’ajouter soit même de nouveaux types de switchs, ou des « images de face avant » ? Est-il également possible d’utiliser des clés SSH pour les connexions aux serveurs et switchs à la place du mot de passe ?

    • [^] # Re: Beau travail

      Posté par  (site web personnel) . Évalué à 1.

      Merci landry pour la bibliothèque mais il est prévu d'utiliser dnspython afin de faire la collecte via AXFR et faire du dnsupdate.

      Pour les faces avant, pour l'instant ce n'est pas malheureusement pas possible l'algorithme est trop statique, il faut que je prenne le temps de le réécrire pour qu'il soit adapté à chaque modèle de switch en fonction des ports trouvés (28 ports gbit = 24 + 4 en général, 50 ports = 48 + 2 …). Cette fonctionnalité devrait en théorie être réécrite pour la version 1.3 elle est dans ma todo list depuis la 1.1, mais la 1.2 ne visait pas à améliorer autre chose que les performances concernant les switches.

      Pour les clefs SSH ce n'est pas encore prévu, je n'ai pas regardé comment faire du côté PHP, côté python j'ai vu comment faire. Si tu as quelques compétences de développement, n'hésite pas à patcher la classe SSH php et la classe SSH python afin de supporter l'authentification par clefs. Il me suffira ensuite de modifier les handlers de connexion pour s'adapter à ce mode de connexion (un select + un peu d'ajax devraient le faire).

      Pour la partie DNS quelle serait ta vision ? Ma vision est de me baser entièrement sur le système d'ACL des serveurs named afin de gérer les options de chacune des zones DNS. Ensuite, comme l'ensemble du module IPManager, il est prévu que je me base sur une notion de cluster DNS (à 1, 2 ou plus membres) dont un serveur est maître, les autres automatiquement configurés en slave comme il faut.
      Autres fonctions:
      * Ajouter les fonctionnalités de sécurité d'un DNS (récursivité, transferts…)
      * Eventuellement un versionning de zone un peu comme chez gandi (à confirmer)
      * Un mode mirroring de zone qui va permettre de "répliquer" une zone dans un autre (exemple: tu veux qu'une zone alpha.org aie exactement les mêmes enregistrements qu'une zone beta.org).

      Ce sera développé petit à petit au mois d'août, pendant que mon chantier de refactoring de code. N'hésitez pas à participer et proposer des patches sur des fonctionnalités. Les API de Z-Eye ne sont pas encore documentées mais cela viendra (et elles ne sont pas compliquées, hormis certains des nouveaux générateurs d'interface).

      Veepee & UNIX-Experience

      • [^] # Re: Beau travail

        Posté par  (Mastodon) . Évalué à 2.

        Pour la lib en effet si les AXFR et nsupdates sont fait en backends, il vaut mieux utiliser le module python équivalent, je m’attendais à ce que ce soit fait directement par le frontend php.

        Si je trouve un peu de temps, je regarderais les code des classes SSH…

        Pour la partie DNS, je ne sais pas si les ACLs Bind permettent d’atteindre une granularité intéressante sans devenir d’une complexité sans nom, je pense qu’il faut que les fichiers de conf restent lisibles par un humain. Côté conf, il n’y a pas tant de type de clusters que ça, il faut prévoir je pense une conf master / slave classique et une où le maître est caché. Il faut penser aussi à la possibilité de faire du ou des serveurs des caches récursifs référencés dans le DHCP.

        Une fois que le DNS fonctionne, je pense qu’il serait judicieux de ne plus référencer l’IP, mais le FQDN dans les réservations DHCP :

        host XXXXXX {
        hardware ethernet DE:AD:BE:EF:CA:FE;
        fixed-address XXXXXX.YYYYYY.tld;
        }

        Pour la réplication de zone, si elle doit être continue, tu as regardé les enregistrements DNAME ?

        • [^] # Re: Beau travail

          Posté par  (site web personnel) . Évalué à 2.

          merci pour tous ces éléments de réponse.
          Pour le module python je le ferais avec un système de queue via la base pgsql, qui sera lue régulièrement afin de push les modifications. Effectivement j'utiliserai DNSpython qui convient très bien pour tous les besoins de mises à jour.

          Les ACL de bind sont assez simples dans l'ensemble:

          • IP
          • Réseau
          • Nom DNS
          • Clef DNSSec
          • Autre ACL

          Je n'avais pas penser à intégrer une partie frontend/backend DNS mais c'est très intéressant comme approche, 2 serveurs DNS en front et 2 en back c'est effectivement top en terme de sécurité. Il faudrait que je voie comment modéliser ce procédé simplement.

          Pour le fixed-address, je ne savais pas qu'on pouvait mettre le FQDN. Le seul souci de ce FQDN c'est dans le cas d'une zone à enregistrements dynamiques, les FQDN n'existent pas. Comment réagit le DHCP ?

          Je ne connaissais pas non plus le DNAME, je vais regarder bientôt, déjà faire une partie plus classique avant d'aller vers des fonctionnalités plus avancées, mais ce que tu évoques est très intéressant.

          Veepee & UNIX-Experience

        • [^] # Re: Beau travail

          Posté par  (site web personnel) . Évalué à 1.

          Bien, ce week-end j'avais un peu de temps libre, je viens de faire un gros commit pour la notion de cluster et j'ai terminé la notion d'ACL (niveau frontend).

          Pour le cluster, voici comment j'ai designé. Chaque cluster peut avoir des membres. Ces membres ont chacun un type exclusif (maître, esclave, cache), et il faut a minima un maître. Il est possible de positionner des ACL sur le cluster (notify,update,query,recursion,transfer). Si des serveurs cache sont présents, les ACL sont appliqués sur ceux-ci, les autres serveurs étant en toute logique en backend. Autrement elles sont appliquées sur les maîtres/esclaves. Il n'y aura pas besoin de configurer les ACL entre les membres du cluster, ce sera automatique.

          Qu'en dites vous ?

          Veepee & UNIX-Experience

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.