Vulture 2.0.8 : problème d’ordre dans la directive ProxyPass dans le cas de plusieurs applis pour un même FQDN

Tue, 30 Dec 2014 13:48:52 +0000

Erreur de génération de conf Apache (ProxyPass) dans Vulture 2.0.8

Depuis la version 2.0.4 de Vulture, il est possible de présenter plusieurs « applications » (comprenez application web) sur un même FQDN, en les différenciant via leur URL complète.

C’est notamment utile dans le cas de l’utilisation de PNP intégré à shinken. Vous présentez la webui sur le WAN via https://shinken.example.org/, et les graphiques PNP sur https://shinken.example.org/pnp4nagios. Vous avez ainsi tout qui fonctionne comme en local dans un seul et même FQDN. Cette mise en place a fait l’objet d’un précédent article

Cependant, en plus d’apporter des fonctionnalités très appréciables, la mise à jour en 2.0.8 a apporté son lots de petits tracas supplémentaires sur mon installation, notamment pour Shinken (voir ici)

Je n’avais pas encore remarqué immédiatement, mais il y a eu également une régression de Vulture au niveau de la fonctionnalité dont je parle au début. Je ne pouvais plus accéder à mes graphes PNP4nagios dans Shinken.
En fait, après avoir analysé les logs, je me suis rendu compte que toutes les requêtes, et en particulier celles pour PNP, était redirigées vers Shinken, provoquant inévitablement un code retour 404 ([Edit]403 en fait[/Edit]).

Après avoir cherché à différents endroits, j’ai fini par remarquer que le problème vient en fait de la génération de la configuration Apache par Vulture en version 2.0.8. Contrairement aux versions précédentes, les directives ProxyPass ne sont pas ordonnées correctement.

Voici à quoi ressemble la configuration dans l’exemple suivant :

<VirtualHost 0.0.0.0:443>
ServerName appli.example.org
[...]
<Location />
[...]
</Location>
ProxyPass / http://@IP_privee:port_appli1/
[...]
ProxyPass /appli2/ http://@IP_privee:port_appli2/appli2
<location /appli2/ >
ProxyPassReverse /
[...]
</location>

La documentation Apache indique qu’il faut placer la directive ProxyPass avec l’URL la plus stricte/longue en premier, ce qui n’est pas le cas ici (Section encadrée « Ordre de classement des directives ProxyPass » dans Doc Apache de mod_proxy).

Cela implique donc que toutes les requêtes sont redirigées sur Shinken. CQFD.

En attendant un patch, vous pouvez manuellement déplacer la seconde directive ProxyPass au dessus de la première et redémarrer Vulture.
Ca m’a permis de contourner le problème et de retrouver mes graphes dans Shinken. Cependant, ce contournement ne survivra pas à la prochaine génération de la configuration en cas de modification depuis l’interface web Vulture.

Publier sur le WAN la WebUI de Shinken via Vulture

Sun, 21 Oct 2012 19:13:14 +0000

Ceux d’entre vous qui me suivent savent déjà que je suis de manière avide tous les développements du projet Shinken, un outil de supervision compatible avec Nagios, mais qui apporte des fonctionnalités de haute dispo et de vue business bien supérieures à ce qu’on peut faire simplement avec Nagios. Depuis quelques temps, les développeurs de Shinken ont beaucoup bossé sur une interface plus épurée et pourtant plus puissante que celle de Nagios (voire même Centreon pour certaines idées) en HTML 5.

Dans les débuts de cette interface, j’ai eu le plus grand mal à la faire passer au travers de mon web proxy applicatif personnel (Vulture). Aujourd’hui, avec la stabilisation du code de la WebUI de Shinken et aussi une meilleure compréhension des mécaniques de vulture, j’ai réussi à la faire passer sur Internet et je peux donc consulter à tout instant l’état de mon infra perso, ce qui, vous en conviendrez, est une nécessité absolue.

Mais trêves de bavardages. La première chose que je tiens à dire, c’est que cet articule ne couvrira pas l’installation de Shinken, pour la bonne et simple raison que j’ai horreur d’écrire des articles quand des blogs/forum/wiki existent déjà pour dire la même chose. Pour rappel :

Si vous souhaitez installer Shinken, vous n’avez qu’à exécuter la commande suivante :

Page de download de Shinken (lien mort, remplacé par Internet Archive)

Pour configurer Shinken

10 Minute Shinken Installation Guide (lien mort, remplacé par Internet Archive)

Passons maintenant aux choses sérieuses. Dans un premier temps, vous avez installé et configuré Shinken, il fonctionne, et vous pouvez ouvrir votre WebUI en local

Le dashboard classique de l’outil de supervision de base. C’est la moins sexy des vues de Shinken mais je reste un peu vieux jeu

Maintenant, tout se passe côté Vulture. Je pars du principe que vous disposer d’un nom de domaine (on n’a qu’à prendre vulture.fr, au hasard), et que vous avez mappé les adresses suivantes sur l’IP depuis votre domaine vers votre serveur vulture

portal.vulture.fr
shinken.vulture.fr
pnp.vulture.fr

Vous l’aurez certainement deviné, la première sert au portail et est rattaché à la définition de l’interface vulture. Tout arrivera sur cette interface (pour ceux qui en ont plusieurs, pour les autres qui n’en ont qu’une, c’est évident). Cependant pour les deux autres, vous pouvez remarquer que j’ai été obligé d’utiliser deux noms différents pour ma WebUI (au moins dans un premier temps, en attendant de trouver une meilleure façon de faire). Et pour cause…
Malheureusement, la WebUI utilise un composant python qui génère du code HTML 5 à la volée, en écoute sur le port 7767. Cependant, pour compléter un peu la vue des services et notament pour ce qui est des perfdata, l’équipe de Shinken à pris le parti de réutiliser le travail de pnp4nagios, qui est intégré directement dans l’interface. Or, pnp4nagios est un composant web tout ce qu’il y a de plus basique, qui tourne dans un apache sur le pour 80 (ou n’importe quelle autre port, on s’en fiche, juste pas le 7767).

Du coup, vu de vulture, j’ai été contrains à créer deux applications, et donc à leur donner deux noms distincts. C’est là la partie qu’il reste à améliorer. Il est surement possible de faire mieux, pour l’instant je n’ai pas trouvé…

Une fois nos deux applications définies dans vulture, il reste encore un petite opération pour que le tout fonctionne. A l’heure actuelle, le code de Shinken à la facheuse tentance à générer des liens et à rediriger automatiquement vers des pages via des URLs absolues… du type http://@IP_locale/webui. En local, votre navigateur saura résoudre cette IP privée, mais pas sur Internet. C’est pourquoi nous allons demander à vulture de réécrire tous les contenus qui posent problèmes à la volée. Pour cela il faut aller dans le menu « Plugin de réécriture de contenu ». Il faudra transformer toutes les requêtes qui sont en HTTP en local en HTTPS derrière vulture, et transformer les URL pnp pour qu’elles pointent vers la bonne application.

Shinken crache des liens HTTP simple toutes les 30 secondes, ce qui est fâcheux quand votre vulture écoute sur du HTTPS

la webui génère de moches adresses IP locales que vulture n’ose pas modifier sans notre accord explicite

Une fois ces étapes réalisées, vous devriez pouvoir afficher la webui derrière votre vulture comme si vous étiez en local. Reste donc à accepter les certificats autosigner, à s’authentifier dans la WebUI PUIS dans pnp4nagios, et le tour est joué. Et comme vulture est un SSO en plus d’être un firewall applicatif, il sera aussi possible de bypasser ces deux authentifications, mais ceci fera l’objet d’un article ultérieur (quand j’aurai pris le temps de comprendre comment ça fonctionne)

Pnp4nagios on Zwindler's Reflection

Vulture 2.0.8 : problème d’ordre dans la directive ProxyPass dans le cas de plusieurs applis pour un même FQDN

Erreur de génération de conf Apache (ProxyPass) dans Vulture 2.0.8

Publier sur le WAN la WebUI de Shinken via Vulture