ka.da

Aller au contenu | Aller au menu | Aller à la recherche

mardi, avril 6 2010

Héberger des projets Django avec Nginx et Gunicorn

Mise à jour : j'ai finalement décidé d'utiliser supervisor pour gérer/monitorer ce genre de services, donc je posterais un billet prochainement sur ce thème.

Je continue l'optimisation de mon serveur web (cf le premier épisode) avec cette fois-ci mes projets Django que j'ai migré vers Nginx et Gunicorn. (veuillez noter que Gunicorn permet également de faire tourner d'autres types d'applications Python que Django)

Virtualenv

Pour gérer mes projets Django, j'utilise virtualenv et toute cette doc part donc du principe que vous l'utilisez également. Si ce n'est pas le cas 1. je vous encourage à le faire ;) 2. vous devrez adapter cette doc en conséquence.

Gunicorn

On commence par installer Gunicorn dans chacun des environnements virtuels hébergeant vos projets Django (cf plus bas pour les détails)

$ pip install gunicorn

ou

$ easy_install gunicorn

Ensuite pour chaque projet Django qui sera propulsé par Gunicorn, le plus simple est de créer un fichier de configuration gunicorn.conf.py pour indiquer les options du serveur à son lancement. Voici un exemple de fichier :

backlog = 2048
bind = "unix:/var/run/gunicorn/monprojet.sock"
pidfile = "/var/run/gunicorn/monprojet.pid"
daemon = True
debug = False
workers = 2
logfile = "/opt/django/www_domain_tld/log/gunicorn.log"
loglevel = "info"

Pour bind vous pouvez soit spécifier un socket Unix soit une adresse et un port TCP/IP. Veuillez consulter la doc configuration pour les détails.

Vous pouvez alors lancer gunicorn avec la commande suivante :

$ gunicorn_django -c gunicorn.conf.py

Bien sûr, comme pour l'article précédent que se passe-t-il en cas de redémarrage du serveur ? Il faut relancer les processus gunicorn un par un. Pour éviter ce genre de désagréments j'ai donc créé un script destiné au système de démarrage sysvinit de Debian.

Ce script a comme prérequis :

  • d'avoir pour chaque projet Django
    • un virtualenv dédié dans un répertoire www_domaine_tld
    • dans ce virtualenv un répertoire nommé monprojet avec les sources de celui-ci et notamment les fichiers importants pour Django (settings.py, urls.py...)
  • d'avoir un répertoire /etc/gunicorn/sites
  • dans ce répertoire vous faites un lien vers le virtualenv de chaque projet en lui donnant le nom du répertoire du projet, exemple :
# cd /etc/gunicorn/sites
# ln -s /opt/django/www_domaine_tld monprojet
  • le fichier gunicorn.conf.py est situé dans le virtualenv (donc dans le répertoire parent de celui des sources du projet)
  • il faut que le pid spécifié dans ce fichier soit de la forme monprojet.pid puisque son nom est ainsi extrapolable par rapport au nom du lien dans /etc/gunicorn/sites

Ce qui donne (pour éclaircir tout ça) une arborescence comme suit :

/etc/gunicorn/sites/
                    monprojet1 -> /opt/django/www_domaine1_tld      # lien vers /opt/django/www_domaine1_tld
                    monprojet2 -> /opt/django/www_domaine2_tld      # lien vers /opt/django/www_domaine2_tld

/opt/django/
            www_domaine1_tld/
                             bin/                         #
                             include/                     # répertoires créés par virtualenv
                             lib/                         # 
                             monprojet1/                  # répertoire contenant les sources du projet
                             gunicorn.conf.py             # fichier de configuration de gunicorn
            www_domaine2_tld/
                             bin/                         #
                             include/                     # répertoires créés par virtualenv
                             lib/                         # 
                             monprojet2/                  # répertoire contenant les sources du projet
                             gunicorn.conf.py             # fichier de configuration de gunicorn

Et voici le script /etc/init.d/gunicorn

#!/bin/sh 

### BEGIN INIT INFO
# Provides:       gunicorn
# Required-Start: $local_fs $syslog
# Required-Stop:  $local_fs $syslog
# Default-Start:  2 3 4 5
# Default-Stop:   0 1 6
# Short-Description: Gunicorn processes
### END INIT INFO

USER=www-data
NAME="gunicorn"
DAEMON="gunicorn_django"
CONFDIR=/etc/gunicorn/sites
PIDDIR=/var/run/gunicorn
VENV_ACTIVATION="source ../bin/activate"
CONFFILE="../gunicorn.conf.py"
OPTIONS="-c $CONFFILE"
RETVAL=0

# source function library
. /lib/lsb/init-functions

# pull in default settings
[ -f /etc/default/gunicorn ] && . /etc/default/gunicorn

start()
{
    echo $"Starting $NAME."
    cd $CONFDIR;
    for d in *; do
        echo -n $d;
        PIDFILE=$PIDDIR/$d.pid
        if [ -f $PIDFILE ]; then
            echo ": already started!"
        else
            cd $d;
            cd $d;
            su -c "$VENV_ACTIVATION; $DAEMON $OPTIONS" $USER && echo ": OK";
        fi
    done
    echo "done"
}

stop()
{
    echo $"Stopping $NAME:"
    cd $CONFDIR
    for d in *; do
        echo -n $d;
        if [ -f $PIDDIR/$d.pid ]
        then kill -QUIT `cat $PIDDIR/$d.pid` && echo ": OK" || echo ": failed";
        fi
    done
    echo "done"
}

reload()
{
    echo $"Reloading $NAME:"
    cd $CONFDIR
    for d in *; do
        echo -n $d;
        if [ -f $PIDDIR/$d.pid ]
        then kill -HUP `cat $PIDDIR/$d.pid` && echo ": OK" || echo ": failed";
        fi
    done
    echo "done"
}

case "$1" in
    start)
        start
        ;;
    stop)
        stop
        ;;
    restart)
        reload
        ;;
    reload)
        reload
        ;;
    force-reload)
        stop && start
        ;;
    *)
        echo $"Usage: $0 {start|stop|restart}"
        RETVAL=1
esac
exit $RETVAL

Nginx

Pour Nginx, on retrouve un fichier de configuration semblable à celui-ci :

upstream www_domaine_tld {
    server      unix:/var/run/gunicorn/monprojet.sock fail_timeout=0;
}

server {
    listen      80;
    server_name www.domaine.tld;

    access_log  /var/log/nginx/www.domaine.tld.access.log;
    error_log   /var/log/nginx/www.domaine.tld.error.log;

    location /media {
        root    /opt/django/www.domaine.tld/lib/python2.5/site-packages/django/contrib/admin/;
      expires       30d;
    }

    root            /opt/django/www.domaine.tld/monprojet/media;

    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_redirect off;       

        if (!-f $request_filename) {
            proxy_pass http://www_domaine_tld;
            break;
        }
    }
}

Et voili.

samedi, avril 3 2010

Faire tourner des applications Ruby on Rails avec Nginx et Unicorn

Mise à jour : j'ai finalement décidé d'utiliser supervisor pour gérer/monitorer ce genre de services, donc je posterais un billet prochainement sur ce thème.

Afin d'optimiser mon petit serveur virtuel chez Gandi qui, à force de lui ajouter des fonctions, des sites web, des utilisateurs avait de petits problèmes de charge au point de temps en temps de ne plus répondre, je migre du serveur web Apache vers Nginx. Étant donné que je fais tourner de tout et de rien sur Apache : du php, des cgi, du Ruby on Rails et du Django, l'opération s'avère un poil complexe, et je vais essayer de présenter petit à petit les solutions retenues pour servir chacune de ces technologies avec Nginx, en commençant par les applications Ruby on Rails.

Unicorn

Avec Apache, pour faire tourner mon application Ruby on Rails (Redmine) j'utilisais Passenger/mod_rails, parce qu'après moults recherches c'est la solution que j'avais trouvé. Le passage à Nginx m'a permis de me pencher à nouveau sur ce problème et j'ai décidé de me tourner vers Unicorn[1].

Pour installer unicorn le plus simple est de passer par l'outil de gestionnaire de packages Ruby gem :

# gem install unicorn

Afin de servir vos projets Rails, il faut lancer un processus Unicorn par projet, en spécifiant les options nécessaires. Le plus simple pour spécifier ces options est de créer un fichier de configuration pour Unicorn directement dans chaque projet Rails. Ce fichier doit être nommé unicorn.rb et situé dans le répertoire config du RAILS_ROOT c'est-à-dire du répertoire racine de votre projet.

Voici un exemple de fichier sur lequel vous pouvez vous baser pour créer votre propre configuration.

# configuration file for Unicorn (not Rack)
#
# See http://unicorn.bogomips.org/Unicorn/Configurator.html for complete
# documentation.

# Use at least one worker per core if you're on a dedicated server,
# more will usually help for _short_ waits on databases/caches.
worker_processes 2

# Help ensure your application will always spawn in the symlinked
# "current" directory that Capistrano sets up.
working_directory "/opt/redmine" # available in 0.94.0+

# listen on both a Unix domain socket and a TCP port,
# we use a shorter backlog for quicker failover when busy
listen "/var/run/unicorn/redmine.sock", :backlog => 64
#listen 8080, :tcp_nopush => true

# nuke workers after 30 seconds instead of 60 seconds (the default)
timeout 30

# feel free to point this anywhere accessible on the filesystem
pid "/var/run/unicorn/redmine.pid"

# some applications/frameworks log to stderr or stdout, so prevent
# them from going to /dev/null when daemonized here:
stderr_path "/opt/redmine/log/unicorn.stderr.log"
stdout_path "/opt/redmine/log/unicorn.stdout.log"

# combine REE with "preload_app true" for memory savings
# http://rubyenterpriseedition.com/faq.html#adapt_apps_for_cow
preload_app true
GC.respond_to?(:copy_on_write_friendly=) and
  GC.copy_on_write_friendly = true

before_fork do |server, worker|
  # the following is highly recomended for Rails + "preload_app true"
  # as there's no need for the master process to hold a connection
  defined?(ActiveRecord::Base) and
    ActiveRecord::Base.connection.disconnect!

  # The following is only recommended for memory/DB-constrained
  # installations.  It is not needed if your system can house
  # twice as many worker_processes as you have configured.
  #
  # # This allows a new master process to incrementally
  # # phase out the old master process with SIGTTOU to avoid a
  # # thundering herd (especially in the "preload_app false" case)
  # # when doing a transparent upgrade.  The last worker spawned
  # # will then kill off the old master process with a SIGQUIT.
  # old_pid = "#{server.config[:pid]}.oldbin"
  # if old_pid != server.pid
  #   begin
  #     sig = (worker.nr + 1) >= server.worker_processes ? :QUIT : :TTOU
  #     Process.kill(sig, File.read(old_pid).to_i)
  #   rescue Errno::ENOENT, Errno::ESRCH
  #   end
  # end
  #
  # # *optionally* throttle the master from forking too quickly by sleeping
  # sleep 1
end

after_fork do |server, worker|
  # per-process listener ports for debugging/admin/migrations
  # addr = "127.0.0.1:#{9293 + worker.nr}"
  # server.listen(addr, :tries => -1, :delay => 5, :tcp_nopush => true)

  # the following is *required* for Rails + "preload_app true",
  defined?(ActiveRecord::Base) and
    ActiveRecord::Base.establish_connection

  # if preload_app is true, then you may also want to check and
  # restart any other shared sockets/descriptors such as Memcached,
  # and Redis.  TokyoCabinet file handles are safe to reuse
  # between any number of forked children (assuming your kernel
  # correctly implements pread()/pwrite() system calls)
end

Éditez les premières variables pour correspondre à votre configuration : nombre de processus au démarrage, répertoire de travail, écoute sur un socket ou un port TCP/IP, emplacement du fichier pid et des logs de capture de stdout et stderr.

Vous pouvez alors vous mettre dans le répertoire en question et lancer Unicorn comme suit :

/opt/redmine$ unicorn_rails  -c config/unicorn.rb -E production -D

Je n'ai malheureusement pas trouvé comment spécifier l'environnement à utiliser (le RAILS_ENV, ici production) autrement que dans la ligne de commande : l'indiquer dans le fichier de configuration ne marche pas... mais le premier qui trouve/sais merci de laisser un commentaire !

Tout ça c'est bien sympa mais ce n'est pas pratique de devoir lancer à la main chacun des processus unicorn nécessaire ni de devoir les relancer à la main si le serveur redémarre.

Pour pallier à ce problème, il faut créer un script de démarrage de Unicorn. Vu que ma Debian utilise un init à la Système V j'ai préféré créer un script pour ce système plutôt qu'utiliser un autre outil pour cela. Celui que j'utilise est adapté de ce site. Il suffit de vérifier que la partie des variables (notamment le RAILS_ENV, USER, DAEMON) correspond à votre configuration.

#!/bin/sh 

### BEGIN INIT INFO
# Provides:       unicorn
# Required-Start: $local_fs $syslog
# Required-Stop:  $local_fs $syslog
# Default-Start:  2 3 4 5
# Default-Stop:   0 1 6
# Short-Description: Unicorn processes
### END INIT INFO

RAILS_ENV="production"
USER=www-data
DAEMON="/var/lib/gems/1.8/bin/unicorn_rails"

NAME="unicorn"
CONFDIR=/etc/unicorn/sites
PIDDIR=/var/run/unicorn
CONFFILE=config/unicorn.rb
RETVAL=0

OPTIONS="-c $CONFFILE -D -E $RAILS_ENV"
# source function library
. /lib/lsb/init-functions

# pull in default settings
[ -f /etc/default/unicorn ] && . /etc/default/unicorn

test -x $DAEMON || exit 0

start()
{
    echo $"Starting $NAME."
    cd $CONFDIR;
    for d in *; do
        echo -n $d;
        cd $d;
        PIDFILE=$PIDDIR/$d.pid
        [ -f $PIDFILE ] && echo ": already started!"
        [ ! -f $PIDFILE ] && su -c "$DAEMON $OPTIONS" $USER && echo ": OK";
    done
    echo "done"
}

stop()
{
    echo $"Stopping $NAME:"
    cd $CONFDIR
    for d in *; do
        echo -n $d;
        if [ -f $PIDDIR/$d.pid ]
        then kill -QUIT `cat $PIDDIR/$d.pid` && echo ": OK" || echo ": failed";
        fi
    done
    echo "done"
}

reload()
{
    echo $"Reloading $NAME:"
    cd $CONFDIR
    for d in *; do
        echo -n $d;
        if [ -f $PIDDIR/$d.pid ]
        then kill -USR2 `cat $PIDDIR/$d.pid` && echo ": OK" || echo ": failed";
        fi
    done
    echo "done"
}

case "$1" in
    start)
        start
        ;;
    stop)
        stop
        ;;
    restart)
        reload
        ;;
    reload)
        reload
        ;;
    force-reload)
        stop && start
        ;;
    *)
        echo $"Usage: $0 {start|stop|restart}"
        RETVAL=1Unicorn se lance en utilisant des sockets mais peut également utiliser TCP/IP.
esac
exit $RETVAL

Ce script est orienté Debian, et devra probablement être adapté pour d'autres distributions.

Pour le faire tourner il vous faut :

  • un répertoire /etc/unicorn/sites dans lequel vous mettez des liens symboliques vers vos projets Rails (le RAILS_ROOT plus exactement de chacun)
  • dans chacun des RAILS_ROOT de vos projets un fichier config/unicorn.rb comme indiqué au-dessus

Nginx

Ensuite pour utiliser Unicorn depuis Nginx, il vous suffit d'avoir une déclaration de virtualhost du type :


upstream redmine_domain_tld {
    server      unix:/var/run/unicorn/redmine.sock fail_timeout=0;
}

server {
    listen      80;
    server_name redmine.domain.tld;

    access_log  /var/log/nginx/redmine.domain.tld.access.log;
    error_log   /var/log/nginx/redmine.domain.tld.error.log;

    location /images {
        root    /opt/redmine/public/images;
    }

    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_redirect off;       

        if (!-f $request_filename) {
            proxy_pass http://redmine_domain_tld;
            break;
        }
    }
}

Et voilà. La suite de ma migration de Apache vers Nginx dans un prochain épisode.

Notes

[1] merci à Olivier Meunier de m'avoir rappeler l'existence de ce soft... auquel j'aurais dû penser tout de suite en connaissant gunicorn

mardi, avril 29 2008

news sécurité informatique (ou Vos Données Chiffrées Ne Sont Pas Aussi Sûres Que Vous Ne Le Pensiez)

Un petit récapitulatif des nouvelles concernant la sécurité informatique intéressantes vues (plus ou moins) récemment sur la toile.

  • Tout d'abord, une news très importante : la découverte que vos disques durs chiffrés ne sont pas aussi sûrs que vous (et moi !) ne le pensiez. En effet, une étude a démontré que la clé d'un disque dur chiffré reste encore quelques minutes dans la RAM après l'extinction d'un ordinateur, rendant celui-ci vulnérable. Cette nouvelle a fait le tour du web sécurité et voici donc quelques liens pour approfondir le sujet :
  • un article original expliquant comment l'OLPC pourrait être détourné de son but premier (l'utilisation par des enfants) et utilisé à des fins militaires;
  • d'autres informations importantes si vous voyagez aux USA : il semble que les douanes puissent nous seulement vous demander de sortir votre ordinateur portable, de l'ouvrir et de l'allumer mais également de leur laisser accéder aux données voire de leur donner le mot de passe ou clé de chiffrement : c'est également chez Bruce Schneier. (pour d'autres infos concernant les douanes US sur le même blog, voyez ici et );
  • tiens, le magazine Wired nous fait un howto pour passer plus facilement les check-in d'aéroport, ça tombe bien...
  • Un article très intéressant de Bruce Schneier sur wired.com concernant le respect de la vie privée ('privacy') et la surveillance généralisée. Il nous explique que l'éternel argument opposé aux réfractaires/résistants à la surveillance généralisée est celui de la surveillance mutuelle : vous savez ce que je fais, et moi je sais ce que vous faites. Malgré le fait que cette situation n'est pas idéale, elle semble tenir la route. Mais malheureusement, l'équilibre est rompu par un autre aspect, celui du pouvoir. En effet, par exemple, lorsqu'un officier de police vous demande vos papiers d'identité, même si il vous donne les siens, son pouvoir est considérablement supérieur au vôtre puisqu'il peut lui avec les informations chercher dans les bases de données de la police des informations sur vous, chose que vous ne pouvez faire. Je vous laisse lire l'article pour la suite de l'argumentation;
  • Francis Pisani nous parle également des policiers via la présentation d'un site pour noter ceux de Los Angeles;
  • un article en anglais expliquant comment protéger sa vie privée sur internet. Il est notamment destiné aux personnes risquant leur vie pour défendre leurs opinions mais certaines informations sont intéressantes pour tous [via grepgrrl.org];
  • un billet concernant Tor nous rappelant que l'anonymat et la protection de la vie privée ('privacy'), ce n'est pas tout à fait la même chose même si les deux concepts sont liés;

des articles un peu plus techniques :

lundi, mars 24 2008

migration Sarge -> Etch (OCSInventory-NG)

Comme c'est le calme plat en ce moment sur ce blog[1], je vais suivre l'exemple de Grégory Colpart et retranscrire ici une migration Sarge -> Etch[2].

Le serveur en question est un serveur dédié au logiciel libre d'inventaire OCSInventory-NG, c'est donc tout simplement une combinaison de serveur web Apache, de serveur de base de données MySQL, de PHP et de Perl. La vraie particularité (et seule ?) de ce serveur est celle d'être un serveur virtuel Xen.

Une fois le fichier /etc/apt/sources.list édité pour y ajouter les sources de etch, un

# aptitude update
# aptitude dist-upgrade

a suffi pour lancer la migration.

Quelques petits problèmes se sont néanmoins présentés :

  • Apache ne voulait pas se lancer et j'avais une erreur
[Tue Mar 18 11:40:40 2008] [error] Can't locate Apache/compat.pm in @INC.....
[Tue Mar 18 11:40:40 2008] [error] Can't load Perl module Apache::Ocsinventory for server...

dans mes logs Apache. Il faut alors éditer le fichier de configuration OCS pour Apache (/etc/apache2/conf.d/ocsinventory.conf chez moi) et modifier la ligne

PerlSetEnv OCS_MODPERL_VERSION 2

Explication : la migration m'a fait passé de apache à apache2 et de libapache-mod-perl (version 1.x) à libapache2-mod-perl2 (version 2.x)

  • j'ai eu quelques problèmes avec MySQL qui ne voulait pas redémarrer, j'en ai donc profité pour migrer de mysql-server-4.1 à mysql-server-5.0 sans problème (à part que le serveur phpmyadmin permettant de gérer les divers serveurs mysql n'a pas le paquet mysql-client-5.0... pour l'instant)
  • je suis également passé de php4 à php5 sans problème non plus.

Rien de particulier donc. J'ai fait rebooter mon serveur virtuel au cas où, et j'avais, par sécurité, fait une copie de mon serveur virtuel (stocké sur LVM) avant la migration pour le cas où celle-ci se passerait mal. Au final, moins de 2h de maintenance, et moins d'une 1/2 heure - 1 heure je pense, pour ce serveur.

Notes

[1] en partie à cause d'un déménagement qui a entrainé une coupure internet mais pas seulement...

[2] migration non initialement prévue mais, afin de pouvoir utiliser un petit script de ma composition (ocs-ipinterface), j'avais besoin du paquet python-ipy non disponible sur sarge

mercredi, janvier 9 2008

utiliser apt-cacher pour les mises à jour de vos machines Debian

Que ce soit à la maison ou au travail, quand on commence à avoir beaucoup de machines Debian, se pose le problème de leurs mises à jour et surtout de la bande passante utilisée pour celles-ci.

Au niveau Debian, plusieurs solutions existent, comme utiliser un proxy web classique (Squid par exemple), partager le répertoire contenant les fichiers téléchargés (ce qui peut être un peu risqué), répliquer complètement l'arborescence Debian (mais ça demande à télécharger des paquets dont probablement on ne se servira jamais) ou bien encore utiliser un outil dédié à ce problème.
Plusieurs existent : apt-proxy, approx, apt-cacher.

Il semble que de ces différentes solutions aucune ne ressorte vraiment, et que des problèmes existent sur chacune d'elle. En tout cas, ici, je vais vous présenter apt-cacher.

côté serveur

L'installation est, comme d'habitude, facile sous Debian, il vous suffit de faire un

# aptitude install apt-cacher

Ensuite, un petit tour du côté de /etc/apt-cacher/apt-cacher.conf nous permet de configurer l'application, notamment le port d'écoute, le répertoire cache, les hôtes autorisés. En général, les paramètres par défaut sont corrects, je n'ai eu besoin de modifier que les paramètres pour utiliser un proxy :

http_proxy=votreproxy.lan.domain.tld:8080
use_proxy=1

Ensuite, pour permettre le lancement automatique de l'application, il faut modifier /etc/default/apt-cacher

AUTOSTART=1

Il suffit ensuite de vérifier que vos paramètres dans /etc/apt/sources.list sont bons. Il faut par exemple que toutes les distributions pouvant être utilisées par les clients soient listées.

côté client

Il suffit, sur chaque client amené à utiliser le proxy apt, de modifier /etc/apt/sources.list pour avoir au lieu de

deb http://ftp2.fr.debian.org/debian/ etch main
deb http://security.debian.org/ etch/updates main

quelque chose comme ceci pour pointer vers votre serveur apt-cacher et son port associé (3142 par défaut)

deb http://apt-cacher:3142/ftp2.fr.debian.org/debian/ etch main
deb http://apt-cacher:3142/security.debian.org/ etch/updates main

Remarquez que l'on indique à apt-cacher le miroir Debian que l'on veut utiliser, donc, afin de profiter vraiment de apt-cacher, il faut veiller à ce que tous les clients utilisent le même.[1]

Pour faire la modification facilement, je vous propose une petite ligne de commande sed :

# sed -i -e 's!http://!http://apt-proxy:3142/!g' /etc/apt/sources.list

Pensez à vérifier que les paramètres de proxy apt sont bons, c'est-à-dire en général qu'il n'y a pas de proxy indiqué dans /etc/apt/apt.conf ou dans le répertoire /etc/apt/apt.conf.d/[2].

Notes

[1] Si vraiment, vous avez beaucoup de clients, et que faire la modification sur chacun devient très compliqué, je vous encourage alors à aller voir du côté de Puppet ou Cfengine. Vous pouvez trouver des informations complémentaires sur debian-administration.

[2] par exemple, xen-tools écrit un fichier proxy-guess dans ce répertoire avec les paramètres proxy de l'hôte Xen dom0

vendredi, septembre 28 2007

réinstallation de GRUB sur le MBR avec un système sur LVM chiffré

Après réinstallation de Windows XP sur mon portable professionnel, je me retrouve comme d'habitude à chercher les commandes dont j'ai besoin pour réinstaller GRUB sur le MBR qu'a écrasé Windows et qui m'empêche d'avoir accès à Linux. Voici donc un petit mémo.

J'utilise le live-cd System Rescue CD pour ce faire. Je démarre dessus.

Une fois que j'ai accès au prompt, je déchiffre ma partition chiffrée (ici /dev/hda3) contenant mon LVM.

root@sysresccd /root % /sbin/cryptsetup luksOpen /dev/hda3 hda3_decrypt

Je rescanne les LVM et active les nouveaux volumes découverts

root@sysresccd /root % vgscan
root@sysresccd /root % vgchange -a y

Je crée ensuite un répertoire temporaire où je monte mon / et mon /boot et tous les autres partitions pouvant être nécessaires (/usr est le minimum pour avoir accès à l'exécutable grub)

root@sysresccd /root % cd /tmp
root@sysresccd /tmp % mkdir root
root@sysresccd /tmp % mount /dev/data-root root
root@sysresccd /tmp % mount /dev/hda2 root/boot
root@sysresccd /tmp % mount /dev/data-usr root/usr
root@sysresccd /tmp % mount /dev/data-var root/var

Il suffit ensuite de faire un chroot sur le système Debian et de lancer la réinstallation de GRUB

root@sysresccd /tmp % chroot /tmp/root /bin/bash
sysresccd:/# /usr/sbin/grub
grub> root (hd0,1)
grub> setup (hd0)
...
grub> quit
sysresccd:/# exit

Et voilà, je peux redémarrer et retrouver le menu me permettant d'avoir accès à Debian.

mercredi, septembre 26 2007

faire tourner Windows sur Xen

Pour une raison ou pour une autre[1] vous pouvez avoir envie (?) ou besoin de faire tourner un Windows sous votre Linux. Heureusement, depuis peu Xen couplé à un processeur récent le permet.

Installation de Windows 2000 sur Xen (vue dans un bureau Gnome)

prérequis

  • un processeur HVM : vous pouvez vérifier ici si le vôtre l'est
  • un poste/serveur Linux Debian Etch minimum[2] avec Xen fonctionnel
  • un CDROM d'installation de Windows (je n'ai testé qu'avec Windows 2000 mais XP et 2003 Server semblent fonctionner également)
  • des petits doigts :) et ce billet

procédure
Pour utiliser les nouvelles fonctionnalités des processeurs virtualisants et donc pouvoir installer Windows[3] il vous faut installer un package spécial qui fournit les outils utilisateurs

# aptitude install xen-ioemu-3.0.3-1

On copie ensuite le cdrom sur le disque dur

# dd if=/dev/cdrom of=/tmp/win2000pro.iso

On crée un fichier image vide appelé à contenir le système invité (6Go ici)

# dd if=/dev/zero of=Win2k.img bs=1M count=6144

On crée le fichier de configuration Xen /etc/xen/win2000.cfg pour Windows. Voici le mien, adaptez-le à votre configuration

# more /etc/xen/win2k.cfg
kernel = "/usr/lib/xen-default/boot/hvmloader"
builder='hvm'
memory = '256'
name = 'Win2000'
disk = [ 'file:/mnt/media/data/xen/domains/win2k/win2k.img,ioemu:hda,w','file:/tmp/win2000pro.iso,ioemu:hdc:cdrom,r' ]
vif = [ 'type=ioemu, bridge=xenbr0' ]
device_model = '/usr/lib/xen-default/bin/qemu-dm'
memmap = '/usr/lib/xen/boot/mem-map.sxp'
boot='d'
sdl=1
vnc=0

Les directives spécifiques à un hôte HVM sont kernel, builder, device_model et memmap.
Dans la partie disk il vous faut spécifier l'image ISO pour l'installation, vous pouvez ensuite connecter votre lecteur de cd-rom en remplaçant la ligne par disk = 'file:/mnt/media/data/system/xen/do....
La directive boot indique 'd' pour booter sur le cd-rom et 'c' pour booter sur le disque dur virtuel.
sdl=1 permet, si vous êtes sous X, d'avoir une fenêtre qui s'ouvre automatiquement quand vous lancez la machine virtuelle ce qui est au moins nécessaire lors de l'installation. Vous pouvez ensuite utiliser le mode de prise à distance que vous préférez. (mise à jour : si vous voulez utilisez VNC, changez sdl=0 vnc=1 et connectez-vous avec vncviewer sur localhost:5900)

Et voilà, un petit

# xm create /etc/xen/win2000.cfg

et c'est parti !

divers
Pour pouvoir monter le fichier image Windows que vous avez un bête mount -o loop ne suffit pas, voici la commande qui va bien

# mount -o loop,offset=$((63*512)),rw /mnt/media/data/system/xen/domains/win2k/win2k.img temp/

J'ai vu également que Russell Coker a écrit un billet intitulé A support guide [for|to] Xen avec un résumé des principales commandes utiles pour Xen.

Au fait, je fais tourner un Windows 32 bits sur ma Debian en 64 bits.

copies d'écrans
Quelques screenshots pour le plaisir

Installation de Windows 2000 sur Xen

Installation de Windows 2000 sur Xen (premier login)

Installation de Windows 2000 sur Xen (le fameux "Démarrer avec Windows 2000")

PS : je suis depuis peu syndiqué sur le planète des utilisateurs francophones de Debian, planète libre et peut-être même planète APRIL alors :

PS2 : dès vendredi 1er octobre, une nouvelle taxe[4] "copie privée" arrive sur les disques durs externes et les clés USB, alors si vous aviez un achat en tête, précipitez-vous !

Notes

[1] la mienne, c'est d'espérer pouvoir enfin rejouer à SimCity 4 Rush Hour que malheureusement je n'arrive pas à faire tourner avec Wine

[2] à vrai dire n'importe quelle distribution est valable bien évidemment mais je me base sur celle-ci

[3] en fait n'importe quel OS non modifié comme par exemple OpenBSD ou NetBSD (cf)

[4] qui a dit encore une ? qu'il se dénonce !

mardi, septembre 11 2007

Flash sous Debian 64 bits

Depuis que j'ai un nouveau PC qui tourne sous 64 bits, mon gros problème était d'arriver à utiliser Flash sous Mozilla et Firefox. En effet, Flash est une technologie propriétaire[1] et Adobe ne propose pas de version 64 bits. Plusieurs solutions existent néanmoins pour réussir à le faire mais elle sont toutes assez compliquées comme avoir un chroot 32 bits pour faire tourner les applications 32 bits[2]. Heureusement, depuis peu existe un utilitaire appelé nspluginwrapper permettant d'utiliser des plugins sur une plateforme pour laquelle ils ne sont pas conçus, comme par exemple des plugins 32 bits sur une plateforme 64 bits qui est ce qui nous intéresse.

J'ai commencé par suivre une doc Ubuntu qui m'a permis d'avoir Flash sous Mozilla Seamonkey/Iceape mais malheureusement ça ne marchait pas pour Firefox/Iceweasel.

Heureusement cet utilitaire est arrivé dans Debian testing, et, comme depuis peu j'ai un pied dans testing/lenny[3] j'ai alors pu l'installer tout simplement avec

# aptitude install nspluginwrapper

et là, magie ! Iceape et Iceweasel supportent le Flash... :)

update : j'ai oublié de vous dire pourquoi Flash ça pue

Notes

[1] vive les logiciels libres !

[2] cf http://debian-administration.org pour des articles traitant du problème

[3] principalement pour avoir une version de Digikam supérieure à 0.9.2 qui gère les fichiers RAW

jeudi, août 30 2007

ssh : supprimer une entrée du fichier known_hosts

pour ne pas rechercher sans fin cette astuce quand j'en ai besoin...

Sous Debian, quand on se connecte à un serveur ssh, avec les options par défaut, il y a une vérification de la signature de la clé du serveur. Ces signatures sont enregistrés dans le fichier ~/.ssh/known_hosts et lorsqu'on se connecte à un serveur auquel on s'est déjà connecté, le client vérifie si la clé du serveur n'a pas changé, cela afin d'éviter des problèmes de sécurité (connexion à un serveur usurpateur).
Le problème se pose lorsqu'on sait que la clé a changé, par exemple si c'est un serveur qu'on gère et qu'on vient de le réinstaller, et que le client ssh n'arrête pas de se plaindre que la clé est mauvaise et ne veut à aucun prix s'y connecter. Dans ce cas, il faut éditer le fichier et enlever l'entrée correspondante qui pose problème... hum... malheureusement, maintenant c'est difficile à faire le fichier étant hashé. La commande magique c'est donc

ssh-keygen -R <nom_du serveur_SSH>

[vu sur linuxfr]

samedi, juillet 28 2007

le son sur la M2N

Je continue ma bataille pour tout faire marcher sur ma carte mère ASUStek M2N, et j'aborde maintenant le son. Sur Debian Etch par défaut, avec le noyau 2.6.18-adm64 (qu'il soit Xen ou pas) celui-ci ne marche pas, le driver ne semblant pas se charger correctement. Si vous faites un

# alsaconf

il ne vous détecte aucune carte son.

Il nous faut récupérer les drivers ALSA plus récents que ceux disponibles sur Etch.

Tout d'abord on désinstalle/purge[1] tous les paquets alsa déjà installés[2] Ensuite on installe les paquets qui nous seront nécessaires

# aptitude install alsa-utils alsa-base build-essential linux-headers-`uname -r`

On récupère les derniers drivers

# wget ftp://ftp.alsa-project.org/pub/driver/alsa-driver-1.0.14.tar.bz2

Puis on les compile et installe

# tar xvjf alsa-driver-1.0.14.tar.bz2
# ./configure --with-oss=yes --with-cards=hda-intel 
# make
# make install

On met à jour la liste des modules

# update-modules

Et enfin on détecte la carte son

# alsaconf 

[vu sur]

On peut ensuite vérifier que tout fonctionne bien en utilisant par exemple les commandes indiquées sur le forum Trucs & Astuces de debian-fr.org ici.

oups, j'ai oublié d'indiquer l'essentiel : les identifiants de ma carte son

# lspci |grep -i audio
00:05.0 Audio device: nVidia Corporation MCP61 High Definition Audio (rev a2) 
# for i in `lspci | grep [aA]udio | sed "s/ .*$//"`; do echo `lspci -n | grep $i` ; done
00:05.0 0403: 10de:03f0 (rev a2)

Notes

[1] # aptitude purge <paquet>

[2] on les trouve avec dpkg -l | grep alsa

Xen sur une ASUStek M2N

Je suis actuellement en phase "installation système" sur mon nouveau pc construit autour d'une carte mère ASUStek M2N basée sur un chipset nVidia nForce 430. Malheureusement, Xen n'a pas marché direct, et, m'étant un peu arraché les cheveux pour le faire fonctionner, je poste ici les informations importantes contenues dans le fichier /boot/grub/menu.lst[1] afin de faire fonctionner le kernel 2.6.18-4-xen-amd64 :

title Xen 3.0.3-1-amd64 / Debian GNU/Linux, kernel 2.6.18-4-xen-amd64
root (hd0,0)
kernel /xen-3.0.3-1-amd64.gz noapic
module /vmlinuz-2.6.18-4-xen-amd64 root=/dev/mapper/vg--root-lv--root ro acpi=off noapic nolapic console=tty0
module /initrd.img-2.6.18-4-xen-amd64
savedefault

Notes

[1] les parties importantes sont les mentions 'noapic', 'acpi=off', 'nolapic'

jeudi, juillet 12 2007

faire du NAT avec Xen

Si vous ne disposez que d'une adresse publique et que vous voulez héberger plusieurs serveurs virtuels sous Xen, vous êtes obligé de passer par du NAT et dans ce cas voici comment configurer votre hôte dom0 Xen pour que ça marche.

Tout d'abord il faut modifier le fichier /etc/xen/xend-config.sxp pour y indiquer

(network-script network-nat)
(vif-script vif-nat)

Ensuite, pour Debian, un simple script ajouté au répertoire /etc/network/if-up.d[1] et nommé iptables[2] par exemple, fournit les règles pour le pare-feu iptables pour effectuer la translation d'adresse :

#!/bin/sh

echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -j MASQUERADE

Si ensuite vous voulez faire de la redirection de ports (ou port forwarding) il faut alors rajouter à ce fichier une règle du genre

iptables -A PREROUTING -t nat -p tcp -i eth0 --dport 80 -j DNAT --to 192.168.3.2:80

en spécifiant correctement les ports et adresses qui correspondent à votre configuration.

Bien évidemment, ce morceau de script pour configurer le pare-feu ne suffit pas pour assurer la sécurité de vos machines Xen (dom0 et domU)

Notes

[1] le fait de placer ce fichier dans ce répertoire permet qu'il soit lancé à chaque fois que le réseau est lancé

[2] n'oubliez pas de le rendre exécutable avec un chmod u+x iptables

dimanche, juillet 8 2007

chiffrement de disque dur... la suite

Je vous parlais l'autre jour de la sécurité qu'apporte un chiffrement complet de disque dur. Mais malheureusement, actuellement, sous Linux, vous êtes obligé de garder une partie non chiffrée qui est /boot, et l'intégrité de celle-ci devient essentielle pour assurer la sécurité de l'ensemble des données. On trouve justement sur ce billet un rapide howto sur les modifications à faire sur votre système Debian pour le faire booter sur un cdrom contenant le kernel et tout ce qui va bien tiré de /boot.

non testé

samedi, juin 9 2007

sécurité informatique

Une série de billets (datant de fin 2006 mais bien évidemment toujours d'actualité) de Russell Cooker concernant la sécurité informatique (des données surtout) en environnement professionnel (les commentaires sont à lire également) :

les commentaires m'ont renvoyé vers des sites comme :

Le principe du chiffrement de disque dur est aujourd'hui un moyen simple et efficace de protéger des données pouvant être volées (sur des ordinateurs portables bien sûr mais également sur des postes fixes). Heureusement aujourd'hui les plus grandes distributions Linux le supportent nativement, et c'est bien sûr le cas de Debian. Si vous devez donc en installer une, je vous conseille d'activer le chiffrement du disque dur. C'est ce que j'ai fait pour mon portable en suivant le petit guide disponible sur le blog de Uwe Hermann.

lundi, avril 9 2007

Debian Etch 4.0 est sortie

Ça y est, c'est fait, la nouvelle Debian, la version 4.0 : Etch, est sortie.

Plus d'infos

Yeah! Et merci à toute l'équipe Debian ainsi qu'à tous ceux qui ont aidé.

dimanche, février 25 2007

insertion d'une clé usb chiffrée sous Debian Etch

Aujourd'hui en faisant du tri, je suis tombé sur une clé usb oubliée. Après l'avoir insérée, quelle ne fût pas ma surprise de me retrouver avec cette boîte de dialogue

Luks clé USB information - Debian Etch - 25 II 2007

je m'exécute donc

# aptitude install cryptsetup

et après rebranchement de la clé j'ai droit au pop-up m'invitant à entrer ma "phrase de passe"[1]

Luks clé USB passphrase - Debian Etch - 25 II 2007

malheureusement je ne m'en souviens pas[2] et je me retrouve à devoir "tuer" la fenêtre avec xkill[3]...

En tout cas, content de voir que la cryptographie entre dans les environnements graphiques ce qui devrait permettre de la diffuser et de faciliter son usage.

On en parlait déjà il y a un an [via][4]

Notes

[1] passphrase...

[2] j'avais dû utiliser cette clé pour créer une clé usb bootable chiffrée sous Debian en suivant un guide sur debian-administration.org que je ne retrouve pas...

[3] Alt-F2 sous Gnome pour lancer une commande, xkill Entrée

[4] à l'époque déjà il me semble

mercredi, février 7 2007

nouveaux usages de la 3D

Traditionnellement utilisée pour des applications industrielles comme la modélisation d'objets (voitures, théières...) la 3D commence à se répandre dans nos ordinateurs. On la retrouve dans des situations somme toutes assez naturelles, comme la représentation géographique[1] ou l'animation de personnages. Mais on commence également à nous la servir à toutes les sauces[2] sans que des usages vraiment novateurs semblent apparaître.

Heureusement, voici deux exemples qui contredisent cette impression en représentant des données abstraites de façon plus ergonomique ou originale :

  • ce projet propose par exemple de représenter les résultats de recherches internet sous une forme 3D avec des avatars stylisés permettant d'accélérer le tri parmi les résultats ;
  • Visitorville représente quant à lui les statistiques de votre serveur web sous un aspect 3D avec des buildings pour représenter les pages web, des véhicules pour représenter les interconnexions....

[via]

PS : si vous êtes (néanmoins) intéressés par les nouveautés 3D de Linux, je vous conseille de regarder cet article avec des images assez impressionnantes de Beryl en action (et qui fait passer MacOS X et Vista pour des dinosaures, dixit l'auteur), et ce tutoriel pour installer Beryl sur Debian. [via]

Notes

[1] comme chez Google Earth ou l'IGN

[2] tous les systèmes d'exploitation nouvelle génération s'enorgueillissent de disposer de fonctionnalités 3D... même si personne ne sait encore à quoi ça sert... :)

lundi, janvier 29 2007

installer Debian depuis Windows

C'est magique ! Vous pouvez maintenant découvrir Debian sans même graver un CD !

Installation de Debian sous Windows

C'est ici, annoncé et lu là-bas. Encore une fois merci aux développeurs Debian :)

mardi, décembre 19 2006

c'est l'hiver, Debian gèle

eh oui ! j'avais presque loupé l'info, mais Debian freeze et ça c'est une grande nouvelle !

[via]

Firefox^WIceweasel 2 est sorti...

Comme vous le savez sûrement[1] Mozilla Firefox 2.0 est sorti. Je vous passe la liste des nouveautés, vous renvoyant plutôt vers la page officielle, néanmoins en voici quelques-unes que j'ai remarqué plus particulièrement :

  • Firefox possède maintenant un restaurateur de session. Quand vous fermez celui-ci avec des onglets ouverts, il vous les rouvrira au prochain lancement (paramétrable dans les préférences) :
  • la gestion des flux RSS est améliorée puisque vous pouvez avoir un aperçu avant de l'insérer dans le gestionnaire interne de Firefox ou l'envoyer vers une application sur votre ordinateur ou même un service en ligne ;
  • Firefox possède maintenant un détecteur de phishing ;
  • la possibilité d'annuler la la fermeture d'un onglet (bouton droit sur un onglet) est une fonctionnalité très intéressante.

Plus d'infos sur les choix faits sur l'ergonomie des onglets

J'en ai profité pour faire le tour du site dédié aux extensions et thèmes des produits Mozilla pour découvrir les dernières (extensions) indispensables, dont beaucoup liées à la sécurité ou la protection de la vie privée ('privacy'), en voici quelques unes :

  • CookieSafe est l'extension indispendable pour gérer les cookies sous Firefox, offrant (enfin !) une ergonomie comparable à celle de Mozilla Suite/Seamonkey ;
  • NoScript vous offre une protection accrue en désactivant par défaut Javascript et vous permettant de l'activer que pour certains domaines de confiance ;
  • Flashblock pour désactiver les animations flash qui polluent les pages web (pubs principalement, entêtes...) et les réactiver ponctuellement ;
  • SafeHistory et SafeCache pour des protections supplémentaires quand vous surfez ;
  • CFG.Search est l'extension indispensable si vous utilisez Gmail ou tout autre service Google mais que vous ne voulez pas laisser des cookies à chaque recherche... je ne l'ai pas encore testée, mais elle semble très intéressante ;
  • Foxtor pour facilement basculer entre utilisation de Tor ou pas ;
  • Stealther pour temporairement désactiver TOUT (cache, historique, cookies, referer...) et Distrust pour la même chose ;
  • et bien sûr l'extension pour Beagle.

Sinon, à côté de ça, sachez que sur Debian (et donc potentiellement toutes les dérivées, telle Ubuntu) Firefox, Thunderbird et Mozilla Suite/Seamonkey ont été remplacées par respectivement IceWeasel, IceDove et IceApe. Sans entrer dans les détails et encore moins sur la polémique que l'on a vu fleurir sur les blogs des divers "camps", sachez que ces "forks" sont dûs à des problèmes de copyright de la Fondation Mozilla sur ses produits. Ces copyrights interdisent de distribuer ces logiciels avec leur nom et les icônes associés si le code source a été modifié... ce qui est une hérésie du point de vue Linux et open source (à quoi sert le code source si on ne peut le modifier ?) et une impossibilité pour Debian (qui corrige les failles de sécurité pendant toute la durée de vie de sa branche stable, celle-ci étant énormément plus longue que le support offert par la MoFo/MoCo[2]). Je vous encourage à parcourir les sites de news et les blogs pour découvrir plus en détail cette affaire si elle vous intéresse, je pense que vous trouverez assez facilement...

[Vous pouvez trouver plus d'infos par ex sur cette page qui semble être celle du mainteneur Debian des paquets Mozilla/GnuZilla/IceLizard]

Notes

[1] vu le retard que je prends au niveau des billets de ce blog... le manque d'internet à la maison n'aidant pas...

[2] Mozilla Foundation/Mozilla Corporation

- page 1 de 3