Z-Eye, gestion réseau et monitoring unifié

33
14
avr.
2013
Distribution

Présentation

Z-Eye est une distribution libre associant plusieurs systèmes de monitoring, sécurité et réseau afin d'arriver à fournir une masse d'informations claires et de pouvoir tracer ce qu'il se passe en corrélant plusieurs sources de données.

Pourquoi cette dépêche ?

Pourquoi une nouvelle solution libre de monitoring ? Z-Eye voit plus loin que la supervision d'un réseau. Il vise l'hypervision et la gestion de celui-ci, de manière claire, simple et efficace, tant au niveau 2 et 3 OSI qu'au niveau 7. Ceci en cherchant à offrir un produit de qualité "professionnelle".

Cette dépêche a pour but de présenter le projet, mais également d'être un appel à contributions, que ce soit par un retour de la communauté, ou bien par des participations (patchs, développement, factoring de code existant…).

Logo

Sommaire

Caractéristiques

Z-Eye est une distribution complète basée sur FreeBSD 9.1, au détriment de Debian, d'où provient historiquement la solution.

Ce choix a été mûrement réfléchi, et a été décidé d'une part pour la robustesse et la rapidité de FreeBSD, mais également afin de bénéficier de paquets plus récents, et notamment de l'arbre de ports de FreeBSD, qui contient un ensemble conséquent de logiciels libres stables, compilés et personnalisables.

La distribution une fois installée est prête à être utilisée. L'ensemble des services est pré-configuré. Il faut noter que Z-Eye est livré avec un état de l'arbre de ports permettant de le maintenir comme si vous aviez installé et configuré tous les paquets vous même.

Z-Eye s'appuie sur trois types de supports de données :

  • fichiers plats (MRTG notamment) ;
  • deux bases de données PostgreSQL 9.2 internes (Z-Eye/Netdisco et Snort) ;
  • une possibilité de se relier à des bases MySQL/PgSQL FreeRadius externes.

Au niveau des langages utilisés, ils sont au nombre de quatre :

  • PHP (5.4), pour 90% de la solution, qui est en web ;
  • Javascript, pour une interface avec un peu de dynamisme et de modernité ;
  • Python, pour une partie des scripts de collecte ;
  • Shell, pour les modifications de l'installeur BSD.

Pour la partie PHP, Z-Eye utilise la libFSS, qui est une bibliothèque à la base minimaliste que j'avais développée pour des besoins modulaires spécifiques, et qui est désormais ma bibliothèque de référence pour plusieurs projets libres en Web que je conçois au sein de mon UMR CNRS (le second sera présenté dans l'année ici même). Cette bibliothèque a pour but d'offrir une couche d'abstraction légère au HTML, afin d'accélérer le développement d'applications Web. Au niveau web, il faut noter que les pages web sont desservies par Apache 2.2 (Apache 2.4 dans la prochaine version) avec support HTTPS actif

La solution n'est absolument pas MVC compliant et vu la complexité des interfaces en terme de modularité je doute qu'elle puisse l'être un jour, visant l'aspect fonctionnel et maintenable avant l'aspect beauté du code.

Naissance

Z-Eye est apparue comme une idée fin 2011, suite à la demande de mon SI, puis a commencé à naître et prendre forme début 2012.

Suite à des besoins en terme de visibilité sur notre infrastructure, j'ai mis en place divers outils de monitoring système, réseau et sécurité afin de pouvoir savoir ce qu'il se passait sur l'infrastructure. Dès lors, une masse d'informations a commencé à prendre forme que ce soit en fichiers plats, ou en base de données. Z-Eye a été L'Oeil qui a permis d'unifier les différentes interfaces libres de nos systèmes de monitoring, un simple écran unifié, réunissant les parties intéressantes de Nagios3, SNORT et Netdisco (Note : nagios3 a été remplacé par Icinga depuis)

Cycle de développement

Z-Eye est sorti en version 1.0 le 17 mars 2013 après près d’un mois de stabilisation du code et de recherche de bugs.

Au niveau du cycle de développement il s'agit d'un mode de type petites versions. Chaque version apporte quelques nouveautés, des corrections et des refontes d'API mais pas dans un nombre conséquent. Le rythme est prévu à une version tous les deux mois environ.

Pour la numérotation des versions, étant donné ce cycle court, il suivra la méthodologie OpenBSD (1.0, 1.1, 1.2 … 1.9, 2.0, 2.1…).

Enfin Z-Eye utilise deux branches de développement: -current et -stable.

Des idées

Au fur et à mesure du temps, de nouveaux besoins et de nouvelles idées sont apparues, et Z-Eye est devenue une application de plus en plus complexe.

La collecte réseau

equipement
En obtenant des données provenant de commutateurs, il s'est posé la question : mais, ne pourrait-on pas profiter de cet ensemble d'informations pour administrer les commutateurs ? À ce moment est née une interface permettant de modifier la configuration des ports de commutateurs, sous Cisco uniquement.

portmod

mapnet

DHCP & DNS

Utilisant des réservations IP via DHCP, il a été décidé d'interfacer nos DHCP UNIX (OpenBSD) afin de pouvoir recouper les informations entre les commutateurs et les DHCP (baux + configuration), et retrouver les baux inutiles. Un peu plus tard, c'est bind9/named qui a suivi, avec la lecture des fichiers de zones, afin de retrouver quels enregistrements DNS étaient inutiles (que ce soit par une machine trop ancienne ou encore parce que les CNAME ne correspondaient plus).

DHCP

FreeRadius

Pour finir, nous avons décidé d'augmenter le niveau de sécurité de notre SI en utilisant la technologie MAB (Mac Authentication ByPass), permettant d'authentifier une machine en 802.1X via son adresse MAC (et accessoirement d'attribuer un VLAN dynamiquement via Radius). Sachant que nous avions un système de réservations, et un cache DHCP en base, j'ai créé un système qui permet de synchroniser les réservations DHCP avec un groupe Radius.

dhcprad

Et ce n'est pas tout !

Du concret

Z-Eye permet également de générer des graphes d'utilisation, de gérer la sauvegarde automatique de vos équipements réseaux, de retaguer des VLANs, mais également de gérer Icinga en web, de gérer une base de données Radius (utilisateurs, groupes), et bien d'autres choses !

Il est à noter que deux options ont été ajoutées à la gestion des équipements réseau afin de faciliter l'exploitation :

  • la notion de pièce (pièce où arrive le port réseau) ;
  • la notion de prise (prise murale/numéro de brassage en baie du port réseau).

Les trois points forts de la solution sont :

  • le "Speed reporting", écran unifié d'alertes ;
  • la recherche, permettant de retrouver ce dont on a besoin rapidement dans un ensemble extrêmement large de données (switchs, DNS, DHCP, Radius…) ;
  • un système de droits sur les modules et un système de droits très fins sur les commutateurs permettant de définir quel est le champ d'action de chaque utilisateur (oui le technicien ne pourra pas changer le port-security et les cœurs de réseau).

Je vous invite à lire le Wiki qui est presque complet, et contient l'ensemble de la documentation de chacun des modules de Z-Eye, ainsi qu'un ensemble de captures d'écrans.

Licences

Z-Eye utilise deux licences de développement (hormis bibliothèques externes au projet) et une licence de contenu :

  • licence BSD : la bibliothèque libFSS ;
  • licence GPLv2 : l'ensemble des modules et scripts Z-Eye ;
  • Creative Common By ND : le logo (réalisé par Jennifer Aouizerat).

La bibliothèque libFSS est entièrement libre, contenant quelques API pouvant vous permettre d'interfacer rapidement quelques protocoles et systèmes.

Ce choix d'un développement sous licence GPL a été réfléchi afin de favoriser l'aspect communautaire de la solution, n'empêchant pas une entreprise de pouvoir y contribuer et de faire des prestations d'installation/configuration.

Évolutions à prévoir

La 1.1 est en cours de développement. Cette version apportera un dynamisme plus moderne à Z-Eye. Voici une liste non exhaustive des changements:

  • actuellement, l'application est très statique, avec ses pages nécessitant un chargement complet. Un nouveau dynamisme ajoute des dialog jQueryUI qui servent à confirmer les suppressions, mais également à ajouter et modifier des informations au sein des différents formulaires de l'application ;
  • des transactions SQL sont désormais effectuées pour les requêtes de suppression/insertion ;
  • amélioration de l'API libFSS (javascript, LDAP, SQL) ;
  • ajout de l'autocomplete sur la recherche ;
  • factorisation de certaines parties du code ;
  • modernisation de parties du code assez anciennes.

Sur le moyen terme, il est prévu d'ajouter des fonctions d'IPM (gestion IP), permettant de gérer les DHCP et DNS UNIX (bind9 mais aussi bind10), mais également d'autres petites choses, afin d'améliorer l'expérience utilisateur et la précision des données.

Sur le moyen et long terme, il est prévu de créer un service de planification qui s'occupera des différentes tâches de récolte et d'optimiser les intervalles de récolte et la charge système due à ceux-ci. Ce scheduler remplacera les tâches cron actuelles.

Conclusion

Il s'agit d'un projet énorme, qui m'a pris environ 450h depuis un an. Il y de la recherche, des déboires (eh oui quand on fait un test sur un équipement réseau, parfois il échoue et ça donne des résultats surprenants), mais en contrepartie nous avons eu un gain de productivité et de visibilité non négligeable au sein de notre équipe (4 pour 700 utilisateurs).

Je suis ouvert à toute suggestion — notamment sur l'intégration de certains ports qui peuvent être utiles à la solution —, toute question mais également à toute contribution.

Je vous remercie de votre lecture.

  • # Security Onion

    Posté par (page perso) . Évalué à 1.

    Je n'ai pas pu essayer security onion qui demande une machine 64 bits mais ton application semble assez proche dans l'idée, peux tu positionner ton projet vis-à-vis de Security Onion ?

    • [^] # Re: Security Onion

      Posté par . Évalué à 3.

      Et regardant rapidement les deux je dirais qu'ils n'ont pas du tout la même finalité : security onion est un système de détection d'intrusion, pas de supervision.

      • [^] # Re: Security Onion

        Posté par (page perso) . Évalué à 3.

        Effectivement, Z-Eye a pour but à la fois de monitorer le réseau et d'offrir de la sécurité par la visibilité d'évènements (systèmes => icinga, sécurité => SNORT), mais également de pouvoir gérer le réseau et ses éléments fondateurs.

        CNRS & UNIX-Experience

  • # Produits solarwinds

    Posté par . Évalué à 3.

    Bonjour,

    Même question que Julien CARTIGNY, plus haut: est-ce que cette solution est à rapprocher de 5 produits (LANsurveyor | Kiwi CatTools | Orion Network Performance Monitor (NPM) | Orion NetFlow Traffic Analyzer (NTA) | Orion IP Address Manager (IPAM)) de chez salorwinds que je teste actuellement?
    Mon chef ayant trouvé ces solutions qui correspondent à certains de nos besoins, il m'a demandé de les tester mais également de trouver si possible, les même produits/possibilitées mais en Libre et/ou Opensource.

    En dehors de ma recherche, cette solution parait très intéressente. Par exemple, la gestion des baux DHCP est très intéressente, et aussi la gestion d'équipements réseau.
    Basé sur freebsd…gage de sécurité et logiciels récents à jours…

    "You need to stop using the crap shipped with Ubuntu."

    • [^] # Re: Produits solarwinds

      Posté par (page perso) . Évalué à 3.

      Solarwinds est un peu plus poussé, peut être plus réservé pour une entreprise multinationale (surtout pour la partie réseau). Je ne sais pas l'échelle de ton entreprise mais pour une petite ou moyenne structure Z-Eye est actuellement très bien adapté (nous avons 45 serveurs, 75 commutateurs (~2500 ports) et 1 coeur de réseau). Les performances de Z-Eye dépendront essentiellement du disque (qui va subir énormément d'écritures pendant les différentes collectes, surtout SNORT). Dans mon cas cela tourne sur un Dell R210 sur le Raid système et ca tourne comme un charme.

      Pour la partie IPAM, ce n'est pas encore intégré, pour le moment la distrib se contente de collecte, mais si le besoin s'en fait ressentir je la prévois pour la 1.2 (elle m'est également demandée par mon chef qui aimerait que nos techniciens puissent modifier adresses dans le DHCP).

      Pour les performances réseau, Z-Eye utilise MRTG, les données sont collectées de manière active sur les différents équipements. La partie Netflow n'est pas interfacée, mais cela pourrait être une amélioration pour l'avenir, il suffirait de trouver le logiciel qui va bien (peut être est-il déjà présent dans la distrib) et de l'interfacer.

      L'avantage certain de Z-Eye c'est qu'il est totalement en web et qu'il est possibilie de définir des droits (avec une granularité illimitée, il suffit juste de rajouter la notion de droit au bon endroit avec le bout d'interface pour pouvoir le gérer). La plupart des outils que tu cites utilisent des clients lourds et forcément Windows.

      As tu des fonctions spécifiques en tête qui te seraient essentielles et présentes dans ces produits ?

      CNRS & UNIX-Experience

      • [^] # Re: Produits solarwinds

        Posté par . Évalué à 1.

        Nous avons un peu plus de 750 serveurs. La grande majorité sont des VMs (avec kvm).
        Nous allons grossir dès cette année.
        Ce qui veut dire aussi risque plus élevés de problèmes, tentatives d'intrusions etc…
        Nous utilisons déjà Nagios et passons sur FAN (Fully Automated Nagios - Nagios, Centreon et autres).
        Nous utilisons Cfengine pour l'automatisation de certaines tâches.
        Mais d'autres outils nous manquent pour renforcer notre vue sur le réseau (analyse, détection, résolution des problèmes).

        Ce qui nous intéresse dans les produits de solarwinds:
        -Partie "Plan du réseaux": creation du plan LAN/WAN, découverte auto de la topologie réseaux. Détection automatique des nouveaux périphériques et des changements de topologie de réseau. Plan réseaux à exporter (peu importe le format: Visio, Draw de Libreoffice ou Openoffice, pdf…).

        -Partie "Outil réseau": sauvegarde et de géstion des configurations du réseau. Planification des travaux par lots et mise en œuvre des changements de configuration à travers les routeurs, les commutateurs et pare-feu. Notification des changements de configuration via e-mail et de générer des rapports de base.

        -Partie "Performance réseau": détection et diagnostic des problèmes réseaux. Vue en temps réelle et dynamique du plan réseaux.

        -Partie "Analyse Traffic": analyse de la bande passante et du traffic. Identifier les utilisateurs, applications et protocoles qui consomment le plus de bande passante. Historique.

        -Partie "Gestionnaire d'adresses IP": gestion centralisée de l'infra IP. Gérer DHCP/DNS. Gestion de conflits d'adresses ip. Historique.

        Peut-être est-ce possible d'incorporer quelques unes de ces fonctions?

        Ce qui me plait et qui correspondent à nos besoins dans Z-eye:
        -IDS avec Snort
        -gestion des baux dhcp
        -gestion du dns (on vient de se taper un inventaire des machines utilisées/non utilisées et donc refresh des zones DNS)
        -collecte réseau: administration des switchs
        -connection à un serveur LDAP

        J'ai fais pas mal de recherche de solutions Libre/Opensource qui centralisent (même à peu près) la gestion réseaux…et je dois dire que c'est très difficile à trouver! Tout est éparpillé un peu partout! Un bout de solution par ici…un autre bout par là…rien n'est "unifié", "centralisé".
        Z-eye est très intéressent sur ce point. C'est aussi ce que l'on recherche.

        "You need to stop using the crap shipped with Ubuntu."

        • [^] # Re: Produits solarwinds

          Posté par (page perso) . Évalué à 5.

          Je ne te cache pas que le point faible de Z-Eye est la partie IDS. Même s'il est présent et fonctionne très bien, je ne peux pas fournir de sondes SNORT, la plupart sont soumises à des droits particuliers qui m'empêchent de les redistribuer. De ce fait il s'agit d'un éventail de sondes assez larges mais peut être pas suffisament précis pour des besoins de DC ? (ca je ne sais pas). De plus l'interface qui gère l'IDS est vraiment restreinte, cela n'a pas été ma priorité. Dans l'immédiat elle permet de modifier rapidement les variables qui définissent les différents protocoles courants (HTTP,SMTP,SNMP,SSH…) et serveurs associés.
          De plus les algorithmes qui vont de la collecte jusqu'à l'affiche sont assez lourds (SNORT => Barnyard => PG => ACID => PG => Z-Eye => PG). J'aimerais pouvoir les simplifier en me passant de base mais pour le moment je suis plus sur la partie réseau.

          En ce qui concerne l'administration de commutateurs, comme je l'ai dit pour le moment il s'agit de commutateurs CISCO, mais mon API permet d'utiliser SSH et de créer un module pour chaque constructeur, ce qui te permet d'utiliser des fonctions "standards" qui lanceront des commandes plus spécifiques sur chaque commutateurs (tu peux faire de l'hybride SNMP/SSH d'ailleurs). Cette spécificité CISCO n'impacte pas la collecte de données qui elle se fait avec des outils de collecte plus complets (Netdisco/MRTG).

          Concernant la gestion DHCP/DNS pour le moment il s'agit juste de collecte, mais promis je vais voir pour interfacer ca une fois la 1.1 stabilisée, validée et publiée. Il te faudra peut être attendre 1 à 2 mois le temps que je développe ca comme il faut et que je sois certain de la stabilité/sécurité du code. (donc mai/juin). Ceci ne t'empêche pas de pouvoir l'utiliser dès maintenant et d'upgrader plus tard quand de nouvelles fonctions apparaîtront. (l'ensemble est très facile à upgrader et je donne toujours des instructions exactes de mises à jour de DB, fichiers).

          J'avoue comme toi que ce qui pèche c'est effectivement la partie réseau où l'on trouve beaucoup de proprio, c'est à cause de ce besoin aussi que j'ai décidé d'agrandir Z-Eye et d'en faire une application "publique", au lieu de la garder au chaud dans mon institution CNRS.

          CNRS & UNIX-Experience

          • [^] # Re: Produits solarwinds

            Posté par (page perso) . Évalué à 4.

            Je ne te cache pas que le point faible de Z-Eye est la partie IDS.

            Puisque vous tournez sur FreeBSD, je vous suggère je jeter un œil sur Prélude-IDS, qui est dans les ports : security/prelude-*.

        • [^] # Re: Produits solarwinds

          Posté par (page perso) . Évalué à 2. Dernière modification le 16/04/13 à 10:51.

          Pour la partie IPAM, tu devrais regarder ici : http://opennetadmin.com/.
          Pour ce qui est du plan réseau, j’utilise Netdisco. Avec un peu de boulot, en piochant dans la DB Postgres de Netdisco, il doit même être possible de fabriquer un générateur pour ce genre d’hôtes dans Shinken sur le modèle de la génération d’hôtes VMware :

          define host{
                  use     switchs,vlan10
                  host_name       xxxxx
                  address         10.1.1.254
                  parents         yyyyy
                  _ports          Unit 1 Port 2,Unit 1 Port 4,Unit 1 Port 5,Unit 1 Port 6,Unit 1 Port 7,Unit 1 Port 9,Unit 1 Port 10,Unit 1 Port 11,Unit 1 Port 13,Unit 1 Port 14,Unit 1 Port 15,Unit 1 Port 16,Unit 1 Port 17,Unit 1 Port 25,Unit 1 Port 27,Unit 2 Port 2
          }
          
          define service{
                  use                     base-service-prod
                  service_description     check_traffic_on_$KEY$
                  display_name            Get interface $KEY$ traffic
                  hostgroup_name          switchs
                  check_command           check_traffic_name!$_HOSTsnmp_community$!$KEY$!$VALUE$
                  duplicate_foreach       _ports
                  default_value           90!95
          }
          
          

          Les ports déclarés dans la macro utilisateur _ports sont ceux d’interconnexion avec les switchs « fils ».
          Ce que je n’ai pas encore regardé, c’est la génération semi-automatique d’un graph Nagvis/Weathermap à partir de ces hôtes et ports, peut-être en utilisant une automap ou en repartant des graphs (le svg ou le graphviz) générés par Netdisco.

          • [^] # Re: Produits solarwinds

            Posté par (page perso) . Évalué à 2.

            La cartographie réseau que tu vois sur la présentation LinuxFr est générée via graphviz et un fichier .dot écrit par Z-Eye.
            Je suis en train de basculer sur la librairie JS sigma pour réaliser une carte interactive qui affiche la carte réseau et la carte icinga en combiné, avec de la colorisation pour la charge des liens et le statut icinga de chaque équipement, mais pour l'instant je suis bloqué sur l'algorithme qui me permet de génerer proprement les coordonnées X et Y. (donc j'ai juste un superbe brouillons de points à coordonnées aléatoires dans l'immédiat :p)

            Pour l'import shinken, c'est une bonne idée que tu évoques que de proposer l'import de commutateurs vers le système de monitoring. Je vais y penser pour Icinga, en rajoutant un import automatique des équipements existants. Pour la parenté depuis les données Netdisco j'émets une réserve dans le sens où elle peut faire des graphes Icinga étranges si tu as des liens multiples et croisés entre équipements.

            Merci pour le lien IPAM, je m'inspirerai de quelques données administratives intéressantes et promis j'intègre ca d'ici 1 ou 2 mois

            CNRS & UNIX-Experience

            • [^] # Re: Produits solarwinds

              Posté par . Évalué à 1.

              Petite question: shinken est évoqué par Landry, de mon côté puis-je remplacer Icinga par FAN dans Z-eye? ou avoir des connections entre Icinga et Nagios?

              Certains outils ont la même utilisation sur les 2 solutions, mais d'autres outils diffèrent totalement.

              "You need to stop using the crap shipped with Ubuntu."

              • [^] # Re: Produits solarwinds

                Posté par (page perso) . Évalué à 2.

                Oui ce serait possible, mais dans ce cas il faudra interfacer Z-Eye différement. Il faut savoir que Z-Eye enregistre ses données en base, et n'écrit pas les templates (qui ne sont qu'à titre informatifs dans cette version 1.0) dans la configuration Icinga.

                Si la syntaxe est identique, il suffira simplement d'écrire les fichiers dans le répertoire qui va bien et d'inclure le fichier écrit par Z-Eye (pour Icinga, 4 fichiers seulements sont écrit, séparant les hôtes, services et commandes notamment, et ces fichiers sont inclus par la configuration principale Icinga, qui elle n'est pas réécrite). Si elle diffère eh bien il faudra voir si les attributs sont cohérents avec FAM, et garder/supprimer ceux qui ne sont pas nécessaires puis aller écrire les fichiers de la manière qui va bien. Je ne connais pas FAM, mais à mon avis il faudra réécrire le module de monitoring et le réinterfacer avec les quelques modules concernés (cartes, système d'affichage d'alertes et administration d'Icinga).

                Pourquoi vouloir remplacer Icinga par autre chose ? Quel est ton besoin ? Utiliser un élément de monitoring existant ? Si c'est le cas, j'envisagerais peut être pour une version future un import de configuration si c'est viable, histoire de faciliter les choses à chacun.

                CNRS & UNIX-Experience

                • [^] # Re: Produits solarwinds

                  Posté par . Évalué à 1.

                  On déploie en ce moment même la solution FAN.
                  Si je veux mettre Z-eye en place, Icinga fera de l'ombre à Nagios ou sont ils complémentaires?

                  "You need to stop using the crap shipped with Ubuntu."

                  • [^] # Re: Produits solarwinds

                    Posté par (page perso) . Évalué à 2.

                    Nagios et Icinga sont les mêmes produits, si tu mets Z-Eye en place tu n'as plus besoin de nagios du coup, tu le remplaces par Icinga.
                    Comme je le disais il n'y a actuellement pas de fonction d'import de fichiers de configuration existants, cela passe par le backend DB avant d'être écrit (pour des soucis de compatabilités futurs, on ne sait jamais).
                    Z-Eye te propose toutes les options Icinga via l'interface web, qui vont le configurer de la façon qui va bien. Et tu pourras toujours avoir accès à la vraie interface d'Icinga qui est derrière via https://z-eye/icinga (peut être reconfigurer l'Apache vu qu'il doit être verrouilé sur localhost par défaut).

                    Néanmoins en utilisant l'Icinga intégré tu t'assures de bénéficier d'une part d'un logiciel de monitoring libre et qui évolue bien, et d'autre part des différents éléments que pourra proposer l'interface Z-Eye vis à vis d'Icinga, au fur et à mesure de l'ajout des fonctionnalités.

                    CNRS & UNIX-Experience

                    • [^] # Re: Produits solarwinds

                      Posté par . Évalué à 1. Dernière modification le 18/04/13 à 18:27.

                      Ok, tu veux dire que nagios et icinga sont très très proches en terme de fonctionnalitées…

                      Je sais que ce n'est pas l'endroit pour du support…j'essai de tester la version stable 1.0 de Z-eye dans kvm, mais dès le boot, j'ai ceci:

                      CPU doesn't support long mode
                      ….
                      Can't work out which disk we are booting from.
                      Guessed BIOS device 0xffffffff not found by probes, defaulting to disk0:
                      panic: free: guard1 fail @ 0x1fd18b50 from /usr/src/sys/boot/i386/loader/../../common/module.c:1004
                      --> Press a key on the console to reboot <--

                      Pour info, j'ai 2 VMs freebsd9 (test desktop et serveur ldap) de test dans kvm qui tournent sans problème.

                      "You need to stop using the crap shipped with Ubuntu."

                      • [^] # Re: Produits solarwinds

                        Posté par (page perso) . Évalué à 2.

                        Euh… après installation ca te fait ca ou en lançant le CD ?
                        C'est du 64bit attention.

                        Et j'utilise aussi KVM puisque ma VM de dev et de génération de release est sous libvirt :)

                        CNRS & UNIX-Experience

                        • [^] # Re: Produits solarwinds

                          Posté par . Évalué à 0.

                          J'ai l'erreur en lançant le cd.
                          Je crois que vient de là l'erreur…j'ai mon OS en 32bits…je vais donc essayer sur une machine physique de test.

                          "You need to stop using the crap shipped with Ubuntu."

                          • [^] # Re: Produits solarwinds

                            Posté par . Évalué à 2.

                            Effectivement, tout s'est passé pour le mieux lors de l'installation sur un autre pc.

                            Quelques petites questions:
                            -Peut-on créer plus d'un compte en "interne"?
                            -Communauté SNMP: pas de possibilité de modifier les éléments créés?
                            -l'arbre des ports n'existe pas, est-ce volontaire?
                            -l'inconvéniant avec les comptes "externe" (avec ldap, par exemple) ont doit se délogguer d'admin, puis se logguer avec un compte de son arbre ldap pour qu'il soit copié dans l'outil et ainsi appliquer les droits que l'on veut (groupe etc…). Possible d'avoir un listing des comptes de son arbre directement depuis le compte admin? ou possibilité de chercher les groupes dans ldap?

                            Aurais tu une page pour centraliser les demandes? sur laquelle on puisse noter les points d'améliorations et d'ajouts.

                            Maintenant que j'ai fait un peu le tour de l'outil, faut que j'active le snmp sur mes équipements réseaux et tester plus en profondeur ;)

                            "You need to stop using the crap shipped with Ubuntu."

                            • [^] # Re: Produits solarwinds

                              Posté par (page perso) . Évalué à 3.

                              Salut paco, désolé du retard

                              Pour les comptes internes, non effectivement on ne peut pas j'ai choisi l'exclusivité du compte externe via LDAP sur cette version 1.0 (et idem sur la 1.1 à vrai dire). Bien évidemment tu peux les créer toi même à la main, mais il faut savoir comment se chiffrent les mots de passe (classe lib/FSS/SecurityMgr.FS.class.php:EncryptPassword, niveau 4).

                              Pour les communautés SNMP, non effectivement, tu peux ajouter et supprimer, cela n'a aucun impact sur l'ensemble des fonctionnalités derrière, cela se contente de reconfigurer netdisco et le cache de communautés pour la collecte. Vu la simplicité de cette configuration je n'ai pas choisi d'activer la modification, ceci dit cela peut être un axe d'amélioration intéressant que je pourrais implémenter pour la 1.1, mais peu important.

                              L'arbre de ports n'est pas téléchargé, pour des raisons de légèreté de la distribution, néanmoins tu disposes déjà de la configuration des ports actuels (/var/db/ports). Un portsnap fetch extract résolvera ce souci :)

                              Pour le LDAP effectivement, je note qu'on ne peut pas, est-ce que le fait d'activer un import en saisissant le nom de compte d'un utilisateur d'annuaire te conviendrait ?

                              Pour les améliorations, je pense que l'ami bugzilla devrait suffire pour cela, ca permettra de centraliser les demandes (http://bugs.unix-experience.fr)

                              CNRS & UNIX-Experience

                              • [^] # Re: Produits solarwinds

                                Posté par . Évalué à 1.

                                Pourquoi retard? t'as aussi le droit à une vie (sociale et pro) ;)

                                Pour les comptes internes, je pensais, par exemple, rajouter un compte de spare, au cas où le 1er compte aurait des soucis (redondance toussa…).

                                Pour les communautés SNMP, si t'en supprimes une et la re-créée, derrière tu es obligé de re-configurer tous les droits sur les équipements réseau liés à cette communauté…qui se configurent très finements effectivement.

                                Ok pour l'arbre des ports. Ma question allait dans le sens où si tu désires installer un outil qui ne soit pas installé de base. Et puis dans le futur tu remplaceras par pkgng.

                                Import comptes ldap: dis moi si c'est faisable > serait-ce possible d'activer cet import directement dans les groupes d'utilisateurs (Admins sécu, Admin sys, Admins réseaux, Tecs)?
                                Petite question: un utilisateur peut-il être dans plusieurs groupes d'utilisateurs? Par exemple, mon chef peut-il être à la fois dans Admins sécu, Admin sys, Admins réseaux et Tecs?

                                Je vais me créer un compte sur l'ami bugzilla.

                                Merci à toi pour le temps passé à répondre à mes questions.

                                "You need to stop using the crap shipped with Ubuntu."

                                • [^] # Re: Produits solarwinds

                                  Posté par (page perso) . Évalué à 2.

                                  Le premier compte est très spécifique, car l'UID 1 est un UID super utilisateur qui aura forcément tous les droits (hardcoded)

                                  Ah oui j'avais oublié le détail des droits, effectivement tu as raison je le rajoute dans ma todo list pour la 1.1 c'est important.

                                  pkgng est déjà utilisé sur la distribution en fait :) tu veras la liste des ports installés avec pkg info et non pkg_info . Ensuite pour la mise à jour je recommande l'utilisation de portmaster (portmaster -a, déjà installé) pour la mise à jour de ceux-ci.

                                  Pour l'import je peux éventuellement faire un formulaire qui rajoute la liste des groupes auquel associer le compte, en terme de gestion c'est plus pratique, je rajoute ca dans les idées d'import.

                                  Un utilisateur peut être dans plusieurs groupes, les droits sont cumulés.

                                  Après je te suggère d'attendre la 1.1 pour la production car on passera sur Apache 2.4 et ses améliorations de performances sont très agréables, ou alors tu pourras upgrader ta machine, mais il faudra réécrire une partie de la configuration Apache (concernant les droits) et faire quelques modifs sur rc et rc.conf, et accessoirement recompiler tout PHP pour que le module apache soit compatible. (après tu n'es pas obligé de passer à Apache2.4, j'ai choisi cette orientation unilatéralement, tu peux rester sur la version fournie en 1.0 et continuer avec l'arbre de ports actuel).

                                  CNRS & UNIX-Experience

  • # Update 1.1

    Posté par (page perso) . Évalué à 3.

    Pour information, j'ai prévu de sortir la version 1.1 de Z-Eye le 29 avril dans la journée.

    Cette évolution apportera un ensemble d'éléments de dynamique, des améliorations de performance sur le code, et quelques fonctionnalités intéressantes comme l'autocomplete sur la recherche, la confirmation sur suppression, etc…

    Une première mise à jour banale, qui consiste en l'amélioration de la cohérence de la libFSS et des différents modules Z-Eye et du design de la solution.

    Informations: http://z-eye.unix-experience.fr/index.php/Changelog_%28-current%29

    CNRS & UNIX-Experience

Suivre le flux des commentaires

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