Mot-clé - PHP

Fil des billets

dimanche 9 juin 2013

Transformer un Raspberry Pi en passerelle vers Hubic d'OVH : Nginx, script Toorop & Cloudfuse

10 mars 2014 - Attention, il semble que le code de https://github.com/Toorop/HubicSwiftGateway ne soit plus fonctionnel aujourd'hui... Il faudrait vraisemblablement se rabattre vers https://github.com/oderwat/hubic2swiftgate...

Hubic est une intéressante offre de stockage en ligne proposée par OVH, le champion français de l'hébergement web. Elle dispose notamment d'un bon rapport qualité/prix (60€ HT/an pour 500 Go). Mais elle souffre de plusieurs défauts : pas de client Linux disponible au moment de l'écriture de ces lignes, et le client Windows/MacOs se résume à un client de synchronisation comme le client d'ownCloud ou celui de Dropbox et peut être insuffisant pour réaliser des sauvegarde de données (par exemple des photos).

Voici une reprise de plusieurs bonnes idées glanées sur le net pour pallier ces défauts : nous allons transformer un Raspberry Pi en passerelle Hubic ce qui permettra à tous les périphériques du réseau local d'accéder à Hubic en se passant du client d'OVH.

Introduction technique

Hubic s'appuie (si la presse spécialisée dit vrai) sur OpenStack, et plus précisément sur OpenStack Object Storage encore appelé Swift. Il est donc possible de se connecter à Hubic à l'aide d'un client swift que l'on pourra installer sur son système avec son gestionnaire de paquets préféré (pour les non-linuxiens, Cyberduck intègre normalement les fonctionnalités d'un client swift).

Toutefois, OVH a ajouté à Hubic une couche d'authentification qui n'est pas gérée par défaut par les clients swift. Heureusement entrent alors en jeu les talents de Toorop et son fort utile script que nous allons déployer plus bas.

Un script PHP pour passer l'étape d'authentification

Toorop a développé un script fort utile qui se charge de l'authentification auprès d'Hubic et permet ensuite une "libre" communication avec un client swift. Le script en question est codé en PHP et est disponible ici : https://github.com/Toorop/HubicSwiftGateway.

Installons d'abord un serveur web + PHP sur le Raspberry Pi (que l'on considèrera dans la suite propulsé par Raspbian, dérivée de Debian). Par souci de légèreté, nous déploierons ici Nginx :

aptitude install nginx php5-fpm

puis téléchargeons le script de Toorop :

cd /var/www
git clone https://github.com/Toorop/HubicSwiftGateway.git
cp -R /var/www/HubicSwiftGateway-master/src/www /var/www/HubicSwiftGateway

et créons un nouvel hôte virtuel dans la configuration de nginx qui pointera vers /var/www/HubicSwiftGateway :

touch /etc/nginx/sites-available/hubicgw

Le fichier de configuration pourra contenir :

server {
       server_name hubicgw.raspberry.lan;
       root /var/www/HubicSwiftGateway;
       index index.html index.htm index.php;

       location ~ \.php$ {
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                fastcgi_pass unix:/var/run/php5-fpm.sock;
                fastcgi_index index.php;
                include fastcgi_params;
        }
}

On active cet hôte virtuel par :

cd /etc/nginx/sites-enabled
ln -s ../sites-available/hubicgw

et on redémarre nginx :

service nginx restart

La première étape est passée : si on appelle dans le navigateur hubicgw.raspberry.lan alors le système devrait répondre "Headers AUTH_USER and/or AUTH_KEY are missing" ce qui est normal et atteste d'un bon fonctionnement du script php. Le travail sur le Raspberry Pi s'achève ici : il est fin prêt à jouer le rôle de passerelle vers Hubic.

Se connecter alors avec le client swift

A partir de maintenant, les actions sont à effectuer sur les postes depuis lesquels on souhaite accéder à Hubic. On peut dès lors se connecter à Hubic à l'aide du client swift que l'on aura préalablement installé sur la machine de son choix (par ex. aptitude install swift sous Debian) :

swift -A http://hubicgw.raspberry.lan/ -U login_hubic -K motdepasse_hubic

(bien sûr, si le réseau local sur lequel on se trouve n'est pas parfaitement sécurisée Wifi, CPL..., on veillera à activer une connexion https pour éviter que des oreilles indiscrètes ne viennent écouter notre login et notre mot de passe Hubic !)

Simplifier l'accès grâce à cloudfuse

Nous allons poursuivre en installant sur le poste local le petit utilitaire cloudfuse que l'on trouvera ici : https://github.com/redbo/cloudfuse. Une fois téléchargé, il faut le compiler et l'installer par :

./configure
make
make install

On créera alors un fichier .cloudfuse à la racine du compte utilisateur :

username=login_hubic
authurl=http://hubicgw.raspberry.lan
cache_timeout=20

et la commande suivante permettra d'effectuer le montage de l'accès hubic comme un dossier classique de votre ordinateur :

cloudfuse /mnt/hubic/ api_key=password_hubic

Il nous est dès lors possible de naviguer au sein de l'espace hubic depuis le gestionnaire de fichiers favori.

Faire ses sauvegardes avec rsync sur Hubic

Tout est en place pour la dernière étape : nous pouvons désormais utiliser rsync (fameux logiciel unix de sauvegarde) pour synchroniser notre répertoire de photos avec sa sauvegarde en ligne :

rsync -var --size-only /path/to/my/photos /mnt/hubic/default/mon/dossier/photos

Bonnes sauvegardes !

mercredi 5 juin 2013

Paramétrer Nginx pour accueillir Zend Framework

Nginx est un serveur web réputé pour sa légèreté. Toutefois, les habitués d'Apache (comme moi) pourront être quelque peu déroutés lors des premiers paramétrages.

Activer, désactiver un site

Par exemple, si les répertoires /etc/nginx/sites-available et /etc/nginx/sites-enabled rappellent bien /etc/apache2/sites-available et /etc/apache2/sites-enabled, il n'y a dans le package nginx pour Debian (au moment où ces lignes sont écrites) pas d'équivalent aux commandes (fort pratiques) a2ensite et a2dissite. Il faut donc recourir à la main à la création de liens comme ci-dessous :

cd /etc/nginx/sites-enabled
ln -s ../sites-available/monSite

puis redémarrer le serveur par

service nginx restart

Toutefois, il semble que certains utilisateurs astucieux s'activent : https://github.com/perusio/nginx_ensite.

La gestion de PHP

La gestion de PHP est également différente : il n'y pas le mod_php mais il est proposé d'utiliser FastCGI Process Manager (PHP FPM) comme décrit ici.

Cas pratique : avec une application Zend Framework 1

Voici le code du "virtual host" qui m'a permis de faire fonctionner l'application (basée sur Zend Framework 1) avec Nginx :

server {
  server_name app.domain.tld;
  root /var/www/app/public;
  index index.php;
  try_files $uri $uri/ @notfile;

  location @notfile {
    rewrite ^(.*) /index.php last;
  }

  location ~ \.php$ {
   fastcgi_pass unix:/var/run/php5-fpm.sock;
   fastcgi_index /index.php;
   fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
   include fastcgi_params;
  }
}

Et pour passer des paramètres comme cela se fait dans Apache avec

RequestHeader add MY_SETTING my_value

on utilisera dans Nginx la commande :

fastcgi_param MY_SETTING my_value;

En espérant que ces petites astuces vous permettront de mieux faire cohabiter Zend Framework et Nginx !

mercredi 27 mars 2013

Echappement pour les requêtes à la base de données

En reprenant dernièrement une vieille application, je restais perplexe devant des problèmes d'échappement de caractères assez basiques. Comment diable l'application pouvait-elle fonctionner par le passé ?

Je découvrais alors qu'il existait (et c'est maintenant obsolète) une option :

 php_admin_value magic_quotes_gpc 1
/// 
valable avant PHP 5.3 qui provoquait un échappement global des caractères !

Cette approche est désormais obsolète (la fonction magic_quotes_gpc n'est plus prise en compte dans PHP 5.4) et il semble bien préférable d'échapper au cas par cas les champs avec la fonction :

string mysqli::real_escape_string ( string $escapestr ) ///

lundi 11 mars 2013

Phpunit, les variables $_SERVER["nom_du_champ"] et quelques autres surprises

Tester son application est une bonne habitude - personne n'ira soutenir le contraire. Et Phpunit est un des outils majeurs pour ce faire en PHP.

Si l'application à tester tourne avec Zend Framework 1.11, il faut d'abord savoir que Phpunit 3.6.x n'est a priori pas compatible et qu'il faut se rabattre sur les versions 3.4.x (la branche phpunit 3.4 est mentionnée dans la documentation officielle Zend Framework comme celle à privilégier) et peut-être 3.5.x.

Variables $_SERVER

Je butai sur une autre difficulté : l'application à tester utilise plusieurs variables serveur du type $_SERVER"nom_du_champ" qui sont normalement fournies par un SSO (mécanisme d'authentification qui pousse l'identité de l'utilisateur dans les variables $_SERVER. En temps normal, c'est donc le serveur Web qui s'occupe de peupler les variables $_SERVER - qui peut s'en charger pour les tests ? Phpunit peut le faire : on peut ajouter la ligne suivante dans le fichier phpunit.xml (qui définit les tests) :

<server name="nom_du_champ" value="1234567"/>

En PHP, la variable $_SERVER"nom_du_champ" sera alors accessible au cours des tests et aura la valeur '1234567'.

Phpunit 3.4 s'arrête avec un 'x'

Plus tard, Phpunit s'arrêta au cours d'un test sans aucune information, terminant la ligne par le signe pourcent % :

PHPUnit 3.4.14 by Sebastian Bergmann.

.....% 

Normalement, phpunit explique les raisons de l'arrêt et est suffisamment verbeux pour permettre le débogage. Il semble qu'un arrêt aussi brutal soit dû à l'utilisation de la fonction 'exit' dans le code de l'application. En effet, 'exit' stoppe l'exécution de tout code et phpunit n'y échappe pas et s'éteint sans avoir le temps de terminer son travail et de nous glisser à l'oreille les résultats des tests (non achevés d'ailleurs).