Rudder

Voici ce qui se passe, dans le détail et dans l'ordre sur un nouveau noeud. Je te laisse filtrer le niveau de détails des informations, et intégrer ce qui te paraît cohérant dans la doc !

1. Installation du paquet rudder-agent
         1. Dépot de fichiers (surtout dans /opt/rudder et /etc)
               1. /etc : script d'init rudder-agent et fichier default associé
               2. /opt/rudder/share/initial-promises : promesses d'initialization de l'agent, ce sont ceux qu'il utilise tant qu'il n'a pas été accepté dans Rudder
               3. /opt/rudder/lib/perl5 : FusionInventory et ses dépendances Perl
               4. /opt/rudder/bin/run-inventory : wrapper qu'on utilise pour lancer FusionInventory avec les bonnes libs
               5. /opt/rudder/sbin : binaires de CFEngine Community
               6. /var/rudder/cfengine-community : aucun fichier, mais création de l'arborescene de répertoires nécessaire
               7. /var/cfengine : dossier créé, mais c'est probablement une connerie
         2. Installation des binaires CFEngine dans leur répertoire "de travail" : cp a /opt/rudder/sbin/cf* /var/rudder/cfengine-community/bin/
         3. Installation des promesses d'initialization dans le réperoire de travail de CFEngine : cp -r /opt/rudder/share/initial-promises/* /var/rudder/cfengine-community/inputs
         4. Création d'une clé SSL unique pour cette machine (dans /var/rudder/cfengine-community/ppkeys)
         5. Génération d'un UUID unique pour cette machine (uuidgen > /opt/rudder/etc/uuid.hive)
         6. Lancement de cf-execd (le démon de CFEngine qui lance cf-agent toutes les 5 minutes) et cf-serverd (démon de CFEngine qui écoute pour les connexions sur le réseau, ca nous sert pour le "gros bouton rouge")

2. Configuration manuelle de l'adresse IP du serveur Rudder

3. Au premier lancement de cf-agent (maximum 5 minutes après le lancement de cf-execd)
         1. Copie depuis le serveur Rudder du répertoire "tools" (/opt/rudder/share/tools sur le serveur, vers /var/rudder/tools sur le noeud)
         2. Tentative de copie depuis le serveur Rudder des promesses du noeud (échec car le noeud n'est pas encore accepté)
         3. Vérification que les processus cf-execd et cf-serverd tournent, et lancement sinon
         4. Entre 5:00 et 5:05, redémarrage quotidien de cf-execd et cf-serverd
         5. Ajout d'une ligne dans /etc/crontab pour lancer cf-execd s'il ne tourne pas
         6. Relancement de cf-serverd s'il ne tourne pas (oui oui, encore, et non, ca ne sert à rien de le refaire je crois)
         7. Vérification que le paquet curl est installé, et sinon l'installe
         8. Récupération de l'UUID du serveur Rudder (curl http://adresse_serveur_Rudder/uuid)
         9. Si l'inventaire n'a pas déjà été envoyé dans les 8 dernières heures, ou si la classe force_inventory est définie :
               1. Création d'un inventaire en XML avec FusionInventory dans /var/rudder/tmp/inventory
               2. Lancement de diverses commandes pour récupérer des infos en plus :
                     1. Liste de VMs pour VMWare et VirtualBox
                     2. Récupération d'infos CPU (CPUID)
                     3. Récupération de l'UUID de la machine (/usr/sbin/dmidecode -s system-uuid)
               3. Insertion de données supplémentaires dans le fichier d'inventaire XML :
                     1. UUID de la machine
                     2. Clé publique CFEngine
                     3. Nom de l'utilisateur qui a lancé CFEngine (normalement root)
                     4. UUID du serveur Rudder
                     5. Nom de l'agent CFEngine (Community ou Nova)
                     6. Liste de VMs obtenues pour VMWare et VirtualBox
                     7. Liste d'utilisateurs du système (lus dans /etc/passwd)
               4. Copie du fichier d'inventaire en XML de /var/rudder/tmp/inventory vers /var/rudder/inventories/
               5. Envoi du fichier d'inventaire vers le serveur Rudder (avec curl)

4. À chaque lancement successif de cf-agent (toutes les 5 minutes, à x heures 00/05/10/etc, + ou - 1 minute)
         1. Répétition de toutes les vérifications du point 3 ci-dessus

À noter : le noeud ne génère aucun rapport avant d'être accepté.

Ensuite, aucun changement jusqu'à ce que le noeud soit accepté dans l'interface web. Alors, le serveur génère des promesses pour le noeud, et l'étape 3.1 ci-dessus récupère ses promesses.

Les promesses minimales pour tout noeud incluent deux Policy Templates dites "system", qui font les étapes de vérification suivantes sur chaque noeud :

1. Copie depuis le serveur Rudder des promesses du noeud (mise à jour à chaque changement, aucune copie sinon)
   2. Copie depuis le serveur Rudder du répertoire "tools" (/opt/rudder/share/tools sur le serveur, vers /var/rudder/tools sur le noeud) (mise à jour en cas de changement, aucune copie sinon)
   3. Si, et seulement si, les promesses du noeud ont changés, vérification que cf-execd et cf-serverd tournent bien  (WTF la condition ?)
   4. Entre 5:00 et 5:05, redémarrage quotidien de cf-execd et cf-serverd
   5. Ajout d'une ligne dans /etc/crontab pour lancer cf-execd s'il ne tourne pas
   6. Vérification que les processus cf-execd et cf-serverd tournent, et lancement sinon
   7. Écriture de l'UUID du noeud dans /opt/rudder/etc/uuid.hive (s'il n'y est pas déjà)
   8. Détection du démon syslog (rsyslogd/syslog-ng/syslogd)
   9. Modification de la configuration du démon syslog (/etc/rsyslog.d/rudder-agent.conf ou /etc/syslog-ng/rudder.conf ou /etc/syslog.conf) pour envoyer les logs de Rudder via le protocole syslog au serveur Rudder
  10. Redémarrage du démon syslog si la configuration a été modifiée
  11. Inventaire (même procédure que ci-dessus) si il est entre 0:00 et 6:00, à une heure prise aléatoirement (si le lancement est bien effectué toutes les 5 minutes comme prévu, cette heure sera entre 0:00 et 1:00) et si l'inventaire n'a pas déjà été envoyé dans les 8 dernières heures OU si la classe force_inventory est définie
  12. Viennent ensuite les Policy Templates configurées dans l'interface Rudder

À noter : toutes ces opérations génèrent des rapports qui sont remontés au serveur Rudder. Actuellement l'interface n'affiche pas le résultat pour ces deux Policy Templates dites "system", mais c'est peut-être une betîse ?

Une précision pour l'inventaire : on peut à tout moment forcer la création et l'envoi d'un inventaire sur tout noeud en lancant la commande "/var/rudder/cfengine-community/bin/cf-agent -IKD force_inventory".

Finalement, sur ton schéma, le "Warning" en résultat de "Process Reports from the Node" est un peu sur-simplifié. On ne lève jamais vraiment de warning, mais à chaque lot de reports reçus, on calcule un état de compliance, affiché dans l'interface web.