Archive for the 'Linux' Category

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.

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.

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 !

From etch to lenny

Lenny est sorti, youpi ! Ou pas quand on voit le merdier d’un telle mise à jour. La mise à jour a eu lieu sur des Dell PowerEdge 2950 : le détail a son importance. Première étape : MAJ du /etc/apt/sources.list. on remplace etch par lenny. Ensuite apt-get update && apt-get dist-upgrade et c’est parti. On répond a plein de questions : non ne bousille pas samba, ni OpenLDAP et encore moins Bind9 … Hop, redémarrage de la bécane. Tout à l’air OK. Un petit ping depuis une autre machine : ça ping pas ! Hop ifconfig : pas de carte réseau. Je repense aux messages d’installation du noyau 2.6.26 et notamment un warning qui m’avait paru bizarre à la création de l’initramfs.

apt-get install firmware-bnx2
dpkg-reconfigure linux-image-2.6.26-1-686

Ensuite un petit reboot et on récupère le réseau. Ensuite comme je suis un mec audacieux, j’ai voulu mettre à jour Xen de 3.0 vers 3.2. Shutdown des domU, désinstallation de tout ce qui était Xen 3.0 et installation des mêmes paquets en 3.2. Montage du filesystem des domU et chroot dedans pour les passer en lenny. Redémarrage de la machine et lancement des domU : ça freeze … Après un peu de googling, il faut ajouter ça dans le fichier de configuration de la domU :

extra = 'xencons=tty'

En conclusion, je pense qu’il vaut mieux faire une fresh install (si vous pouvez vous le permettre) pour passer de etch à lenny. Je préfère mettre à jour mes Freebi !

Retour sur l’overlay OpenLDAP slapo-accesslog

OpenLDAP dispose d’un module interne d’audit des différentes actions (write, read, bind, unbind etc.). J’ai cherché à l’utiliser pour auditer les connexions au serveur LDAP (statistiques d’utilisation des comptes). Le stockage des logs se fait dans une base de données (idem que les backends traditionnels OpenLDAP). La configuration du module se fait par le slapd.conf :

moduleload accesslog
[...]
database bdb
suffix cn=accesslog
directory /var/lib/ldap/accesslog
rootdn cn=accesslog
[...]
overlay accesslog
logdb cn=accesslog
logops bind

Explications : on charge le module (moduleload accesslog) puis on définit la base de données qui va stocker nos logs (ici une base de donnée BerkleyDB dans une arborescence du système de fichier distincte de la base principale). Enfin, on configure l’overlay en lui demandant de reporter les tentatives de bind dans les logs (directive logops).

Redémarrage du LDAP et la hop : ça marche (moyennant la création d’un répertoire /var/lib/ldap/accesslog avec les bon droits dessus !).

J’essaie de visionner les logs depuis une machine lambda (dans un vrai cas d’utilisation, il aurait fallu mettre des ACLs pour éviter que la planète entière ne récupère les logs) :

[garnett@irondick]# ldapsearch -x -h monldap.example.org -b "cn=accesslog"

It works, voila la sortie :

dn: reqStart=20081204135447.000003Z,cn=accesslog
objectClass: auditBind
reqStart: 20081204135447.000003Z
reqEnd: 20081204135447.000004Z
reqType: bind
reqSession: 29
reqAuthzID:
reqDN: cn=garnett,dc=example,dc=org
reqResult: 0
reqVersion: 3
reqMethod: SIMPLE

On a pas mal d’informations : la date du bind, le compte utilisé, la méthode d’authentification (simple ou via SASL) et la version utilisée du protocole LDAP. Seulement pas de mention de l’hôte à l’origine du bind, c’est dommage ! Après consultation du schéma détaillé dans le man de slapo-accesslog cette information n’y figure pas.

Un autre truc qui m’a refroidi (extrait du man) :

It is also noted that the schema describe here is a work in progress, and hence subject to change without notice.

Aie !!

Au coin du feu : SELinux by example

Dans le cadre de ma thèse, je dois utiliser SELinux. SELinux est une extension du noyau Linux implémentant le contrôle d’accès mandataire (MAC). Le MAC permet de poser des restrictions d’accès (read, write, etc.) à des sujets (utilisateur, processus etc.) sur des objets (fichiers, socket réseau etc.). Même root doit se plier à ce contrôle d’accès. Les UNIX traditionnels reposent plutôt sur un contrôle d’accès discrétionnaire (DAC) où les permissions sont définies “à la discrétion” du possesseur de l’objet avec une omnipotence de root.

Pour ce qui est de l’ouvrage je l’ai trouvé très bon. La problématique est bien introduite, les bases des différents contrôle d’accès sont bien posées. La présentation de l’architecture de SELinux est concise et appuyée par des schémas clairs. Des cas concrets d’utilisations sont détaillés (notamment sous Fedora) et beaucoup d’outils périphériques sont introduits. Bref, devant la pauvreté (en volume) des ouvrages consacrés à ce sujet et le côté “éparse” des ressources disponibles sur le net traitant de ce sujet la possession de ce livre est un MUST.

Clés USB et comptes LDAP

L’utilisation d’une clé USB sous Ubuntu par un utilisateur lambda est conditionée par son appartenance (ou non) au groupe “plugdev”. Plusieurs solutions :
- Passer sur toutes les machines ajouter les utilisateurs dans le groupe plugdev : autant se tirer une balle tout de suite.
- Faire un groupe posix dans LDAP “plugdev” et mettre les gens dedans. L’objection principal que je vois est que le GID de ce groupe est local (donc bas) : les GID distribués par LDAP doivent être sur une plage supérieure.
- Ajouter dynamiquement l’utilisateur dans le groupe “plugdev” après l’authentification.

J’ai retenu la dernière solution. On peut faire ça en utilisant la PAM pam_group.so.

/etc/security/group.conf

*;*;*;Al0000-2400;cdrom,floppy,plugdev

Cette ligne nous dit en gros que n’importe qui qui se connecte sur la machine à n’importe quelle heure et par n’importe quel moyen (ssh, login en mode texte, [k|x|g]dm etc.) se voit ajouter aux groupes locaux cdrom, floppy et plugdev.

/etc/pam.d/common-auth

auth    optional        pam_group.so
auth    sufficient      pam_ldap.so
auth    requisite       pam_unix.so nullok_secure
auth    optional        pam_smbpass.so migrate missingok

On active la pam_group qui va réaliser les actions définies dans /etc/security/group.conf. Attention a bien la placer en tête de fichier.

Enfin dans /etc/dbus-1/system.d/hal.conf, il faut remplacer “deny” par “allow” à la ligne :

<deny send_interface="org.freedesktop.Hal.Device.Volume"/>