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.

Vulture 2.0.8 : des nouveautés et des impacts sur la WEBUI de Shinken

Fri, 25 Jul 2014 14:14:08 +0000

Fin mai, la version 2.0.8 est sortie et a apporté un lot impressionnant de fonctionnalités supplémentaires (ainsi que quelques bugfixes d’usages)… ainsi que quelques petites surprises pour ma configuration, et notamment pour publier la WebUI de Shinken au travers de Vulture.

Mais le jeu en vaut largement la chandelle, regardez plutôt …

Réécriture de la documentation

OMG ! Vulture dispose ENFIN d’une documentation (relativement complète) pour CHAQUE page de l’interface d’administration. Cela permet de remettre au clair les passages qui n’avaient pas été bien compris lors de mes premières installs et corriger quelques erreurs dues au manque d’information sur les versions précédentes.

A noter, si vous commencez, il faut aller sur ces deux pages, avant de lire la doc en entier, pour ne pas être perdu :

Refonte intégrale du packaging

Refonte intégrale du packaging : Vulture s’installe désormais simplement avec 3 paquets

ENFIN bis ! Et ça fonctionne bien, fini les galères pour installer les dépendances. Par contre la liste des distribs gérées se limite à sont plus simple appareil : CentOS 6.5 et Debian 7.

Mise à jour automatique des configurations

Bon… ça, ça fait un moment qu’on nous le promet, et j’ai du faire une fausse manipulation certainement car comme d’habitude… j’ai tout perdu… Si vous avez des retours positifs, je suis preneur ;)

Support d’une URL par défaut dans les interfaces

En voilà une bonne idée ! Cependant, j’ai eu à l’inverse la mauvaise idée d’en indiquer une pour mon interface, alors que cette appli/URL n’existait pas, et je me suis retrouvé avec de gros soucis sur mon portail, qui ne marchait tout simplement plus.

J’avais des erreurs au niveau des logs des applications, avec des messages d’erreurs faisant état d’une application inconnue depuis le fichier Core::AuthzHandler.

Je le re-testerai une autre fois, pour voir, mais je me demande s’il ne manque peut être des contrôles vu que c’est une nouvelle fonctionnalité. Si vous n’en avez pas besoin, je vous conseille de ne pas l’utiliser.

Plugins – Transhandler

Suite à l’installation de la 2.0.8 de Vulture, je n’arrivais plus à faire fonctionner la WebUI de Shinken. J’arrivais à avoir la mire d’authentification, mais pas les images et le CSS.

Après dépilage des logs, j’ai fini par remarquer que les connexions faisant appels au CSS et aux images (de type static/*) se retrouvaient redirigés sur le serveur où est installé Vulture, et pas sur le serveur Shinken où elles sont situées.

Après vérification, j’ai trouvé avec étonnement que le plugin TransHandler STATIC static/* livré par défaut lors de l’install était appliqué à toute mes applis, alors que cette règle n’est normalement appliqué à AUCUNE application (paramètre positionné à None)**. [Edit] En fait selon l’équipe de Vulture, c’est normal, quand on a la colonne « Application » à « None », ça signifie que ça s’applique à toutes les applications [/Edit]
**

La documentation fait bien état de ce plugin, qui sert effectivement à mettre en local sur le serveur qui héberge Vulture toutes les ressources statiques (ici).

J’ai désactivé ce plugin, et tout est rentré dans l’ordre. [Edit] Il semblerait que cela soit plus compliqué que cela. Ce contournement provoque notamment des effets de bord sur le portail. J’ai ouvert un thread sur le google group de vulture à ce sujet.[/Edit]

Will not rewrite (Rewrite Content) this content-type: application/json

Une fois Shinken de nouveau disponible, ce n’était pas terminé pour autant. Visiblement, depuis la 2.0.8 (peut être avant mais je n’ai pas remarqué en 2.0.4), le plugin de réécriture de contenu de la page à la volée Rewrite Content ne prend plus en charge l’ensemble des contenus par défaut. Cela se traduit par une page web qui n’est simplement pas réécrite (on retrouve les URL privée de PNP dans la page Shinken) et par le message suivant dans le fichier de log

Le log est plutôt explicite, et la doc aussi (vultureproject.org/documentation/configuration/configuration-des-applications-web/composants-plugins/reecriture-de-contenu/) !

Vulture ne pourra altérer que les contenus dont le content-type est l’un des suivants (il est cependant trivial d’en ajouter d’autres, contacter l’équipe de développement pour signaler un type non géré)

Les types sont les suivants :

text/xml
text/html
application/vnd.ogc.wms_xml
text/css
application/x-javascript

J’ai donc signalé ce manque à l’équipe mais en attendant qu’ils publient un patch, vous pouvez simplement ajouter dans l’expression régulière application/json et text/javascript ligne 138 du fichier /opt/vulture/lib/Vulture/Plugin/Plugin_OutputFilterHandler.pm

diff /opt/vulture/lib/Vulture/Plugin/Plugin_OutputFilterHandler.pm*
138c138
< if ($r->content_type ne '' and $r->content_type !~ /(text/xml|text/html|application/vnd.ogc.wms_xml|text/css|application/x-javascript|text/plain|application/json|text/javascript)/){
---
> if ($r->content_type ne '' and $r->content_type !~ /(text/xml|text/html|application/vnd.ogc.wms_xml|text/css|application/x-javascript|text/plain)/){

2.0.8 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

Vulture 2.0.8 : des nouveautés et des impacts sur la WEBUI de Shinken