Catégories
Blog Web

Quelques liens glanés pendant l’été

De retour de congés après 3 semaines de sevrage de clavier et de souris. Tel un aventurier solitaire avec mon smathphone comme couteau de commando, voici les liens intéressants que j’ai étoilé pour moi et maintenant pour vous.

  • Pas mal de mouvement du coté des WAF (Web Application Firewall) pour NGinx avec notamment ModSecurity qui débarque. Je pense prochainement faire un billet sur son grand concurrent Français, j’ai nommé Naxsi. Preuve que le secteur est en pleine ébullition, même Korben, notre DDOS Generator propose une configuration statique de Nginx pour se protéger de quelques attaques.
  • YunoHost, une distribution GNU/Linux basée sous Debian propose toutes les briques pour un serveur professionnel administrable par une interface Web. Une démo est disponible en ligne.
  • Textmate 2 passe sous licence GPL v3. Vu les raisons invoqués par le créateur, je ne pense pas que cela face beaucoup avancer les choses pour les logiciels libres…
  • Le partage des configurations du prompt Shell est très à la mode, j’adore celui là: LiquidPrompt.
  • GlusterFS, le système de fichiers nativement distribués est disponible en version 3.3. Encore un prochain sujet de billet.
  • Si vous devez faire un site Web, plutôt qu’une bête feuille CSS de reset, je vous propose d’utiliser Normalize.css.
  • Vous êtes un utilisateur de Syslog-ng ? Alors cet article devrait vous plaire.

De mon coté, quelques activités durant le mois de juillet:

Bonne reprise aux chanceux qui ont pris des vacances !

 

Catégories
Blog Open-source Planet-libre

Hébergements des blogs du Planet Libre

Dans mon dernier billet, j’avais utilisé des scripts pour récupérer automatiquement un certain nombre d’informations sur les blogs Français. J’ai donc adapté ces scripts pour recueillir ces mêmes informations sur les blog du Planet Libre (liste des blogs datées du mois de juillet 2012).

Les informations suivantes sont analysées :

  • le nom de l’hébergeur
  • le type de serveur Web utilisé et si le blog utilise un proxy/cache Varnish

Sur l’hébergement, OVH arrive en tête. Par contre et contrairement aux autres types de blogs, le nombre de serveurs auto-hébergés arrive en troisième position (13%, à égalité avec Online.fr).

Sur les serveurs Web, Apache domine Nginx (pourtant très à la mode) avec plus de 70% des blogs. On peut aussi noter la faible proportion de blogs utilisant Varnish (environ 2%).

Catégories
Blog Open-source Planet-libre Reseau Systeme Web

Comment sont hébergés les blogs Français ?

On annonce régulièrement que l’avènement du Web 3.0 sonnera comme la fin des blogs, du moins dans la forme dont on les connait actuellement. En attendant cette révolution, les blogs restent, de mon point de vu, la source d’information la plus intéressante sur la World Wide Web. La France n’est pas à la traîne et dispose d’une blogosphère dynamique. Nous allons dans ce billet nous intéresser aux techniques d’hébergements qu’utilisent ces sites.

J’ai compacté les grandes tendances des données obtenues dans le diagramme suivant:

La french blogosphère et son hébérgement en 2012
La french blogosphère et son hébérgement en juillet 2012

 J’ai donc chercher, pour les blogs appartenant au TOP 300 du classement eBuzzing de juillet 2012, les informations suivantes:

  • le nom de l’hébergeur
  • le type de serveur Web utilisé
  • si le blog utilise un proxy/cache Varnish

Pour cela, j’ai écrit des scripts shell (disponible sur le GitHub suivant sous licences LGPL) permettant de récupérer automatiquement la liste des blogs sur le site eBuzzing, de chercher dans la base Whois chez qui le blog est hébergé et enfin d’étudier l’header HTTP renvoyé pour avoir des informations sur le type de serveur Web et l’utilisation éventuelle de Varnish, le proxy/cache à la mode.

Les résultats bruts sont dans ces deux fichiers CSV: hébergeur et type de serveur Web.

Note importante:

Les informations données dans ce graphe sont à prendre avec certaines précautions. En effet, concernant les hébergeurs, l’utilisation de service comme CloudFare (utilisé notamment par Korben.info) masque l’hébergeur. Pour le type de serveur Web, il est tout à fait possible à un administrateur, pour des raisons de sécurité, de masquer ou de transformer les informations renvoyées par l’en-tête HTTP.

Les hébergeurs

OVH, Le leader Français de l’hébergement trône en haut de la plus haute marche du podium avec 21% des blogs parmi le TOP 300 eBuzzing. Il est suivi avec 19% des blogs, par la plate-forme OverBlog qui permet de créer sont blog en quelques clicks. Enfin, dans le même esprit, on retrouve 14% des blogs hébergés par la plate-forme Blogger de Google (a noter que pour ce dernier, l’hébergeur est masqué, mais on voit que ces blogs utilisent le serveur Web GSE, solution spécifique à Google).

Dans les autres hébergeurs, on peut noter la très bonne 6em place du très professionnel hébergeur Typhon avec 3% des blogs.

Les types de serveur Web

Pas de grosses surprises. Apache Web Serveur arrive en tête avec 71% des blogs. Bien qu’il existe des solutions plus légères, surtout pour héberger un simple blog, Apache conserve une solide réputation en terme de fiabilité et de facilité d’administration grâce aux nombreuses sources d’informations que l’on peut trouver sur le Web. Vient ensuite, avec 17% des blogs, Nginx le challenger qui monte. Un solution également très stable mais beaucoup plus légère que j’utilise personnellement depuis quelques années sur ce blog. Enfin, on retrouve, avec 14% des blogs, le serveur GSE de Google, utilisé sur sa plate-forme Blogger (à noter qu’il en existe une implémentation open-source sous licence Apache 2).

Varnish or not Varnish

J’ai été surpris par le nombre assez important (26%)  des blogs utilisant cette superbe solution de proxy/cache qu’est Varnish. En regardant ce chiffre de plus près, il faut noter que la plate-forme OverBlog le met en place par défaut sur l’ensemble de ses serveurs. Vu le gain de performance et l’allègement des ressources CPU qu’il procure sur les blogs à fort trafic, je pense que ce chiffre va fortement évoluer dans les prochains mois.

Et pour les blogs libristes ?

J’ai également exécuté les même scripts de statistiques sur les blogs traitant des logiciels libres en me basant sur le classement Wikio (limité au 60 premiers blogs). Vous pouvez consulter et exploiter les données qui sont disponibles dans les deux fichiers suivants: hébergeurs et type de serveur Web.

Et vous lecteurs/blogueurs, vous êtes chez quel hébergeur ? Quel serveur Web ? Varnish ?

Partager tout cela avec nous dans les commentaires !

Catégories
Blog Open-source Planet-libre Web Webdesign

Modèles de présentations HTML5 pour remplacer PowerPoint

Suite à mon track sur la supervision lors de la première journée de SophiaConf 2012, j’ai eu pas mal de question par mail sur le logiciel utilisé pour concevoir mon support. J’ai en fait utilisé une présentation 100% HTML5 basée sur l’outil Impress.js, lui même inspiré de Prezi. Je ne trouve que des avantages à ce type de présentation. En effet, en mettant de coté le dynamisme et l’aspect « fun », on manipule un format standard, lisible sur n’importe quel navigateur digne de ce nom (je dois avouer que Impress.js, fonctionne beoucoup plus fluidement sur Chromium que sur Firefox).

Nous allons dans ce billet découvrir un panel de solutions équivalentes permettant, moyennant une bonne connaissance du langage HTML et de CSS, de concevoir des présentations originales sans avoir à installer aucun logiciel sur votre machine mis à part un éditeur de texte et un navigateur Web. Bref une solution 100% libre, basée sur des standards !

Les commentaires sont bien sûr là pour compléter cette liste et nous faire partager vos expériences sur le sujet !

Impress.js

Démonstration

GitHub

C’est par cet outil que j’ai découvert les alternative possible à la grande maladie des entreprises du 21em siècle: PowerPoint.

L’exemple fourni sur le GitHub permet de bâtir simplement un jeu de slide. Pour être un peu plus original, il faudra aller éditer le fichier CSS. Impress.js s’occupe de tout le reste: transition entre les slides, vu d’ensemble des slides, animations. C’est un projet perpétuellement en évolution, à surveiller sur GitHub.

Personnellement, j’ai « forké » le projet sur mon espace GitHub, puis je génère une branche par présentation. Cela me permet d’avoir toujours les présentations sous le coude. A noter GitHTML, l’excellente extension à Chrome/Chromium , qui vous permet de visualiser directement vos fichiers HTML  et donc votre présentation à partir de GitHub.

Deck.js

Démonstration

GitHub

Projet débuté en mars 2011, il propose une alternative sérieuse à Impress.js. Moins « fun », les présentations générés sont cependant claires et je trouve le code HTML plus propre.

Html5Rocks

Démonstration

Distribué sous licence Apache 2.0, ce jeu de slides est initialement conçu pour présenter les nouveautés du langage HTML5. Sa structure peut permettre de bâtir simplement votre propre présentation avec en prime des exemples de fonctions HTML5 déjà toutes faites.

Html5Slides par Google

Démonstration

Google Code

Difficile de faire un billet sur un tel sujet sans parler de Google qui y va de son modèle de présentation compatible HTML5. Pas de surprise ici. C’est simple et sobre avec un code HTML facilement compréhensible, même pour un béotien. A noter que le modèle est sous licence Apache 2.0.

Reveal.js

 

Démonstration

GitHub

Bien que présenté comme un modèle CSS de présentation 3D, Reveal.js est plus un modèle HTML permettant de faire des présentations sous la forme de matrice en deux dimensions. On peut, si on le souhaite et si la présentation a été faite pour, se déplacer en haut, en bas, à gauche et à droite pour passer d’un slide à l’autre. Ce mode de navigation, un peu perturbant n’est pas forcement adapté pour un track mais plutôt pour un présentation « à tiroirs ».

Shower

Démonstration

GitHub

Ce modèle de présentation permet de faire rapidement une présentation au format HTML5. On peut noter la possibilité de voir les miniatures des slides avant de commencer la présentation. Les transitions sont simples et rapides. On dispose également de fonctions intéressantes pour, par exemple adapter les images automatiquement à la taille de l’écran ce qui peut être sympa pour une présentation basée sur des photos.

RoboDeck

Démonstration

GitHub

Le principal intérêt de ce modèle de présentation est que si la présentation est disponible en ligne alors il est possible de synchroniser les visiteurs sur le slide en cours. Pour cela, le serveur sur lequel les slides sont hebergés va envoyer (via Web Socket) les informations NEXT et PREV. Je trouve par contre les présentations pas très sexy… A suivre quand même pour des présentations massivement en ligne.

Slides par Brian Cavalier

Démonstration

GitHub

Sur ce modèle, les transitions se font par un très agréable fondu enchaîné. J’aime beoucoup le CSS par défaut qui est sobre et clair. A réserver à des présentations sérieuses.

Slides par Brian Cavalier

Démonstration

GitHub

Comme le précédent modèle, les transitions se font par un très agréable fondu enchaîné, mais la comparaison s’arrête là. Ici on est dans un style de présentation plus « fun » et très bien adapté aux développeurs (avec notamment le syntax highlight). A bookmarker !

Pour conclure

De nos jours et en mettant à part les présentations qui doivent passer entre les mains de personnes sachant uniquement utiliser PowerPoint, je ne comprends pas que l’on utilise pas plus se genre de modèle de présentation. En effet, elles n’ont que des avantages: simple à éditer (avec un éditeur de texte), facilement transportable sur une clés USB ou l’on peut ajouter une version Chromium ou Firefox portable et avec nativement une mise en ligne optimisée (c’est du HTML 🙂 !). Alors ciao PPT et bonjour HTML.

Et vous chers lecteurs vous en êtes ou avec la cure de désintoxication de PowerPoint ?

D’autres modèles à nous conseiller ?

Catégories
Open-source Planet-libre Reseau

Simuler un réseau WAN entre deux réseaux LAN

A partir de sa version 2.6, le noyau Linux dispose d’une fonction permettant de simuler certaines caractéristiques comme un délais de transit, une perte de paquets ou même un débit maximal sur une simple interface réseau locale. J’avais déjà parlé de ce sujet il y a quelques temps pour simuler une liaison WAN entre une machine et son réseau. Suite à une question d’un lecteur, voici un billet dans lequel nous allons mettre en place un simulateur de liaison WAN entre deux réseaux LAN. Cette infrastructure pourra être utile à toutes personnes devant valider sur table une architecture inter-site.

De quoi avons nous besoin ?

Pour bâtir cette infrastructure, nous avons besoins de deux réseaux LAN (mais deux PC peuvent suffirent) et d’une machine GNU/Linux disposant de deux interfaces réseaux permettant de faire un pont entre ces deux LAN. Le choix d’une architecture en pont (bridgé) permet d’insérer facilement le simulateur dans une architecture réseau existante.

 

Configuration du bridge

Personnellement, j’ai utilisé une distribution GNU/Linux Debian Squeeze pour mettre en place le simulateur. Mais toutes les distributions GNU/Linux avec une version de Kernel >= 2.6 peuvent faire l’affaire.

Après une installation standard du système d’exploitation Debian, il faut ajouter le paquet bridge-utils pour permettre à ce dernier de créer le pont entre les deux interfaces réseaux:

sudo aptitude install bridge-utils

Il faut ensuite éditer le fichier de configuration /etc/network/interfaces de la manière suivante:

auto lo

iface lo inet loopback

iface eth0 inet manual

iface eth1 inet manual

auto br0

iface br0 inet dhcp

bridge_ports eth0 eth1

Puis on fait prendre en compte cette configuration par le système:

sudo /etc/init.d/networking restart

Note: il faut attendre une trentaine de seconde lors de l’initialisation.

On vient donc de créer une nouvelle interface virtuelle (br0) qui fait un pont entre les deux interfaces physiques (eth0 et eth1).

Si vous connectez en l’état le simulateur entre vos deux LAN, tout le trafic transitera de manière transparente à la vitesse maximale de vos interfaces eth0 et eth1.

Configuration du simulateur

On passe maintenant à la partie intéressante de ce billet: comment simuler un lien WAN à partir de notre simulateur.

Vous allez voir que c’est relativement simple. Nous allons utiliser un script de configuration automatique qui va activer / désactiver le simulateur à la demande. Les caractéristiques du WAN à simuler seront codées en dur dans la section configuration du script. A vous de l’adapter à vos besoins.

Voici le script en question (également disponible sur mon GitHub):

#!/bin/bash
#
# simulwan-bridge.sh
# Nicolargo - 2012
#

##############################################################################

# Nom des interfaces ou l'on doit faire les simulations
# eth0 cote LAN local 
# eth1 cote LAN distant
IF=eth1

# Liaison sortante (UPLOAD) a appliquer sur IF
# Debit sortant
BWU=8mbit
# Délai de transit sortant
DELAYU=15ms
# % de paquets perdus sortant
LOSSU=0.0001%

# Liaison entrante (DOWNLOAD) a appliquer sur IF
# Debit entrant
BWD=1mbit
# Délai de transit entrant
DELAYD=15ms
# % de paquets perdus entrant
LOSSD=0.00001%

##############################################################################

start() {
    modprobe ifb
    ip link set dev ifb0 up

    tc qdisc add dev $IF ingress

    tc filter add dev $IF parent ffff: \
    protocol ip u32 match u32 0 0 flowid 1:1 \
    action mirred egress redirect dev ifb0

    # Liaison entrante
    tc qdisc add dev ifb0 root handle 1:0 \
    netem delay $DELAYD 10ms distribution normal \
    loss $LOSSD 25%

    tc qdisc add dev ifb0 parent 1:1 handle 10: \
    tbf rate $BWD buffer 3200 limit 6000

    # Liaison sortante
    tc qdisc add dev $IF root handle 2:0 \
    netem delay $DELAYU 10ms distribution normal \
    loss $LOSSU 25%

    tc qdisc add dev $IF parent 2:1 handle 10: \
    tbf rate $BWU buffer 3200 limit 6000
}

stop() {
    tc qdisc del dev ifb0 root
    tc qdisc del dev $IF root
    # ip link set dev ifb0 down
}

restart() {
    stop
    sleep 1
    start
}

show() {
    echo "Liaison entrante"
    tc -s qdisc ls dev ifb0
    echo "Liaison sortante"
    tc -s qdisc ls dev $IF
}

case "$1" in
    start)
        echo -n "Starting WAN simul: "
        start
        echo "done"
        ;;
    stop)
        echo -n "Stopping WAN simul: "
        stop
        echo "done"
        ;;
    restart)
        echo -n "Restarting WAN simul: "
        restart
        echo "done"
        ;;
    show)
        echo "WAN simul status for $IF:"
        show
        echo ""
        ;;
    *)
        echo "Usage: $0 {start|stop|restart|show}"
        ;;
esac

exit 0

Par défaut, le script simule une liaison WAN de type ADSL (8 Mbps en download et 1 Mbps en upload avec un délais de transit de 30ms en aller/retour et un taux de perte de 10^-4).

Pour l’installer, il suffit de saisir les commandes suivantes:

sudo wget -O /etc/init.d/simulwan.sh https://raw.github.com/nicolargo/simulwan/master/simulwan-bridge.sh
sudo chmod a+x /etc/init.d/simulwan.sh

Pour lancer le simulateur WAN:

sudo /etc/init.d/simulwan.sh start

Pour arrêter le simulateur WAN:

sudo /etc/init.d/simulwan.sh stop

Pour avoir un état des interfaces:

sudo /etc/init.d/simulwan.sh show

Conclusion

Vous venez donc à moindre coût de mettre en place une architecture permettant de simuler des liaisons WAN. Le PC sur lequel se base votre simulateur n’a pas besoin d’être une bête de course et vous pouvez donc facilement récupérer du vieux matériel pour mettre en place ce système.

 

 

 

Catégories
Open-source Planet-libre Reseau

Suivi graphique des attaques DDOS avec Munin

Les attaques DDOS sont une véritable plaie pour les sites Internet. Même pour des sites à forte audience et donc dimensionnés au niveau architecture système et réseau pour absorber ces aléas, il est important de surveiller de prêt ces attaques. Nous avions déjà abordé ce sujet ensemble en mettant en place une alerte Nagios sur attaque DDOS. Nous allons ici compléter cette supervision en apportant un suivi graphique de ces attaques en utilisant un plugin spécifique pour Munin.

Installation de Munin

Il suffit de vous reporter au billet que j’avais écrit sur le sujet il y a quelques mois. Le plugin qui va se charger de la détection des attaques DDOS doit être installé sur chacun des noeuds (« Munin node ») à surveiller.

Principe du Plugin ddos_

Ce plugin se base sur le même principe que le plugin Nagios. Il va lire le nombre de connexions de type SYN_RECV ouvertes et les renvoyer au noeud Munin maître pour que ce dernier stocke l’information dans une base RRD et l’affiche à la demande dans un page Web.

Le plugin est disponible sur mon GitHub (il est donc possible de l’améliorer et d’en faire profiter la communauté).

Si vous êtes intéressé par l’écriture de vos propres plugins pour Munin, le plus simple est de commencer par la lecture de la documentation officielle.

Revenons à notre plugin ddos_.

Pour l’installer sur un noeud, la procédure à suivre est la suivante:

cd /tmp
wget https://raw.github.com/nicolargo/muninplugins/master/ddos_
sudo munin-node-configure --shell
sudo cp ddos_ /usr/share/munin/plugins/
sudo chmod a+x /usr/share/munin/plugins/ddos_
sudo munin-node-configure --shell
sudo ln -s /usr/share/munin/plugins/ddos_ /etc/munin/plugins/ddos_
sudo service munin-node restart

On peut vérifier que le plugin est bien actif en saisissant la commande:

sudo munin-node-configure | grep ddos
ddos_                      | yes  |

Il faut ensuite attendre quelques heures pour voir apparaître le graphe au niveau de votre serveur Munin.

Par défaut, le plugin est configuré pour afficher les valeurs en WARNING quand le nombre de SYN_RECV dépasse le seuil des 50 et en CRITICAL au dessus de 70 (vous pouvez bien sûr changer ces valeurs dans le munin.conf).

C’est pas beau Munin 🙂 ?

Catégories
Open-source Planet-libre Web

Partager simplement des fichiers sur le Web avec DropCenter

Suite à mon billet sur les solutions auto-hébergées de partage de fichiers par interface Web, quelques lecteurs et followers m’ont conseillés de regarder du coté de DropCenter. Une solution libre (licence CC BY-NC-ND 2.0), légère (sans base de données) et que l’on peut auto-héberger.

Cerise sur le gâteau, le projet est développé par deux jeunes Français (aka IdleMan et Fox). Il ne m’en fallait pas plus pour me plonger dans le test de DroCenter. C’est partie pour la visite guidée.

Installation de DropCenter

Nous allons commencer par détailler l’installation de DropCenter sur une machine Debian 6 (mais la procédure peut être suivie pour n’importe quelle distribution GNU/Linux ou BSD).

Les pré-requis sont réduits au strict minimum car il suffit de disposer d’un serveur Web compatible avec le langage PHP (j’utilise personnellement le stack NGinx + PHP FPM).

cd /tmp
wget http://dropcenter.fr/wp-content/Versions/1.4Beta/dropCenter1.4Beta.zip
unzip ./dropCenter1.4Beta.zip
sudo mv dropCenter /var/www/dropcenter
sudo chown -R www-data:www-data /var/www/dropcenter

Note: les commandes précédentes vont installer la version 1.4b de DropCenter dans le répertoire Web /var/www/dropcenter.

Note 2: Par défaut, votre configuration PHP limite la taille maximale des fichiers à uploader à 16 Mo. Pour augmenter cette valeur, il faut modifier les paramètres post_max_size et upload_max_filesize dans votre fichier de configuration php.ini. Attention, sur un système 32 bits, la limite doit être de 2147483647 octets (2 Go – 1). 

Il ne reste plus qu’à pointer un navigateur vers l’URL: http://votreserveur.com/dropcenter pour accéder à la page de configuration du compte administrateur.

Il suffit de saisir les informations suivantes pour créer le compte administrateur initial:

  1. le login de l’administrateur
  2. le mot de passe associé (il serait bien de disposer dans le formulaire d’un champ de confirmation pour ressaisir une seconde fois le mot de passe…)
  3. l’adresse mail de l’administrateur (idem)
  4. l’URL racine de votre installation de DropCenter
  5. de vérifier que les pré-requis de votre serveur Web sont bons

« That’s all folks ! ».

L’installation est terminé, vous pouvez commencer à utiliser votre service DropCenter !

Utilisation de DropCenter

Il suffit de d’aller sur l’URL http://votreserveur.com/dropcenter pour accéder à votre DropCenter.

L’interface utilisateur est simple:

Il suffit de copier/glisser le fichier à uploader (si votre navigateur est compatible, en bref si vous n’utilisez pas IE :)) ou de cliquer sur cette même zone.

Après sélection, les fichiers vont automatiquement être « uploadés » dans le sous-répertoire /var/www/dropcenter/uploads/.

Il est alors simple d’obtenir le lien (URL) vers le fichier en question (une fonction de type raccourcissement d’URL serait la bienvenue !).

Les fichiers uploadés sont seulement visibles des personnes disposant d’un compte sur votre DropCenter. La création de nouveaux comptes utilisateurs est limité aux administrateurs. Par contre ils sont téléchargeables par n’importe qui disposant du lien vers le fichier.

Autre fonction que je trouve intéressante est la possibilité de s’abonner à un flux RSS permettant de suivre tout ce qui se passe sur votre DropCenter (ajout d’utilisateur, upload de fichiers…). Le lien est disponible en bas de l’interface Web. Les auteurs proposent même un deuxième logiciel nommé DropNews (disponible sous Linux et Windows) qui exploite ce flux RSS pour afficher directement les évènements sur le bureau de votre ordinateur.

Note pour les utilisateurs utilisant PHP-FPM

Je suis tombé sur l’erreur suivante qui m’empêchait de  voir la liste des fichiers disponibles sur mon DropCenter:

2012/06/02 16:05:07 [error] 30975#0: *181 FastCGI sent in stderr: « PHP message: PHP Warning: date(): It is not safe to rely on the system’s timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected ‘Europe/Berlin’ for ‘CEST/2.0/DST’ instead in /var/www/dropCenter/php/function.php on line 49

Pour résoudre ce petit problème, j’ai ajouter la ligne suivante à mon fichier /etc/php5/fpm/php.ini:

date.timezone = Europe/Paris

Puis j’ai relancé PHP-FPM:

sudo service php-fpm restart

Alors ?

Je dois dire que j’ai été bluffé par la rapidité d’installation de DropCenter par rapport aux autres solutions du même style.

L’utilisation est du même acabit: simple et efficace. Le logiciel fait ce qu’on lui demande et il le fait bien !

Pour revenir à mon billet précédant, je pense que DropCenter est de loin la meilleure solution légère comme alternative aux services en ligne propriétaire.

Le futur de DropCenter

Ce projet prometteur est actuellement en version 1.4 bêta. La version stable devrait bientôt sortir et être suivie d’une version 2 qui apportera, entre autres, les fonctionnalités suivantes:

  • classement des fichiers par taille, date, tags, auteur
  • upload vers Dropbox
  • édition avancée des fichiers
  • version pour mobile et tablettes
  • restrictions sur le Hotlinking

Les auteurs recherchent des contributeurs matures et motivés ayant des compétences en PHP/Javascript/CSS/HTML (pour la partie web), C++/QT (pour la partie client lourd) et WebDesign (pour la partir UI).

Catégories
Nagios Open-source Planet-libre Reseau Web

Superviser PHP-FPM avec Nagios ou Shinken

Vous savez que j’ai un faible pour le couple Nginx / PHP-FPM que je trouve à la fois léger, rapide et simple à administrer. Suite à un message d’un follower (@JulSa_ pour ne pas le citer), je me suis intéressé à la supervision du process PHP-FPM depuis mon serveur de supervision Shinken (mais la procédure suivante fonctionne également avec Nagios).

Petite introduction

Pour superviser PHP-FPM, mieux vaut comprendre comment il fonctionne. PHP-FPM est une implémentation du langage PHP proposant, à votre serveur Web, une interface basée sur FastCGI. Contrairement à une interface CGI classique, FastCGI permet d’optimiser le nombre, la gestion et les caractéristiques des processus PHP en attente des requêtes venant de votre serveur Web.

Ma première réponse au message de @JulSa_ a été: « tu n’as qu’à surveiller si le processus est bien lancé sur ton serveur ». Bien que cette solution soit possible elle est insuffisante. En effet, comme l’on vient de le voir, l’interface FastCGI de PHP-FPM permet d’optimiser le chargement des processus en mémoire et sur certaines configuration, un fonctionnement « normal » doit se caractériser par la présence d’au moins 5 processus PHP-FPM. On se rend compte qu’il va falloir utiliser une autre méthode si l’on veut obtenir une supervision plus fine.

La solution: check_phpfpm_status

En cherchant sur la toile on tombe rapidement sur le plugin check_phpfpm_status (page officielle sur GitHub) qui propose d’utiliser les informations remontées directement par PHP-FPM (qui est quand même le mieux placé pour dire comment il va…) à travers son URL de statut.

Configuration de votre serveur à superviser

Si vous avez une installation par défaut de PHP-FPM, il y a de forte chance que cette URL de statut ne soit pas activée. Nous allons donc dans un premier temps configurer PHP-FPM et NGinx pour qu’ils répondent à cette URL.

La configuration de PHP-FPM se fait à travers le fichier /etc/php5/fpm/pool.d/www.conf (out tout autre pool utilisé par votre serveur) en éditant la ligne suivante:

pm.status_path = /status

Pour Nginx, il faut ajouter la cible /status et la rediriger vers PHP-FPM en ajoutant la section suivante à votre configuration (par exemple /etc/nginx/sites-enabled/default-site):

# PHP-FPM Status
location /status {
                 fastcgi_pass   127.0.0.1:9000;
                 fastcgi_index  index.php;
                 include fastcgi_params;
                 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

Note: cette configuration part sur le principe ou les processus PHP-FPM écoute sur le port 9000 (port TCP par défaut)

On doit ensuite relancer Nginx et PHP-FPM:

sudo service php5-fpm restart
sudo service nginx restart

Puis tester que votre serveur répond bien à l’URL: http://votreserveur.com/status

Installation de check_phpfpm_status sur votre serveur de supervision

On peut maintenant passer à la configuration de votre serveur de supervision (Nagios ou Shinken).

La première étape est de récupérer le script et de l’installer:

cd /tmp
wget https://raw.github.com/regilero/check_phpfpm_status/master/check_phpfpm_status.pl
chmod a+x check_phpfpm_status.pl

Sur ma configuration (Debian 6 + Shinken), j’ai dû éditer le script pour remplacer la ligne:

use lib « /usr/local/nagios/libexec »;

par

use lib « /usr/local/shinken/libexec »;

On copie ensuite le script dans le répertoire des plugins de Nagios/Shinken:

sudo cp check_phpfpm_status.pl /usr/local/shinken/libexec/

Il est possible de tester le script en ligne de commande:

$ /usr/local/shinken/libexec/check_phpfpm_status.pl -H votreserveur.com -u /status

PHP-FPM OK - www, 0.070 sec. response time, Busy/Idle 1/2, (max: 2, reached: 0), ReqPerSec 0.3, Queue 0 (len: 128, reached: 0)|Idle=2;Busy=1;MaxProcesses=2;MaxProcessesReach=0;Queue=0;MaxQueueReach=0;QueueLen=128;ReqPerSec=0.312155

Configuration de Nagios/Shinken pour surveiller PHP-FPM

La dernière étape consiste à configurer votre serveur de supervision en y intégrant ce nouveau plugin. Il y a plein de méthode possible pour cette étape.

Fichier commands.cfg:

### PHP-FPM
define command{
        command_name    check_php_fpm
        command_line    $USER1$/check_phpfpm_status.pl -H $HOSTADDRESS$ -s $ARG1$ -u $ARG2$ -w $ARG3$ -c $ARG4$
}

On voit donc que le service va prendre 3 paramètres:

  • ARG1: le nom d’host sous lequel votre serveur Web répond (par exemple votreserveur.com)
  • ARG2: l’url de status sous laquelle le serveur va répondre (par exemple /status)
  • ARG2: les 3 valeurs de PHP-FPM (MIN_AVAILABLE_PROCESSES,PROC_MAX_REACHED,QUEUE_MAX_REACHED, séparés par des virgules) qui vont déclencher une alarme WARNING
  • ARG3: les 3 valeurs de PHP-FPM (MIN_AVAILABLE_PROCESSES,PROC_MAX_REACHED,QUEUE_MAX_REACHED, séparés par des virgules) qui vont déclencher une alarme CRITICAL

Les 3 valeurs représentent:

  • MIN_AVAILABLE_PROCESSES: Working with the number of available (Idle) and working process (Busy).
  • PROC_MAX_REACHED: the fpm-status report will show us how many times the max processes were reached sinc start, this script will record how many time this happended since last check, letting you fix thresolds for alerts
  • QUEUE_MAX_REACHED: the php-fpm report will show us how many times the max queue was reached since start, this script will record how many time this happended since last check, letting you fix thresolds for alerts

Une valeur négative (-1) permet d’ignorer le paramètre.

Par exemple, l’appel à la commande suivante:

./check_phpfpm_status.pl -H votreserveur.com -s votreserveur.com -u /status -w 1,-1,-1 -c 0,2,5

va déclencher une alarme CRITICAL si vous avez 0 processus PHP-FPM ou si vous avez atteint le nombnre maximum de processus 2 fois depuis le dernier check ou bien si vous avez atteint 5 fois la taille maximale de la queue. Une alarme de type WARNING sera émise si il n’y a qu’une seul processus.

On déclare enfin le service de check sur la machine à surveiller:

define service {
        use generic-service
        host_name votreserveur.com
        service_description PHP_FPM
        check_command check_php_fpm!votreserveur.com!/status!1,-1,-1!0,2,5    
}

Le résultat:

A vos configurations 🙂

Catégories
Image Musique Open-source Planet-libre Video Web

Migrer OwnCloud vers la version 4.0.1

Voici une petite procédure « quick and dirty » pour migrer votre installation OwnCloud X (X=3 ou 4.0.0) vers OwnCloud 4.0.1.  En plus des classiques corrections de bugs, cette nouvelle version apporte notamment les fonctions suivantes:

  • le chiffrement et la gestion en version des fichiers
  • la possibilité d’utiliser le glisser-déposer pour uploader les fichiers à partir de l’interface Web
  • le partage de calendrier (via CalDAV)
  • la visualisation des fichiers OpenOffice directement dans l’interface Web

Si vous voulez une procédure d’installation détaillé de OwnCloud 4, vous pouvez suivre ma procédure pour la version 3 (valable aussi pour la version 4.0.1 à quelques adaptations près) disponible ici.

De OwnCloud 3 vers OwnCloud 4… ou 5 !

Pour les plus aventureux, il est possible de directement tester la version de développement (HEAD) de OwnCloud (actuellement en version 5). Pour cela il faut télécharger le projet directement depuis le Git officiel (hébergé sur Gitorious):

sudo git clone git://gitorious.org/owncloud/owncloud.git /var/www/owncloud4

Si vous préférez utiliser la version 4.0.1 stable, alors on télécharge l’archive sur le site officiel:

wget http://download.owncloud.org/releases/owncloud-4.0.1.tar.bz2
tar -xjf ./owncloud-4.0.1.tar.bz2
sudo mv owncloud /var/www/owncloud4

A partir de là, on peut procéder à la migration:

sudo cp -R /var/www/owncloud/config/* /var/www/owncloud4/config/
sudo cp -R /var/www/owncloud/data /var/www/owncloud4
sudo chown -R www-data:www-data /var/www/owncloud4
sudo mv /var/www/owncloud /var/www/owncloud3 ; sudo mv /var/www/owncloud4 /var/www/owncloud

Note: attention, cette procédure copie l’intégralité du répertoire et donc de vos données d’un  répertoire vers un autre… prévoir un espace disque suffisant.

Vous pouvez ensuite tester votre serveur OwnCloud pour voir si tout c’est passé correctement. Si c’est le cas, vous pouvez supprimer la version 3.0:

sudo rm -rf /var/www/owncloud3

Installation du client Linux

Cette nouvelle version intègre également la possibilité de télécharger depuis l’interface Web un client lourd pour votre machine GNU/Linux.

En fait, ce bouton télécharge simplement vers le site officiel qui explique la procédure à suivre selon votre distribution. Par exemple sous Ubuntu 12.04:

sudo sh -c "echo 'deb http://download.opensuse.org/repositories/isv:ownCloud:community/xUbuntu_12.04/ /' >> /etc/apt/sources.list.d/owncloud-client.list"
sudo apt-get update
sudo apt-get install owncloud-client

Au premier lancement, l’URL de votre serveur OwnCloud ainsi que le couple login/password vous seront demandé.

Par défaut, le client va partager un répertoire ~/ownCloud mais il est bien sur possible d’en choisir d’autres (par exemple ~/Dropbox :)). Il sera nommé sous l’alias clientsync dans votre interface Web OwnCloud.

Conclusion

Cette nouvelle version de OwnCloud devient une alternative vraiment sérieuse aux solutions alternatives et non libres comme Dropbox ou Google Drive. Le test grandeur nature que je suis en train de mener me fera peut être complètement basculer vers ce cloud libre.

Et vous déjà migré ?

Catégories
Open-source Planet-libre Web

Auto-héberger son service Web de partage de fichiers

L’échange direct de gros fichiers sur le Web, c’est à dire sans installer de client externe type FTP et en utilisant uniquement le protocole HTTP, oblige les utilisateurs à passer par des services en ligne comme Free Upload (gratuit mais avec une limite à 1 Go par fichier), YouSendIt (limite à 10 Go mais payant) ou encore les Dropbox et Google Drive (limite d’environ 300 Mo quand on passe par l’interface Web). C’est à dire des solutions propriétaires et qui peuvent regarder et exploiter les fichiers partagés.

Nous allons donc dans ce billet voir comment auto-héberger un service équivalent à partir de solutions libres. J’ai délibérément écarté les solutions de type « cloud » comme OwnCloud qui sont un peu trop lourdes, à mon goût, pour ce genre de besoin.

La liste des logiciels étudiés est la suivantes:

Au passage, merci à mes followers pour toutes ces bonnes pistes.

Jyraphe

Avec ce nom, on pouvait craindre un développement « usine à gaz » en Java (troll inside). C’est loin d’être le cas. Ce logiciel me semble effectivement le plus adapté à mon besoin. C’est pour cela que je l’ai positionné en début de billet, pour les plus pressés.

Développé en PHP, il se base sur la philosophie « Getting Real »: faire peu de chose mais le faire bien.  Cela se retrouve également dans la simplicité de mise en place. Nul besoin de base de donnée MySQL ou de module spécifique. Seul un serveur Web (Apache ou autres) avec le support de PHP est nécessaire au fonctionnement de Jyraphe.

Installation de Jyraphe

L’installation est des plus simple. Par exemple, sur une distribution Debian:

cd /tmp
wget http://download.gna.org/jyraphe/jyraphe-0.5.tar.gz
tar zxvf jyraphe-0.5.tar.gz
sudo mv jyraphe/pub /var/www/jyraphe
sudo chown -R www-data:www-data /var/www/jyraphe

On doit ensuite créer:

  • un fichier vide /var/www/jyraphe/lib/config.local.php avec les droits en écriture pour l’utilisateur www-data. C’est dans ce fichier que le script d’installation va régler les paramètres
  • un répertoire /var/www/jyraphe/var-AzErT2012/ qui contiendra vos fichiers (remplacer AzErT2012 par un nom de votre choix)

En saisissant les commandes suivantes:

sudo touch /var/www/jyraphe/lib/config.local.php
sudo chown www-data:www-data /var/www/jyraphe/lib/config.local.php
sudo chmod u+w /var/www/jyraphe/lib/config.local.php

sudo mkdir /var/www/jyraphe/var-AzErT2012
sudo chown -R www-data:www-data /var/www/jyraphe/var-AzErT2012
sudo chmod -R u+w /var/www/jyraphe/var-AzErT2012

Il ne reste plus qu’à lancer le script d’installation: http://votreserveur.com/jyraphe/install.php

On finalise l’installation en protégeant le fichier de configuration:

sudo rm /var/www/jyraphe/install.ph
sudo chmod u-w /var/www/jyraphe/lib/config.local.php

Note: Par défaut, votre configuration PHP limite la taille maximale des fichiers à uploader à 16 Mo. Pour augmenter cette valeur, il faut modifier les paramètres post_max_size et upload_max_filesize dans votre fichier de configuration php.ini. Attention, sur un système 32 bits, la limite doit être de 2147483647 octets (2 Go – 1). 

En ce qui concerne la sécurité de votre installation. Je vous conseille de protéger l’accès au script d’upload (index.php) par un mot de passe afin de limiter l’accès à votre service…

Utilisation de Jyraphe

L’accès à Jyraphe mène directement à la page d’upload:

A la fin du téléchargement, on obtient l’URL à envoyer à vos correspondants pour qu’ils puissent télécharger le fichier:

Mon avis sur Jyraphe

Les +:

  • Installation simple et rapide
  • Pré-requis système minimaliste (pas de base de donnée)
  • Stable et léger

Les -:

  • A vous de gérer la sécurité d’accès à votre service (pas de gestion d’utilisateurs)
  • Interface Web un peu « old school » (Pas de barre de progression « JS » lors de l’upload)
  • Cycle de développement un peu lent (la version 0.6 est en développement depuis juin 2009)

FileZ

FileZ est une très bonne alternative à Jiraphe. Je le place cependant en deuxième position car je trouve qu’installer une base de donnée MySQL pour ce genre de besoin est un peu lourdingue….

Développé initialement par l’université d’Avignon, il est maintenant maintenu sur GitHub par les 2 principaux contributeurs.

La procédure d’installation n’est pas des plus simple, il faut donc y aller étape par étape. Je vous propose donc de vous guider dans le tutoriel suivant:

Installation de FileZ

L’installation est des plus simple et nécessite:

  • un serveur Web Apache avec le support du module mod_rewrite ou Nginx (voir la configuration FileZ pour Nginx dans ce billet)
  • le module PHP doit être activé
  • une base de donnée MySQL pour stocker les informations sur les fichiers et pour gérer l’authentification (il est aussi possible d’utiliser un serveur LDAP pour cette tache)
  • pour une installation depuis GitHub, il faut que le package git-core soit installé sur votre serveur

On commence par créer la base de donnée FileZ:

# mysql -u root -p
Enter password:

mysql> create database filez;
Query OK, 1 row affected (0.00 sec)

mysql> GRANT ALL PRIVILEGES ON filez.* TO "filez"@"localhost" IDENTIFIED BY "filezmdp";
Query OK, 0 rows affected (0.00 sec)

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)

mysql> USE filez

mysql>  CREATE TABLE `filez`.`db_users` (
`uid` SERIAL NOT NULL ,
`login` VARCHAR( 20 ) NOT NULL ,
`password` VARCHAR( 40 ) NOT NULL ,
`givenname` VARCHAR( 255 ) NOT NULL ,
`sn` VARCHAR( 255 ) NOT NULL ,
`mail` VARCHAR( 255 ) NOT NULL
) ENGINE = MYISAM ;

mysql> exit
Bye

Ensuite:

sudo git clone git://github.com/UAPV/FileZ.git /var/www
sudo chown -R www-data:www-data /var/www/FileZ

Cette commande va créer un répertoire /var/www/FileZ dans le répertoire racine de votre site Web et appliquer les droits pour l’utilisateur www-data (vous pouvez bien sûr adapter cette configuration à vos besoins).

Il faut ensuite se rendre à l’URL: http://votreserveur.com/FileZ

Le wizard d’installation va se lancer et vérifier que les pré-requis de votre serveur sont bons (ce qui serait étonnant). Si ce n’est pas le cas, il faut modifier la configuration de son serveur Web et/ou de PHP.

Note: Si vous utilisez Nginx, FileZ ne trouvera jamais le module mod_rewrite (et pour cause, il n’existe pas de le monde Nginx). Il suffit juste de cliquer sur continuer et d’ignorer le message.

On passe ensuite à la phase de configuration de FileZ en remplissant un formulaire. Vous pouvez vous inspirer de cette configuration en l’adaptant à votre système. La seule chose que j’ai changé est le fait de ne pas utiliser https (pas actif sur mon serveur):

En cas de problème, vous aurez le droit à un message du style:

Dans ce cas, il faut corriger les éventuels problèmes avant de continuer par exemple en créant le répertoire d’Upload:

sudo mkdir -p /var/filez/uploads
sudo chown -R www-data:www-data /var/filez/uploads

Puis en donnant les bons droits sur le répertoire de log:

sudo mkdir -p /var/log/filez
sudo chown -R www-data:www-data /var/log/filez

Utilisation de FileZ

Une fois l’installation finalisé on peut accéder à son FileZ:

Mon avis sur FileZ

Les +:

  • Gestion des utilisateurs (droits, mail automatique…)
  • Interface Web agréable

Les –:

  • Installation lourde
  • Pré-requis important (Apache + mod-rewrite, autre module si barre de progression…)
  • Utilisation obligatoire de MySQL

Les autres solutions

Voici un panel des autres solutions que j’ai écarté (peut être à tort mais je n’avais pas le temps de tout tester).

Open Upload

Tout comme FileZ, OpenUpload propose une gestion plus fine des utilisateurs et des accès que Jiraphe. Le plus gros défaut est le manque cruel de documentation claire pour l’installation (même si on cherche sur le Wiki).

ZendTo

Développé par l’université de Southampton, c’est une solution complète. On retrouve également la gestion des utilisateurs et des droits. L’installation est plus complexe que Jiraphe mais le site officiel propose des tutoriels plutôt complets.

Si vous souhaitez élargir l’utilisation de votre service à plusieurs personnes, c’est clairement une solution à regarder.

LinShare

Cette solution semble aussi complète mais je l’ai rapidement écarté en lisant le premier des pré-requis:

« To use Linshare you need to install a suitable JDK… »

Je cherchais une solution légère et pure Web, donc exit LinShare…

Xtrafile

Un dernière solution très bien faite (vous pouvez voir un site de démonstration ici). Elle se base sur un serveur Web / PHP + MySQL. Il existe une procédure d’installation très complète (sur CentOS) sur le forum.

Conclusion

Comme nous avons pu le voir ensemble à travers ce billet, il existe de nombreuses alternatives libres pour échanger simplement des gros fichiers via le navigateur Web.

Utilisez vous une de ces solutions ?

Préférez vous les services en ligne existants (mais non libres) ?

Partagez vos expériences dans les commentaires ci-dessous !