Rudder 4 — nouvelle version de la solution de Continuous Configuration

58
20
avr.
2017
Administration système

Un peu plus de deux ans après la sortie de Rudder 3, une nouvelle version majeure voit le jour, et avec elle de nombreux changements qui distinguent encore davantage Rudder des outils de gestion de configuration classiques.

Dashboard Rudder 4

Rudder est une solution libre et multi‐plate‐forme de Continuous Configuration (gestion de configuration et audit en continu), visant particulièrement les besoins d’infrastructures de production.

Sommaire

Qu’est‐ce que Rudder ?

Rudder est une solution libre de Continuous Configuration qui audite le système d’information (SI) en continu et automatise les opérations logicielles de façon contrôlée et sécurisée.

Derrière le terme de Continuous Configuration, on trouve une base de gestion de configuration, alliée à des fonctionnalités d’audit en continu. La différence entre un outil de gestion de configuration traditionnel et Rudder, c’est que les changements peuvent être simulés individuellement avant d’être validés, puis vérifiés après être appliqués et, enfin, tracés et maintenus dans le temps. Tout ce qui n’est pas conforme à l’état cible, auquel on souhaite rester ou accéder, remonte des alertes en temps réel, crée des rapports de dérive ou déclenche une remédiation automatique. Cela en fait un outil particulièrement adapté pour répondre aux contraintes d’infrastructure de production.

D’un point de vue pratique, Rudder permet de :

  • gérer le socle système (distribuer des clefs SSH, paramétrer le DNS, gérer les utilisateurs, paramétrer les permissions sur les dossiers et fichiers, lancer des tâches, gérer les certificats, etc.) ;
  • installer, mettre à jour et configurer des applications ;
  • appliquer et vérifier en continu les politiques de sécurité, y compris pour des normes externes (ISO 27001, PCI-DSS, PSSI de l’ANSSI, etc.).

En bref, Rudder est :

  • un outil de gestion de configuration et d’audit en continu, existant depuis 2011 ;
  • libre (code sous GPL v3, documentation sous CC by-SA 2.0, avec quelques bibliothèques sous licence Apache) ;
  • composé d’un serveur qui gère les configurations et la remontée de conformité (en Scala) et d’un agent de configuration (en C), qui gère Debian, Ubuntu, RHEL/CentOS, SLES et AIX ;
  • utilisé par de larges productions critiques comme la Caisse d’Épargne, BMW, Eutelsat ou Novartis ;
  • principalement développé par Normation (http://www.normation.com/fr/normation/qui-sommes-nous/), qui propose différents services autour de Rudder, tels que du support ou de la formation, ainsi que des greffons payants pour des besoins spécifiques, notamment pour le support des machines Windows.

Logo Rudder 4

Pour ceux qui veulent voir plus en détails le fonctionnement de Rudder, vous pouvez consulter le schéma d’architecture.

Rudder 4

Rudder 4.0 est sorti le 10 novembre 2016, et Rudder 4.1, le 30 mars 2017. Les axes d’évolutions de ces versions sont présentés dans la suite de l’article.

Le mode Audit

La fonctionnalité centrale de Rudder 4 est la possibilité de configurer un serveur pour n’effectuer que de la vérification de l’état de certaines règles de configuration. On peut réaliser cette configuration pour une machine complète ou pour une portion de configuration, ou bien encore au niveau global sur l’ensemble des règles de configuration et l’ensemble des machines.

Rudder offre donc maintenant deux modes : Audit et Enforce, respectivement pour vérifier l’état sans le modifier, et pour modifier le système pour atteindre l’état cible.

Audit mode

Quels sont les cas d’utilisation possibles :

  • outil d’audit pur ; par exemple, pour une vérification de normes (PCI-DSS, ISO 27001, etc.). À la différence d’avec un outil dédié, une fois la configuration effectuée, elle peut directement être utilisée pour configurer ;
  • validation de changements avant de les appliquer ; par exemple, une nouvelle configuration ; ce cas peut être vu comme un équivalent d’un mode dry‐run classique, mais potentiellement sur l’ensemble de l’infrastructure et avec une granularité supérieure (portant seulement sur certains points de configuration) ;
  • validation après l’installation de Rudder sur une infrastructure existante, pour valider qu’il correspond à la configuration cible théorique, avant d’activer le mode Enforce.

Si les techniques (règles fournies par défaut à l’installation) peuvent se révéler limitées pour de l’audit, la construction des règles d’audit est particulièrement simple et accessible à l’aide du Technique Editor, un éditeur de configuration Web.

Performance

Rudder est déployé sur des parcs de tailles de plus en plus importantes et d’un objectif d’une centaine de machines gérées sur un serveur, avec les premières version (Rudder 2), puis de l’ordre du millier de machines (Rudder 3), la version 4 vise un ordre de grandeur d’une dizaine de milliers de machines gérées efficacement depuis un serveur.

Performance du serveur

Le travail pour passer à cette échelle a consisté en plusieurs points :

  • des tests de performance approfondis pour prioriser les améliorations ;
  • un travail sur le modèle de données de l’application, notamment dans le stockage de l’information de conformité ; les rapports de conformité attendus (correspondant aux configurations mises à disposition des machines), sont désormais stockés sous format JSON, par nœud, en un point unique, au lieu d’être répartis dans plusieurs tables ; cela simplifie grandement les calculs de conformités lors de la réception des rapports d’exécution de l’agent ;
  • une amélioration du cache interne de l’application, notamment du cache de valeurs de conformité.

L’interface Web a aussi reçu des améliorations :

  • les ressources statiques ont maintenant une URL versionnée et sont correctement mises en cache ; et la compression des ressources a été activée partout ;
  • lorsque nous avons introduit le Dashboard et les graphes de changements récents, nous nous sommes tournés vers c3.js pour l’affichage des graphiques. Cette bibliothèque utilise du SVG, mais Firefox présente de gros problèmes de performance dans le rendu des SVG. Ceci, combiné à l’usage que nous en faisons (de petits graphes dans des tableaux) engendre une baisse dramatique des performances (chaque graphique prend des centaines de millisecondes à s’afficher, ce qui bloque le navigateur et engendre un niveau d’utilisation élevé du processeur). Ce n’était pas visible avec seulement quelques graphes, mais lorsque ce nombre augmente cela pouvait complètement bloquer l’utilisation du navigateur. En version 4.1, c’est terminé ! Nous avons remplacé cette bibliothèque par chart.js, qui utilise un canevas pour afficher ces graphes ce qui offre une hausse des performances énorme sous Firefox.

Performance de l'agent

D’autre part, côté agent, la légèreté et la rapidité permettent de diversifier les types de déploiements vers des parcs légers (Raspberry Pi, etc.), en plus d’utiliser moins de ressources sur les machines gérées.

Nous nous sommes concentrés sur la performance de l’agent, notamment après avoir constaté de graves dégradations de performances avec des règles contenant des variables (tableaux en l’occurrence) de taille importante (plusieurs centaines d’éléments), et a abouti en version 4.1.1 à une amélioration très significative de la durée d’exécution de l’agent dans certains cas (la création de 500 utilisateurs sur une machine passe de dix minutes à une quinzaine de secondes). Un agent avec quelques règles de configuration simples s’exécute en une à deux secondes et peut aller jusqu’à quelques dizaines de secondes pour des configurations avec plusieurs centaines d’éléments configurés, avec une consommation de mémoire vive de quelques dizaines de mégaoctets.

Organiser les configurations

Quand la quantité de configurations devient importante dans votre installation Rudder, il peut devenir difficile de retrouver les éléments de configuration (nœuds, règles, etc.). Pour cela, plusieurs améliorations ont été apportées :

  • un système d’étiquettes (tags) sur les objets de configuration (règles, directives) a été ajouté. Les étiquettes sont basées sur un système clef‐valeur, pour plus de souplesse dans l’utilisation (par exemple : “environnement” → “production”). Une règle ou directive peut avoir autant d’étiquettes que souhaité, potentiellement avec la même clef ;
  • les étiquettes sont éditables dans l’interface Web et via l’API, et sont utilisables en tant que filtres dans les champs de recherches (avec de l’auto‐complétion).

Tags Rudder

Depuis Rudder 3.1, nous avons la possibilité d’utiliser des propriétés de nœuds (stockées sous forme de chaînes de caractères ou d’objets JSON) pour regrouper les nœuds basés sur des propriétés définies et pour ajouter des données dans les « politiques » générées.

Ces propriétés ne pouvaient être définies que via l’API de Rudder et étaient affichées dans l’interface Web. De plus, leur utilisation a été facilitée par l’inclusion d’un moteur JavaScript dans les champs de paramètres, permettant une manipulation simple du contenu des variables.

Dans Rudder 4.1, nous pouvons désormais ajouter ou supprimer les propriétés de nœuds directement depuis cette interface, via l’onglet Properties dans les détails d’un nœud. Vous pouvez aussi créer de nouvelles propriétés, dont les valeurs peuvent aussi bien être une simple chaîne de caractères, ou bien des données au format JSON pour les structures plus complexes.

Pilotage via l’API

Le cycle de développement de la version 4 a permis l’ajout de deux nouvelles possibilités dans l’API.

La première donne simplement accès à la configuration du serveur Rudder lui‐même, ce qui permet d’automatiser des changements de configuration. Elle permet, par exemple, de modifier la fréquence d’exécution des agents, ou la durée de rétention des sauvegardes des fichiers modifiés par les agents sur les nœuds gérés, ou encore de réaliser des instantanés (snapshots) de la configuration de Rudder.
La deuxième API introduite concerne le déclenchement d’agents. En effet, l’agent Rudder est autonome et se connecte régulièrement au serveur Rudder figurant dans sa configuration pour obtenir la dernière version des configurations à appliquer (par défaut, toutes les cinq minutes). Ainsi, quand un changement de configuration cible est réalisé sur le serveur, la propagation s’étale sur plusieurs minutes (ou dizaines de minutes, selon de délai d’exécution configuré).

Pour permettre d’appliquer au plus vite un changement de configuration en cas de besoin, une nouvelle API a été mise en place. Elle permet, depuis le serveur, de déclencher une exécution des agents sur les nœuds.

Cette API a deux modes principaux :

  • déclenchement sur un ensemble de nœuds et obtention de la sortie de l’agent ;
  • déclenchement asynchrone d’exécution de l’agent sur l’ensemble des nœuds, sans attendre le résultat.

Rudder est maintenant totalement pilotable par API, que ce soit au niveau de la création et gestion des règles de configuration ou de l’administration de Rudder, ou de l’extraction d’informations de conformité. Les API permettent en général de personnaliser le fonctionnement de Rudder et d’automatiser certaines opérations spécifiques (acceptation de nouvelles machines sur un serveur Rudder, édition de configurations, etc.). Pour faciliter la manipulation de l’API, il existe une interface en ligne de commande et une bibliothèque Python.

Note : Comment se passe la modification de configuration sur le serveur, que ce soit via l’API ou l’interface Web ? Le code de configuration est en fait stocké dans un dépôt Git sur le serveur, permettant ainsi une modification via l’interface ou directement dans le code. De plus, une partie des fonctionnalités liées à la configuration (instantané, annulation d’un changement, journal des événements) est directement basée sur l’utilisation du dépôt Git sous‐jacent.

Ergonomie de l’interface Web

L’interface de Rudder n’avait pas beaucoup évolué depuis la sortie de la version 3.0, tandis que le logiciel n’a cessé d’intégrer de nouvelles fonctionnalités. La version 4.0 fut l’occasion parfaite de rajeunir l’image de Rudder en lui offrant une nouvelle interface, plus moderne et responsive.

Voici une liste non exhaustive des principales améliorations :

  • nouvelle disposition du menu ;
  • ajout d’un champ de recherche global portant sur toutes les entités (machines, configuration, etc.) présentes dans Rudder. Ce champ de recherche dispose aussi d’un langage de requêtage simple pour effectuer une recherche sur un type d’objet ou un champ précis ;
  • intégration du nouveau logo ;
  • nouveau thème pour l’arbre des groupes, directives, règles, etc. ;
  • la plupart des formulaires intègrent désormais le cadriciel Bootstrap.

Quicksearch Rudder

Autour du développement

Lors du travail sur Rudder 4, les processus de développement ont été améliorés. Nous avons ajouté de nouvelles possibilités à notre outil de développement rudder-dev, notamment la possibilité d’ouvrir un ticket de correction directement depuis la ligne de commande. Nous avons, en plus de cet outil, créé un bot GitHub qui teste les demandes d’intégration Git (pull requests) et effectue les fusions (merge) dans les branches supérieures automatiquement, quand c’est possible. Sinon, il fournit la commande pour l’effectuer manuellement (cf. https://github.com/Normation/rudder/pull/1616, par exemple). Cela a permis d’éviter des problèmes lors de la fusion de branches contenant plusieurs correctifs différents, quand cela n’avait pas été fait immédiatement après la fusion dans la branche de destination.

De plus, nous sommes en train de modifier le système de priorisation des tickets pour coller au mieux aux besoins de la majorité des utilisateurs et être plus en cohérence avec la feuille de route.

Suite à une rétrospective sur le développement de la version 4.0, nous avons lancé de nouveaux canaux de discussion avec les utilisateurs et contributeurs, notamment une nouvelle FAQ et un blog autour du développement.

Nous avons aussi participé cette année encore au Configuration Management Camp à Gand. Nous avions cette année une salle dédiée et avons accueilli cinq discussions à cette occasion, en plus de notre intervention au sein de la main track de l’événement.

Et maintenant ?

La prochaine fonctionnalité importante sera le développement d’un agent pour Windows, basé sur l’outil natif DSC (Desired State Configuration), intégré à Powershell depuis la version 4 et désormais open source.

Nous souhaitons en outre utiliser les possibilités introduites dans les versions 4.0 et 4.1 pour proposer des fonctionnalités plus avancées, comme, par exemple, un déploiement progressif de configuration (ramp‐up) basé sur les premiers retours de conformité.

Pour en savoir plus et tester Rudder, vous pouvez :

Aller plus loin

  • # Bien joué!

    Posté par  . Évalué à 9.

    Description parfaite, à la fois précise et courte. Et le bon sens de montrer un écran où la conformité n'est pas à 100%, comme dans la vraie vie(TM). Ça donne l'envie de s'y mettre!

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: Bien joué!

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

      Description parfaite, à la fois précise et courte.

      Ça donne l'envie de s'y mettre!

      Comme d'habitude avec les gens exceptionnels de Normation : c'est une équipe optimiste et visionnaire, et pas que, ils livrent ! Rudder a de vrais différentiateurs par rapport à la concurrence, et je regrette toujours que Rudder ne soit pas connu à la hauteur de ce qu'il devrait… La visualisation et vérification de la conformité sont clé.

      • [^] # Re: Bien joué!

        Posté par  . Évalué à 5.

        Comme d'habitude avec les gens exceptionnels de Normation : c'est une équipe optimiste et visionnaire, et pas que, ils livrent ! Rudder a de vrais différentiateurs par rapport à la concurrence, et je regrette toujours que Rudder ne soit pas connu à la hauteur de ce qu'il devrait… La visualisation et vérification de la conformité sont clé.

        Wow. Que de compliments ! Merci infiniment pour cette confiance !!!

        Mais LinuxFR aide à ce qu'il soit mieux connu, alors merci LinuxFR :)

  • # Typo

    Posté par  . Évalué à 7.

    Les ressources statiques ont maintenant une URL versionnée et sont correctement mises en cache, et la compression des ressources ont été activée partout.

    Très bon article par ailleurs :)

    bépo powered

  • # Merci pour la dépêche

    Posté par  . Évalué à 1.

    Merci pour cette passionnante dépêche que je ne puis hélas plusser.
    Je m'en vais de suite essayer Rudder.

    La webui est-elle responsiv?

    Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

    • [^] # Re: Merci pour la dépêche

      Posté par  . Évalué à 6.

      La webui est-elle responsiv?

      Elle l'est, c'est écrit dans la dépêche à la section ergonomie de l'interface web :

      La version 4.0 fut l’occasion parfaite de rajeunir l’image de Rudder en lui offrant une nouvelle interface, plus moderne et responsive.

      Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

      • [^] # Re: Merci pour la dépêche

        Posté par  . Évalué à -2.

        Ah, autant pour moi j'ai lu trop vite.
        Merci @kantien ;)

        Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

    • [^] # Re: Merci pour la dépêche

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

      La webui est-elle responsive ?

      réponse au § ergonomie de l'interface web ;-)
      https://linuxfr.org/news/rudder-4-nouvelle-version-de-la-solution-de-continuous-configuration#ergonomie-de-linterface-web

    • [^] # Re: Merci pour la dépêche

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

      Merci pour ce retour!

      Il reste encore un peu de travail pour faire en sorte que toutes les pages de Rudder soient parfaitement responsives, mais dans l'ensemble, l'interface a fait d'énorme progrès à ce niveau là. Certaines pages le sont déjà (comme le dashboard, les formulaires, popups, etc..), tandis que certaines sections de page (comme celle des Règles dans les détails d'une Directive, par exemple) ont encore besoin de quelques améliorations dues à leur complexité.

      Cette nouvelle interface est beaucoup plus souple que l'ancienne, notamment grâce à l'ajout d'un nouveau framework front-end (Boostrap) destiné à cet effet. Le critère de responsivité fait maintenant parti des objectifs à tenir lors de la réalisation de nouvelles pages/composants d'UI.
      Nous espérons rendre Rudder totalement responsive au fil du temps!

      • [^] # Re: Merci pour la dépêche

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

        Tiens, je trouve ça curieux… C'est sans doute mon ensemble de biais cognitifs, mais je ne vois pas des devops déployer, vérifier, adapter/corriger sur mobile. Car je présume qu'ils sont équipés de vrais ordinateurs complets (laptops, desktops). J'ai faux ?

        Ceci dit, cool que ce soit responsive !

        • [^] # Re: Merci pour la dépêche

          Posté par  (site web personnel) . Évalué à 4. Dernière modification le 21 avril 2017 à 22:50.

          La modification des configurations me paraît aussi peu probable sur mobile, mais potentiellement plus la consultation de l'état de l'infrastructure (conformité, changements effectués).

          En plus, l'aspect responsive, sans aller jusqu'au mobile, est utile pour s'adapter à des matériels aux résolutions diverses (ou simplement pouvoir passer l'interface sur une moitié d'écran sans qu'elle ne devienne inutilisable ;)).

      • [^] # Re: Merci pour la dépêche

        Posté par  . Évalué à -2. Dernière modification le 24 avril 2017 à 00:05.

        De rien :)
        J'ai testé l'interface avec un smartphone pour voir le côté responsiv. Un peu déçu je me suis arrêté au dashboard (notez que je sais la difficulté actuel de faire du responsiv donc je vous en veux pas ^ ^ )
        Voici un screenshot :
        DLFP

        Questions subsidiaires :

        Peut-on exécuter des commandes sur une ou plusieurs machines (par exemple apt-get update) ?

        Peut-on déployer des scripts (par exemple j'ai un script maison gérant des tunnels SSH a lancer au boot) ?

        Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

        • [^] # Re: Merci pour la dépêche

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

          Peut-on exécuter des commandes sur une ou plusieurs machines (par exemple apt-get update) ?

          Un certain nombre de Techniques (installation de paquet, modification d'un fichier, etc.) permettent l'exécution d'une commande quand un changement est effectué (installation ou mise à jour du package, modification du fichier). On peut aussi exécuter des commandes de façon plus générale (notamment dans le Technique Editor, quand on définit un bloc de configuration). Cependant, ce n'est en général pas l'objectif, et on préfère autant que possible définir des états à atteindre plus que des actions (comme des commandes), pour obtenir des configurations plus fiables et plus souples. Pour reprendre l'exemple du apt-get update, il est effectué automatiquement quand des paquets sont gérés par Rudder sur la machine, et l'utilisateur n'a qu'à configurer les paquets à installer et leurs versions (donc définir un état à atteindre).

          Pour exécuter des commandes qui demandent une synchronisation entre plusieurs machines, il est préférable d'utiliser un outil plus adapté aux actions ponctuelles comme Rundeck ou Ansible, qui peuvent utiliser les informations présentes dans Rudder (liste de machines, groupes, etc.).

          Peut-on déployer des scripts (par exemple j'ai un script maison gérant des tunnels SSH a lancer au boot) ?

          Oui, par exemple avec la Technique "File download (Rudder server)" qui permet de télécharger sur les nœuds un fichier (ou dossier) présent dans /var/rudder/configuration-repository/shared-files sur le serveur Rudder.

          • [^] # Re: Merci pour la dépêche

            Posté par  . Évalué à -1. Dernière modification le 24 avril 2017 à 21:22.

            Interdiction mais faite de te plusser, mais je te remercie grandement pour ta patience. Petit à petit, l'idée du fonctionnement de Rudder se forge dans ma tête.

            J'avoue que j'aimerais m'en servir pour mettre à jours un certains nombres de raspberry pi (quand le client raspbian serait prêt) + quelques machines et vérifier que les services n'ont pas été cassé.

            Il me reste deux questions si cela ne vous dérange :
            1) Rudder crée-t-il un VPN? En effet je vois une interface tun0 sur la machine où j'ai installé rudder server.
            DLFP

            2) y a-t-il des rules/techniques pour suivre l'activité hardware, si possible depuis le DashBoard (j'aimerais checker qu'il n'y a pas de surchauffe, surtout pour cet été qui s'annonce chaud)

            PS: les devs de Rudder devraient jeter un œil au Dashboard de piwik, il y a de l'idée a récupérer :)

            Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

  • # Quelle présentation !

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

    Je ne peux que me joindre aux compliments déjà rédigés : une dépêche mêlant clarté, illustration et complétude, adossé à une maturité visiblement du produit, bravo !

  • # Par rapport à Ansible

    Posté par  . Évalué à 5.

    J'essaye de comprendre comment cela fonctionne et ce que cela apporte par rapport à Ansible et Ansible Tower.

    Ce que j'ai trouvé:

    L'équivalent d'un ansible-role semble être une Technique. L'équivalent du ansible-workbook est une config graphique dans Rudder.
    Je n'ai pas trouvé la doc expliquant comment rajouter une Technique et si il y a des contraintes (e.g. FAUT utiliser ncf  ?)
    La doc a "The creation of new Techniques is not covered by the Web interface. This is an advanced task which is currently not covered by this guide." (http://www.rudder-project.org/doc-4.0/_manage_the_techniques.html ).

    Ansible peut lire la config Rudder http://www.rudder-project.org/doc-4.0/_use_the_inventory_in_ansible.html

    • [^] # Re: Par rapport à Ansible

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

      Merci, je me posais sensiblement les mêmes questions que toi. J'y vois beaucoup plus clair maintenant !

    • [^] # Re: Par rapport à Ansible

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

      L'équivalent d'un ansible-role semble être une Technique. L'équivalent du ansible-workbook est une config graphique dans Rudder.

      Effectivement, un playbook correspond plus ou moins à une Règle dans Rudder (qui est configurée via l'interface Web ou l'API). Une Règle regroupe des éléments de configurations issus de Techniques ("configuration de nginx", "configuration du serveur SSH", etc.) en un ensemble qui a un sens métier ("serveur de cache Web", "serveur de base de données", etc.), et les associe à un groupe de machines.

      Je n'ai pas trouvé la doc expliquant comment rajouter une Technique et si il y a des contraintes (e.g. FAUT utiliser ncf  ?)

      La création de Techniques peut se faire de deux manières :

      • en utilisant le Technique Editor (accessible dans https://demo.rudder-project.org/, Utilities -> Technique editor) qui est une interface Web de construction de techniques à partir de méthodes de base ("s'assurer de la présence d'un package", "s'assurer qu'un service est démarré", etc.). Il est intégré à Rudder et très simple d'utilisation, tout en permettant d'établir des liens entre les actions (n'exécuter une action que si une autre est en erreur, ou quand un fichier a été modifié, etc.) ou de manipuler des variables. C'est la solution conseillée en général.
      • en écrivant du code de configuration, ainsi qu'un fichier de description des paramètres en entrée (ce qui correspond au contenu du dépôt https://github.com/Normation/rudder-techniques). C'est la méthode la plus souple, mais elle demande un apprentissage particulier (notamment le framework de configuration ncf).

      Ansible peut lire la config Rudder http://www.rudder-project.org/doc-4.0/_use_the_inventory_in_ansible.html

      Plus précisément, Ansible peut utiliser Rudder comme inventaire dynamique, pour récupérer la liste des noeuds et leurs propriétés (groupe, variables clé-valeur associées). Rudder et Ansible peuvent ainsi être utilisés de manière complémentaire, avec Rudder pour le maintien du socle (gestion des programmes installés, configuration système: utilisateurs, sécurité, etc.) et Ansible pour l'exécution d'actions ponctuelles et de tâches d'orchestration (déploiement, etc.).

  • # Retour premier essai

    Posté par  . Évalué à -4. Dernière modification le 23 avril 2017 à 16:27.

    Comme promis plus haut, je me suis lancé dans l'installation de rudder 4. Pour le moment, ça ne fonctionne pas ^ ^
    En effet mon navigateur reste planté sur la page de chargement et à part le rechargement régulier de la page, rien ne se passe. (même pas la demande de login)
    OS server : Debian Jessie (up-to-date)
    OS client : pour le moment pas encore de client (je testerai après avec Raspbian, Ubuntu et Debian).

    infos un peu brute du retour :
    tuto suivis : https://www.rudder-project.org/doc-4.0/_install_rudder_root_server_on_debian_or_ubuntu.html

    Rechargement infini de la page d'accueil lors du premier lancement
    "Rudder is currently loading, please wait"
    Note : adblock et fake referer désactivé

    Erreur dans /var/log/rudder/reports/all.log

        * WARNING Generated inventory is not valid, as it is missing mandatory fields. *
        * Not sending it to the Rudder Server                                          *
        * You can check the invalid inventory in /var/rudder/tmp/inventory/        *
    

    et

        Apr 23 16:01:44 0rionServer1 rudder[28105]: CFEngine(agent) rudder R: @@server-roles@@result_error@@server-roles@@server-roles-directive@@1@@Check rudder status@@None@@2017-04-23 14:00:41+00:00##root@#The http://localhost:8080/rudder/api/status web application failed to respond for the second time. Restarting jetty NOW !
        Apr 23 16:01:44 0rionServer1 rudder[28105]: CFEngine(agent) rudder Method 'generic_alive_check' failed in some repairs
    
    

    Note :

    root@0rionServer1:/home/myUser# ls /var/rudder/tmp/inventory/
    0rionserver1-root.ocs
    

    Anecdote :

    Si on a choisit Yes par inadvertance à la question "Add more networks? (yes/no)" on est obligé de relancer /opt/rudder/bin/rudder-init

    Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

    • [^] # Re: Retour premier essai

      Posté par  . Évalué à 1.

      Tu n'as pas remarqué d'erreur lors de l'installation ?

      Sinon je t'invite à regarder le fichier de log de l'appli web /var/log/rudder/webapp/.stderrout.log

      • [^] # Re: Retour premier essai

        Posté par  . Évalué à -3.

        C'est bon : Mode barbare j'ai formaté la machine et ré-installer rudder ^ ^ Bon, j'ai dû m'y remettre à deux fois (la première tentative ayant planté suite à des problèmes de "La relation system-events existe déjà"), mais maintenant ça à l'air de fonctionner :)
        Ceci dis, le contenu de /var/log/rudder/webapp/ est assez désagréable à lire/appréhender (il était bourré de fichiers).

        Je suis en train d'installer des agents pour tester :) (petit tuto en cours de rédaction pour l'occasion ^ ^ )

        Par contre c'est étonnant que pour un logiciel dont on vante le côté français il ne soit pas traduit en français (ni sa doc) :P

        Tiens petites questions en vrac :

        • Peut-on participer à la traduction de la doc/WEBUI?

        • Quelles sont les pré-requis matériel/bandwidth pour genre 10 machines, 100 machines, 1000 machines ?

        • L'export des backups est-il automatisable via cron ?

        • il faut vraiment passer par la modification de /opt/rudder/etc/rudder-users.xml pour changer le password de l'admin? Rien dans la WEBUI de prévu?

        PS : c'est pratique que la doc soit aussi accessible localement directement depuis un lien sur la webui.

        Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

        • [^] # Re: Retour premier essai

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

          Par contre c'est étonnant que pour un logiciel dont on vante le côté français il ne soit pas traduit en français (ni sa doc) :P

          Il n'y a actuellement pas de version traduite (ou en cours de traduction) de Rudder ou de la documentation, principalement parce qu'il y a peu de demande (beaucoup d'utilisateurs ne sont pas francophones, et la plupart des utilisateurs francophones lisent l'anglais). En plus, ça demanderait beaucoup de ressources, qu'on estime pour l'instant mieux utilisées à améliorer la documentation existante.

          Quelles sont les pré-requis matériel/bandwidth pour genre 10 machines, 100 machines, 1000 machines ?

          La documentation d'installation donne contient une estimation pour la RAM et le disque nécessaires sur le serveur.

          Il n'y a pas de métrique de bandwith documentée, mais il existe notamment un mode Changes only qui permet de n'envoyer de rapports d'exécution que sur les modifications effectuées (et pas sur les composants qui sont déjà corrects et n'ont pas été modifiés), permettant de réduire fortement la consommation réseau de la remontée de rapport utile sur des environnements avec des contraintes réseau (connexion mobile, etc.).

          L'export des backups est-il automatisable via cron ?

          Il est possible de récupérer les archives de configuration via l'API, c'est donc facilement automatisable dans un script.

          Il faut vraiment passer par la modification de /opt/rudder/etc/rudder-users.xml pour changer le password de l'admin? Rien dans la WEBUI de prévu?

          Il est aussi possible d'utiliser un serveur LDAP pour l'authentification (mais la gestion des autorisations se fait pour l'instant toujours dans /opt/rudder/etc/rudder-users.xml).

          • [^] # Re: Retour premier essai

            Posté par  . Évalué à -3.

            Un gros merci pour tes explications @amousset :)

            En plus, ça demanderait beaucoup de ressources, qu'on estime pour l'instant mieux utilisées à améliorer la documentation existante.

            Pas forcément, la communauté est là pour ça. :)

            La documentation d'installation donne contient une estimation pour la RAM et le disque nécessaires sur le serveur.

            Pour les flemmards :P
            Pour la RAM

            less than 50 nodes: 2GB
            between 50 and 1000 nodes: 4GB
            more than 1000 nodes: 4GB + 1GB of RAM by 500 nodes above 1000. 
            

            Pour PostGreSQL

            max_space = number of Directives * number of Nodes * retention duration in days * 400 kB
            

            -

            Il est possible de récupérer les archives de configuration via l'API, c'est donc facilement automatisable dans un script.

            Nice ty ;) Je vais faire un tuto pour expliquer comment scripter un export des backups vers Nextcloud :)

            Il est aussi possible d'utiliser un serveur LDAP pour l'authentification (mais la gestion des autorisations se fait pour l'instant toujours dans /opt/rudder/etc/rudder-users.xml).

            En passant, la commande indiquée dans la Doc (read mypass; echo -n $mypass | sha512sum) chez moi ne donne rien (elle tourne dans le vide autant sur Ubuntu16 que Debian8).
            La commande que j'ai utilisé pour changer le password admin est

            echo -n "monPassword" | shasum -a 512
            

            (n'oubliez pas le coups de "history -c" pour pas que votre password soit visible en remontant l'historique du terminal)

            PS: si certains veulent jeter un coup d’œil voila le tuto qui me sert de retour d'expérience

            Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

    • [^] # Re: Retour premier essai

      Posté par  . Évalué à 1.

      Possible que le hostname de la machine soit à l'origine du problème. Si c'est "localhost" ça peut causer l'erreur. Essaye de mettre un autre hostname avec 'hostname' ou dans /etc/hosts.

Suivre le flux des commentaires

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