Dans un article précédent, je vous avais présenté la solution que j’utilisais pour profiter du cache de Varnish afin de combler les manques d’un proxy sur lequel je n’avais pas forcément la main. Aujourd’hui j’utilise toujours cette méthode, même à mon chez moi. C’est bien pratique. J’ai cependant rencontré quelques petits soucis en passant sur la Wheezy. C’est donc l’occasion de faire une petite mise à jour sur le sujet… ...

Je viens de mettre à jour mon environnement de test vers Puppet 3 (depuis une version 2.7.19). Pas de grosses difficultés, pas de grosses surprises… Je vais vous décrire dans cet article la méthode utilisée. Le principal point bloquant que j’ai rencontré lors de cette mise à jour s’est trouvé être mon serveur MySQL (utilisé pour la partie storeconfigs/inventory). J’ai eu toute une série de bugs que je n’ai pas réussi à résoudre et le fait que cette méthode sera bientôt obsolète m’a encouragé à passer à PuppetDB. J’ai eu également 2/3 erreurs plus simples liées à certains de mes manifests… ...

Dans cet article, je vais vous présenter une solution pour envoyer l’ensemble des commandes exécutées avec le shell bash sur un serveur syslog distant. Cette option est possible en utilisant la variable d’environnement PROMPT_COMMAND ou nativement avec bash à condition de le recompiler. C’est cette deuxième solution que je vais vous présenter avec deux alternatives : recompiler bash et l’installer directement depuis les sources ou modifier le paquet Debian. Nous verrons également une configuration rsyslog client/serveur pour centraliser tous vos logs à un seul endroit....

Il existe aujourd’hui plusieurs séries de Pacemaker : la version 1.0 sur laquelle sont basés les précédents tutoriels (la version stable actuelle), la version 1.2 qui sera la future version stable et la version 1.1 qui contient les nouvelles fonctionnalités en provenance de la version de dev et les corrections de bugs. C’est sur cette version que sera basé Pacemaker 1.2 qui devrait sortir en fin d’année. Pour pouvoir utiliser la version 1.1 en production, les développeurs ont rajoutés 2 nouveaux schémas de configuration. Avec cette nouvelle version, vous pouvez utiliser Corosync 2.0, utiliser de nouvelles fonctionnalités (déplacer les ressources en fonction de l’utilisation de votre serveur, gestion des ACLs…). ...

Dans cet article, je vais vous présenter une solution pour superviser l’exécution du vos agents Puppet avec Xymon. Cette solution utilise un module Puppet et plus précisément une librairie Ruby pour rajouter une possibilité de “reporting” au niveau de votre Puppet Master. Grâce à cette librairie, vous avez en plus de vos rapports habituels (logs, dashboard…), un voyant puppet pour chacun de vos serveurs Puppetisés. Ce voyant affiche le résultat du dernier déclenchement de l’agent : le test deviendra par exemple rouge (et donc alertant) si l’exécution de Puppet a échouée. Pour la partie installation client/serveur Xymon, je vous renvoie sur mon précédent article. ...

Xymon est un outil de supervision pour les serveurs (Linux, Unix, Windows), les applications et les équipements réseau. Les informations sur la “santé” de ces divers clients sont collectées et présentées sur une page web avec pour chacun d’eux, un voyant vert, jaune ou rouge représentant l’état du “service” supervisé. Par défaut, Xymon est capable de superviser un ensemble de services réseau, les ressources d’un serveur, l’état d’un service HTTP (et HTTPS) et met à jour une collection de graphes RRD permettant de voir l’évolution dans le temps. Xymon fonctionne sur le principe client / serveur : un serveur Xymon collectera les informations des différents clients. Dans cet article nous verrons l’installation et la configuration d’un serveur Xymon (4.3.7), l’installation d’un client et quelques astuces… ...

Si vous utilisez une version récente de Puppet (> 2.7) ou si vous envisagez de mettre à jour, il est peut-être temps de faire du ménage dans vos variables et dans la façon dont vous les déclarez. A partir de la version 2.7, vous risquez de voir apparaître un certain nombre de message pour vous encourager à ne plus utiliser des “variables dynamiques” (dynamic lookup) et d’utiliser des variables qualifiées. Dans les prochaines versions, si vous ne faites rien, vos variables auront “undefined” pour valeur ! Basé sur le grand ménage du lundi dans mes modules, voici les warnings sur lesquels je suis tombé et les corrections que j’ai dû apporter. ...

Dans les précédents articles sur le thème clusters/Pacemaker, nous avons aperçu rapidement une solution qui permet de regrouper les ressources sur un seul et même nœud (une VIP et son service par exemple) : l’utilisation de la commande group. J’avais alors évoqué la problématique liée à son utilisation et le fait qu’il était parfois préférable d’utiliser une solution à base de colocation/order. Le but étant d’éviter l’arrêt en cascade des ressources groupées. Je vais essayer ici de détailler la problématique et d’y apporter une solution. ...

Suite des articles sur l’installation d’un serveur Puppet scalable (à lire : partie 1 et partie 2). Votre PuppetMaster est installé, nous allons maintenant voir comment rajouter un autre PuppetMaster avec un partage de charge et les problématiques levées par ce fonctionnement (gestions des clés SSL par exemple). Il y a plusieurs solutions pour le partage de charge : nous verrons ici une solution à base d’HAProxy. Dans la deuxième partie de cet article, nous étudierons l’installation du dashboard de Puppet Labs. ...

Je vous propose ici une petite astuce pour parcourir un hash dans un template Puppet. Le besoin : je génère un fichier via un template dans lequel je parcours un hash pour afficher la liste des clés/valeurs. Problème : Puppet génère un fichier différent à chaque lancement car on ne peut pas prédire l’ordre de ce hash. J’ai rencontré ce problème de façon aléatoire sur certains serveurs avec Ruby 1.8 (Ruby 1.9 conserve l’ordre du hash). ...