Enlarge your pen1s … Heu non, LVM sous KVM

Intrigué par l’effervescence autour de KVM (libre, intégré au noyau, choisi par RedHat et compliant avec la libvirt), j’ai décidé de le tester. J’ai donc déployé une Squeeze 64 bits sur un R410 de test pour essayer d’installer une VM avec un montage ISCSI. Pas de problèmes particuliers sauf pour l’utilisation du LVM à l’installation de la VM. J’ai choisi de créer un LV sur l’hôte par partition demandé sur la VM qui seront partitionnés à l’installation de la VM. L’inconvénient de cette méthode est que l’on multiplie les vd*1 sur le guest, ce n’est pas cosmétique. La seconde de méthode est de faire du LVM sur LVM : on crée le PV de la VM sur un LV du système hôte et on enquille. Je suis un peu effrayé (peut être à mauvais titre) par la superposition de niveaux de LVM.

Je veux retailler le / hébergé sur le LV /dev/virtvol/vm et lui ajouter 4 Go. Tout va se passer sur le système hôte. Let’s go :

# lvextend -L+4G /dev/virtvol/vm

Extending logical volume vm to 26,00 GiB
Logical volume vm successfully resized

On ouvre ensuite la table des partitions avec kpartx. Cet outil recrée une arborescence sous /dev/mapper correspondant à la structure des partition du volume cible.

# kpartx -av /dev/virtvol/vm

add map virtvol-vm1 (254:1): 0 46122552 linear /dev/virtvol/vm 63

On recrée la table des partitions sur le volume mappé dans /dev/mapper. Cette opération consiste à supprimer la partition dans un premier temps et à la recréer à la taille maximum. Comme on a une seule partition par table, on se fait pas de noeuds au cerveau avec les offset de départ etc. Et dans un situation de crise genre mes logs sont pleins (ils ont de la chance) on est content d’agrandir sans se poser de questions.

# fdisk /dev/mapper/virtvol-vm

The number of cylinders for this disk is set to 3394.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)
 
Command (m for help): <strong>p</strong>
 
Disk /dev/mapper/virtvol-vm: 27.9 GB, 27917287424 bytes
255 heads, 63 sectors/track, 3394 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x0000aab8
 
                     Device Boot      Start         End      Blocks   Id  System
/dev/mapper/virtvol-vm1               1        2871    23061276   83  Linux
 
Command (m for help): d 1
Selected partition 1
 
Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-3394, default 1): 
Using default value 1
Last cylinder, +cylinders or +size{K,M,G} (1-3394, default 3394): 
Using default value 3394
 
Command (m for help): p
 
Disk /dev/mapper/virtvol-vm: 27.9 GB, 27917287424 bytes
255 heads, 63 sectors/track, 3394 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x0000aab8
 
                     Device Boot      Start         End      Blocks   Id  System
/dev/mapper/virtvol-vm1               1        3394    27262273+  83  Linux
 
Command (m for help): w
The partition table has been altered!
 
Calling ioctl() to re-read partition table.
 
WARNING: Re-reading the partition table failed with error 22: Argument invalide.
The kernel still uses the old table. The new table will be used at
the next reboot or after you run partprobe(8) or kpartx(8)
Syncing disks.

On va pas faire les malins et actualiser au niveau du noyau la table de partitions :

# kpartx -d /dev/virtvol/vm
# kpartx -av /dev/virtvol/vm

add map virtvol-vm1 (254:1): 0 54524547 linear /dev/virtvol/vm 63

Un petit contrôle du système de fichier de la partition redimensionnée :

# e2fsck -f /dev/mapper/virtvol-vm1

e2fsck 1.41.10 (10-Feb-2009)
Passe 1 : vérification des i-noeuds, des blocs et des tailles
Passe 2 : vérification de la structure des répertoires
Passe 3 : vérification de la connectivité des répertoires
Passe 4 : vérification des compteurs de référence
Passe 5 : vérification de l'information du sommaire de groupe
/dev/mapper/virtvol-vm1 : 27849/1441792 fichiers (0.9% non contigus), 312705/5765319 blocs

Retaillage (dommage j’ai oublié ma pipe) :

# resize2fs /dev/mapper/virtvol-vm1

resize2fs 1.41.10 (10-Feb-2009)
En train de retailler le système de fichiers sur /dev/mapper/virtvol-vm1 à 6815568 (4k) blocs.
Le système de fichiers /dev/mapper/virtvol-vm1 a maintenant une taille de 6815568 blocs.

On démonte le /dev/mapper :

# kpartx -d /dev/virtvol/vm

Lancement de la VM :

# virsh start vm

Domain vm started

Sinon pour la partie KVM / libvirt ça m’a semblé pas mal du tout.

Intégration de Pyzor, Razor2 et DCC sous Spamassassin / Amavisd-new

Ce billet fait un point sur l’intégration des bases données distribuées d’empreinte de messages dans un environnement Spamassassin invoqué par Amavisd-new sous Debian. Ces systèmes sont uniquement basés sur les occurrences. C’est a dire qu’on va compter le nombre de fois que les serveurs centraux “voient” passer un message. Les empreintes interviennent dans le processus de normalisation des messages pour être présentés aux serveurs. On réalise plusieurs empreintes pour un message correspondants aux partie “intéressantes” du message (fuzzy checksums). Ces empreintes sont ensuite soumises sous forme de rapport aux serveurs. La différence entre DCC et Pyzor/Razor2 est dans le mécanisme de collecte : DCC collecte tout (ham et spam) tandis que Razor2 et Pyzor ne collectent que des spams. La partie qui nous intéresse est le client. Quand il voit passer un message, il interroge les serveurs pour avoir les statistiques relatives à ce message.

On va commencer par installer ce que l’on peut via les packages :
# apt-cache search razor

pyzor - spam-catcher using a collaborative filtering network
razor - spam-catcher using a collaborative filtering network

# apt-cache search dcc-client
Rien, il faudra se palucher DCC depuis les sources … La raison est que la version packagée par Debian est vulnérable à une faille non corrigée.

1. Razor2 et Pyzor

# apt-get install razor pyzor
On initialise un environnement par défaut Razor (création du .razor dans la home du root) :
# razor-admin -d -create
Ensuite en enregistre sa machine sur le réseau Razor :
# razor-admin -register
On y ajoute le fichier de configuration par défaut de l’agent :
# cp /etc/razor/razor-agent.conf /root/.razor/
On balance ça dans la home de l’utilisateur amavis :
# cp -r /root/.razor /var/lib/amavis
On effectue ensuite deux ou trois modifications dans /var/lib/amavis/.razor/razor-agent.conf :
- passer debug à 0 ;
- ajouter la ligne : “razorhome = /var/lib/amavis/.razor” pour que Razor2 trouve sa home.
On fixe le possesseur du répertoire fraichement ajouté :
# chown -R amavis:amavis /var/lib/amavis/.razor
Dans les préférences Spamassassin de l’utilisateur amavis (/var/lib/amavis/.spamassassin/user_prefs), on lui spécifie l’emplacement du fichier de configuration de Razor2 :

razor_config /var/lib/amavis/.razor/razor-agent.conf

Pour Pyzor, c’est plus simple, on définit le serveur auquel rattacher l’agent local :
# pyzor discover

downloading servers from http://pyzor.sourceforge.net/cgi-bin/inform-servers-0-3-x

Puis recopie de la configuration dans la home de amavis :
# cp -r /root/.pyzor /var/lib/amavis/
chown -R amavis:amavis /var/lib/amavis/.pyzor

On test Pyzor :
# su amavis -c 'pyzor ping'
Côté Spamassassin, on vérifie que dans /etc/mail/spamassassin/v310.pre on a bien les plugins activés :

loadplugin Mail::SpamAssassin::Plugin::Razor2
loadplugin Mail::SpamAssassin::Plugin::Pyzor

2. DCC

On va donc le compiler :
# cd /usr/local/src/
# wget http://www.rhyolite.com/dcc/source/dcc.tar.Z

--2010-02-24 11:06:08--  http://www.rhyolite.com/dcc/source/dcc.tar.Z
Resolving www.rhyolite.com... 192.188.61.3, 2001:4978:230::3
Connecting to www.rhyolite.com|192.188.61.3|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1630683 (1.6M) [application/x-compress]
Saving to: `dcc.tar.Z'
 
100%[======================================>] 1,630,683   84.2K/s   in 21s     
 
2010-02-24 11:06:29 (75.4 KB/s) - `dcc.tar.Z' saved [1630683/1630683]

# tar xzf dcc.tar.Z
# cd dcc-1.3.120

On va compiler DCC avec trois options : l’uid qui vaut amavis, on désactive le serveur et la partie dccm (interface Sendmail).
./configure --with-uid=amavis --disable-server --disable-dccm
# make
# make install

Dans /etc/mail/spamassassin/v310.pre, décommenter :

#loadplugin Mail::SpamAssassin::Plugin::DCC

Dans /etc/mail/spamassassin/local.cf, ajouter :

# dcc
use_dcc 1
dcc_path /usr/local/bin/dccproc
 
#pyzor
use_pyzor 1
pyzor_path /usr/bin/pyzor
 
#razor
use_razor2 1

Effectivement dans le cadre d’une utilisation avec Amavis, ça sert pas a grand chose (les réglages de ce fichier sont écrasés par Amavis). Par contre si on décidait de dédier la machine à Spamassassin et d’interfacer la version optimisée (Spamd) directement avec Postfix, le local.cf serait utilisé.

On redémarre Amavis et on test :
# /etc/init.d/amavis restart
# wget http://svn.apache.org/repos/asf/spamassassin/branches/b2_4_0/sample-spam.txt
# su amavis -c 'spamassassin -D test-report.txt 2>&1
# egrep -i '(pyzor|razor|dcc)' test-report.txt

[11769] dbg: plugin: loading Mail::SpamAssassin::Plugin::DCC from @INC
[11769] dbg: dcc: network tests on, registering DCC
[11769] dbg: plugin: loading Mail::SpamAssassin::Plugin::Pyzor from @INC
[11769] dbg: pyzor: network tests on, attempting Pyzor
[11769] dbg: plugin: loading Mail::SpamAssassin::Plugin::Razor2 from @INC
[11769] dbg: razor2: razor2 is available, version 2.84
[11769] dbg: config: fixed relative path: /var/lib/spamassassin/3.002005/updates_spamassassin_org/25_dcc.cf
[11769] dbg: config: using "/var/lib/spamassassin/3.002005/updates_spamassassin_org/25_dcc.cf" for included file
[11769] dbg: config: read file /var/lib/spamassassin/3.002005/updates_spamassassin_org/25_dcc.cf
[11769] dbg: config: fixed relative path: /var/lib/spamassassin/3.002005/updates_spamassassin_org/25_pyzor.cf
[11769] dbg: config: using "/var/lib/spamassassin/3.002005/updates_spamassassin_org/25_pyzor.cf" for included file
[11769] dbg: config: read file /var/lib/spamassassin/3.002005/updates_spamassassin_org/25_pyzor.cf
[11769] dbg: config: fixed relative path: /var/lib/spamassassin/3.002005/updates_spamassassin_org/25_razor2.cf
[11769] dbg: config: using "/var/lib/spamassassin/3.002005/updates_spamassassin_org/25_razor2.cf" for included file
[11769] dbg: config: read file /var/lib/spamassassin/3.002005/updates_spamassassin_org/25_razor2.cf
[11769] dbg: razor2: part=0 engine=4 contested=0 confidence=0
[11769] dbg: razor2: results: spam? 0
[11769] dbg: razor2: results: engine 8, highest cf score: 0
[11769] dbg: razor2: results: engine 4, highest cf score: 0
[11769] dbg: pyzor: pyzor is available: /usr/bin/pyzor
[11769] dbg: pyzor: opening pipe: /usr/bin/pyzor check < /tmp/.spamassassin11769frgBiutmp
[11769] dbg: pyzor: [11771] finished: exit=0x0100
[11769] dbg: pyzor: got response: public.pyzor.org:24441 (200, 'OK') 0 0
[11769] dbg: dcc: dccifd is not available: no r/w dccifd socket found
[11769] dbg: dcc: dccproc is available: /usr/local/bin/dccproc
[11769] dbg: dcc: opening pipe: /usr/local/bin/dccproc -H -x 0 -a 212.17.35.15 < /tmp/.spamassassin11769frgBiutmp
[11769] dbg: dcc: got response: X-DCC-CollegeOfNewCaledonia-Metrics: sara 1189; Body=1 Fuz1=1 Fuz2=38

UnixGarden : Jail et OpenVZ

Juste un post pour indiquer la mise en ligne ce jour d’un article soumis sous “creative commons” à Linux Magazine. Je trouve ce principe particulièrement intéressant de publier l’article sur le web librement accessible quelques mois après sa parution. Il est disponible ici.

NAT authentifié avec authpf

A mon sens le NAT est une horrible (mais nécessaire) verrue. Le pire étant quand même lorsque l’on ose qualifier de sécurité le fait de NATer des machines : “On peut initier des connexions vers l’exterieur mais pas l’inverse“. C’est vrai, sauf que les machines compromises initient des connexions vers l’extérieur pour signifier à leur botnet de raccordement leur disponibilité. Devant garantir un minimum de traçabilité de ces accès, j’ai décidé de mettre en place une passerelle de NAT authentifié avec authpf. Authpf permet de jouer des règles PF via les ancres lors d’une connexion SSH. The big picture :




La machine authpf est un OpenBSD 4.6. La problématique est que cette machine n’est pas notre pare-feu principal (snif …). Les flux doivent donc être routés vers cette machine au niveau du pare-feu en fonction du réseau source. Ceci n’est possible qu’en appliquant du “policy routing” qui permet d’appliquer des règles de routage en fonction d’autres critères que le réseau (ou la machine) de destination. On définit ensuite le routeur externe comme passerelle du NAT authentifié et c’est gagné.

1. Configuration de la passerelle

Au niveau de la passerelle, il faut ajouter les lignes suivantes au niveau du rc.conf :

pf=YES
pf_rules=/etc/pf.conf.local

J’aime bien mettre mes règles PF dans un fichier à part.

Examinons le pf.conf.local (seule les sections intéressantes sont affichées) :

set skip on lo
block in log all
block out log all
 
nat-anchor "authpf/*"
rdr-anchor "authpf/*"
binat-anchor "authpf/*"
 
anchor "authpf/*"

On laisse tout passer sur 127.0.0.1 (lo), ensuite on bloque tout et on loggue en entrée et en sortie. Enfin, on pose les ancres pour ajouter dynamiquement les règles des utilisateurs authpf.

2. Création des utilisateurs

Dans tout organisme moderne, on dispose d’un LDAP avec les utilisateurs dedans (et surtout un uid associé à un userPassword). Dans ce cas, on peut connecter son NAT authentifié au LDAP. Pour ce faire, deux options : ypldap ou login_ldap. J’ai choisi la méthode via login_ldap car je ne dispose pas de vrai posixAccount dans mon LDAP et des informations telles que l’UID sont nécessaires. Voila ma section dans le /etc/login.conf pour associer LDAP et authpf :

ldap-authpf:\
        :auth=-ldap:\
        :x-ldap-server=monldap.mondomaine:\
        :x-ldap-basedn=ou=People,dc=mondomaine:\
        :x-ldap-binddn=cn=toto,ou=user4bind,dc=mondomaine:\
        :x-ldap-bindpw=azerty:\
        :x-ldap-filter=(&(objectClass=inetOrgPerson)(uid=%u)):\
        :welcome=/etc/motd.authpf:\
        :shell=/usr/sbin/authpf:\
        :tc=default:

Pour créer les utilisateurs :
useradd -L ldap-authpf -d /var/empty -s /usr/sbin/authpf -r 1500..3000 -g =uid pastounus
Cela crée l’utilisateur pastounus avec une home bidon (-d /var/empty) qui va utiliser la “login class” ldap-authpf (-L ldap-authpf) ainsi que le shell authpf (-s /usr/sbin/authpf) et un groupe privé UPG (-g =uid).

3. Utilisation

On ajoute les règles de l’utilisateur pastounus dans le fichier /etc/authpf/users/pastounus/authpf.rules :

int_if=bge0
 
nat pass log on $int_if from $user_ip to any -> XXX.XXX.XXX.XXX

Et voila : une fois authentifié, pastounus est naté ! On notera quand même qu’il convient d’ajouter les routes de retour sur la passerelle pour les réseaux derrière le NAT authentifié. La passerelle devra également proxifier les réponses ARP pour les IP vers lesquelles elle effectue les translations. Tout cela se passe dans le rc.local. Dans notre exemple XXX.XXX.XXX.XXX est l’adresse de NAT, YYY.YYY.YYY.YYY est le réseau privé à NATer et ZZZ.ZZZ.ZZZ.ZZZ est la patte du pare-feu sur laquelle est raccordée la passerelle.

# Add your local startup actions here.
 
echo '.'
route add -net YYY.YYY.YYY.YYY/24 ZZZ.ZZZ.ZZZ.ZZZ
 
arp -s XXX.XXX.XXX.XXX @mac_nat_auth pub

Upgrade vers FreeBSD 8.0

Voila un petit mois que je n’ai rien posté sur ce blog. J’avais un peu la tête sous l’eau. J’ai donc passé mes serveurs FreeBSD hébergeant des jail en 8.0. Seulement, je me suis loupé dans la procédure d’upgrade. J’ai upgradé un jail en 8.0 puis en rappelant la commande freebsd-update j’ai omis le -b pour lui donner comme racine un jail donc il a mis à jour le système de base. Je n’ai pas voulu interrompre la procédure donc je l’ai laissé finir.

Le problème lorsque l’on utilise freebsd-update pour mettre à jour ses jails c’est qu’il se base sur la version renvoyée par uname. Si l’on met à jour le système de base avant les jails, alors freebsd-update lancé sur le jail considère que le système est déjà à jour. Pour s’en sortir, deux options :

1) Création d’un faux uname

On move /usr/bin/uname vers /usr/bin/uname.org et on se fait un petit script du style :

#!/bin/sh
/usr/bin/uname.org $* | sed s/"8.0-RELEASE"/"7.2-RELEASE-p4"/g

Ok c’est encore plus crade que du porno thaïlandais …

2) Copie d’un jail “master”

Directement inspiré d’un post trouvé ici. Cette méthode propose de disposer d’un master jail à répliquer. J’étais un peu dans cette configuration avec comme “master jail” celui que j’avais upgradé avant ma boulette. Les installations des différents jails étant assez homogènes (ferme de serveur FreeBSD / Apache / Trac / SVN) il me suffisait de répliquer ce jail et de recoller les data de /usr/local/[svn|www]-trac qui contiennent respectivement les instances subversion et Trac associées. Pour copier un jail, ne surtout pas faire un bête cp mais plutôt :

# cd /jail/masterjail
# tar -cpf - . | tar -C /jail/newjail -xpf –

Pour conserver les permissions, la nature du fichier (surtout les liens) etc. Quand on combine tar et ssh on obtient même un “master jail” deployable de façon sécurisée sur tous les serveurs partageant son architecture (uname -m). A noter que cette manipulation a quand même nécessité la recompilation du port www/apache22 sur le newjail.

Debian lenny et BCM 5716

Parti pour tester les possibilités de monitoring du package OMSA sur des Dell Poweredge R410 flambants neufs, je me suis cassé le nez sur la carte réseau. Celle ci est une Broadcom tout ce qu’il y a de plus classique simplement les drivers du chipset BCM 5716 sont absents du noyau 2.6.26 compilé pour lenny. S’en est suivi une journée de bataille pour tenter de se créer un CD netinst.iso customizé avec le noyau 2.6.30 des backports. Autant le dire tout de suite, j’ai perdu la bataille !

Pour moi la manipulation a consisté à récupérer le noyau 2.6.30 des backports ainsi que le firmware qui va avec (comme dirait Sefyu) sur une clé USB. Armé de tout ca, on peut démarrer une install standard via le netinst.iso classique. Une fois le système installé, reboot. Il est aussi conseillé de récupérer les packages virtuels associés dans les backports (linux-image-2.6-686-bigmem et firmware-bnx2) pour suivre les mises à jour.

Pour la suite, on va monter la clé et installer les deux packages backportés :

mount -t vfat /dev/sdb1 /mnt/usb
cp /mnt/usb/*.deb /root
cd /root
dpkg -i linux-image-2.6.30-bpo.1-686-bigmem[...].deb
dpkg -i firmware-bnx2_0.17~bpo50+1_all.deb
dpkg -i llinux-image-2.6-686-bigmem_[...].deb
dpkg -i firmware-bnx2.deb

Ensuite, comme on a utilisé les backports, il faut les ajouter dans notre /etc/apt/sources.list :

deb http://www.backports.org/debian lenny-backports main contrib non-free

Ensuite, il faut mettre à jour le cache apt et récupérer le keyring des backports :

apt-get update
apt-get install debian-backports-keyring

Enfin pour gérer les mises à jour, il faut que nos 2 packages backportés pointent sur les dépôts backports. Pour se faire, il faut créer ou modifier le fichier /etc/apt/preferences :

Package: linux-image-2.6-686-bigmem_[...].deb
Pin: release a=lenny-backports
Pin-Priority: 999
 
Package: firmware-bnx2
Pin: release a=lenny-backports
Pin-Priority: 999

Et hop, maintenant la mise à jour devrait se faire trankilou. Il est important de noter que l’emploi des logiciels backportés a des implications au niveau sécurité. Les mises à jour sont au bon vouloir du mainteneur. Les problèmes ouverts pour lenny sont consultables ici.

Proxy FTP sous Linux

Pour éviter de NATer à tort et à travers nos (chers) utilisateurs, nous avons décidé de mettre en place un proxy FTP. Nous pensions pouvoir trouver une multitude d’outils pour rendre ce service. Hé bien non, il n’y en a que deux :

  • ftp-proxy qui est un peu plus récent (2005) et qui lui ne semble pas avoir de problèmes connus.

Notre choix s’est porté sur ftp-proxy. Ce produit fait partie de la proxy-suite développée par SuSE (mais elle avale pas). L’installation sur une Debian Lenny est d’une simplicité biblique.

Tout d’abord, installons le package :

apt-get install ftp-proxy

Ensuite, il faut autoriser le démarrage du service en mode daemon dans /etc/default/ftp-proxy :

RUN_DAEMON=yes

Enfin, il faut modifier le fichier /etc/proxy-suite/ftp-proxy.conf. J’ai mis l’intégralité de mon fichier purgé des commentaires :

[-Global-]
AllowMagicUser yes	
AllowTransProxy no	
DestinationAddress	localhost	
DestinationTransferMode	client
Group			nogroup
LogDestination	/var/log/ftp-proxy/ftp-proxy.log
LogLevel		INF
Port 2121
User			nobody

Une petite explication des paramètres. AllowMagicUser permet de “mettre de la magie” dans le nom de l’utilisateur. En gros ça permet d’interpréter une chaine type utilisateur@serveur:port ce qui est assez courant pour les clients FTP en ligne de commande. AllowTransProxy permet d’autoriser ou non le proxy transparent. J’ai choisi de le désactiver. DestinationAddress est utile quand on veut utiliser ftp-proxy en reverse devant un de nos serveurs FTP (pour interdire des commande ou bloquer du trafic non FTP). Dans ce cas on doit aussi activer le mode transparent. DestinationTransferMode permet de forcer le mode de fonctionnement en actif ou en passif. Ici je laisse le choix au client. Group et User fixent l’identité sous laquelle le service s’exécute. LogDestination et LogLevel l’emplacement et le niveau de détails des événements remontés. Enfin Port donne le port utilisé par ftp-proxy. Il n’y a plus qu’a le lancer :

/etc/init.d/ftp-proxy start

Et voila !

Install party : pappy fait de la resistance

th_2604-old-tuxAujourd’hui j’ai participé à une install party organisé par LUG orléannais Cenabumix. Cette manifestation s’est passée dans les locaux de l’IUT Informatique d’Orléans. Au programme : installation et dépannage de GNU\Linux et deux conférences sur les thèmes de la messagerie Jabber et des logiciels libres. Ambiance très sympa et atmosphère studieuse. Ce qui m’a frappé c’est d’abord le monde. Plus d’une centaines de personnes sont passées et les conférences ont fait le plein. L’audience était fortement hétérogène avec quand même une forte population d’age mure qui n’ont pas peur de se lancer dans le monde du libre. Un de nos sémillant ancêtre m’a même dit “Moi je garde une partoche windows pour mes petits enfants quand ils viennent jouer, sinon je n’aurais que Ubuntu !”. En discutant avec eux, il semble que les principales raison qui leur on fait opter pour un système Linux sont :

  • Le foutage de gueule de Microsoft avec Vista et Seven. En effet, un geste élégant aurait été d’offrir Seven : “ce qu’aurait du être Vista” selon l’adage. Mais non la tu passes deux fois à la caisse.
  • Le prix des systèmes propriétaires non négligeable.
  • La complexité des nouveaux systèmes. Ce qui plait avec Ubuntu et Mandriva c’est le système de gestion de paquets. En 1 clic, nos pappys récupèrent Opera, Thunderbird, Audacity etc. Et ça, ça n’existe ni sous Windows, ni sous OSX (fink et Darwin porcs = LOL).
  • Les systèmes Linux sont plus virus-free que Windows c’est indéniable.

Bref, nos ancêtres sont des as du clic, rebelles dans l’âme qui recherchent avant tout la simplicité. Une position dont devraient s’inspirer nombre de décideurs qui persistent sur les chemins du logiciel fermé avec une surface d’attaque aussi importante que le montant de la maintenance annuelle.

Chrooting Bind9

Tutorial rapide pour chrooter bind9. Le but est d’avoir un répertoire /var/lib/named ou se va se chrooter bind9. La configuration va se faire dans le etc relatif au chroot et les zones seront stockées dans le var relatif au chroot. Les manipulation sont faites sur une Debian Lenny. Créons d’abord les répertoires :

mkdir /var/lib/named
mkdir -p /var/lib/named/etc
mkdir /var/lib/named/dev
mkdir -p /var/lib/named/var/cache/bind
mkdir /var/lib/named/var/log
mkdir -p /var/lib/named/var/run/bind/run

On déplace la configuration :

mv /etc/bind /var/lib/named/etc

On fait un lien au cas on voudrait facilement le déchrooté (et aussi pour les upgrades) :

ln -s /var/lib/named/etc/bind /etc/bind

On se crée un socket en écoute dans le chroot pour rsyslog. Dans /etc/rsyslog.conf :

$AddUnixListenSocket /var/lib/named/dev/log

On crée les devices dans le chroot

mknod /var/lib/named/dev/null c 1 3
mknod /var/lib/named/dev/random c 1 8
chmod 666 /var/lib/named/dev/null /var/lib/named/dev/random

On fixe les permissions :

chown -R bind:bind /var/lib/named/var/*
chown -R bind:bind /var/lib/named/etc/bind

Enfin dans /etc/defaults/bind9 :

OPTIONS="-u bind -t /var/lib/named"

Un restart de rsyslogd et bind et c’est parti !

Client Windows XP, KFW, KDC Unix et Mozilla

Un petit post pour mémoire sur le fonctionnement d’un client Windows XP avec KFW (Kerberos For Windows) et les outils Mozilla. Mon but est de proposer une authentification Kerberos aux utilisateurs itinérants : non raccordés à un domaine, compte local à la machine et authentification (au moment du login) non liée au KDC. KFW est un utilitaire distribué par le MIT qui permet d’intégrer une couche GSSAPI “traditionnelle” dans Windows. En effet, Windows utilise une variante fermée de la GSSAPI qui se nomme SSPI (Security Support Provider Interface). L’installation de KFW n’est pas compliquée (suivant, suivant et terminer). Une fois installée, on doit configurer le fichier krb5.ini (qui ressemble comme deux goutes d’eau au krb5.conf). Voici un exemple minimal :

[libdefaults]
	default_realm = MONDOMAINE.FR
 
[realms]
        MONDOMAINE.FR = {
                kdc = kdc.mondomaine.fr
        }
 
[domain_realm]
	.monrealm.fr = MONDOMAINE.FR
	mondomaine.fr = MONDOMAINE.FR

Ensuite, il suffit de cliquer pour obtenir les credentials (TGT). Ensuite, pour les applications Mozilla il faut faire un petit réglage. En effet, Firefox et Thunderbird utilisent par défaut la SSPI. On peut forcer l’utilisation de la GSSAPI en désactivant le SSPI. Pour ce faire, dans “Outils”, “Options” et “Editeur de configuration” placez le network.auth.use-sspi à false.