Apache on Zwindler's Reflection

[Tutoriel] A la recherche d’un équivalent à PhotoStation : Piwigo/CentOS 7

Thu, 11 Feb 2016 16:30:45 +0000

Je cherche un équivalent à PhotoStation des NAS Synology

Voilà encore un article que j’ai commencé à écrire il y a longtemps et je trouve enfin le temps de le terminer. Dans ma ~~recherche~~ quête d’un service équivalent à celui offert par Synology avec son PhotoStation, je suis tombé sur les sites de Korben et Nicolargo qui nous parlent tous deux de OpenPhoto.

Pour resituer, je cherche un logiciel auto-hébergeable qui me permettrait de visualiser et partager certaines de mes photos à ma famille qui sont aujourd’hui sur mon NAS, sans avoir à recourir à un service en ligne tiers (certains sont payant, d’autres réduisent la qualité, sans parler de l’aspect protection de la vie privée).

Sur le papier, ça semblait correspondre.

Pourtant, j’avais du mal à trouver le site. Les rares informations que je trouvais renvoyaient vers des sites visiblement down.

OpenPhoto ? Ah non…

Et pour cause :

Le projet OpenPhoto a été créé en 2011
Puis renommé en Trovebox en 2013 lorsque ses concepteurs ont tenté de créer une entreprise
github.com/photo/frontend
Qui a fermé ses portes en mai 2015. Darn !

Bon du coup, ça n’en fait pas forcément un candidat idéal pour une mise en production même si a priori les sources toujours disponibles sur github ont été données à la communauté. Plus d’informations sur le dépôt GitHub <a href=)

L’installation avait l’air assez simple et le look vraiment prometteur, le principe est identique à la galerie d’OwnCloud et de CozyCloud : on doit importer ses photos dans l’application.

Cela peut être une bonne solution pour les gens qui veulent mettre à disposition quelques photos triées sur le volet ou qui n’ont pas tout centralisé (voir mon article sur CozyCloud).

Au delà de ça, le fait que le projet soit terminé et qu’il n’y ait eu aucune activité (pas de reprise de la communauté) depuis un an est rédhibitoire pour moi. Dommage.

Piwigo

En fouillant dans les commentaires de l’article de Korben cités plus haut, je suis tombé sur un commentaire d’un des développeurs de Piwigo (Pierrick LE GALL), un autre projet, Français et libre, visant à fournir un serveur de galerie web.

Et si le look est clairement moins léché, le projet est lui bien vivant, ce qui lui confère instantanément des points par rapport à Trovebox :-p.

En lisant la documentation, on remarque que le projet est clairement plus orienté vers un hébergement de l’application sur des sites mutualisés type OVH ou Gandi. Cependant rien ne vous empêche comme moi d’installer une base de données MariaDB et un serveur web sur un Debian/CentOS pour mettre à disposition mon service de galerie web.

Installation rapide

Si vous utilisez Piwigo sur un hébergement mutualisé, il est probable que la procédure sera plus complexe. Je vous conseille de lire la documentation officielle dans ce cas.

A partir d’une base CentOS 7 de type Desktop, j’ai installé Piwigo de la façon suivante :

yum install mariadb-server mariadb #Installation de mariadb
systemctl start mariadb #Démarrage de mariadb
systemctl enable mariadb #Activation de mariadb au boot
mysql_secure_installation #Configuration de mariadb de manière sécurisée
systemctl restart mariadb

mysql -uroot -p
Enter password: #Connexion à la base pour création bdd et utilisateur piwigo
CREATE DATABASE piwigo;
CREATE USER 'piwigo'@'localhost' IDENTIFIED BY 'motdepassetressecure';
GRANT ALL PRIVILEGES ON piwigo.* TO 'piwigo'@'localhost';
FLUSH PRIVILEGES;
exit

yum install httpd php php-mysql php-gd ImageMagick #Installation du serveur Web apache, de PHP et des dépendances
vi /etc/php.ini #modifier la timezone si le serveur est sur l'heure de Paris
date.timezone = Europe/Paris
systemctl start httpd #Démarrage de httpd
systemctl enable httpd #Activation de httpd au boot

firewall-cmd --permanent --add-port=80/tcp #Ajout du port 80 dans les exceptions du firewall
#firewall-cmd --permanent --add-port=443/tcp #Pour l'instant pas nécessaire car on ne met pas de HTTPS dans ce tutoriel
firewall-cmd --reload #rechargement des règles de firewalling

cd /var/www/html
mkdir piwigo &amp;&amp; cd piwigo
chown -R apache:apache piwigo
wget -O piwigo-netinstall.php http://piwigo.org/download/dlcounter.php?code=netinstall #Récupération du code d'installation automatique
chown -R apache:apache /var/www/html/piwigo

A partir de là, on peut ouvrir la page d’installation http://@IPpiwigo/piwigo/piwigo-netinstall.php dans un navigateur web

Troubleshooting

Si vous avez une erreur de permission lors de l’installation, vérifiez bien entendu que l’utilisateur apache a bien les droits en écriture dans le répertoire. Cependant, cela peut également être un problème de SELinux (typiquement j’avais cette erreur dans /var/log/messages)

Feb 7 21:32:44 xxxx dbus[652]: [system] Activating service name='org.fedoraproject.Setroubleshootd' (using servicehelper)
Feb 7 21:32:44 xxxx dbus[652]: [system] Successfully activated service 'org.fedoraproject.Setroubleshootd'
Feb 7 21:32:44 xxxx setroubleshoot: Exception during AVC analysis: [Errno 32] Broken pipe

Lors d’un gros import de photos de grande taille, j’ai fais sauter la limite de php fixée par défaut à 128M. Je l’ai augmentée un peu en espérant que ce n’était pas une fuite de mémoire

vi /var/log/httpd/error_log
[Sun Feb 07 22:23:13.636911 2016] [:error] [pid 27999] [client 192.168.1.13:65337] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 13824 bytes) in /var/www/html/piwigo/admin/include/image.class.php on line 738, referer: http://@IPpiwigo/piwigo/picture.php?/98/category/1
vi /etc/php.ini
memory_limit = 256M
systemctl restart httpd

Premières impressions

A côté de Trovebox ou d’autres logiciels de galerie et/ou de service en ligne, Piwigo dans sa version de base fait un peu web 2.0.

[Édit]J’ai eu une discussion Twitter avec Pierrick LE GALL qui m’a conseillé de jeter un œil au skin Modus. Voir un peu de tuning plus bas[/Édit]

Je me suis très vite rendu compte que l’outil est très intuitif et très complet. L’absence d’une interface plus « moderne » a été très vite éclipsée par la puissance de l’outil de base, sans compte la base d’extension qui est très conséquente.

Outre les fonction classiques sociales et de recherche du type commentaires/notes/tags qu’on peut mettre sur les photos, Piwigo possède une gestion très poussée de la gestion des droits par utilisateur ou par groupes, ce qui est appréciable quand on veut stocker des photos et n’en montrer que certaines à la famille et/ou aux collègues et aux amis.

C’était mon besoin principal et Piwigo rempli le contrat parfaitement.

On retrouve en plus quelques fonctionnalités sympas qui vont au delà de la galerie perso comme la possibilité d’ajouter en mode « batch » des filigranes pour les photos des professionnels. Pratique ! De manière générale, la possibilité de pouvoir affecter un paramètre à plusieurs photos en même temps est un gros point positif.

Ce n’est bien entendu qu’un exemple puisque je n’ai pas terminé tous les tutoriels interactifs et que je n’ai même pas encore testé le magasin d’extension !

Une vraie bonne grosse surprise donc. Enjoy !

Pour que ce soit parfait

Comme pour tous les autres produits que j’ai pu tester, je dois re-importer mes photos dans les fichiers internes du serveurs Web (comme avec CozyCloud).

Outre l’aspect fastidieux de la chose (j’ai déjà rangé toutes mes photos dans des dossiers sur mon NAS et j’en ai beaucoup), je n’aime pas l’idée de devoir dupliquer des fichiers (hors sauvegardes).

Je ne sais pas encore s’il est possible de tirer parti du stockage de mon NAS pour éviter cette étape d’import (en présentant mon dossier de photo en NFS par exemple). Je vérifierai car c’est le dernier point qui me gène encore un peu pour obtenir un réel équivalent de PhotoStation qui (si je ne m’abuse) s’appuie directement sur les photos locales du NAS.

[Édit]J’ai également reçu un Tweet de @FloFian (décidément !) à ce sujet. Voir un peu de tuning plus bas[/Édit]

Un peu de tuning

Comme je l’ai dis un peu plus haut, en réaction à mon article, j’ai brièvement échangé avec les développeurs de Piwigo qui m’ont donnés des conseils pour résoudre les petits points de réserve que j’ai pu remonter suite à l’installation de Piwigo.

D’abord le skin Modus en remplacement du skin elegant. Et là effectivement c’est bien plus épuré et très similaire à OpenPhoto et bien plus moderne (question de goût) :

Et la seule chose à faire pour passer sur ce rendu est d’aller dans l’écran d’administration, puis dans Configuration/Thèmes et d’aller dans l’onglet Ajouter un thème.

Là où j’ai encore un peu de travail, c’est sur l’ajout de photos provenant d’un partage NFS sans les importer au préalable. @FloFian m’a conseillé de simplement faire un montage NFS sur le serveur qui héberge Piwigo, puis de faire un lien symbolique dans le répertoire /galleries de l’arborescence de Piwigo (dans /var/www/html/piwigo pour mon exemple).

Pour autant, ça ne semble pas fonctionner pour l’instant. Mais je n’ai pas encore vraiment creusé et ça pourrait simplement être un loupé sur une option dans Apache (genre FollowSymlinks) ou autre. Je mettrais à jour l’article en conséquence.

Bonus track

Pour les amateurs de Docker (j’en parlais pour CozyCloud avec Docker dans cet article), un contributeur à mis à disposition sur GitHub un « Docker compose » pour automatiser le déploiement de Piwigo. Là aussi je n’ai pas encore jeté un œil mais au cas où ça vous dit d’essayer …

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.

Quand Vulture 2.0 planne au dessus de la carcasse d’un Lenny et de son fidèle Mediawiki

Tue, 01 Nov 2011 17:03:35 +0000

Peut être que vous connaissez Vulture, mais peut être pas. Pour ceux d’entre vous qui ne se sont jamais vraiment posé la question de la sécurité pour les contenus web que vous diffusez sur Internet, protéger un minimum ses applications web devient très rapidement vital si elles sont autohébergées, et encore plus (*shock*) si vous les avez développées vous même. On aimerait bien éviter de devenir la porte ouverte à toute les fenêtres…

De plus, une fois la peur des pirates informatique américo-chinois (ou autre gouvernement soutenant ouvertement les pirates informatiques : il n’y a bien que la France pour n’avoir que des équipes de « défense ») étant partiellement écartée, on peut aussi disposer de beaucoup de contenus publiés, disposant chacun de leur propre méthode d’authentification, et souhaiter pouvoir faire du Single Sign On pour éviter d’avoir 50 comptes différents et de taper ses logins/passwords toute la journée! Aaaaah le Single Sign On. Les SSII nous en auront vendu, des solutions clés en mains permettant de s’interfacer avec tout en un clic, ou presque! Toute la nuance étant dans le « ou presque ».

Aujourd’hui, je ne vais donc pas vous vendre la solution ultime à tous vos problématiques de sécurisation de vos applications web ni vous donner un portail SSO universel, mais tout de même…

Présentation

Vulture est un projet open source, permettant de faire la plupart des tâches qu’on attend d’un portail Web SSO. Depuis plusieurs mois, il n’y avait pas eu beaucoup d’activité sur le projet, qui est resté pendant un bon moment aux versions 1.98 et 1.99. Cependant il manquait à la version 1.XX certaines fonctionnalités utiles, notamment la propagation de l’authentification via cookies (utilisé par exemple pour mediawiki). Un peu dommage pour un SSO si on doit se ré-authentifier pour aller sur son Wiki pour aller chercher des infos techniques rapidement.

Cependant, cet été, une version 2.0 a vu le jour, même si le fait que cela soit une beta ou non n’est pas très clair je trouve ([EDIT] A priori on est toujours en béta, donc pas de prod je vous prie).

Vulture est un reverse-proxy offrant des fonctions Web-SSO et firewall applicatif.

Un des gros points noir du projet Vulture est le manque de clarté dans leur documentation, notamment pour les débutants dans les reverse-proxy. A mon avis, un petit tutoriel pas à pas s’impose pour pouvoir configurer « au minimum » l’accès à quelques applications.

Installation

La première chose que je dois vous dire, c’est que j’ai effectué l’installation sur une machine virtuelle vieillissante en Debian Lenny. Je vais donc tout de suite commencer par vous déconseiller de tester sur une Lenny, mais plutôt de le faire sur une Squeeze, pour des raisons de paquets non disponibles dans les dépôts…

La documentation relative à l’installation en elle même est disponible sur le site du projet

www.vultureproject.org/documentation/installation/

Une fois toutes les dépendances installées comme indiqué sur le site puis le paquet .deb installé, vérifiez que vous n’avez aucune erreur lors du lancement de l’application (automatique).

A priori vous devriez pouvoir vous connecter sur l’interface web de vulture en local sur le port 9090 (et local seulement). Pour ceux qui voudraient ne pas être obligés de faire ça en local justement (VM sans environnement graphique ou réseau local bien protégé), vous pouvez faire un tunnel SSH ou modifier les paramètres apache de Vulture, comme indiqué dans la doc d’installation.

Personnellement je suis sur un réseau NATé, donc le seul moyen d’accéder au port 9090 est d’être sur mon réseau local, et j’ai pu laisser des paramètres de sécurité apache très lights. Le plus propre serait évidemment d’interdire toutes les IP autres que votre poste d’administration.

Listen *:9090
[...]
<Virtualhost *:9090>

Pour ceux qui n’ont rien écouté et qui ont quand même voulu installer leur vulture sur un Lenny, si vous vous retrouvez avec l’erreur suivante, c’est parce que le paquet libdb4.8 n’est tout simplement pas installé pour une raison simple : elle n’est pas disponibles dans les dépôts standards.

Starting vulture: apache2: Syntax error on line 40 of /var/www/vulture/conf/1.conf: Cannot load /usr/lib/apache2/modules/mod_security2.so into server: libdb-4.8.so: cannot open shared object file: No such file or directory
apache2: Syntax error on line 40 of /var/www/vulture/conf/2.conf: Cannot load /usr/lib/apache2/modules/mod_security2.so into server: libdb-4.8.so: cannot open shared object file: No such file or directory

Une façon de s’en sortir est heureusement d’installer le fameux paquet depuis un site tiers

wget http://backports.debian.org/debian-backports/pool/main/d/db/libdb4.8_4.8.24-1~bpo50+1_i386.deb
dpkg -i libdb4.8_4.8.24-1~bpo50+1_i386.deb

Configuration

Maintenant on entre dans le vif du sujet. Nous sommes parvenus à installer Vulture, et il est maintenant accessible en local ou pas (c’est selon).

Pour se connecter, c’est facile, le mot de passe administrateur est parfaitement secure puisqu’il s’agit de admin/admin, donc vous pouvez le laisser tel quel :-p.

Ceux qui connaissent déjà la version précédente de Vulture ne seront pas trop surpris : elle est strictement identique. Bien que la documentation soit assez claire sur la fonction de chacun des champs dans chacun des menus (documentation de Vulture), il n’y a pour l’heure aucun tutoriel pour permettre à tout le monde d’installer Vulture.

Voici donc, une liste d’étapes commentées pour vous permettre de mettre en place le strict minimum : un portail commun pour vos application web faisant office de firewall applicatif, avec une authentification simple, ainsi que l’ajout d’une application (mediawiki ici) sans SSO.

Les problématiques plus poussées seront développées dans un prochain article (SSO, ajout d’une authentification LDAP, …).

Gestion des utilisateurs

Comme dit plus haut, la première priorité est donc de changer le mot de passe de l’administrateur. Pour se faire, il suffit de cliquer sur le menu Users puis de cliquer sur la petite icône représentant une feuille et un crayon pour éditer l’utilisateur.

Pour une raison que j’ignore, même si je doute que ce soit une nouvelle fonctionnalité révolutionnaire, le mot de passe est affiché via son hash MD5. Et pour le modifier il faut entrer également un hash MD5 du nouveau mot de passe.

Une fois qu’on a modifié le mot de passe de l’administrateur, on peut ensuite créer tous les utilisateurs qu’on veut autoriser à se connecter au portail et au applications.

Creation d’un module de log

Pour générer les fichiers de journalisation sur les erreurs et les accès apache de chacun des composants interfacés au portail, Vulture se base sur le module apache mod_log.

Contrairement à la version précédente de Vulture, il est nécessaire de créer/paramétrer son propre module de logging avant de pouvoir commencer à déclarer les interfaces. A mon avis, là aussi, c’est juste un oubli, qui sera rajouté par la suite.

En attendant, voici les champs à remplir pour pouvoir disposer d’une journalisation correcte sur chaque interfaces et chaque application :

Name : Combined
Error Log Verbosity : error
Access Log Format : « %h %l %u %t « %r » %>s %b « %{Referer}i » « %{User-agent}i » »
Directory where to place Logfiles : /var/log/

Création d’une interface

Vulture permet de créer un certain nombre d’interfaces, qui correspondent en fait aux virtualhosts en écoute pour le portail qui regroupe toutes les applications.

Il est donc nécessaire d’en créer au moins une, que l’on liera par la suite à toute nos applications.

Dans mon cas, j’ai souhaité que toutes les applications web que je publie sur Internet soient centralisées par un portail HTTPS. Pour ce faire, j’ai créé plusieurs alias DNS qui pointent tous vers l’IP du portail vulture (192.168.0.XX), ainsi qu’un alias pour le portail lui même (portail.example.org).

J’ai ensuite généré les certificats SSL (autosignés ici). Pour générer plus rapidement les certificats, il est possible d’utiliser le modèle fournit sur le site vulture.open-source.fr (lien mort, j’utilise Internet Archive), puis exécuter la commande :

openssl req -x509 -days 1825 -newkey rsa:1024 -batch -out server.crt -keyout server.key -nodes -config openssl.cnf

Pour créer l’interface il suffit donc de remplir les champs correspondants

Creation de l’application

Une fois l’interface créée sans encombre, reste maintenant à définir les paramètres de vulture pour l’application que l’on souhaite protéger derrière le Vulture. Ici, il s’agit d’un Mediawiki, sur lequel on peut s’authentifier via une base de données interne, ou via LDAP. Dans les deux cas, il n’était pas possible d’interfacer Mediawiki avec Vulture 1.99. Ici, je ne détaillerai pas la méthode pour effectuer ce SSO normalement disponible depuis la 2.00, pour la simple raison que je ne l’ai pas encore testé, mais cela fera l’objet d’un prochain article.

Ici, les champs à remplir sont :

Internet Name : l’alias que l’on a décidé pour l’application, mediawiki.example.org par exemple
Interface : L’interface qu’on vient de créer
Private URL : L’url complète vers laquelle on doit pointer pour trouver l’application web. Ici il s’agit de l’IP et du numéro de port du mediawiki
Authentication : les méthodes qui sont autorisées pour décider si l’utilisateur à l’accès ou non. Ici la seule méthode dont on dispose pour l’instant est vulture (il faut donc la sélectionner)

Après une petit redémarrage de l’interface (logo avec les deux flèches vers en cercle), le portail et l’application devraient être disponible

Enjoy