Installation de Rudder

Logo-Rudder-fond-transparent-1

Un article pour aborder l’installation et la configuration de Rudder que j’ai testé il y a cela un an, puis je viens de découvrir les dernières nouveautés de la version 2.8. Rudder est ce qu’on appelle un outil de gestion de configuration et il s’appuie notamment sur CFEngine 3. Lorsqu’on a un parc de serveurs assez conséquent qu’il soit hétérogène ou non, il devient très fastidieux de faire des tâches répétitives. Par exemple, s’assurer que la configuration des routes soient bonnes, la gestion du fichier /etc/hosts (lorsqu’on n’a pas de DNS), appliquer la même politique du sécurité sur le serveur ssh, installer un package… La liste est très longue 🙂

Sans rentrer dans les détails, Rudder se compose de 2 gros composants :

  • Rudder Agent : une intégration de l’agent CFEngine et de celui de FusionInventory, qui en se connectant au Rudder Server, va récupérer les rules (promises) à appliquer et envoyer l’inventaire de la machine.
  • Rudder Server : Qui se compose de CFEngine et d’une interface Web. Cette dernière qui reste très intuitive va nous permettre d’intégrer les agents Rudder, composer ces rules et les appliquer sur un ou plusieurs groupes d’agents.

Pourquoi Rudder ? CFEngine est un outil très puissant dont l’apprentissage du langage reste très difficile lorsqu’on commence à l’utiliser. Sa configuration se base essentiellement sur des fichiers textes. Et c’est là que Rudder tire toute sa puissance ! Grâce à son interface web et des promises pré-définies, vous allez pouvoir créer très facilement vos propres promises et choisir les agents sur lesquels les appliquer. D’ailleurs personnellement j’ai encore du mal avec la syntaxe de CFEngine et Rudder accélère énormément le déploiement de mes config.

Pour faire une petite comparaison, Rudder c’est un peu comme Puppet Dashboard mais il n’existe pas de version Enterprise avec une limitation des nodes !

Je vais utiliser 2 vm que j’appelerai rudder-server et rudder-agent. Des packages touts prêt existents pour Debian/Ubuntu, Centos/Redhat et SLES.

Mon installation se fera sur une Centos 6 et je vais utiliser la dernière version du Rudder de dispo. A ce jour, c’est le 2.8 (sorti le 07/11/2013)

Installation du Server

Si vous n’avez pas de DNS, il faut modifier le fichier /etc/hosts et rajouter les informations relatives aux 2 VMs

Un exemple :

192.168.122.10 rudder-server
192.168.122.15 rudder-agent

 

Configuration du repository YUM :

1
rudder-server # vi /etc/yum.repos.d/rudder.repo

copier les informations suivantes :

1
2
3
4
5
[Rudder_2.8]
name=Rudder 2.8 Repository
baseurl=http://www.rudder-project.org/rpm-2.8/RHEL_6/
gpgcheck=1
gpgkey=http://www.rudder-project.org/rpm-2.8/RHEL_6/repodata/repomd.xml.key

Puis lancer l’install :

1
rudder-server # yum install -y rudder-server-root

Après l’installation, une première configuration est nécessaire, lancer la commande suivante :

1
rudder-server # /opt/rudder/bin/rudder-init.sh

Répondez aux questions, à titre d’exemple :

  • Hostname : rudder-server (nom du serveur)
  • Allowed networks : 192.168.122.0/24 (le réseau à autoriser)
  • sample data : no (Information de demo)
  • LDAP database : yes (promises à installer)

J’ai rencontré un soucis au premier lancement, j’ai dû redémarrer le serveur ldap puis relancer la commande :

rudder-server # /etc/init.d/slapd restart

 

Après l’installation, prenez votre navigateur préféré et aller sur l’url : https://rudder-server/rudder/

Identifiant : jon.doe/secret

Sélection_013

Si tout se passe bien, vous devriez avoir cette page ensuite :

Sélection_015

Le serveur d’application Jetty peut mettre un certain temps à se démarrer. Si vous rencontrez des soucis, analyser le fichier de log

1
rudder-server # tail -f -n 20 /var/log/rudder/webapp/YYY_MM_DD.stderrout.log

Installation de l’Agent

Répéter les mêmes actions que pour la partie server : configuration du fichier /etc/hosts et yum.

Puis lancer l’install :

rudder-agent # yum install -y rudder-agent

Configurer l’agent rudder en renseignant le nom du serveur Rudder à contacter :

rudder-agent # echo rudder-server > /var/rudder/cfengine-community/policy_server.dat

Démarrage l’agent :

rudder-agent # /etc/init.d/rudder-agent start

Forcer la communication avec le serveur Rudder si vous ne souhaitez pas attendre que l’agent le fasse de lui-même :

rudder-agent # /var/rudder/cfengine-community/bin/cf-agent -KI

Vous pouvez vérifier que la communication s’est bien faite en lançant cette commande sur le serveur rudder :

rudder-server # find /var/rudder/inventories -name "*.ocs"

Vous devriez voir l’inventaire de fusion dans /var/rudder/inventories/incoming

Petite subtilité : si vous n’avez pas de DNS, il faut impérativement que l’agent puisse résoudre le nom du serveur rudder et inversement. Auquel cas, vous allez rencontrer des difficultés de communication entre l’agent et le serveur.

Visualisation de l’Agent depuis Rudder Server

Depuis l’interface, vous devriez voir votre Agent dans Node Management > Accept new nodes. Ce dernier doit être accepté afin de pouvoir l’utiliser.

Sélection_016

Cochez puis cliquer sur Accept into Rudder

Si vous partez maintenant dans Node ManagementList nodes vous devriez le voir apparaitre :

Sélection_017

Si vous cliquez sur l’agent, vous allez retrouvez plusieurs information dont notamment l’inventaire effectué par FusionInventory.

Utilisation de Rudder

L’installation de Rudder (serveur et l’agent) a été plus tôt simple. Nous allons voir maintenant comment utiliser l’interface et les possibilités qu’elle offre. Je vais prendre 2 exemples corrects :

  • Sur l’ensemble de mon parc de serveurs j’ai notamment quelques Centos 5 et 6. Afin de ne pas trop solliciter notre bande passante internet, j’ai créé un miroir en local des dépôts de Centos. Je souhaite donc pousser sur tous mes serveurs Centos la config yum associé à mon dépôt local.
  • Second exemple : n’ayant pas de DNS il faut gérer le fichier /etc/hosts afin que mes serveurs Centos puisse joindre mon serveur de dépot yum

Tout d’abord, il faut connaitre les objets que Rudder utilise :

  • Les Groups : ils vont nous permettre de rassembler des Nodes (Agents), tous mes serveurs linux, ou CentOS. On verra qu’ils peuvent être dynamiques ou statiques
  • Les Techniques : on peut voir cela comme des templates de Promises. Rudder propose un panel de techniques permettant de gérer différentes configuration. Par exemple, la configuration du service ssh, avec toutes les options qui la composent.
  • Les Directives : On instancie une directive à partir d’une technique. Une directive offre la possibilité de paramétrer des valeurs. C’est un peu l’équivalent d’une promise. Par exemple, dans une configuration particulière du service ssh , je désire que root n’a pas le droits de s’y connecter, l’authentification se fait uniquement par clé ssh, l’authentification par mot de passe est désactivée.
  • Les Rules : c’est l’application d’une ou plusieurs Directives sur un ou plusieurs Groups. A travers du menu de gestion des Rules on peut voir leur état. Si Rudder les a bien déployé ou non.

Les Groups

Je vais créer 2 groupes que je vais nommer Centos 5 et Centos 6. Dans l’interface il faut aller : Node Management > Groups > Create a new item

Sélection_018

Il faut donner un nom “Centos 5”, une description et pour ma part je coche Dynamic comme type et pour finir, Save

Sélection_032

Prochaine étape paramétrer ce groupe en effectuant des filtres :

  • Operating System Name = CentOS
  • Operating System Version Regex 5.*
  • pour finir cliquer sur Search pour visualiser les nodes qui correspondent aux critères.

Dans le cadre d’un groupe dynanique, les nouveau node du type CentOS 5 seront automatiquement rattachés à ce groupe.

Pour finir, cliquer sur Save et ajouter si nécessaire un commentaire.

La création du prochain groupe les CentOS 6 se fait de la même manière mais on va utiliser la fonctionnalité de clonage de groupe et changer les critères :

Sélection_034

  • Operating System Name = CentOS
  • Operating System Version Regex 6.*

Si vous cliquez sur Search, vous devriez voir apparaitre le node rudder-agent

Directives

Pour la création d’une nouvelle directive, il faut aller dans Configuration Policy > Directives. Pour le moment, il n’y a de technique qui gère les repo YUM alors que pour APT, il en existe une dans Application management > APT package manager configuration. C’est pas grave, on va utiliser Distributing files > Enforce a file content.

Sélection_023

On clique que Create Directive

Sélection_024

On donne un nom et une description par ex. : “yum config local miroir centos 5/6” puis cliquer sur Configure

Sélection_026

En terme de configuration, j’ai choisi :

  • Path : /etc/yum.repos.d/CentOS-Base.repo
  • Enforce the content of the file” coché
  • File Content
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# YUM repo Centos configuration
# Don't change this file
# it is managed by rudder
 
[base]
name=CentOS-$releasever - Base
baseurl=http://mirrorcentos/centos/$releasever/os/$basearch/
gpgcheck=1
enabled=1
 
[updates]
name=CentOS-$releasever - Updates
baseurl=http://mirrorcentos/centos/$releasever/updates/$basearch/
gpgcheck=1
enabled=1
 
[extras]
name=CentOS-$releasever - Extras
baseurl=http://mirrorcentos/centos/$releasever/extras/$basearch/
gpgcheck=1
enabled=1

On clique sur Save pour finaliser la configuration de la directive.

On attaque la création de la seconde directive selon le même principe. Mais cette fois-ci, il faudra gérer le fichier /etc/hosts afin de connaitre le host mirrorcentos. Son adresse ip par ex est 192.168.122.99

On va utiliser la technique System settings > Networking > Hosts settings

Sélection_027

On renseigne un nom et une description

Sélection_028

 

Dans Hosts setting #1 il faut renseigner les informations associées au host. Si besoin, on peut en rajouter un autre en cliquant sur Add another.

Rules

On va maintenant créer notre première rule il faut aller dans “Configuration Policy” > Rules > “Add a new rule”

Sélection_029

Au niveau du paramétrage :

Sélection_030

Rien de plus simple, on va sélectionner les 2 directives créées et les 2 groupes dynamiques :

  • rule : yum config local miroir centos 5/6
  • rule : mirrorcentos host
  • group : Centos 5
  • group : Centos 6

Cliquer sur Save pour créer la rule. Il faut attendre quelques minutes pour que la rule s’applique sur le node. Mais si vous n’avez pas de problème de résolution de noms (agent et serveur), voire de syncho NTP vous devriez voir les rules s’appliquer sans problème :

Sélection_031

On peut aussi vérifier que les modifications ont bien été déployées :

rudder-agent # cat /etc/hosts
rudder-agent # cat /etc/yum.repos.d/CentOS-Base.repo

Pour aller plus loin

Il est possible d’écrire ces propres Techniques et l’intégrer dans Rudder une doc est disponible. Il faut au minimum connaitre la syntaxe de CFEngine. Pas très pratique pour un débutant ou soit passé par une formation.

CFengine sous Windows : l’agent existe mais il est payant. La société Normation (éditrice de la solution Rudder) propose une version de leur agent pour Windows. Perso, je ne l’ai pas testé.

Il existe aussi CFEngine en version Enterprise, voici un comparatif https://cfengine.com/cfengine-comparison

Si vous souhaitez discuter avec les développeurs et la communauté un channel irc est disponible : #rudder sur Freenode. Une forge est aussi disponible pour remonter des bugs ou des features.

Références :

http://www.rudder-project.org

https://cfengine.com/docs/3.5/index.html

http://www.blogcompiler.com/2012/09/30/scalability-of-cfengine-and-puppet-2/

En attendant centreon 2.4, thruk propose son panorama view

Pour ceux qui suivent le projet de Centreon de près, la prochaine version 2.4 intègrera les widgets et bien plus encore. Une fonctionnalité très attendue pour ma part car on pourra afficher des graphes, l’état des services sur un même tableau de bord avec la possibilités de filtrer sur plusieurs critères, la rotation de plusieurs dashbord… Le but étant d’utiliser un seul et même outil pour personnaliser sa supervision via des tableaux de bord.

Néanmoins, si vous êtes impatient comme moi et que vous regardez un peu ce que propose les autres outils, j’ai dernièrement testé le panorama view de Thruk. C’est un nouveau plugin qui est apparu en version 1.36 de (sorti le 19 juil 2012) qui ressemble beaucoup au dashbord que propose Icinga. Ce plugin vous permet de créer autant de dashbord que vous voulez et de rajouter des widgets.Personnellement, j’apprécie beaucoup le fait qu’on peut déplacer et redimensionner ses widgets à foison.

Parmi les widgets fournis, on retrouvera :

  • l’état des ses hosts et services
  • la disponibilité des hosts et services (sous forme d’un camembert)
  • la métrologie provenant des graphes pnp
  • les métrics et graphes de ModGearman

Mais voilà en tant qu’utilisateur de Centreon, j’aurai bien aimé que mes graphes RRD s’affichent sous Thruk et heureusement que mon ami Tensibai a fourni un patch très intéressant : la possibilité d’afficher les graphes RRD via l’autologin key (un peu comme un cookie de session) et en fournissant le host et le service en paramètre.

Son utilisation est très simple; voici un petit howto pour l’activer :

  • Modifier la configuration d’un utilisateur pour activer l’autologin key
  • Allez dans Configuration>Users, choisissez notre utilisateur (pour ma part : nagiosadmin), puis dans l’onglet dans l’onglet “Centreon Authentification”
  • Générer un autologin key, puis sauvegarder

Pour générer un graphe automatiquement, il va falloir utiliser une url bien particulière :

http://IP/centreon/include/views/graphs/generateGraphs/generateImage.php?username=<USER>&akey=<KEY>&hostname=<HOST>&service=<SERVICE>

Remplacer <USER> <KEY> <HOST> <SERVICE> par vos propres valeurs.

Maintenant dans Thruk en allant le panorama view, il faut utiliser le widget Pnp Graph

Dans le champ Graph, il faut utiliser l’url de Centreon avec fournissant les bons paramètres de <USER> <KEY> <HOST> <SERVICE>

A la fin, cela ressemble à ça chez moi :

Vous n’êtes pas convaincu : essayer donc de faire vos propres test sur le site : http://demo.fullyautomatednagios.org/thruk/

 

Thruk une alternative au cgi de Nagios

Vous connaissez très certainement les CGI de Nagios, l’interface web très sobre (même si elle a un peu évoluée) qui présente l’état des indicateurs de supervision. Elle a beaucoup de défaut, voici un petit panel :

  • ses très faibles performances lorsqu’on a des dizaines de milliers de services à afficher
  • non conçue pour le mode distribué. Elle peut l’être avec un peu de gymnastique entre nsca et du mode passif. Bref un gros bordel à configurer
  • s’appuie sur des fichiers locaux pour récupérer l’état des services, d’où sa lenteur
  • ne possède pas de filtres avancés (genre je veux tous les services hard, avec notification, qui sont en CRITICAL dont aucun downtime n’est planifié)
  • génère de la latence à Nagios

Bref, on peut en citer encore mais je vais m’arrêter là. C’est pourquoi je préfère utiliser Thruk. Une application web codée en perl et qui a l’avantage d’être performante et très rapide.

Ses atoûts :

  • elle s’appuie sur livestatus pour récupérer l’état des services et host. Livestatus étant un broker voulant d’être très rapide
  • Encore grâce à Livestatus, thruk peut afficher les indicateurs de plusieurs Nagios. Elle fonctionne donc très bien avec le mode distribuée
  • Possède des filtres avancés
  • Permet de sauvegarder en tant que favoris ces propres tableaux de bord
  • On peut changer son apparence. Il y a les thèmes Vautour, le Nagios Classic (tout moche !), Nuvola
  • Compatible avec Icinga et Shinken
  • s’installe facilement avec OMD

Bon, y a pas que des avantages je vous dirai, j’ai noté quelques inconvénients mais ça reste très soft :

  • des dépendances à Perl à satisfaire si vous voulez pas que l’installeur vous insulte. Mais il propose aussi de les télécharger et les installer pour vous 😉
  • en terme de mise à jour, il faut faire quelques manip pour retrouver ses favoris, les logos, sa configuration
  • intégrer thruk avec Apache nécessite l’installation de fast-cgi ou
  • Thruk c’est un démon supplémentaire. Bon ok celui-là c’est pas réellement un inconvénient.

 

Voici quelques screenshots :

Vous n’êtes pas convaincu, alors voici une démo. Login nagiosadmin / nagiosadmin

Quelques doc pour l’installer :

Dotclear 2 WordPress

Après quelques années pour avoir utilisé Dotclear, j’ai décidé de changer mon moteur de blogging pour WordPress. Bien que je suis attaché à utiliser des produits développés par des communautés françaises, j’ai trouvé que Dotclear commençait à s’essouffler et ne proposait pas autant de fonctionnalités que WordPress. J’avoue que j’ai un peu craqué pour WordPress car

  • il y a de nombreux plugins disponibles
  • sa convivialité pour son panel d’administration
  • Les thèmes proposés dont Mystique que je trouve génial pour personnalisé le skin

La migration de Dotclear vers WordPress s’est fait très facilement grâce au plugin dc22wp2. Pour ma part, l’étape a consisté de :

  1. installer un wordpress 3.0.4 (dernière version WP supporté par le plugin dc22wp2)
  2. installer le plugin dc22wp2
  3. effectuer la migration
  4. et pour finir upgradé wordpress 3.0.4 à la dernière version 3.3.1

Il reste encore quelques articles à retaper mais la majeure partie a été récupérée.

Le dotclear reste néanmoins disponible sur http://lkco.gezen.fr/dotclear/

Mon serveur piraté

Vous l’avez peut être remarqué, mon blog, ma galerie photos et les dépots FAN ainsi que d’autres sites web que j’hébergerais ont été indisponibles depuis le 18/11/2011.

La cause : un petit hacker très malin qui a réussi à exploiter une faille de sécurité dans les plugins Ajax de mon Zenphoto. il a réussi à supprimer tout le contenu de /var/www appartenant à mon utilisateur www-data. Oui j’avoue j’aurai dû être un plus prudent en changeant le propriétaire de mes applis Web ! ça c’est une autre histoire. En traçant mes logs Apache, j’ai pu comprendre comment il a fait :

  • Grâce au plugin ajaxfilemanager de Zenphoto, il a réussi à télécharger cette petite appli. Pas de soucis, on y retrouve du code source Perl, php SQL, et pas de virus
  • Après avoir extraire le contenu du zip, il a réussi à se connecter à la page http://lkco.gezen.fr/zenphoto/zp-core/zp-extensions/tiny_mce/plugins/ajaxfilemanager/inc/dz.php Le fichier dz.php était contenu dp.zip
  • Enfin, c’est là le drame : la page dz.php fourni au hacker l’équivalent d’un ajaxterm lui permettant de lancer des commandes shell. La fin vous la connaissez.
  • Tout ceci lui a pris environ 10 minutes avant se s’auto-killer lui même

Les plus gros dégâts sont surtout :

  • quelques dépots YUM de FAN qui supprimés et des ISO mais ils ont pu être restaurés
  • mon blog avec toute la customization que j’ai pu apporté ont été perdu. Pas de chance, je n’avais pas fait de sauvegarde

Au niveau de mes comptes utilisateurs système et base de données mysql rien à signaler. A vrai dire j’ai blindé mes comptes d’administrateur avec des mots de passe fort. Voilà tout se reconstruit petit à petit ! Ci-dessous l’interface qui a été utilisé, je l’ai installé sur une vm pour voir à quoi ça ressemblait.

Conclusion : faire des sauvegardes régulièrement, suivre les news des applications que vous utilisez. Et oui, sur le site de Zenphoto, cette faille est corrigé dans la dernière version.

FAN 2.1 est disponible en version stable !

Salut à tous, après plus d’un an de gestation, la dernière monture de FAN est disponible en version stable.

Comme d’habitude, FAN est disponible sous forme d’une iso téléchargeable : http://fannagioscd.sourceforge.net/wordpress/download/

Quoi de nouveau dans cette version :

  • Nagios 3.2.3
  • Centreon 2.1.13
  • NagVis 1.5.8
  • Les plugins officiels de Nagios 1.4.15
  • La possibilité de configurer une supervision distribuée
  • L’ajout du thème Vautour personnalisé FAN pour les CGI de Nagios
  • La mise à jour en CentOS 5.6

Pour plus d’informations :

Merci à toutes les personnes qui ont participé à l’élaboration de cette nouvelle version : ctemple, dadu, taytay, frogx, hvad, rvrignaud, lkco, arthurc, wistof…

Bilan du salon Solutions Linux 2010

L’édition 2010 est un bon cru pour cette première ! L’association entre Nagios-fr (dorénavant Monitoring-fr.org) et FAN fut un succès pour tous.

Durant ces 3 jours NON-STOP où nous avons pu échanger, présenter la supervision, effectuer des démos, s’interroger sur l’avenir de Nagios, rencontrer d’autres acteurs dans le logiciel libre. Je pense notamment à GLPI, Fusion-inventory, l’APRIL, la société Méréthis, les packageurs Fedora et bien d’autres que j’oublie. Et puis j’imagine que tout le monde a pu y trouver son compte et s’éclater auprès d’une communauté très active.

Personnellement, je remercie :

  • Toutes les personnes qui sont venues nous rencontrer, qui nous encouragent dans ce que nous entreprenons pour FAN.
  • Merci à Parinux dont Emmanuel Seyman pour cette belle organisation du village associatif
  • Merci à Mozilla de nous avoir fourni gratuitement Internet
  • Merci aux sociétés de nous avoir offert quelques coupes de champagne et bières !
  • Merci Dadu pour les boissons et la bouffe : c’est toujours sympa 😉
  • Merci à l’équipe de FAN et Nagios-fr qui ont mis toute leur énergie dans ce salon. Car rester 3 jours pratiquement debout toute la journée ça commence à faire beaucoup pour des geek pas habitués. Mais c’est de la bonne fatigue !!!

Une expérience à renouveler l’année prochaine et peut être à cet été pour les ReuMeuLeuLeu

Richard Stallman à Lyon le 13 janvier 2010

L’annonce est donnée par l’ALDIL : Richard Stallman sera à Lyon le 13 janvier 2010 où il donnera une conférence. Le lieu n’est pas encore déterminé mais on peut déjà penser à bloquer cette date. Après la conférence, la soirée va certainement se terminer dans un bar ou restaurant. On aura plus de détail ultérieurement. A suivre donc

JDLL 2009 : 11ème édition des Journées Du Logiciel Libre

L’ALDIL organise les __15, 16 et 17 octobre 2009__ la 11ème édition des Journées Du Logiciel Libre sur le Campus de la Doua (Villeurbanne) dans les locaux de CPE Lyon (école supérieure de chimie, physique et électronique). %%% Cet événement réunira une trentaine d’exposants et sera animé par une cinquantaine de conférences sur des sujets concrets ou réflexifs autour de la place du logiciel libre dans notre quotidien et nos pratiques professionnelles. Plusieurs centaines de visiteurs sont attendus. L’ALDIL (Association Lyonnaise pour le Développement de l’Informatique Libre) réunit ainsi chaque année les utilisateurs, les développeurs et les prescripteurs de solutions libres.%%% [JDLL|http://www.jdll.org/|fr]%%% [ALDIL|http://www.aldil.org|fr]

ah j’en apprends toujours avec ssh

Aujourd’hui au boulot, pour un de mes clients je dois regarder l’organisation de son annuaire pour notre application. Je l’appelle en lui demandant très gentillement si je peux obtenir un moyen pour venir effectuer des requêtes sur son annuaire.

Après quelques péripéties, ouverture de port sur le firewall, de la translation d’adresse et j’en passe… il me donne enfin un accès ssh sur l’un de ces serveurs, qui n’est malheureusement pas pour moi le serveur hébergeant l’annuaire LDAP.

Je me connecte, j’ai les informations pour venir requêter son annuaire mais je n’ai pas la commande “ldapsearch”. En regardant un peu le système (RHE 4.2), j’ai 3 solutions devant moi :

  • Installer le paquet qui fournit la commande ldapsearch. Pas super, comme solution car d’une part le serveur n’est pas rélié à internet, et d’autre part ne sachant pas ce que fait ce serveur, je n’aime pas installer des choses si c’est une machine de prod.
  • Créer un programme php car j’en fait vu que le paquet php-ldap était installé. N’étant pas un bon codeur, cette solution ne m’intéresse pas beaucoup.
  • Trouver une bidouille avec ssh pour lancer depuis mon poste, la commande ldapsearch à travers un tunnel.

En choisissant la dernière solution, j’ai ma machine A où je peux venir me connecter en ssh sur la machine B. Depuis B, je peux venir interroger la machine C qui héberge l’annuaire Ldap. (la connexion de A vers C est impossible)

En fouillant, dans le manuel de ssh. J’ai enfin trouvé ce que je voulais :

sur A, je lance

A$ ssh -g -L1234:C:389 B

Du coup, sur ma machine A, je lance

A$ ldapsearch -h localhost -p 1234 -x -b "XXXX"

Une redirection sur localhost:1234 est effectuée sur C:389 à travers la connexion ssh sur C:22