lalahop
Categorie: Logiciels

Tout est dans le titre : l'installation de cups-pdf avec apt-get sous Debian Wheezy se bloque/gèle/freeze/hang sur la ligne "Reloading Common Unix Printing System: cupsd.". Le même problème peut survenir lors de la désinstallation de cups-pdf.

Un ps aux | grep dpkg permet de constater qu'il y a un processus "/bin/sh /var/lib/dpkg/info/cups-pdf.postinst" qui tourne. Comme par hasard, quand on kill se processus, l'installation continue. Certes elle échoue mais elle continue.

En décortiquant ce script, on observe l'utilisation de lpstat. OK, on se documente sur le bouzin et on essaye nous même, en ligne de commande, "lpstat -h localhost -r" : aucun retour ...

Hum ... que donne "lpstat -h 127.0.0.1 -r" ? "scheduler is running" ...

Hum ... problème de résolution des noms locaux ... On vérifie le contenu de /etc/hosts : il contient bien une association localhost <=> 127.0.0.1. Il contient évidement le même type d'association pour IPv6 ...

Hum ... donc s'il ne résout pas les noms locaux, un "lpstat -h nom_de_la_machine -r" va échouer ... Même pas ... Donc c'est bien un soucis interne à lpstat.

La solution est évidente (mais pas forcement propre, je n'ai aucun avis sur la question) : on modifie /var/lib/dpkg/info/cups-pdf.postinst pour remplacer toutes les occurrences de localhost (même celles qui ne sont pas utilisées comme paramètre d'un lpstat).

Tant qu'à faire, pour s'éviter des problèmes lors de la déinstallation/suppression de cups-pdf, on modifie les scripts /var/lib/dpkg/info/cups-pdf.postprerm et /var/lib/dpkg/info/cups-pdf.postpostrm de la même manière.

Ensuite si ce n'est pas déjà fait, on kill le processus /bin/sh /var/lib/dpkg/info/cups-pdf.* qui bloque l'installation/désinstallation de cups-pdf.

Enfin, on lance juste dpkg --configure -a et l'installation/déinstallation de cups-pdf se termine sans problèmes.

Adversity bloque le CSS de piwik.org

Si vous avez remarqué que, depuis quelques temps, le CSS du site officiel de Piwik (piwik.org) n'est plus chargé par votre navigateur et si vous utilisez la liste Adversity pour Adblock Plus (ou Adblock Edge), alors ce billet est fait pour vous. Dans le cas contraire, je n'ai pas de solution pour vous.

Il s'agit bien de deux règles de la liste Adversity qui opèrent ce blocage involontaire (on comprend que le but initial de ces règles est de bloquer piwik.js/piwik.php, les deux parties du traqueur JS sur une installation Piwik et que ce blocage est un effet de bord) :

  • /piwik.
  • ||piwik.

Au rayon des "solutions", on a :

  • Désactiver Adblock Plus sur piwik.org.
  • Désactiver les deux règles sus-citées. Cela se passe dans les Préférences de filtre d'Adblock, sélectionnez la liste Adversity, recherchez les deux règles et décochez-les. La prise en compte est immédiate. Les règles désactivées ne seront pas reactivées durant une MAJ de la liste. Attention : si vous n'utilisez pas d'autres plugins, alors le traqueur Piwik fonctionnera à nouveau sur tous les sites que vous visitez (ce qui n'est pas dramatique ( beaucoup moins que Google Analytics quoi) mais je préfère prévenir les esprits sensibles).
  • Désactiver/supprimer Adversity/Adblock Plus ;). Juste pour troller.

J'ai fait remonter l'information via les adresses mail publiées sur la page Google Code de la liste car pour moi il s'agit d'un comportement non désiré : bloquer le traqueur Piwik (piwik.js/piwik.php) sur tous les sites (y compris sur piwik.org) est bien un comportement désiré d'une telle liste. Bloquer le CSS du site officiel d'une solution de stats me semble être plus un effet de bord des règles qu'un comportement désiré car le CSS du site officiel d'un traqueur n'est pas nuisible ...

Il ressort de la conversation que le but de la liste Adversity est de supprimer la publicité et les traqueurs statistiques (jusque là, je suis d'accord). Piwik.org étant le site officiel d'un traqueur statistiques (je suis toujours OK 😛 ), ce sur-blocage doit être attendu (je ne suis plus d'accord, pour les raisons indiquées dans le précédent paragraphe). Aucun effort n'est fait ni ne sera fait pour s'assurer que ce genre de pages s'affichent comme attendu. Au moins, c'est clair 🙂 .

Piwik : importer depuis les logs

Si vous avez la main sur votre serveur, Piwik met à votre disposition un script Python qui vous permet d'importer les statistiques (visites, pages vues, ...) depuis les logs de votre httpd (support Apache, Nginx, IIS et tous les autres vi vous spécifiez les regex qui vont bien). Piwik agit comme Webalizer AWStats.

Table des matières

Avantages/Inconvénients

Quels sont les avantages par rapport au traqueur JS ?

  • L'information a déjà été produite par le démon http, pourquoi la produire à nouveau avec le traqueur JS ?
  • Vos visiteurs gagnent en temps de chargement (deux requêtes de moins).
  • Vous libérez votre serveur dans les moments de forte charge (quand il y a les visites quoi) et vous calculez vos stats dans un moment de faible charge (typiquement la nuit mais ce n'est pas toujours le cas).

Quels sont les inconvénients par rapport au traqueur JS ?

  • La doc nous dit plus complexe à mettre en place ... ça se discute.
  • Avec le traqueur JS, on ne comptabilise que les visites provenant d'humains + des quelques bots qui interprètent le Javascript. Avec les logs, on comptabilise tout. SI votre site est scanné par les bots, vos stats vont perdre énormément de leur fiabilité. C'est clairement le point noir de l'analyse de logs. Même sur un tout petit blog comme celui-ci les stats perdent de leur valeur car des robots scan en continue et tentent de poster des commentaires ...

Faire tourner les logs

Pourquoi

Il est nécessaire de faire tourner les logs de votre httpd avant de lancer le script d'import sur celui-ci car, dans le cas contraire, les visites seront dédoublées par Piwik. Comme un exemple vaut mieux qu'un long discours :
Exemple de statistique dédoublée

Notez le "2x" alors que la page n'a en réalité été visité qu'une seule fois dans cet exemple.

De plus, si vous ne faîtes pas tourner les logs, vous aurez une quantité toujours plus importante à parser : les logs de la veille + les logs d'aujourd'hui ...

Comment

Pour faire tourner les logs, nous allons utiliser logrotate. Pour cela, il suffit de créer un fichier /etc/logrotate.d/apache (vérifiez qu'il n'existe pas déjà, vous aurez juste à adapter weekly/monthly => daily) avec le contenu suivant :

/var/log/apache2/GGS/*.log {
        daily
        missingok
        rotate 365
        compress
        delaycompress
        ifempty
        create 640 root adm
        sharedscripts
	olddir /var/log/archives/apache2/GGS
        postrotate
                /usr/sbin/apache2ctl graceful > /dev/null
        endscript
}

Ainsi, dans cet exemple, les logs situés dans le dossier /var/log/apache2/GGS (pensez à adapter) seront tournés tous les jours, stockés dans /var/log/archives/apache2/GGS pendant 365 jours sous forme compressée à partir de la deuxième rotation.

Configurer l'import

Il suffit de créer un fichier dans /etc/cron/daily.d/ qui fera, ainsi, appel au script d'import une fois par jour :

#!/bin/sh
 
/usr/bin/python2.6 /var/www/piwik/misc/log-analytics/import_logs.py --url="http://stats.guiguishow.info" --idsite=3 `date +/var/log/archives/apache2/GGS/access.log-\%Y\%m\%d`

Les deux paramètres obligatoires sont url et idsite. Le premier permet d'indiquer sur quel domaine se trouve Piwik (pensez à utiliser https ou toute autre méthode de sécurisation du canal si les deux domaines ne sont pas sur la même machine). L'autre permet d'indiquer l'id du site concerné. Ce dernier peut-être récupéré dans l'interface de Piwik.

Vient ensuite le nom du log à parser. Chaque jour, logrotate placera, dans /var/log/archives/apache2/GGS, le log de la veille sous le nom access.log-date_du_jour.

Concernant le nom que vous donnerez à ce script, prenez en considération le fait que c'est run-parts qui est chargé, par cron, de l'exécution des scripts. Or, comme l'explique son man, run-parts lance les scripts par ordre lexicographique. Il faut que le script logrotate passe avant notre script pour produire le log que nous allons parser. Donc il faut donner un nom "plus grand" à notre script. Dans mon cas : piwik-import.

ÉDIT du 26/11/2012 à 04h45 : Comme le signale Antoine dans les commentaires, créer une deuxième entrée dans cron n'est pas la meilleure méthode. En effet, logrotate permet de lancer une ou plusieurs commandes après la rotation des logs avec la directive "postrotate". D'ailleurs, je m'en sert pour relancer Apache. C'est donc dans cette directive qu'il fait sens d'ajouter la commande de l'import piwik (/usr/bin/python2.6 /var/www/piwik/misc/log-analytics/import_logs.py ...). Fin de l'édit

Règler les problèmes

Log SSL : Fatal error: Cannot guess the logs format.

En effet, alors que je n'ai pas changé de format de log dans ma config Apache entre mon virtualhost http et mon virtualhost https, Piwik me crache cette erreur.

Pour résoudre ce problème, il suffit de forcer le format de log avec le paramètre "--log-format-name=ncsa_extended".

Les FAI n'apparaissent pas, ils sont tous marqués "IP"

D'après la documentation, les FAI sont déduis en effectuant une requête DNS inversée sur l'adresse IP du visiteur. Néanmoins, comme cela est consommateur de ressource, le script d'import désactive cette fonction par défaut.

Pour résoudre ce problème, il suffit d'activer la fonctionnalité avec le paramètre : "--enable-reverse-dns".

Bien entendu, et je parle surtout pour un chroot, il faut qu'Apache ait accès à une bibliothèque de résolution DNS et qu'il y ait un fichier resolv.conf dans le chroot.

La géolocalisation ne marche pas : le pays du visiteur n'apparaît pas !

La doc répond déjà à ça. Avec le traqueur JS, Piwik détermine la localisation grâce au header "Accept-Language" envoyé par votre navigateur. Avec les logs, cette information n'est plus disponible.

Pour résoudre le problème, il faut installer l'extension GeoIP de Piwik ainsi que l'extension PECL GeoIP (vous avez le choix mais cette extension est la plus adaptée pour l'analyse de log, selon la documentation).

Installation de l'extension PECL GeoIP

Pour l'installer sous Debian :

apt-get install php5-geoip

On modifie ensuite la configuration de PHP (/etc/php5/apache2/php.ini) pour y ajouter (on remplacera le chemin ...) :

geoip.custom_directory=/path/to/piwik/misc

On récupère la base de donnée de correspondance entre une IP et sa géolocalisation, on la décompresse et on la range où il faut sous le nom qu'il faut :

wget -c http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz
gunzip GeoLiteCity.dat.gz
mv GeoLiteCity.dat.gz /path/to/piwik/misc/GeoIPCity.dat
Installation du plugin GeoIP de Piwik

Attention, à partir de la version 1,9, ce plugin est inclu d'office, vous n'avez pas à l'installer ni à l'activer. Vous devez juste vérifier que c'est bien l'extension PECL qui est utilisée.

On télécharge, décompresse et on range au bon endroit :

wget -c http://dev.piwik.org/trac/attachment/ticket/45/GeoIP.zip?format=raw -O GeoIP.zip
unzip GeoIP.zip
cp -R GeoIP/ /path/to/piwik/misc/

Il ne reste plus qu'à aller dans l'interface de Piwik, rubrique Paramètres, rubrique Plugins et à activer Geolocation.

Il faut ensuite aller dans l'onglet Geolocation qui vient d'apparaître et vérifier que c'est bien l'extension PECL qui est utilisée.

Voilà, pour les prochaines visites, la géolocalisation fonctionnera.

Si vous voulez que les anciennes visites soient reconsidérées, il faut utiliser le script geoipUpdateRows.php en ligne de commande (php geoipUpdateRows.php). À partir de la version 1.9, il se trouve dans /path/to/piwik/misc/others/geoipUpdateRows.php . Si vous avez installé le plugin vous-même, il se trouve dans /path/to/piwik/plugins/GeoIP/geoipUpdateRows.php .

Il faudra ensuite vous connecter à votre base de données et supprimer toutes les tables commençant par "piwik_archive_". En actualisant l'interface de Piwik, vous devrez voir les pays de vos visiteurs.

Bien entendu, et je parle surtout pour un chroot, il faut qu'Apache ait accès à une bibliothèque de résolution DNS et qu'il y ait un fichier resolv.conf dans le chroot.

J'utilise WordPress et il y a plein de statistiques inutiles !

En effet, il y a des requêtes internes à WordPress (wp-cron), les requêtes liées à l'administration (wp-admin), ... Il est possible d'exclure des user-agents (--useragent-exclude) et des chemins (--exclude-path / --exclude-path-from) avec le script d'import.

Pour éliminer les requêtes concernant wp-cron et l'administration, quelque chose comme cela suffira : "--exclude-path=/wp-[ac]*"

J'utilise WordPress et je vois encore les requêtes concernant le flux RSS

C'est l'inconvénient du parsing de log : on voit tout. On peut néanmoins résoudre le problème mais cela se fait en deux temps.

Dans un premier temps, on filtre */feed*, ce qui permettra d'exclure les urls comme :

  • www.guiguishow.info/feed/
  • www.guiguishow.info/feed
  • www.guiguishow.info/2012/11/03/piwik-importer-depuis-les-logs/feed/ (très utilisé par les bots spammeurs pour vérifier si leur commentaire est posté).

Pour ce faire : "--exclude-path=*/feed*"

Vous allez vous apercevoir qu'il reste encore des visites avec comme chemin "?feed=rss2". Vous allez tenter de les exclure avec une regex mais cela ne fonctionnera pas.

Pour essayer de comprendre, j'ai étudié le code source et j'ai placé des affichages sauvages un peu partout pour voir les chemins traités à chaque étape. J'ai trouvé que ces URLs ne sont jamais passées dans le filtre "exclude". Même en fin de processus, au moment où les hits sont mis dans la queue finale avant envoi, elles n'apparaissent pas (hit.path n'est jamais égal à "?feed=rss2"). En revanche, le referrer de certaines requêtes correspondent avec la chaîne recherchée.

J'en deduis que, indépendamment du script d'import, si Piwik voit une url de votre site en referrer, il l'ajoute en hit même si aucune requpete n'y correspond. Ça parait logique : si cette url apparaît en referrer, alors le visiteur a consulté cette url auparavant. Bien sûr, ce raisonnement se heurte aux referrer modifiés volontairement.

La seule idée qu'il me vient est la suivante : par défaut, c'est-à-dire si vous n'avez pas activé l'option "--enable-http-redirects", les redirections HTTP (301, 302, autres 3xx sauf 304) sont exclues des logs. Nous allons donc rediriger /?feed=rss2 vers /feed/ que nous avons déjà exclu. La redirection ?feed=rss2 -> /feed/ sera ignorée et la consultation de /feed/ qui suivra sera tout aussi ignorée. Ainsi ces hits n'apparaîtront pas dans vos stats et votre visiteur sera redirigé de manière transparente.

Cela peut se faire avec un rewrite mais j'ai choisi de le faire avec la directive RedirectMatch disponible dans le mod alias. Il suffit de spécifier ça dans la configuration d'Apache :

RedirectMatch ^/?feed=rss2$ /feed/

Mais je vois encore mes visites sur les pages "normales"

Là encore, c'est l'inconvénient du parsing de log. Le cookie d'exclusion ne peut pas être utilisé puisqu'il n'apparaît pas dans les logs. L'exclusion de votre IP dans l'interface de Piwik ne fonctionne pas avec le script d'impot.

Si vous avez une IP fixe, on peut toujours imaginer un filtrage avec "grep -v" avant de passer le fichier de log ainsi traité au script d'import.

On peut imaginer une exclusion basée sur un user agent (--useragent-exclude) spécifique qu'une extension Firefox vous ferez prendre uniquement sur votre site.

Bref, on peut imaginer plein de choses mais il faut voir si c'est réalisable et si ce n'est pas utiliser un bazooka pour écraser une mouche 😉 .

Sources

Utiliser LXC sur un Kimsufi

Lorsque l'on veut compartimenter ses services sans trop d'impact sur les performances, on pense à la virtualisation par conteneurs. Souvent, on pense OpenVZ.

On peut se demander quelles différences existent entre OpenVZ et LXC. Comme je ne suis pas un expert, je me contente de reprendre les réponses que l'on peut lire n'importe où sur le web :

  • LXC n'a pas besoin d'un noyau spécial contrairement à OpenVZ.
  • LXC aurait une gestion du réseau beaucoup plus simple qu'OpenVZ.
  • OpenVZ a été supprimé des packages officiels Debian.

Je vous propose d'installer et d'utiliser LXC sur un Kimsufi d'OVH équipé d'une Debian stable 64 bits. Le sujet ayant été abordé de nombreuses fois, ce billet ne sera finalement qu'une compilation des différentes sources avec une correction de ce qui ne marche pas chez moi.

Table des matières

Installer LXC

Pour éviter quelques problèmes, nous allons installer la version 0.8 présente dans les backports pour Squeeze.

Pour utiliser les backports, il faut ajouter cette ligne à votre fichier /etc/apt/sources.list :

deb http://backports.debian.org/debian-backports squeeze-backports main

Installation :

apt-get update && apt-get -t squeeze-backports install lxc

Dans l'interface de configuration semi-graphique, laissez le répertoire proposé.

Compiler un noyau utilisant les cgroups + grsec

Le kernel compilé par OVH n'a pas le support des cgroups qui est requis par LXC.

Je pense qu'installer un noyau Debian standard (apt-get -t squeeze-backports install linux-image-amd64 linux-headers-amd64) doit résoudre le problème sans rien casser.

Mais ici nous voulons activer les cgroups et conserver grsec qui est activé sur les noyaux OVH.

Afin de réduire le temps de compilation, il faut envisager de compiler sur votre desktop, pas sur votre KS. Comptez 1h sur un KS 2G contre 15 minutes sur une machine récente ...

On vérifie que l'on a bien tous les outils nécessaires à la compilation :

apt-get install make gcc libncurses5-dev lzma dpkg-dev

On se prépare un dossier de travail :

mkdir /usr/src/kernel && cd /usr/src/kernel

On récupère les sources du dernier 3.2 :

wget -c https://www.kernel.org/pub/linux/kernel/v3.0/linux-3.2.31.tar.bz2

On les décompresse :

tar jxf linux-3.2.31.tar.bz2

On récupère le dernier patch grsec :

wget -c https://grsecurity.net/stable/grsecurity-2.9.1-3.2.31-201210111928.patch

On applique le patch grsec :

cd linux-3.2.31 && patch -p1 < ../grsecurity-2.9.1-3.2.31-201210111928.patch

On récupère la config OVH + grsec :

wget "https://www.dguillem.fr/dokuwiki/_export/code/public/ovh/kernel-3.2.13-grs-config?codeblock=0" -O ".config"

ÉDIT du 17/02/2014 à 11h10 : L'url ci-dessus est cassée. Je mets mon .config à votre disposition (3.2.45, amd64, grsec et les options nécessaires à LXC déjà activées, issu du lien ci-dessus) :

wget "http://www.guiguishow.info/wp-content/uploads/2014/02/config-linux-3.2.45-amd64-ovh-grsec-lxc" -O ".config"

Il marche bien avec la version 3.2.54 aussi ... normal, c'est du 3.2.X.
Fin de l'édit

ÉDIT du 24/05/2014 à 14h32 : Toujours valide pour la version 3.2.58. Il suffit de laisser les réponses par défaut pour les nouveaux choix. Fin de l'édit

ÉDIT du 23/07/2015 à 15h50 : Toujours valide pour la version 3.2.69. Il suffit de laisser les réponses par défaut pour les nouveaux choix. Mais pour ceux qui veulent directement le bon fichier :

wget "http://www.guiguishow.info/wp-content/uploads/2014/02/config-linux-3.2.69-amd64-ovh-grsec-lxc" -O ".config"

Fin de l'édit

On configure notre noyau :

make menuconfig

Dans l'interface semi-graphique, voici les options à activer en supplément :

General setup -> Control Group Support -> Memory Resource Controller Swap Extension
General setup -> Control Group Support -> Memory Resource Controller Swap Extension enabled by default
General setup -> Control Group Support -> Enable perf_event per-cpu per-conteneur group (cgroup) monitoring
General setup -> Control Group Support -> Group CPU scheduler -> CPU bandwidth provisioning for FAIR_GROUP_SCHED
General setup -> Control Group Support -> Group CPU scheduler -> Group scheduling for SCHED_RR/FIFO

General setup -> Namespace support -> User namespace
General setup -> Namespace support -> PID Namespaces
 
Networking support -> Networking options -> GVRP (GARP VLAN Registration Protocol) support

Device Drivers -> Network device support -> MAC-VLAN support
Device Drivers -> Network device support -> MAC-VLAN based tap driver
Device Drivers -> Network device support -> Virtual ethernet pair device
 
Device Drivers -> Character devices -> Support multiple instances of devpts

Security options -> Grsecurity -> Customize Configuration -> Sysctl Support -> Sysctl support
Security options -> Grsecurity -> Customize Configuration -> Sysctl Support -> Turn on features by default

Vous pouvez également donner un suffixe au nom de votre kernel afin de l'identifier. Cela se fait dans General Setup -> Local version - append to kernel release

lxc-checkconfig permet de vérifier que l'on a bien activé toutes les options requises par LXC :

CONFIG=/usr/src/kernel/linux-3.2.31/.config lxc-checkconfig

Normalement, vous devriez obtenir un "enabled" à chaque ligne. "File capabilities" peut être marqué comme "missing", ce n'est pas bloquant.

On lance la compilation :

make deb-pkg

Si vous compilez sur votre desktop, vous pouvez profiter du multithreading (sous Debian, il vous faudra alors le package supplémentaire gcc-4.7-plugin-dev) :

make deb-pkg -j <nombre de coeurs + 1>

En version automatique (et avec du bashisme inside ) :

make deb-pkg -j $((`nproc`+1))

Pour nproc, voir ici.

Une fois la compilation terminée, vous pouvez installer votre nouveau noyau :

cd .. && dpkg -i linux-image-3.2.31-grsec_3.2.31-grsec-1_amd64.deb linux-headers-3.2.31-grsec_3.2.31-grsec-1_amd64.deb

Note : si vous avez compilez sur votre desktop, pensez à transférer les deux paquets Debian sur votre KS via SCP ...

Normalement, votre kernel se placera en premier dans le menu de boot et donc, votre KS démarrera automatiquement sur votre kernel. Néanmoins, pour en être sûr, il suffit de désactiver l'entrée du menu boot créée pour le kernel OVH :

mv /etc/grub.d/06_OVHkernel . && update-grub2

Il ne vous reste plus qu'à faire démarrer votre KS sur votre kernel ...

reboot

Partitionner

Le but du jeu est de se créer une partition dédiée à nos conteneurs. Pour cela, nous allons prendre de l'espace sur la partition /home. Par la même occasion, nous allons augmenter la taille du swap.

Chacun ses goûts mais moi j'utilise parted :

apt-get install parted

Lister les partitions :

parted
(parted) print

Normalement, vous avez une première partition primaire en ext4 sur lequel se trouve Debian. La deuxième partition (la plus grande), est montée sur /home. La dernière, de 512Mo est le swap. Si ce n'est pas le cas, réfléchissez avant de continuer et remplacez mes commandes par les commandes adaptées à votre situation !

Nous allons :

  • Écraser la partition 2 pour en faire deux partitions : une pour stocker les conteneur, l'autre pour vos données.
  • Détruire le swap pour le recréer avec une taille de 1Go.

Suppression des deux partitions :

rm 2
rm 3

Création de la partition pour les conteneurs (environ 100Go) :

mkpart
primary
ext2 (entrée)
21,5GB
125GB

Création de la partition pour les données (le reste moins 1Go) :

mkpart
primary
ext2 (entrée)
125GB
999GB

Création du swap (-1 = tout l'espace restant)

mkpart
primary
ext2 (entrée)
999GB
-1

Le travail est finit, on quitte parted.

q

Formatage des partitions :

mkfs.ext4 -L CONT /dev/sda2
mkfs.ext4 -L DATA /dev/sda3
mkswap /dev/sda4

Nous allons corriger /etc/fstab :

/dev/sda2	/home			ext4	defaults,relatime		0	2

devient :

/dev/sda3	/home			ext4	defaults,relatime		0	2

Utilisation de LVM

Chaque système de fichiers de chacun de nos conteneurs LXC sera stocké dans un volume logique indépendant.

Création du volume physique :

pvcreate /dev/sda2

Création du groupe de volumes (appelez-le comme vous voulez, dans le cadre de ce billet, ça sera CONT ...) :

vgcreate CONT /dev/sda2

Création d'un premier volume logique destiné à notre premier conteneur (appelez-le comme vous voulez, dans le cadre de ce billet, ça sera CONT1 et adaptez la taille, pour moi, ça sera 25Go ...) :

lvcreate -n CONT1 -L 25G CONT

Formatage de ce premier volume logique :

mkfs.ext4 -L CONT1 /dev/CONT/CONT1

Préparation de LXC

Installation du nécessaire :

apt-get install bridge-utils debootstrap libvirt-bin

Ajout de deux lignes au fstab :

cgroup		/sys/fs/cgroup 		cgroup	defaults			0	0
/dev/CONT/CONT1	/var/lib/lxc/CONT1	ext4	defaults			0	2

Montage :

mkdir /var/lib/lxc/CONT1 && mount /dev/CONT/CONT1
mount cgroup

Lors de la création d'un conteneur, LXC vérifie que le dossier portant le nom de la machine n'existe pas. Or, comme nous voulons un volume logique/conteneur, nous sommes obligé de monter le volume logique avant la création du conteneur et donc ... le répertoire existe. De manière plus claire : LXC n'appréciera pas l'existence de /var/lib/lxc/CONT1. Il faut bypasser ce comportement en modifiant le fichier /usr/bin/lxc-create. Il faut répérer le code suivant :

if [ -d "$lxc_path/$lxc_name" ]; then
    echo "'$lxc_name' already exists"
    exit 1
fi

Et commenter, au minimum, la ligne contenant le exit.

Création d'un premier conteneur LXC

D'abord, désactivons temporairement certaines fonctions de grsec :

echo 0 > /proc/sys/kernel/grsecurity/chroot_deny_mount
echo 0 > /proc/sys/kernel/grsecurity/chroot_caps

Si vous ne le faites pas, alors, vous aurez une erreur de ce type lors du lxc-create :

W: Failure trying to run: chroot /var/cache/lxc/debian/squeeze_amd64.partial mount -t proc proc /proc

Le fichier /var/cache/lxc/debian/squeeze_amd64.partial/debootstrap/debootstrap.log contiendra une erreur de ce type :

mount: permission denied

Et dmesg vous retournera un message du type "use of CAP_SYS_ADMIN in chroot denied"

Création du conteneur :

lxc-create -n CONT1 -t debian

Vous voici dans une interface smi-graphique.
Preseed file : laissez vide
Debian Squeeze
64 bits PC

Archives : laissez comme ça
Miroir : ftp://mirror.ovh.net/debian/ (autant prendre le plus proche 😀 )
Laissez les autres miroires tels quels
Choisissez uniquement la distribution main
Packages : iputils-ping traceroute iptables wget nano rsyslog bash-completion (cela permet d'installer d'office les commandes ping/traceroute/iptables/wget/nano, d'avoir un rsyslogd comme démon de logging et d'activer un minimum d'autocompletion)
Mot de passe root : à choisir avec attention 😉

On n'oublie pas de réactiver les fonctionnalités de grsec :

echo 1 > /proc/sys/kernel/grsecurity/chroot_deny_mount
echo 1 > /proc/sys/kernel/grsecurity/chroot_caps

Configuration réseau

Pour cette partie, je vous renvoie sur un autre tuto dans lequel les différentes possibilités sont bien expliquées : Linux conteneurs sur KIMSUFI OVH.

Prêt pour le lancement

Il faut créer les fichiers spéciaux correspondant à chaque console virtuelle :

mknod -m 666 /var/lib/lxc/CONT1/rootfs/dev/tty1 c 4 1
mknod -m 666 /var/lib/lxc/CONT1/rootfs/dev/tty2 c 4 2
mknod -m 666 /var/lib/lxc/CONT1/rootfs/dev/tty3 c 4 3
mknod -m 666 /var/lib/lxc/CONT1/rootfs/dev/tty4 c 4 4
mknod -m 666 /var/lib/lxc/CONT1/rootfs/dev/tty5 c 4 5
mknod -m 666 /var/lib/lxc/CONT1/rootfs/dev/tty6 c 4 6

Si vous ne le faîtes pas, vous n'aurez pas de prompt avec lxc-console.

Pour que SSH fonctionne, il faut générer les clés du serveur :

ssh-keygen -t rsa -f /var/lib/lxc/CONT1/rootfs/etc/ssh/ssh_host_rsa_key
ssh-keygen -t dsa -f /var/lib/lxc/CONT1/rootfs/etc/ssh/ssh_host_dsa_key

Pour que le conteneur utilise le fuseau horaire local :

echo "Europe/Paris" > /var/lib/lxc/CONT1/rootfs/etc/timezone
cp /var/lib/lxc/CONT1/rootfs/usr/share/zoneinfo/Europe/Paris /var/lib/lxc/CONT1/rootfs/etc/localtime

Lancement

lxc-start -n CONT1 -d

Obtenir une console :

lxc-console -n CONT1

Éteindre le conteneur en douceur (la manière brutale se fait avec lxc-stop) :

lxc-halt -n CONT1

Connaître l'état du conteneur

lxc-info -n CONT1

Démarrage automatique d'un (ou plusieurs) conteneur(s)

Pour démarrer un ou plusieurs conteneur au boot, il suffit simplement de placer un lien symbolique pointant vers le fichier de configuration du(des) conteneur(s) à démarrer dans le dossier /var/lib/lxc/auto. Exemple :

ln -s /var/lib/lxc/CONT1/config /etc/lxc/auto/CONT1.conf

Et pour chaque nouveau conteneur ?

Pour chaque nouveau conteneur, il suffira de créer son volume logique, de le formater, de le monter et d'ajouter la ligne "kivabien" dans /etc/fstab.

Il faudra désactiver les 2 fonctionnalités de grsec, créer le conteneur (lxcreate quoi) et réactiver les fonctionnalités de grsec.

Il faudra configurer l'accès au réseau du conteneur puis il faudra faire les modifications pré-lancement (création des tty, génération des clés SSH, ...).

Tout cela doit s'automatiser facilement avec un script mais je n'ai pas étudié la question.

Note

Normalement, depuis sa version 0.8, LXC est capable d'automatiser la création et l'utilisation de volumes logiques. Ainsi, une commande comme celle-ci "lxc-create -t debian -n test -B lvm --vgname CONT --fssize 5G --fstype ext4" doit créer un conteneur et son volume logique associé. Mais la création échoue. Cela semble être un bug reproductible : http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1062961.html.

J'ai essayé de comprendre et sans être un expert, voici où j'en suis arrivé :
Dans le fichier lxc-debian, ligne 484, en plein dans la fonction Copy_system (), on copie un dossier de la forme /var/cache/lxc/squeeze_amd64 dans le dossier /var/lib/lxc/NOM_CONT/rootfs/squeeze_amd64. On essaye ensuite d'accéder à/ou de monter des dossiers de la forme /var/lib/lxc/NOM_CONT/rootfs/etc/apt/sources.d/debian/list. Mais il n'y a rien ici, tout est dans le dossier squeeze_amd64.

Ce problème n'est pas réparé avec la version de LXC présente dans le dépôt unstable. Je ne sais pas si la version actuelle (via git) corrige ce problème.

Si vous voulez absolument utiliser cette fonctionnalité, voilà une solution qui semble marcher :
Remplacer la ligne 484 de /usr/share/lxc/templates/lxc-debian par

cp -Ra "${_CACHE}/${_DISTRIBUTION}_${_ARCHITECTURE}" "${_ROOTFS}"/* || return 1

Procéder à la création normale du conteneur.

Modifier ensuite le fichier de configuration (ex : /var/lib/lxc/NOM_CONT/config) afin que le paramètre lxc.rootfs contienne la bonne valeur (/var/lib/lxc/NOM_CONT/rootfs). Si vous ne faîtes pas cela, alors vous aurez une erreur "unable to determine your tty name" lors du login via lxc-console.

N'oubliez pas d'ajouter une ligne dans /etc/fstab pour que le conteneur puisse démarrer tout seul. Exemple :

/dev/CONT/test	/var/lib/lxc/test/rootfs	ext4	defaults			0	0

Puis monter ce volume logique comme d'habitude. Vous pouvez ensuite utiliser lxc-start.

Cette méthode me paraît vraiment "bricolage". Je préfère créer/monter moi-même le volume logique ...

Sources

IRSSI, Windows et les accents

IRSSI est un client IRC multiplateforme.

Sur une Debian/Debian-like, pour l'installer : apt-get install irssi. Sous Windows, il suffit de télécharger l'archive auto-extractible sur le site officiel et de l'extraire dans %PROGRAMFILES%/IRSSI ou %PROGRAMFILES(X86)%/IRSSI.

Sous GNU/Linux, il se configure depuis ~/.irssi/config. Sous Windows 7, la configuration se trouve en : C:\Users\\.irssi\config.

Pour le configurer, sous nux comme sous Windows, il suffit de modifier ce fichier de configuration. On peut également configurer IRSSI depuis son interface et lui demander de sauvegarder les paramètres une fois la configuration terminée. Voir : Irssi - client IRC en mode console sur doc.fedora-fr.org ou Irssi sur doc.ubuntu-fr.org. Un tutoriel est également disponible sur le Site du Zéro.

Une fois configuré et connecté aux chan, quelques infos (trouvables dans la doc pour débutant d'IRSSI, m'enfin ...) :

  • Si vous avez join plusieurs chan, vous pouvez passer d'un chan à un autre avec Echap+ (alt+n ne marche pas sous Windows). est un nombre à saisir au pavé numérique (ou avec les chiffres de la deuxième rangée de touches de votre clavier). Vous pouvez aussi utiliser CTRL+N/P pour naviguer de chan en chan.
  • Si vous voyez [Act: ...] dans la barre de statut, c'est qu'il y a eu de l'activité dans une ou plusieurs autre(s) fenêtre(s) : si le numéro de la fenêtre est en bleu : il s'agit d'un message du type join/quit/... Si c'est en blanc, alors ça discute. Si c'est en mauve/violet, alors quelqu'un a fait référence à votre pseudo, ...
  • Si vous voulez garder la conversation qui vient d'avoir lieu mais que vous n'avez pas configuré le logging/auto-logging d'IRSSI, vous pouvez sauvegarder le buffer avec la commande : /LASTLOG -file ~/irc.log. Sous Windows, le log arrivera dans C:\Users\\irc.log. Vous pouvez également naviguer dans le buffer avec les touches PgUp et pgDn de votre clavier.
  • Il est également possible de mettre en évidence une ligne dans laquelle un mot qui vous intéresse a été écrit. C'est la fonctionnalité "text highlighting" d'IRSSI.

Pour enregistrer votre pseudo ou créer un chan, vous devez communiquer avec un bot. Sur Geeknode, il s'agit de C. Sur Freenode, il s'agit de NickServ/ChanServ ...

Venons-en maintenant au sujet de cet article : ces foutus accents sous Windows !

Sous Windows, IRSSI utilise PuTTY qui, par défaut, utilise un encodage iso8859-1. Pour éviter de galérer, je vous propose :

  1. De passer sous un OS propre :D.
  2. Plus sérieusement, il s'agit, dans un premier temps, de définir l'encodage par défaut de PuTTY. Si vous utilisez PuTTY pour un autre usage, ouvrez-le comme d'habitude. Sinon, exécutez le binaire puttycyg.exe qui se trouve dans le dossier d'installation d'IRSSI. Sélectionnez la session "Default Settings" et cliquez sur "Load". Ensuite, allez dans "Translation" et choisissez "UTF-8" dans la liste. Enfin, revenez dans "Session" et cliquez sur "Save".
  3. Si le problème n'a pas disparu, ouvrez le fichier de configuration et utilisez la directive "term_charset = "utf-8";" dans chaque bloc "server" qui supporte cet encodage.
  4. Si le problème n'a toujours pas disparu, il faudra jouer avec la fonctionnalité recode d'IRSSI.

IRSSI possède tout un tas de possibilités comme émettre un "bip" quand quelqu'un mentionne votre pseudo (oui, comme MSN !). Je vous laisse découvrir tout ça ... avec le manuel d'IRSSI. 😀