Auteur/autrice : nicolargo

Créateur de blog de Nicolargo, je suis un partisan des logiciels libres et un passionné des nouvelles technologies.

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

Protéger son serveur en utilisant Fail2Ban

Comme toutes les machines exposées au réseau Internet, mon serveur Web est continuellement la cible de tentatives d’attaques basiques de type brute force et DOS. J’avais déjà abordé le sujet sous la forme de billets tel que « Sécuriser son blog WordPress » ou « Détection des attaques DOS/DDOS avec Nagios« . Nous allons aujourd’hui parler d’une solution de protection active se déclenchant automatiquement lors d’une de ces attaques: Fail2Ban.

Comment marche Fail2Ban ?

Développé en langage Python, Fail2Ban est un logiciel libre permettant d’analyser des fichiers de logs et de déclencher des actions si certaines choses suspectes sont détectées. La grande force de Fail2Ban est sa grande modularité que cela soit au niveau des mécanismes de détections basées sur les expressions régulières ou sur les actions à mener qui peuvent aller de l’expédition d’un mail à la mise en place de règles de Firewall.

Fail2Ban se base sur un système de prisons (jails) que l’on peut définir, activer ou désactiver dans un simple fichier de configuration (/etc/fail2ban/jail.conf).

Une prison (jail) est composée, entre autres, des éléments suivants:

  • Nom du fichier de log à analyser.
  • Filtre à appliquer sur ce fichier de log (la liste des filtres disponibles se trouve dans le répertoire /etc/fail2ban/filter.d). Il est bien sûr possible de créer ses propres filtres.
  • Paramètres permettant de définir si une action doit être déclenchée quand le filtre correspond (« match »): Nombre de « matchs » (maxretry), intervalle de temps correspondant (findtime)…
  • Action à mener si nécessaire. La liste des actions se trouve dans le répertoire /etc/fail2ban/action.d. Il est également possible de créer ses propres actions.

Installation de Fail2Ban

On commence par installer Fail2Ban sur son système. Il se trouve dans la grande majorité des distributions GNU/Linux et BSD. par exemple pour l’installer sur une machine Debian 6, il suffit de saisir la commande suivante (en root ou bien précédée d’un sudo):

apt-get install fail2ban

Protection contre les attaques « brute force » SSH

Un exemple étant toujours plus parlant, nous allons configurer notre Fail2Ban pour bloquer automatiquement les adresses IP des machines essayant des attaques de type « brute force » sur notre port SSH (cette attaque est à la portée de n’importe quel « neuneu ». On trouve de très bon tutoriaux sur le sujet sur le net).

Si une machine cliente échoue 3 fois de suite lors de la saisie du couple login/password sur le serveur SSH alors on bloque l’accès au port TCP/SSH pendant 15 minutes. On analyse pour cela le fichier de log /var/log/auth.log en lui appliquant le filtre /etc/fail2ban/filter.d/sshd.conf puis, si nécessaire, l’action /etc/fail2ban/action.d/iptables.conf. La définition de cette prison (jail) est à faire dans le fichier /etc/fail2ban/jail.conf:

# SSH
# 3 retry ? > Ban for 15 minutes

[ssh]
enabled = true
port = ssh
filter = sshd
action = iptables[name=SSH, port=ssh, protocol=tcp]
logpath = /var/log/auth.log
maxretry = 3
bantime = 900

Un fois le filtre activé en relançant Fail2Ban avec la commande (en root):

service fail2ban restart

On peut rapidement voir son efficacité en regardant le fichier de log (par défaut sous /var/log/fail2ban.log):

Protection contre les attaques DOS (HTTP/GET)

Dans ce deuxième exemple nous allons voir comment lutter efficacement contre les attaques de type DOS ciblant vos serveurs Web. Ces attaques se caractérisent par un nombre inhabituel de requêtes HTTP venant d’un même client (du moins d’une même adresse IP source).

Le plus difficile est de trouver les bons paramètres correspondants à un comportement « inhabituel ». Dans l’exemple suivant, je considère comme « inhabituel » le fait qu’un client effectue plus de 360 requêtes en 2 minutes (soit une moyenne de supérieurement à 3 req/sec) sur mon serveur Web. Dans ce cas, je bloque l’accès au port HTTP pendant une durée de 10 minutes.

La prison (jail) correspondante est la suivante (à ajouter dans votre fichier /etc/fail2ban/jail.conf):

# Protect against DOS attack
# 360 requests in 2 min > Ban for 10 minutes

[http-get-dos]
enabled = true
port = http,https
filter = http-get-dos
logpath = /var/log/varnish/varnishncsa.log
maxretry = 360
findtime = 120
action = iptables[name=HTTP, port=http, protocol=tcp]
mail-whois-lines[name=%(__name__)s, dest=%(destemail)s, logpath=%(logpath)s]
bantime = 600

En regardant de plus près cette prison, on remarque qu’elle utilise en entrée le fichier de log au format NCSA généré par le système de cache Varnish que j’utilise en frontal sur mes serveurs Web (/var/log/varnish/varnishncsa.log). Il est bien sûr possible d’utiliser directement le log de votre serveur Apache ou Nginx. Le filtre http-get-dos n’est pas fourni par défaut. Il faut donc éditer le fichier /etc/fail2ban/filter.d/http-get-dos.conf avec le contenu suivant:

# Fail2Ban configuration file

#

# Author: http://www.go2linux.org

#

[Definition]

# Option: failregex

# Note: This regex will match any GET entry in your logs, so basically all valid and not valid entries are a match.

# You should set up in the jail.conf file, the maxretry and findtime carefully in order to avoid false positives.

failregex = ^<HOST>.*\"GET

# Option: ignoreregex

# Notes.: regex to ignore. If this regex matches, the line is ignored.

# Values: TEXT

#

ignoreregex =

Enfin, en cas de « match », on applique deux actions:

  1. blocage du port HTTP avec l’action iptables définie dans /etc/fail2ban/action.d/iptables.conf
  2. envoie d’un mail signalant le blocage avec l’action mail-whois-lines. L’adresse du mail est défini dans la variable destemail à modifier dans le fichier jail.conf.

Un fois le filtre activé:

service fail2ban restart

On peut regarder le fichier de log (/var/log/fail2ban.log)…:

$ tail -f /var/log/fail2ban.log

2012-02-22 11:36:59,134 fail2ban.actions: WARNING [http-get-dos] Ban 107.---.---.---

… et/ou attendre la réception des mails:

Conclusion

Ce billet est une simple introduction à l’utilisation de Fail2Ban qui peut être configuré de manière beaucoup plus personnalisé et en fonction de vous besoins. Si vous avez d’autres exemples d’utilisation, les commentaires ci-dessous sont fait pour cela !

Catégories
Open-source Planet-libre Systeme

Configurer votre prompt BASH

S’il y a bien une chose que nous, geeks du monde libre, regardons en longueur de journée, c’est bien notre cher prompt (vous savez: $, # …). C’est en lisant ce billet que je me suis dit que mon prompt actuel avait besoin d’un ravalement de façade:

Je souhaite mettre un peu de couleur dans mon nouveau prompt ainsi que des informations sur le dossier en cours. Quand ce dernier est un dossier de développement sous Git, je veux afficher la branche en cours d’utilisation et aussi savoir si mon répertoire est dans l’état « staging » (c’est à dire si je dois faire un commit).

Sans plus attendre, voici un aperçu de mon nouveau prompt (version 2 lignes):

Ce dernier se décompose en deux lignes:

  • user@host:folder (je garde cette structure pour simplifier les copier/coller en SSH, puis l’état Git (avec [le nom de la branche] en couleur rouge si staging, vert sinon)
  • le prompt proprement dit (là ou l’on va taper la commande :)) précédé de $ si on est un utilisateur standard et # si root

Pour la première ligne, j’utilise la variable BASH nommé PROMPT_COMMAND qui a le gros avantage d’être exécuté à chaque fois que le prompt est affiché (pas seulement à l’initialisation). La seconde ligne utilise la variable PS1.

Pour disposer de ce prompt, il est nécessaire d’insérer le code suivant à la fin de votre fichier .bashrc (il est aussi disponible sous GitHUB):

[cc lang= »bash »]

# Colors

NoColor= »\033[0m »

Cyan= »\033[0;36m »

Green= »\033[0;32m »

Red= »\033[0;31m »

Yellow= »\033[0;33m »

# Chars

RootPrompt= »# »

NonRootPrompt= »$ »

# Contextual prompt

prompt() {

USERNAME=`whoami`

HOSTNAME=`hostname`

CURRENTPATH=`pwd`

LEFTPROMPT=$Cyan$USERNAME@$HOSTNAME »: »$Yellow$CURRENTPATH

let LEFTSIZE=$(echo -n « $USERNAME@$HOSTNAME:$CURRENTPATH » | wc -c)

RIGHTPROMPT= » »

let RIGHTSIZE=0

GITSTATUS=$(git status 2> /dev/null)

#echo $GITSTATUS > /dev/null 2>&1

if [ $? -eq 0 ]; then

echo $GITSTATUS | grep « not staged » > /dev/null 2>&1

if [ $? -eq 0 ]; then

RIGHTPROMPT=$Red

else

RIGHTPROMPT=$Green

fi

BRANCH=`git describe –contains –all HEAD`

RIGHTPROMPT=$RIGHTPROMPT »[Git branch « $BRANCH »] »

let RIGHTSIZE=$(echo -n « [Git branch « $BRANCH »] » | wc -c)

fi

let BLANCKSIZE=${COLUMNS}-${LEFTSIZE}-${RIGHTSIZE}

RIGHTPROMPT=$RIGHTPROMPT$NoColor

echo -e -n $LEFTPROMPT

printf « %$(($BLANCKSIZE))s »

echo -e $RIGHTPROMPT

}

# Main prompt

PROMPT_COMMAND=prompt

if [ $EUID -ne 0 ]; then

PS1=$NonRootPrompt »  »

else

PS1=$RootPrompt »  »

fi

[/cc]

Update (20/02/2012): Je viens également d’ajouter une version allégée (en une seule ligne) de ce prompt. Le fichier de configuration BASH correspondant se trouve ici.

Update (21/02/2012): David Olivier vient de modifier  le script (version deux lignes) pour fonctionner avec SVN. A retrouver sur le GitHub.

Et vous, comment est votre prompt ?

 

Catégories
Open-source Planet-libre Systeme

Mon desktop 201202

Cela fait un moment que je n’ai pas tagué un billet avec le tag desktop. La raison est assez simple, mon environnement de travail que ce soit sur mes PC Debian, Ubuntu ou Mint évolue peu depuis ma migration vers Gnome Shell. Après les tâtonnements du début, j’ai pris mes marques et je dois avouer que je ne ferais plus marche arrière.

C’est donc la lecture de ce billet qui a provoqué les dernières modifications de détail que je vous montre sur mon PC portable sous Linux Mint 12:

Description de l’environnement:

Pour installer les thèmes / icônes, il faut suivre la procédure suivante:

cd `mktemp -d`
wget http://www.deviantart.com/download/189180645/boomerang_by_ghogaru-d34mspx.zip
unzip boomerang_by_ghogaru-d34mspx.zip
cd Boomerang_GTK_by_ghogaru
tar zxvf Boomerang.tar.gz
tar zxvf Boomerang\ Deux.tar.gz
sudo mv Boomerang Boomerang\ Deux /usr/share/themes/
cd ..
wget http://www.deviantart.com/download/255099649/faience_icon_theme_by_tiheum-d47vo5d.zip
unzip faience_icon_theme_by_tiheum-d47vo5d.zip
tar zxvf Faience.tar.gz
tar zxvf Faience-Azur.tar.gz
tar zxvf Faience-Claire.tar.gz
tar zxvf Faience-Ocre.tar.gz
sudo mv Faience Faience-Azur Faience-Claire Faience-Ocre /usr/share/icons
wget http://www.deviantart.com/download/255097456/gnome_shell___faience_by_tiheum-d47vmgg.zip
unzip gnome_shell___faience_by_tiheum-d47vmgg.zip
mv Faience ~/.themes/

Et vous il donne quoi votre desktop du moment ?

A vous de nous montrer vos écrans
(par exemple en utilisant yFrog puis en partagant l’URL) !

Catégories
Open-source Planet-libre Systeme

Apprentissage de Qemu/LibVirt par l’exemple

La rédaction des billets de ce blog nécessite de travailler sur plusieurs systèmes d’exploitations différents. Plutôt que de monter une salle machine dans ma maison (pas sur que ma compagne soit d’accord), j’ai donc opté pour un virtualisation sur un serveur dédié OVH qui a le gros avantage de disposer d’une RAM conséquente de 16 Go (pour une machine en l’an 2012). Travaillant la plupart du temps du temps sous Linux, mon choix c’est donc porté sur la solution Qemu/KVM (Kernel-based Virtual Machine).

Installation de Qemu/KVM

Pour que Qemu/KVM ait des performances acceptables, il faut vérifier que votre processeur soit compatible avec les extensions de virtualisation. Sous Linux, il est facile de vérifier cela avec la ligne de commande suivante.

[cce lang= »bash »]

egrep ‘^flags.*(vmx|svm)’ /proc/cpuinfo >/dev/null && echo OK || echo KO

[/cce]

Sur mon serveur de test (Kimsufi 16G chez OVH) pas de problème de ce coté là. J’obtiens un beau OK.

Le serveur peut donc supporter la virtualisation hardware. Chez OVH, le noyau par défaut est statique, il n’est donc pas possible d’ajouter dynamiquement des modules (comme le kvm_intel par exemple). Il faut donc suivre cette procédure. La dernière version des noyaux semble intégrer par défaut les modules KVM.

On peut ensuite passer à l’installation des briques logicielles (environ 257 Mo à télécharger):

  • qemu-kvm – Full virtualization on x86 hardware
  • virtinst – Programs to create and clone virtual machines
  • libvirt-bin – the programs for the libvirt library

On utilise les versions disponibles dans les dépôts Debian:

[cc lang= »bash »]

sudo apt-get install qemu-kvm virtinst libvirt-bin

[/cc]

Un petit reboot de la machine pour être sûr que tous les modules sont chargés avant de poursuivre.

Création de sa première machine virtuelle (VM)

Nous allons commencer par créer une machine virtuelle avec comme système hôte une Ubuntu Desktop 11.10. Une machine virtuelle a besoin d’un conteneur dans lequel elle va pourvoir s’exécuter: ce conteneur s’appelle une image disque. Ensuite, il faudra installer le système hôte à l’intérieur de cette image disque.

Il est possible d’utiliser la ligne de commande pour effectuer ces opérations (ce qui ouvre la voie à une automatisation par scripts). Nous aborderons cela un peu plus loin dans l’article. Pour commencer, nous allons utiliser le module libvirt-manager qui propose une interface graphique (GTK) permettant d’administrer à distance (via un tunnel SSH) son serveur d’hypervision Qemu/KVM.

On commence par vérifier que le daemon d’administration est bien lancé sur le serveur d’hypervision (ce qui devrait être le cas si vous avez suivi les étapes d’installations de ce billet):

[cc lang= »bash »]

sudo /etc/init.d/libvirt-bin status

Checking status of libvirt management daemon: libvirtd running.

[/cc]

Ensuite il faut ajouter votre utilisateur (nicolargo dans mon cas) dans les groupes ‘libvirt‘ et ‘kvm‘:

[cc lang= »bash »]

sudo usermod -a -G libvirt nicolargo

sudo usermod -a -G kvm nicolargo

[/cc]

Sur la machine GNU/Linux cliente (disposant d’une interface graphique), il faut installer les packages (par exemple sous Debian/Ubuntu):

[cc lang= »bash »]

sudo apt-get install virt-manager

[/cc]

Au lancement du client, il faut cliquer sur le menu File > Add connection…

Puis paramétrer la connexion vers votre serveur:

Notre serveur est alors disponible dans la liste, on peut alors configurer ses propriétés:

On configure le type de réseau que l’on va utiliser. Comme je ne dispose que d’une seule adresse publique sur mon serveur OVH Kimsufi, j’utilise la translation d’adresse (voir l’explication dans un chapitre suivant) qui est configurée par défaut:

Puis on configure les répertoires ou l’on pourra trouver les ISOs pour l’installation des machines hôtes:

 

 

Et voila le résultat après téléchargement de quelques images ISO depuis le répertoire ~/iso (le serveur disposant d’une accès 100 Mbs direct sur Internet, cela va assez vite !).

On peut passer à la création de la VM proprement dite en cliquant sur le bouton « Create a new virtual machine ». On accède alors à un wizard:

On entre le nom de la VM (sans espace):

Puis l’image ISO qui va nous servir pour l’installation du système d’exploitation (le « Browse » sur le serveur peut prendre un certain temps):

On défini ensuite les ressources de la VM (CPU et mémoire). A noter que la limite à 2 Go de RAM sur ma configuration de test:

On donne ensuite la taille de l’image disque qui contiendra notre VM. Je conseille 16 Go pour les OS récents.

Enfin on finalise la configuration coté réseau (NAT) et hyperviseur (KVM):

Une fenêtre avec un déport d’affichage devrait alors s’afficher et l’installation du système guest (Ubuntu 11.10) commencer:

 Il ne vous reste plus qu’à finaliser l’installation !

Utilisation de sa VM

Une fois l’installation de la VM effectuée (voir le chapitre précédant). Celle-ci devrait apparaître dans la liste proposé par Virtual Machine Manager. Pour la lancer, il faut sélectionner la VM puis cliquer sur le bouton ‘play’ (Power On the virtual machine):

Et voilà le travail:

Niveau performance ?

Il ne faut pas s’attendre à des miracles. La virtualisation par Qem/KVM bien qu’aillant fait de gros progrès dans les dernières versions restent en dessous d’une solution comme VmWare ou Xen. Elles sont par contre suffisante dans mon cas ou je souhaite valider des procédures et des logiciels système et réseau.

Gestion en ligne de commande

Création de l’image disque

On commence par créer un répertoire ~/vm qui va contenir toutes mes images disques:

[cc lang= »bash »]

mkdir ~/vm

[/cc]

Puis on utilise la commande qemu-img pour générer l’image disque « vierge »:

[cc lang= »bash »]

cd ~/vm

qemu-img create -f qcow2 debian6server.qcow2 16G

[/cc]

Cette dernière commande va donc générer une image disque nommée debian6server.qcow2 de type qcow2 (voir ci-dessous la liste des types disponibles sous Debian 6) avec une taille maximale de 16 Giga octets.

Sur mon système, la liste des « types » d’image disque est la suivante:

  • raw: pas de compression, l’image disque est directement « dumpée » dans un fichier
  • host_device
  • qcow2: format par défaut de Qemu (Qemu Image Format)
  • qcow: ancien format utilisé par Qemu (ne pas utiliser pour la création de nouvelle image disque)
  • vdi: format compatible avec VirtualBox
  • vmdk: format compatible avec VMWare
  • vpc: format compatible avec VirtualPC

Il est possible de convertir une image d’un format à un autre. Par exemple, si vous avez une image au format VMWare et que vous voulez la convertir vers un format Qcow2, il suffit de saisir la commande suivante:

[cc lang= »bash »]

qemu-img convert -f vmdk disk.vmdk -O qcow2 disk.qcow2

[/cc]

Création de la VM

Pour installer la VM, nous avons besoin de l’image ISO du système d’exploitation à installer (Debian 6 server dans mon exemple). On va donc télécharger cette image sur notre serveur (c’est dans ces moments là que l’on est heureux d’avoir un serveur avec une connexion à 100Mbps vers Internet…):

[cc lang= »bash »]

mkdir ~/iso

cd ~/iso

wget http://cdimage.debian.org/debian-cd/6.0.3/i386/iso-cd/debian-6.0.3-i386-CD-1.iso

[/cc]

Maintenant que nous disposons de l’image disque ~/vm/debian6server.qcow2 et du média d’installation ~/iso/debian-6.0.3-i386-CD-1.iso, nous allons créer la machine virtuelle en utilisant la couche d’abstraction libvirt.

Pourquoi utiliser libvirt plutôt que d’utiliser directement les commandes équivalentes Qemu ? Si demain vous décidez de changer votre système de virtualisation, vos procédures/scripts resteront les mêmes. En effet libvirt communique de manière transparente vers un grand nombre de systèmes de virtualisation en proposant en bonus une API de développement (notamment en Python).

On utilise donc la commande suivante pour créer la VM:

[cc lang= »bash »]

virt-install –ram=2047 –name=debian6server –file=/home/nicolargo/vm/debian6server.qcow2 –cdrom=/home/nicolargo/iso/debian-6.0.3-i386-CD-1.iso –hvm –vnc –noautoconsole

[/cc]

Note: la commande virt_install ne semble pas trop aimer les ~ dans les paths. Il faut donc donner le chemin absolu.

Note2: La taille maximale de RAM que je peux allouer est de 2047Mo.

Cette commande va donc créer une VM nommée debian6server qui disposera de 2 Go de RAM (d’ou l’avantage de faire tourner votre hyperviseur sur une machine disposant de pas mal de RAM / 16 Go dans mon cas sur une Kimsufi 16G).

Si tout est ok, le message suivant devrait s’afficher:

Domain installation still in progress.

You can reconnect to the console to complete the installation process.

Pour l’accès à la console (déport VNC via un tunnel SSH), je vous conseille d’utiliser l’interface d’administration de libvirt que vous pouvez lancer sur un PC client disposant d’une interface graphique.

Gestion du réseau par translation

Mon serveur dispose d’une seule adresse IP publique. Les VM auront donc des adresses IP privées et l’on utilisera la translation s’adresse (NAT) pour permettre au VM de sortir sur Internet (voir ce billet pour la création d’un réseau par NAT).

Certaines configurations sont à faire sur votre serveur:

[cc]

sudo sh -c « echo 1 > /proc/sys/net/ipv4/ip_forward »

[/cc]

[cc]

sudo vi /etc/sysctl.conf

# Uncomment the next line to enable packet forwarding for IPv4

net.ipv4.ip_forward=1

[/cc]

Si vous utilisez des règles Iptables alors il faut ajouter les lignes suivantes dans votre scripts (attention de bien vérifier que votre script ne repositionne pas la valeur net.ipv4.ip_forward à 0… je me suis fais avoir):

[cc]

# Qemu rules (NAT VM and allow VM to DHCP)

/sbin/iptables -t nat -A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE

/sbin/iptables -A INPUT -i virbr0 -j ACCEPT

/sbin/iptables -A OUTPUT -o virbr0 -j ACCEPT

/sbin/iptables -A INPUT -i virbr0 -p udp -m udp –dport 53 -j ACCEPT

/sbin/iptables -A INPUT -i virbr0 -p tcp -m tcp –dport 53 -j ACCEPT

/sbin/iptables -A INPUT -i virbr0 -p udp –dport 67:68 –sport 67:68 -j ACCEPT

/sbin/iptables -A FORWARD -d 192.168.122.0/24 -o virbr0 -m state –state RELATED,ESTABLISHED -j ACCEPT

/sbin/iptables -A FORWARD -s 192.168.122.0/24 -i virbr0 -j ACCEPT

/sbin/iptables -A FORWARD -i virbr0 -o virbr0 -j ACCEPT

echo 1 > /proc/sys/net/ipv4/ip_forward

[/cc]

Petite note pour les guests « BSD »

Pour un guest sous OpenBSD, il faut penser à effectuer les actions suivantes pour faire fonctionner correctement la carte réseau:

  • arrêter la VM
  • éditer le fichier /etc/libvirt/qemu/OpenBSD_5.0.xml

[cce]

<interface type=’network’>

…

<model type=’e1000′>

</interface>

[/cce]

  • Relancer la VM

Sources utilisées lors de la rédaction de cet article:

Catégories
Open-source Planet-libre Systeme

Cherche bêta-testeurs pour Glances 1.4

Billet dominical pour lancer une petite annonce: je cherche des bêta-testeurs pour la prochaine version de Glances, mon logiciel de monitoring système.

En effet, la version 1.4 de Glances intégrera la librairie PsUtil lieu et place de StatGrab pour récupérer les informations du système d’exploitation. Ce changement majeur (du moins pour ce modeste logiciel) nécessite une revalidation complète que je n’ai pas le temps de mener sur l’ensemble des système d’exploitation.

Voici un aperçu de cette prochaine version:

En quoi consiste le travail  à faire ?

Installation de la version bêta

Premièrement, récupérer la branche EXPERIMENTAL de Glances (actuellement en 1.4b) de la manière suivante:

[cc]

mkdir ~/tmp

cd ~/tmp

git clone -b experimental git://github.com/nicolargo/glances.git

cd ~/tmp/glances/glances

[/cc]

L’avantage de cette procédure est de pouvoir conserver en parallèle la version stable et la bêta.

Avant de pouvoir lancer la bêta de Glances il faut s’assurer que la librairie PsUtil (version 0.4 ou supérieure) est installé sur votre système.

La version 12.04 inclue cette dernière dans les dépôts officiels.

Pour les autres versions de Debian/Ubuntu, il est possible de suivre la procédure suivante pour l’installer:

[cc]

sudo apt-get install python-dev python-pip

sudo pip install psutil

[/cc]

Test de la version bêta

Pour lancer la version bêta de Glances sur votre système, il suffira ensuite d’utiliser la commande:

[cc]

cd ~/tmp/glances/glances

./glances.py

[/cc]

De qui ai-je besoin ?

Cette version a été testé sous (màj le 21 juin 2012):

  • Ubuntu 10.04 (64 bits), 10.10 (32 bits), 11.04 (64 bits), 11.10 (64 bits), 12.04 (32 bits)
  • Mint 11, Mint 12 et Mint Debian Edition
  • Debian 6 Squeeze et Wheeze (64 bits)
  • Fedora 16, 17
  • CentOS 5, 6
  • Arch 64 bits
  • Gentoo 3.2.5

J’ai donc besoin de toutes les personnes ayant une version d’OS différentes, notamment:

  • RedHat
  • Mandriva (Raymond si tu m’entends)
  • FreeBSD
  • OpenBSD
  • NetBSD

Une fois l’application validée, deux solutions. Si l’application fonctionne correctement, alors un simple message dans ce billet avec le nom de l’OS testé suffira à mon bonheur. En cas de problème, merci d’ouvrir un bug à partir de la page suivante en donnant le maximum d’information: version de Glances, version de PsUtil, version de Python, version du système d’exploitation, description du problème.

Merci à vous !

Catégories
Open-source Planet-libre Reseau Web

OwnCloud 3 sur un serveur Debian / Nginx

Par ces temps de dématérialisation des espaces de stockages, les services en ligne comme Dropbox et SpiderOak focalisent à la fois des commentaires admiratifs (facilité d’utilisation, fiabilité) et réticents (protection de la vie privée, pérennité du service à moyen et long terme, prix). Du bon coté de la force, les alternatives libres et auto-hébergées commencent à pointer le bout de leurs nez. Une de ces solutions a eut droit à son petit buzz ces dernières semaines: OwnCloud.

J’apporte donc ma petite pierre à l’édifice en vous proposant une installation et une configuration de OwnClound version 3 sur un serveur Debian Squeeze sous NGinx.

Présentation de OwnCloud

OwnClound (en version 3 au moment de l’écriture de ce billet) se présente sous la forme d’un serveur à héberger sur une machine GNU/Linux.

Une fois installé, ce dernier propose les services suivants:

  • partage d’espaces disques via le protocole WebDav (support GNU/Linux, BSD, Mac OS X, Windows)
  • partage de fichiers en HTTP (fonction « sharing »)
  • édition de fichier en ligne
  • accès à votre musicale
  • accès à vos photos
  • synchronisation de vos contacts en utilisant le protocole CardDav
  • synchronisation de votre agenda en utilisant le protocole CalDav
  • client disponible sous IOS et Android
  • extensibilité de votre cloud avec des applications…

Installation de OwnClound

Installation de LESP

La plupart des articles sur OwnCloud se base sur une couche LAMP (Linux Apache MySQL PHP). Je vous propose d’utiliser une base LESP (LESP = Linux + Engine X aka NGinx + SqLite + PHP). Les étapes de ce premier chapitre sont à effectuer seulement si les logiciels concernés ne sont pas déjà installés. On commence par installer le couple NGinx / PHP-FPM en utilisant par exemple mon script d’auto install:

[cc]

mkdir ~/installowncloud

cd ~/installowncloud

wget https://raw.github.com/nicolargo/debianpostinstall/master/nginxautoinstall.sh

chmod a+x nginxautoinstall.sh

sudo ./nginxautoinstall.sh

[/cc]

Note: la chose importante est de compiler NGinx avec le support Webdav (–with-http_dav_module).

Configuration de LESP pour OwnCloud

Par défaut, PHP n’autorise pas l’upload de fichier de plus de 2 Mo. Il faut donc changer cette configuration en éditant le fichier /etc/php5/fpm/php.ini pour augmenter cette limite à 1000 Mo (ou plus, c’est à adapter à vos besoins).

[cc]

post_max_size = 1000M

upload_max_filesize = 1000M

[/cc]

On configure NGinx pour qu’il gère le site cloud.comaine.com pointant vers le répertoire /var/www/owncloud (là encore, la configuration est à adapter à votre infrastructure) en éditant le fichier /etc/nginx/sites-enabled/owncloud (à adapter à votre besoins/configuration):

[cc]

server {

listen 80;

server_name cloud.mondomaine.com;

root /var/www/owncloud;

client_max_body_size 1000M;

index index.php;

dav_methods PUT DELETE MKCOL COPY MOVE;

create_full_put_path on;

dav_access user:rw group:rw all:r;

try_files $uri $uri/ @webdav;

location @webdav {

fastcgi_split_path_info ^(.+\.php)(/.+)$;

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

include fastcgi_params;

fastcgi_pass 127.0.0.1:9000;

}

# PHP scripts -> PHP-FPM server listening on 127.0.0.1:9000

location ~ \.php$ {

try_files $uri =404;

fastcgi_pass 127.0.0.1:9000;

fastcgi_index index.php;

include fastcgi_params;

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

}

# Stuffs

location = /favicon.ico {

access_log off;

return 204;

}

# Protect hidden file to read/write access

location ~ /\. {

deny all;

}

}

[/cc]

On relance NGinx:

[cc]

sudo /etc/init.d/nginx reload

[/cc]

Il est possible d’utiliser le protocole sécurisé HTTPS en lieu et place de HTTP pour les communications entre le navigateur Web et votre serveur OwnCloud. La configuration est donnée en exemple sur cette page.

Installation des dépendances

OwnCloud utilise des librairies pour fonctionner correctement. Sous Debian (et Ubuntu), l’installation de dépendances se fait de la manière suivante:

[cc]

sudo apt-get install php5-sqlite php5-json mp3info curl libcurl3 libcurl3-dev php5-curl zip git

[/cc]

Installation de OwnClound depuis son dépôt GIT

OwnClound étant un projet encore « jeune », les évolutions sont fréquentes et je vous conseille l’installation depuis le HEAD des « sources » Git.

[cc]

cd ~/installowncloud

git clone git://gitorious.org/owncloud/owncloud.git

sudo mv owncloud /var/www/

sudo chown -R www-data:www-data /var/www/owncloud

sudo /etc/init.d/php5-fpm restart

[/cc]

Il ne reste plus qu’à finaliser l’installation en pointant un navigateur Web sur l’adresse de votre serveur:

http://cloud.votredomaine.com/

Et oh joie oh espoir:

Mettre à jour OwnCloud

Pour mettre à jour OwnCloud:

[cc]

cd /var/www/owncloud

sudo git pull

sudo chown -R www-data:www-data /var/www/owncloud

[/cc]

Utilisation de OwnCloud

Utilisation de l’interface Web

L’interface Web est légère et bien pensée. Elle présente vos fichiers sous la forme d’une arborescence classique (répertoire/ficher) ou bien avec des filtre pour n’afficher que vos fichiers musicaux (onglet Musique) ou photos (onglet Galerie si vous avez installé l’application). OwnCloud permet bien sûr de jouer vos musiques à distance (fonction streaming). Utilisant le service Spotify, je n’utilise pas trop cette fonction. La visualisation des images est un plus mais ne remplace pas un service dédié (comme on peut le trouver sur Internet).

Bref vous l’aurez compris, je n’ai pas vraiment accroché sur les applications tierces (musiques, photos, contact, agenda…), j’ai mes habitudes avec des services « Web » et il est dur d’en changer. Par contre, la fonction principale de OwnCloud (la mise à disposition d’un espace de stockage dans un nuage) est une alternative possible à Dropbox ou SpiderOak. Il faut toutefois relativiser cette comparaison. En effet, la population des personnes intéressées par OwnCloud et disposant d’une machine allumée et connectée en permanence sur Internet se limite au petit monde des GL (Geeks Libristes).

Nous allons voir maintenant comment accéder à son espace de stockage OwnCloud en utilisant autre chose que l’interface Web.

Accès direct depuis le serveur

Par défaut, vos fichiers sont stockés sur le serveur dans le répertoire /var/www/owncloud/data/user/files. Il est donc tout à fait possible d’accéder directement à cette arborescence depuis le serveur ou un accès distant comme SSH. Il faut par contre veiller à ce que les fichiers / sous-répertoires appartiennent à l’utilisateur www-data:www-data afin que l’on puisse les gérer avec les autres moyens d’accès (interface Web, Webdav…). Attention toutefois, dans sa version actuelle, OwnCloud ne gère pas les liens symboliques.

WebDav depuis Linux

Le plus simple est de faire le montage WebDav depuis votre navigateur de fichier. Sous Gnome le menu « Se connecter à un serveur » (Connect to a server) permet d’afficher la fenêtre suivante:

Il suffira ensuite de créer un bookmark vers le point de montage WebDav ainsi obtenu en le renommant OwnCloud. Un simple click vers ce bookmark vous donnera l’accès à vos données dans votre nuage.

Il est bien sûr possible de faire la manipulation en ligne de commande (après l’installation de davfs2):

[cc]

mount -t davfs http://cloud.mondomaine.com/files/webdav.php /home/user/owncloud

[/cc]

Update (27/02/2012): Afin de simplifier le lien entre vos répertoires locaux et ceux disponibles dans votre Cloud, il est également possible d’utiliser le couple Mirall/CSync qui comblent le gap des fonctions proposées par Dropbox avec un client desktop bien pensé.

WebDav sous Windows

Sous Windows 7, la manipulation est un peu plus complexe, il faut en effet modifier une clé de registre à partir du logiciel « regedit »:

HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Services > WebClient > Parameters > BasicAuthLevel = 2

On peut ensuite passer par l’outil système de connexion de lecteur réseau:

Conclusion

Bien que réservé aux heureux possesseurs d’un serveur connecté en permanence à Internet, OwnCloud est un projet intéressant. Il centralise en un seul point les services utiles à la vie numérique de tous les jours: fichiers, images, photos, contact, agenda. Il lui manque encore quelques fonctions qui seront sûrement apportées par le système de plugins. Je pense notamment à: possibilité de jouer en streaming les vidéos stockées dans notre « cloud », accès par un protocole plus optimisé que WebDav (par exemple SSH), connexion vers les réseaux sociaux pour facilité le partage…

Le modèle économique de la société qui se cache derrière ce projet est de conserver le coeur du système (le serveur OwnCloud) sous licence libre (actuellement AGPL version 3) et de proposer une offre commerciale pour héberger vos données sur leurs infrastructures (cette offre sera disponible mi mars 2012).

Alors près à « switcher » vos données vers votre propres cloud ? Personnellement, j’attend encore un peu.

Quelques liens consultés lors de la rédaction de ce billet:

 

Catégories
Open-source Planet-libre Systeme

Glances v1.3.7: les nouveautés !

Glances, mon logiciel de supervision système évolue en version 1.3.7.

Pour installer cette dernière version, il suffit de suivre la documentation officielle (ou d’attendre la mise à jour dans les dépôts de votre distribution).

Nouveautés

Cette dernière version propose notamment, en plus de quelques optimisations et corrections de bugs:

  • l’affichage des dernières alertes (historique) en bas de la fenêtre
  • modification interne de la gestion des alertes qui ouvre la porte à leurs paramétrages dans une future version
  • ajout du support des consoles en noir et blanc

Voici un aperçu:

Petites précisions sur la principale nouveauté de cette version: les logs.

Les ‘n’ dernières alertes (nombre limité à 10) sont affichées (si l’espace est libre) en bas de la fenêtre. Seules les alertes WARNING ou CRITICAL  pour la CPU, la charge et la mémoire globale sont prises en compte.

Une ligne de log est décomposé de la manière suivante:

  • le premier caractère, en début de ligne, indique la criticité de l’alerte (couleur violette pour les alertes WARNING et rouge pour le CRITICAL) avec en option le caractère ~ si l’alerte en cours.
  • la date de début de l’alerte
  • la date de fin de l’alerte (si elle n’est pas en cours)
  • la description de l’alerte
  • les valeurs (min/moyenne/max) de la statistique concernée durant l’alerte

Le futur de Glances

La principale évolution sur laquelle je travaille pour la future version majeure de Glances (la 2.0) est le remplacement de la librairie StatGrab (le projet semble peu réactif) par PsUtil. J’ai d’ailleurs commencé à étudier la question dans le Wiki et je suis preneur de toutes les bonnes idées pour améliorer Glances.

Je suis toujours preneur de contributeurs pour « packager » Glances dans un dépôt PPA Ubuntu et des dépôts Debian (j’ai essayé mais je n’ai pas le temps de suivre ces actions).

Catégories
Open-source Planet-libre Reseau Systeme

Installation et configuration de Munin, le maître des graphes

Munin est un logiciel de supervision permettant de centraliser la gestion des graphes de données RRDTools. Il permet en quelques commandes que nous allons détailler dans ce billet de générer des graphes complexes pour surveiller vous machines et les processus qui tournent dessus.

Voici un exemple de graphe sur les statistiques remontées par un serveur utilisant Varnish:

Introduction

Munin est proposé sous la forme de deux packages complémentaires: munin et munin-node.

Le premier (munin) est à installer sur votre serveur de supervision (appelé maître). Son objectif principal est de récupérer les données venant des machines à surveiller puis de générer des graphes qui seront présentés aux utilisateurs via une interface Web.

Le second  (munin-node) est à installer sur toutes les machines à superviser (appelées noeuds). Son objectif est de collecter les informations systèmes en utilisant des plugins (présent dans le package munin-node et dans munin-plugins-extra).

La communication entre le serveur maître et les machines noeuds utilise, par défaut le protocole TCP/4949 (initialisation de la connexion TCP de la part du serveur maître).

Installation de Munin

Pour la suite de ce billet (et sauf mention spécifique), je partirai sur le principe ou vous utilisez des machines sous Debian/Ubuntu.

Installation de Munin sur le serveur maître

Le serveur maître doit disposer d’un serveur Web (voir ce billet pour installer simplement NGinx sur votre système) configuré avec le répertoire root par défaut: /var/www.

Comme Munin est présent dans les dépôts officiels, il suffit de saisir la commande suivant qui va installer le package maître ainsi que le package esclave histoire de pouvoir superviser son serveur de supervision…:

sudo apt-get install munin munin-node munin-plugins-extra

sudo ln -s /var/cache/munin/www /var/www/munin

sudo /etc/init.d/munin-node restart

En faisant pointer un navigateur Web vers l’URL:

http://votreserveurdesupervision/munin

Vous devriez voir s’afficher les statistiques de votre serveur. Il faut attendre quelques minutes avant de voir les premiers graphes, le temps que les bases de données soient renseignées.

Installation de Munin sur les machines noeuds

Installation des noeuds sous GNU/Linux

Là encore c’est assez simple:

sudo apt-get install munin-node munin-plugins-extra

La configuration de Muni sur les machines noeuds est centralisée dans le fichier /etc/munin/munin-node.conf. Il faut éditer ce fichier pour y configurer l’adresse IP de votre serveur maître à la ligne suivante:

# A list of addresses that are allowed to connect. This must be a

# regular expression, since Net::Server does not understand CIDR-style

# network notation unless the perl module Net::CIDR is installed. You

# may repeat the allow line as many times as you'd like

allow ^192\.168\.1\.200$

Cette configuration (à adapter à votre besoin) va autoriser la machine maître d’adresse IP 192.168.1.200 à se connecter sur cette machine noeud pour y récupérer les données à superviser.

Il faut ensuite relancer le service Munin-node pour faire prendre en compte la nouvelle configuration:

sudo /etc/init.d/munin-node restart

Installation des noeuds sous Windows

Le projet Munin ne fourni pas de « node » pour WIndows, il faut donc se retourner du coté de la communauté pour trouver notre bonheur. En l’occurrence du coté du logiciel Munin-Node-Win32 disponible au téléchargement sur cette page.  Il suffit de lancer l’installer pour que l’installation et le lancement du processus en tache de fond soit effectué (procédure testé sous Windows 7).

Installation des noeuds sous MacOS

Si vous avez à surveiller des machines sous Mac OS X, il va falloir mettre un peu plus les mains dans le cambouis. En effet, il faut obligatoire passer par l’installation des gestionnaires de paquets Fink ou MacPorts. Je vous conseille la lecture du Wiki officiel.

Configuration des plugins sur les machines noeuds

Nous allons voir dans cette sections comment configurer ce que l’on souhaite superviser sur les machines noeuds. Munin utilise le fichier  /etc/munin/plugin-conf.d/munin-node (ainsi que tous les fichiers se trouvant dans le même répertoire) pour configurer les paramètres des plugins (bien souvent de simples script Perl).

Le répertoire /etc/munin/plugins/ contient la liste des plugins utilisables par la machine noeud et le répertoire /usr/share/munin/plugins/ l’ensemble des plugins. En y regardant de plus prêt, le répertoire  /etc/munin/plugins/ fait des liens symboliques vers le répertoire /usr/share/munin/plugins/.

Pour voir la liste des plugins disponibles sur le noeud, on peut utiliser:

# sudo munin-node-configure

Exemple de l’ajout des plugins NGinx (permettant de surveiller un serveur Web NGinx) sur un noeud:

Pour faire prendre en compte un nouveau plugin sur un noeud (node) il faut faire un lien symbolique entre le fichier en question dans ce répertoire et /etc/munin/plugins/. Par exemple pour accéder aux stats de mon serveur NGinx:

sudo ln -s /usr/share/munin/plugins/nginx_status /etc/munin/plugins/nginx_status

sudo ln -s /usr/share/munin/plugins/nginx_request /etc/munin/plugins/nginx_request

Il est quelquefois necessaire d’installer des dependances pour que le plugin fonctionne.

Pour voir les dépendances nécessaire il suffit de saisir la commande:

sudo munin-node-configure --suggest | grep nginx

nginx_request | yes | no [LWP::UserAgent not found]

nginx_status | yes | no [LWP::UserAgent not found]

Il faut donc installer la librairie perl contenant le module LWP qui est présente dans le package libwww-perl sur Debian/Ubuntu:

sudo apt-get install libwww-perl

Cela a l’air OK:

sudo munin-node-configure --suggest

nginx_request | yes | yes

nginx_status | yes | yes

On peut faire prendre en compte la configuration par Munin-node:

sudo /etc/init.d/munin-node restart

Configuration du maître pour prendre en compte les machines noeuds

Une fois toutes vos machines noeuds configurés (voir le chapitre précédant), il faut maintenant modifier la configuration du serveur maître pour les prendre en compte. Là encore, fidèle à la philosophie Unix, la configuration est centralisé dans le fichier /etc/munin/munin.conf.

En plus des répertoires systèmes en début de fichier:

# The next three variables specifies where the location of the RRD

# databases, the HTML output, logs and the lock/pid files. They all

# must be writable by the user running munin-cron. They are all

# defaulted to the values you see here.

#

dbdir /var/lib/munin

htmldir /var/cache/munin/www/

logdir /var/log/munin

rundir /var/run/munin

Il faut configurer la liste des noeuds de la manière suivante:

# A simple host tree for mondomaine.com

[maitre.mondomaine.com]

address 127.0.0.1

[noeud1.mondomaine.com]

address noeud1.mondomaine.com

[noeud2.mondomaine.com]

address noeud2.mondomaine

Reste à relancer le serveur Munin pour prendre en compte la configuration:

su - munin --shell=/bin/bash

/usr/share/munin/munin-update

exit

En faisant pointer un navigateur Web vers l’URL:

http://votreserveurdesupervision/munin

Puis par exemple les graphes sur l’occupation mémoire:

Pour voir une démonstration en ligne des capacités de Munin, vous pouvez consulter ce serveur maître qui est en accès libre.

Plus de plugins ?

Un des gros avantage de Munin est le fait de pouvoir simplement écrire de nouveaux plugins en utilisant votre langage favori (nous reviendrons bientôt sur ce sujet dans un prochain billet).  Pas mal d’exemples sont proposés  dans le dépôt GitHub suivant (vous devriez trouver votre bonheur).
Catégories
Open-source Planet-libre Systeme Web

NGinx – Protéger son site avec une authentification simple HTTP

Un petit billet « flash express » pour  protéger son site (ou un répertoire de son site) avec une authentification simple (type login/password) sur un serveur NGinx.

Pré-requis

Il faut disposer d’un serveur NGinx bien configuré (par exemple en utilisant ce script d’auto-installation pour Debian ou Ubuntu) puis du logiciel htpasswd que l’on peut installer sous Debian/Ubuntu avec la commande suivante:

[cc]

sudo apt-get install apache2-utils

[/cc]

Création du fichier .htpasswd

Ce fichier va contenir, de manière chiffré, le mot de passe associé à l’utilisateur. La commande à utiliser pour créer ce fichier est la suivante:

[cc]

sudo htpasswd -c /var/www/.htpasswd nicolargo

New password:

Re-type new password:

Adding password for user nicolargo

[/cc]

Ou:

  • -c est une option pour créer le fichier (sans cette option, le couple login/password est ajouté)
  • /var/www/ est l’emplacement du fichier .htpasswd. Le contenu du répertoire /var/www/ (donc la racine de mon site Web) sera donc protégée par le couple login/password
  • nicolargo est le nom de l’utilisateur (login)
  • ilfaut sasir deux fois le mot de passe (password)

Configuration de NGinx

Pour que NGinx puisse gérer les fichiers .htpasswd, il faut ajouter modifier la configuration de son site (à  adapter selon votre configuration):

[cc]

server {

listen 80;

server_name localhost;

root /var/www;

# Static

location / {

index index.html index.htm;

auth_basic « Login »;

auth_basic_user_file /var/www/.htpasswd;

}

# Protect hidden file to read/write access

location ~ /\. {

deny all;

}

}

[/cc]

Après avoir rechargé la configuration:

[cc]

sudo /etc/init.d/nginx restart

[/cc]

Il ne reste plus qu’à…

Tester

En pointant un navigateur sur le site en question, une bannière d’authentification va apparaitre:

 

Note sur la sécurité

Attention de ne PAS utiliser se mécanisme pour protéger des informations sensibles. En effet il n’y a pas de chiffrement des données lors de la transmission en HTTP entre le navigateur et le serveur et le fichier .htpasswd peut être récupéré en cas de corruption de votre serveur…

Catégories
Open-source Planet-libre Web

MyTinyTodo, un outil « TODO list » auto-hébergé et libre

Etant à la recherche d’un outil auto-hébergé, en ligne et libre pour gérer la liste des taches de ma vie quotidienne j’ai lancé un petit sondage sur Twitter. L’étude de vos réponses m’a permis de découvrir le script PHP MyTinyTodo dont je vais détailler l’installation et la configuration dans ce billet.

Introduction

MyTinyTodo (licence GPL) est donc un script PHP (il a donc besoin d’un serveur Web avec le support de ce langage) fonctionnant avec une base de donnée MySQL ou SQLite (j’ai choisi cette deuxième option).

Je pars donc sur le principe que vous disposez d’un serveur Web avec le support de PHP configuré pour pointer par défaut sur le répertoire /var/www (pour arriver à une telle configuration sous Debian vous pouvez utiliser mon script d’auto-installation de NGinx + PHP-FPM).

Certaines commandes nécessites des droits d’administration sur votre machine. J’utilise ‘sudo’ pour les exécuter  mais il est également possible de les saisir dans un terminal root.

Pré-requis

En plus du serveur Web et du support PHP, MyTinyTodo a besoin des librairies pour communiquer avec la base de donnée.

Si vous utilisez MySQL il faut saisir la commande:

[cc]

sudo apt-get install php5-mysql

[/cc]

Si comme moi vous préférez SQLite il faut installer la librairie de la manière suivante:

[cc]

sudo apt-get install php5-sqlite

[/cc]

On doit dans tous les cas relancer le serveur PHP-FPM pour prendre en compte la configuration:

[cc]

sudo /etc/init.d/php-fpm restart

[/cc]

Installation de MyTinyTodo

On commence par récupérer le script MyTinyTodo puis de le mettre au bon endroit sur notre système (c’est à dire dans le répertoire racine du serveur Web: /var/www).

[cc]

cd `mktemp -d`

wget http://mytinytodo.googlecode.com/files/mytinytodo-v1.4.2.zip

unzip mytinytodo-v1.4.2.zip

sudo mv mytinytodo /var/www

wget http://www.mytinytodo.net/lang/zip/fr.zip

unzip fr.zip

sudo mv fr.php /var/www/mytinytodo/lang/

sudo chown -R www-data:www-data /var/www/mytinytodo

[/cc]

Il faut ensuite faire pointer un navigateur Internet vers l’adresse de votre serveur:

http://votreserveur.com/mytinytodo/setup.php

La page suivante devrait s’afficher:

Puis:

Et enfin:

Pour éviter que des gens mal attentionnés modifient votre configuration, il est conseillé d’effacer le fichier setup.php de votre système:

[cc]

sudo rm /var/www/mytinytodo/setup.php

[/cc]

Configuration initiale

Vous pouvez maintenant accéder à votre système de « TODO list » est saisissant l’URL suivante:

http://votreserveur.com/mytinytodo/

Nous allons commencer par appliquer une configuration initiale (langue, fuseau horaire, protection par mot de passe…):

Voici mes paramètres à adapter à vos besoins:

Utilisation

Il ne reste plus qu’à créer des onglets (j’ai pris comme habitude d’avoir un onglet par type d’activité: perso, blog, boulot…) et de saisir vos taches:

Il existe pas mal d’options, une des plus intéressante de mon point de vu est de pouvoir partager un onglet (donc une liste de taches) à travers un flux RSS, pour cela il suffit de deux clics:

Conclusion

MyTinyTodo remplit parfaitement son rôle. Sans fioriture mais avec souplesse et légèreté. J’ai laissé tombé le service en ligne RememberTheMilk (par ailleurs très bien fait) pour mon service MyTinyTodo auto hébergé :).

Update (26/01/2012): Si vous préférez utiliser le couple Apache/Mysql en lieu et place de NGinx/SQLite, je vous conseille la lecture du billet de Jidey sur le blog « Pelle la tarte ».