Archive for the ‘planet-libre’ Category

Un exemple de migration Debian Etch->Lenny [0]

Sunday, April 19th, 2009

Dans la même optique que mes précédents exemples de migration Debian Sarge->Etch ([0], [1], [2] et [3]), je repars sur une série portant sur des migrations Debian Etch->Lenny. Je rappelle rapidement le principe : j’administre une centaine de serveurs pour plusieurs dizaines de sociétés, et la plupart vont être concernés par une migration vers Debian Lenny d’ici un an. Je vais en choisir quelques uns pour illustrer les opérations nécessaires et problèmes recontrés. Et j’incite tout le monde à faire de même afin d’avoir de multiples astuces disponibles sur le web.

Pour ce premier post, la question classique : quand faut-il migrer sa machine vers Debian Lenny ? Tout d’abord, Etch reste maintenu environ un an après la sortie de Lenny, soit jusqu’en février 2010. Il n’y a donc aucune raison d’être pressé à migrer si l’on a pas besoin de nouveaux logiciels. Et surtout, je recommande le principe de précaution, à savoir attendre un certain temps ce qui permettra d’avoir une grande quantité d’informations disponibles sur Internet (ressources Debian, moteurs de recherche, blogs). Enfin, il est important de bien planifier sa migration en fonction du métier de la société (haute/basse saison, vacances, etc.).

Évidemment, les précautions suivantes sont nécessaires : faire des essais de migration sur des serveurs de test, avoir des backups tout frais, couper les services durant la migration et bien prévenir à l’avance tous les utilisateurs et personnes concernées.

Entrons dans le vif du sujet. Au menu, un serveur web situé chez un hébergeur low-cost français. Ce serveur fait parti d’un pool de plusieurs serveurs (load-balancing via du round-robin DNS), donc il faut au préalable le désactiver et attendre que le time-to-live le rende totalement inactif. Ensuite, on reprend les Releases Notes, on modifie le sources.list et on se lance.

On s’assure que les partitions /usr et /tmp ont les bonnes options de montage:

# mount -o remount,rw /usr && mount -o remount,exec /tmp

On lance une mise-à-jour minimale :

# aptitude update && aptitude upgrade

Puis une mise-à-jour complète :

# aptitude dist-upgrade

Rien de bien complexe. Il reste à croiser les doigts pendant les opérations ci-dessus, mais si votre système est « propre », cela se passe très bien, comme souvent sur un système Debian. Il est ensuite important de lire les éventuelles instructions de mise-à-jour situées dans le fichier NEWS d’un paquet (en utilisant apt-listchanges, cela peut être affiché automatiquement).

En ce qui concerne la mise-à-jour du kernel, de mauvaises surprises sont possibles après le redémarrage. Il est notamment recommandé d’avoir un accès à la machine (accès physique, accès « rescue », etc.) pour corriger d’éventuels problèmes. Dans mon cas, l’interface réseau a été renommée de eth0 à eth1 suite à la mise-à-jour d’udev : le fichier  /etc/udev/rules.d/z25_persistent-net.rules se transforme en /etc/udev/rules.d/70-persistent-net.rules, jusqu’ici tout est normal, mais un problème surnaturel semble s’être produit, la carte e1000 (MAC=00:0c:29:65:ae:04) est « devenue » une r8168 (MAC=00:1c:c0:51:12:45) ; au final, c’est plutôt un soucis lié au matériel, enquête en cours chez l’hébergeur low-cost…

Un vrai problème s’est par contre posé avec la mise-à-jour du paquet nginx (un petit serveur web très performant). Suite à sa mise-à-jour, il ne démarre plus :

Starting nginx: 2009/04/19 20:45:26 [emerg] 28783#0: could not build the server_names_hash,
you should increase server_names_hash_bucket_size: 32

Il faut donc ajouter dans la section http {} du fichier nginx.conf :

http {
include       /etc/nginx/mime.types;
default_type  application/octet-stream;

# Necessaire depuis l'upgrade Etch->Lenny
# (ajoute le 19.06.2009 by reg)
server_names_hash_bucket_size 33;
...

Voilà pour ce premier exemple de migration. Il s’agissait d’un serveur « simple » sans installation particulière, donc assez peu de problèmes rencontrés. Les prochains exemples seront certainement un peu plus complexes !

Soirée d’avril au PLUG (Provence Linux User Group)

Wednesday, April 8th, 2009

Une fois n’est pas coutume, voici un petit compte-rendu de la dernière soirée au PLUG, le “Linux User Group” de Marseille. Les soirées se déroulent une fois par mois (souvent le 1er vendredi du mois) à partir de 19h à LaBoate, un endroit très sympatique proche du Vieux Port.

Arrivé un peu en retard, j’ai raté les premières dicussions (anisées), et je suis arrivé pour les traditionnelles pizzas. À cette occasion, certains nous ont rapporté le déroulement de la conférence de Richard Stallman l’après-midi même à Marseille. Ce dernier nous a d’ailleurs proposé de renommer notre LUG (Linux User Group) en GLUG (GNU Linux User Group), condition nécessaire à sa venue à l’une de nos réunions (!). Cette proposition n’a pas fait l’unanimité pour diverses raisons et a finalement été rejetée par les membres présents. D’autres discussions ont suivi, comme l’exploration de Marseille via  Google Maps/StreetView et OpenStreetMap, ou encore la démonstration d’un téléphone portable HTC-Dream tournant sous le fameux système d’exploitation Android.
Ensuite s’est déroulé la première édition des “Lightning Talks du PLUG”, à savoir des petites présentations de quelques minutes sur des sujets/actualités ouvertes à tout volontaire. Françoise Roure nous a tout d’abord parlé d’une Install Party pour les non-voyants en septembre à Marseille. Outre l’appel à la participation, une discussion s’est engagée sur les différents outils libres, notamment Orca ou eSpeak. Ensuite, c’est Jérémy Lecour qui a parlé de l’internationalisation (i18n) de logiciel, et nous a fait part de son expérience récente avec l’internationalisation d’un projet en Ruby on Rails. Un petit débat s’est ouvert sur la terminologie d’internationalisation et de localisation, tandis que d’autres ont découvert les jeux de mot avec I18N et l10N.
Après ces petites présentations, j’ai pu mener une présentation générale sur les gestionnaires de paquets dans les distributions GNU/Linux. J’ai repris les bases, à savoir définir un paquet (code source, binaire, compilation, etc.) et l’intérêt d’un gestionnaire de paquets (installation, dépendance, suppression, mise-à-jour, etc.). Pas mal de questions ont été posées, et l’on aura sûrement l’occasion de faire des présentations sur des gestionnaires de paquets précis (APT, YUM, emerge, ports BSD, etc.) les prochains mois.
La soirée a duré fort tard (jusqu’à 3h pour les plus courageux), et un grand sujet s’est improvisé sur le microblogging. Présentation du principe, des sites en vogue (Twitter, identi.ca), débats sur l’intérêt (Microblog vs IRC !), l’infrastructure d’hébergement nécessaire, et les extensions comme l’amusant twistori. D’autres discussions se sont improvisées, par exemple sur la gestion des tâches via la messagerie et plusieurs personnes ont montré leur fonctionnement (principe du Zero Inbox, exemple avec GMAIL, flags avec Mutt, etc.).

Bref, une soirée riche en discussions comme chaque mois. Le mois prochain (vendredi 1er mai), on abordera en outre le sujet des gestionnaires de code sources (CVS, SVN, Git, etc.). Venez nombreux !

Pirater en toute impunité grâce à la loi HADOPI

Saturday, March 21st, 2009

Je ne vais pas revenir en détail sur la loi HADOPI et les multiples débats à son sujet, vous trouverez de multiples explications sur la toile (Wikipedia, La Quadrature du net, etc.). Je remarque tout de même que la plupart des politiciens s’exprimant à propos d’informatique semblent complètement dépassés par le sujet.

Je ne télécharge pas de musique, pas de film, principalement par… manque de temps. Mais je connais des personnes qui évitent de le faire à cause de la peur du gendarme. En effet, selon certains mythes sur Internet, en téléchargeant illégalement un tube de la Star Académie, on risque de voir débarquer le GIGN à six heures du matin, de voir tout son équipement électroménager broyé et de passer des années dans le quartier haute sécurité d’Alcatraz. Or, la loi HADOPI va signer la fin de ce mythe. La sanction pour les pirates malchanceux sera de recevoir un courrier électronique menaçant d’une coupure de l’accès Internet pendant quelques mois, puis une lettre recommandée. Du coup, si l’on ne reçoit aucune intimidation, on ne risque aucune sanction (les peines issues de la loi DADVSI restent applicables mais c’est uniquement de la théorie, car la loi HAODPI introduit le concept de « riposte graduée »). Cela devient quasiment un « permis de pirater » sans contrepartie ! Au pire, en imaginant subir une coupure d’Internet, la sanction sera partielle car les moyens d’accéder à Internet sont nombreux (accès publics, Wi-Fi des voisins, accès 3G avec les téléphones mobiles, etc.). On est loin de l’intervention policière musclée à son domicile…

Bref, ceci n’est qu’une des incohérences de la loi HADOPI. Il reste à espérer que des alternatives comme la licence globale ou le mécénat global seront étudiées par l’Assemblée Nationale.

Administration d’un serveur NIS sous OpenBSD

Saturday, February 28th, 2009

NIS est un protocole réseau de distribution d’informations système (utilisateurs, groupes, machines, etc.). De plus en plus remplacé par LDAP, il reste encore souvent présent sur des réseaux avec des systèmes hétérogènes.

Un problème assez classique avec NIS est l’administration de la base d’utilisateurs. Déportée dans une base distincte (/var/yp/DOMAINNAME/), on peut :
– la gérer comme une source de données indépendante, mais cela rend assez complexe l’administration, car on ne peut pas vraiment utiliser les outils classiques (commande adduser, détection du max(UID), etc.)
– gérer les utilisateurs/groupes locaux, et générer la base NIS à partir des données locales. Dans ce cas, la problèmatique est de ne pas exporter les utilisateurs/groupes système !

Dans le second cas, il n’existe pas de distinction des utilisateurs/groupes système dans le Makefile.yp distribué par OpenBSD. Heureusement, Antoine Jacoutot a écrit un petit patch pour gérer des MINUID/MINGID/MAXUID/MAXGID : voici le patch.

Ferme ton Bind !

Sunday, February 1st, 2009

Il est important de fermer complètement son Bind, à savoir mettre dans son named.conf :

allow-query { localhost;};
allow-recursion { localhost; };
allow-transfer { none; };

Cela provoque un statut REFUSED pour toutes les requêtes non autorisées. Si refuser les transferts (requêtes AXFR dévoilant toute votre zone) est sage et refuser les requêtes récursives est logique (vous ne voulez pas être serveur DNS pour le monde entier), il faut également refuser toutes les requêtes par défaut afin d’éviter de potentiels dénis de service.

Vous noterez que les directives ci-dessus autorisent les requêtes classiques de la part de localhost dans la mesure où il est fréquent que votre machine se serve de son propre Bind. Si ce n’est pas le cas, mettre toutes les directives à none.

Un moyen simple de vérifier qu’un serveur DNS refuse bien toutes les requêtes :

dig google.fr @<serveur DNS>

Vous ne devez pas obtenir la(les) réponse(s), ni même obtenir la liste des ROOT SERVERS. Vous devez obtenir status: REFUSED (ou alors un timeout…).

J’ai souvent eu du mal à expliquer pourquoi il fallait fermer complètement son Bind, car la menace des attaques DOS restait un peu vague. Ce n’est désormais plus le cas depuis quelques semaines où chaque administrateur d’un Bind assiste (dans ses logs ;-) aux multiples requêtes “. NS IN” générées par des robots/virus :

client 76.9.16.171#39068: query (cache) './NS/IN' denied
client 69.64.87.156#42646: query (cache) './NS/IN' denied

On déplore même des victimes de ces attaques DDOS de grande ampleur, notamment NetworkSolutions qui l’explique sur son blog. Pour contrer cela, on peut refuser les paquets en amont : voici un fameux paquet (format PCAP). On voit donc que l’on peut interdire les paquets comportant une requête DNS récursive (flags = 0x0100). Sur une machine Linux, on peut le faire avec iptables et le module u32 (attention, il semble y avoir des bugs avec certaines versions) :

iptables -A INPUT -p udp --dport domain -m u32 --u32 "0>>22&0x3C@10=0x01000001" -j DROP

SI vous ne voulez pas interdire toutes les requêtes récursives, j’ai trouvé sur Internet une règle plus précise qui matche sur le “. NS IN” (voir commentaires de ce post) :

iptables -A INPUT -j DROP -p udp --dport domain -m u32 --u32 \
"0>>22&0x3C@12>>16=1&&0>>22&0x3C@20>>24=0&&0>>22&0x3C@21=0x00020001"

Enfin, sur l’excellent blog de Stéphane Bortzmeyer, vous trouverez plus de détails et des outils pour mesurer le nombre d’attaques sur votre serveur.

Utiliser mailgraph sans CGI

Sunday, January 18th, 2009

Que ça soit pour des raisons de performance, de sécurité ou de simplicité, il est assez commun de ne pas avoir de module CGI sur un serveur (installer du CGI avec nginx est fastidieux par exemple). Or, l’outil de stats mailgraph n’est prévu que pour tourner en CGI. Voici un petit script qui permet de s’en affranchir et de générer les graphes mailgraph sans CGI :

#!/bin/sh
MAILGRAPH_PATH=/usr/lib/cgi-bin/mailgraph.cgi # Debian
#MAILGRAPH_PATH=/usr/local/www/cgi-bin/mailgraph.cgi # FreeBSD
#MAILGRAPH_PATH=/usr/local/lib/mailgraph/mailgraph.cgi # OpenBSD

MAILGRAPH_DIR=/var/www/mailgraph

umask 022

mkdir -p $MAILGRAPH_DIR

$MAILGRAPH_PATH | sed '1,2d ; s/mailgraph.cgi?//' > $MAILGRAPH_DIR/index.html

for i in 0-n 0-e 1-n 1-e 2-n 2-e 3-n 3-e; do
        QUERY_STRING=$i $MAILGRAPH_PATH | sed '1,3d' > $MAILGRAPH_DIR/$i
done

Il peut être placé en crontab, ce qui permet une sauvegarde régulière des graphes générés. Testé sous Debian, FreeBSD et OpenBSD (variable MAILGRAPH_PATH à adapter).