Howdy, journal !

Peut-être te souviens-tu que j'aime jouer avec les conteneurs [1], qui me permettent d'avoir une certaine forme de virtualisation, sans pour autant devoir jeter mes braves Athlon-XP, qui jouent vaillamment le rôle de serveurs depuis déjà quelques années.

Oui mais voilà : qui dit conteneurs, dit multiplication du nombre de machines à maintenir... et donc dit trouver des solutions pour faciliter la chose. C'est donc ainsi que je me suis mis à jouer avec puppet [2] depuis quelque temps... problème : puppet me bouffe pas mal de RAM, dans les 25Mo de mémoire virtuelle par conteneur, le chargement de Ruby oblige. Or les Athlon-XP sont de "vieilles" machines 32 bits, plutôt limitées quant à la RAM qu'elles peuvent embarquer (respectivement 2 et 3Go maximum sur mes serveurs).

La RAM m'est donc une denrée précieuse que je dois économiser, sous peine de devoir limiter le nombre de mes conteneurs. Or, depuis Lenny, Debian a décidé de passer de sysklogd, par défaut, apparemment plus vraiment maintenu, à rsyslog [3]. Sauf que ça a un méchant coût. Prenons un conteneur sous Lenny que j'ai basiquement "debootstrapé", en lui rajoutant juste exim4-daemon-light, sshd et puppet. Avec rsyslog, un "free -m" m'indique 58Mo de mémoire occupée. Avec syslogkd, la même chose m'indique 32Mo. J'ai aussi voulu comparer avec syslog-ng, déclaré comme "seul autre acteur majeur dans les solutions de log", par le développeur principal de rsyslog [4] : 33Mo.



Alors, j'en vois sourire : "Tu joues ta mijorée pour 25Mo de RAM ? En 2008 ?" ... bah, oui... à choisir, je préfère un système de logs un peu moins évolué, mais avoir puppet installé... Je fais déjà presque tourner une vingtaine de conteneurs dans la machine qui a le plus de RAM, et je prévois d'en faire tourner entre 30 et 40 à terme (un service : un conteneur... ça va vite : par exemple, comme j'ai lourdé bind, en faveur de NSD et unbound [plus parce que c'est infiniment plus simple à configurer que pour une autre raison, l'argument de la légèreté étant balayé par la démultiplication que j'en fais], pour reproduire le système de vues [views], ça bouffe forcément de la resource - 2 conteneurs par DNS, un autoritaire, et un récursif ; sur 3 vues ["DMZ" pour mes invités, DMZ pour les serveurs publics et les serveurs dont ils ont besoin, et DMZ plus réseau, ces deux derniers, internes], en rajoutant le conteneur pour no-ip, vu que je suis avec Orange en cambrousse, ça me fait déjà 7 conteneurs pour gérer DNS). 25Mo de RAM sur un tel nombre potentiel de conteneurs, ça fait environ 1Go de RAM bouffé par les logs (vous me direz que ça en fait autant de bouffé par puppet : certes - mais il m'apporte une valeur ajoutée bigrement considérable)...

... et la machine ne disposant que de 2,5Go de RAM pour les conteneurs, ça fait une différence de presque la moitié de la RAM totale entre rsyslog et le reste (ce qui fait que, avec puppet, il ne me resterait presque plus rien pour les services... et encore, là, j'ai mesuré la RAM occupée au démarrage du conteneur ; m'enfin, même si l'occupation monte un peu dans le temps, ça reste quand même dans ces eaux-là).

Bon, rsyslog a l'air plus puissant que syslog-ng [5], notamment au niveau des capacités à "loguer" à distance, et à gérer les bases de données... Mais même si j'y jette un œil de temps en temps, et que, à l'occasion, je leur ai déjà dû de fières bretelles, je ne suis pas non plus un gros maniaque des logs : c'est probablement un tort, mais je les regarde surtout quand quelque chose me tracasse ; au pire, pour les machines publiques, j'en garde quand même des archives.



Du coup, quitte à choisir un système de log maintenu, et même reconnu comme bon par ses concurrents, même s'il l'est un peu moins que rsyslog, je pense que je vais migrer vers syslog-ng, pour mes conteneurs, au moins, vu les resources dont je dispose. Et toi, multitude du journal : qu'utilises-tu comme système de logs, et pourquoi ?

Et log, tu le traduis comment ? Journal, consigne, archive, mémojournél, ... ?



[1] http://linuxfr.org/~Aefron/27379.html
[2] http://reductivelabs.com/trac/puppet
[3] http://wiki.debian.org/Rsyslog
[4] http://blog.gerhards.net/2007/08/why-does-world-need-another(...)
[5] http://www.rsyslog.com/doc-rsyslog_ng_comparison.html

> Lire le journal (24 commentaires, moyenne: 1,9).

Howdy, journal !

Suite du journal de jeudi dernier [1], en ayant le bon goût, au passage, d'en profiter pour mettre les liens vers les sites concernés (au cas où quelques uns ne les auraient pas encore dans leurs marque-pages).

'a y est : gentoo-portage.com [2] est de nouveau en ligne, à partir des sauvegardes.

Par contre, plus de miniatures des programmes, pas plus que de commentaires d'utilisateurs : ça, c'est perdu... Mike (qui loue et administre ces serveurs) vous encourage donc tous à poster comme des dingues pour en rajouter.

Pour ce qui est du wiki [3], il n'est pas encore revenu en ligne et les sauvegardes les plus récentes semblent dater de mars dernier... Il semble que Mike veuille néanmoins le remettre sur pied au plus vite, à commencer par le canal IRC et le forum, où pourront être discutés les détails de ce qu'il appelle "le nouveau wiki".



Il en profite pour donner un peu plus de détails quant à l'affaire : il semble que TelX (l'hébergeur de Mike) surfacturait Skiplink (le centre de données où étaient les machines), qui a donc commencé à déplacer ses machines vers un autre centre de données, sans vouloir payer ce qu'ils considéraient comme de l'extorsion (et évidemment, Mike n'était pas considéré comme une "personne très importante", et donc, était en fin de la liste des machines à déplacer)...

D'après ce qu'on peut comprendre de ses déclarations, tout le monde a merdé :

- TelX aurait été d'une honnêteté douteuse quant à leurs facturations à Skiplink, et à la demande de faire payer les clients de ce dernier pour récupérer leurs données ;
- Skiplink n'a pas prévenu les clients qu'ils ne considéraient pas importants, et s'en est peu ou prou foutu de récupérer leurs données (bien qu'il semble que les machines aient été à eux) ;
- Mike n'a pas été assez consciencieux avec la sauvegarde des données ;



Voilà : l'heure est maintenant davantage à la reconstruction, et j'ose imaginer que la participation de tous ceux qui le voudront sera utile à la remise sur pieds de ces fantastiques bases de données (je me suis encore servi du cache de google cette semaine pour accéder à l'entrée du wiki pour udev... lors même que je suis debianneux)...

... en espérant qu'une telle catastrophe n'est pas près de se reproduire...

... et en espérant que Gentoo, en tant que distribution, finisse par reconnaître que ce wiki (ça n'engage que moi) est probablement l'une des meilleures sources (si ce n'est la meilleure... j'hésite avec LFS/BLFS, peut-être moins détaillée, d'une certaine manière, mais plus structurée ; ce qui fait que les deux sont difficilement comparables) de connaissances linuxiennes sur le Net ; et se décide à le prendre sous son aile.



[1] http://linuxfr.org/~Aefron/27383.html
[2] http://gentoo-portage.com/
[3] http://gentoo-wiki.com/

> Lire le journal (6 commentaires, moyenne: 2,8).

Howdy, journal !

Bien qu'étant maintenant très Debianeux (depuis Etch, pour diverses raisons), il y a des choses que je ne renierai pas : mes époques LFS, OpenBSD ou encore Gentoo (je ne cite pas OpenWRT, m'y étant remis récemment)...

Gentoo... rah, ces heures à regarder défiler la compilation, comme si je me matais un épisode d'Hypno-toad (cf Futurama... en VF, ça doit être Hypno-crapaud, ou quelque chose comme ça)...

Et sa documentation : autant celle de base, pour installer en chrootant à partir du live-CD minimal, que celle du Gentoo-wiki.com - qu'est ce que j'ai pu y apprendre ! Sans compter l'excellent site de recherche des paquets dispos, Gentoo-portage.com (bon, ça, au moins, c'est un des seuls trucs que j'aime bien sur le site de Debian : leurs pages de recherche de paquets sont vraiment bien foutues... c'est toujours ça, dira-t-on, aussi bien en bonne, qu'en mauvaise langue).



Sauf que là, c'est le drame... historique des faits de ces derniers jours, tels que narrés sur la page vers laquelle nous renvoie toute tentative d'accès à ces deux derniers URL (p'tain : en ce moment, je n'ai pas de chance, avec les sites auxquels je veux accéder... cf mon journal sur le Deathmatch : LDLC vs Tor... backupez bien LinuxFr, on ne sait jamais ;)...

- 17 octobre, vers 1h du matin, UTC-5 : les deux sites sont soudain inaccessibles ;

- 18 octobre : Skiplink, l'hébergeur de ces sites ne répond pas ; l'inquiétude gagne Mike Valstar, qui loue et administre deux serveurs chez eux (pas dans le même rack), dont l'un à la charge de s'occuper des backups de l'autre, qui fait tourner les sites qui nous intéressent ici ; le "téléphone arabe" finit par lui apprendre qu'il y a eu une méchante coupure de courant, mais qu'il semble qu'il y ait surtout un différent entre son hébergeur, et le centre de données dans lequel sont les machines : il commence à penser à changer d'hébergeur, mais pour l'instant, il faut attendre de récupérer les données ;

- 19 octobre : toujours aucune réponse de Skiplink... Mike pense migrer vers Amazon C2, et se mettre à dupliquer ses sauvegardes un peu partout où il le pourra... mais, pour l'instant, il est un peu tard pour agir ;

- 21 octobre : toujours aucune réponse de Skiplink... Arrive la confirmation selon quoi Skiplink doit de l'argent à TelX (chez qui sont physiquement les racks) ; ces derniers sont d'accord pour redémarrer le serveur (contre écus sonnants, pour le courant), mais pas de bol, le réseau est déjà coupé vers les racks incriminés, et ça ne permettrait pas de récupérer les données de l'extérieur...

- 22 octobre : seul TelX peut maintenant permettre de sortir de la panade... 5 options sont envisagées ;

1) Payer le courant pour redémarrer les serveurs (mais si ils sont coupés du réseau...) ;
2 ) Donner les numéros de série des serveurs à TelX, et signer une décharge de responsabilité, pour récupérer les données : sauf que Skiplink refuse de donner les numéros de série des machines ;
3) Payer le branchement de consoles à toutes les machines des racks, pour que Mike puisse trouver tout seul les siennes (au risque de foutre le bordel dans des machines d'autres personnes, et en être tenu responsable) ;
4) Attendre un délai légal de 120 jours, au-delà desquels il semble que TelX (ou Skiplink... je ne suis pas sûr d'avoir bien compris à qui étaient les machines, et je ne m'y connais pas assez en hébergement pour affirmer ça de manière certaine) puisse faire ce que bon lui semble des babasses ;
5) Engager des ninjas ou des pirates pour récupérer les données :o)

... en bref, ça pue... l'option 2) semble la plus raisonnable, mais, faute de grives, il faudrait se contenter de la 4)... on pourra ergoter que backuper sur le même site (même dans des racks différents), et chez le même hébergeur, ce n'est pas très sékioure...

Certes ; je crois qu'on n'y reprendra plus Mike...

En attendant, si par un improbable mais bienheureux hasard, quelqu'un ici pouvait, ou avait des connaissances qui pourraient, d'une manière ou d'une autre, permettre de sortir de cette vilaine panade, le mail de Mike est sur la page qui remplace ce qui était encore, jeudi dernier, ces deux merveilleux sites...

La suite... à un prochain épisode... peut-être.

> Lire le journal (23 commentaires, moyenne: 3,1).

Howdy journal !

Aujourd'hui, je voudrais te parler d'un sujet qui m'est cher, sur mes deux serveurs (des vieilles babasses à base d'Athlon-XP... enfin, avec plein de RAM et de disques durs, quand même, hein) : les conteneurs ! Et plus particulièrement, les conteneurs avec OpenVZ, nouvel arrivant dans la prochaine Debian stable, ie Lenny.

Bon : j'annonce, c'est un _long_ journal (pas assez sensationnel pour en faire une dépêche pour autant... allez, mettons que c'est un article ). Maintenant, si vous voyez déjà l'intérêt de ce genre de solution, vous pouvez directement passer à la partie "2", si vous connaissez déjà VServer, vous pouvez directement passer à la partie "2-2", et si vous êtes un dessaïdeur pressé vous pouvez directement aller vous faire f à la conclusion, la partie "3".

Le sujet est plutôt vaste, et, malgré la longueur, je ne fais que l'effleurer, en donnant quand même pas mal de petits trucs que j'ai appris en touchant aux bousins. En espérant que ce journal serve à quelques uns, qui voudront donner leur chance aux conteneurs (et en ne doutant pas un instant qu'il m'a servi et me servira, à moi, respectivement, à mettre mes idées un peu plus au clair, et, de "pense-bête" occasionnel [oui, je sais, c'est gros pour un bookmark perso])...




0 - Vaccination

Histoire de faire une petite piqûre de rappel, les conteneurs sont un cas particulier de virtualisation, laquelle peut-être subdivisée en deux grands types majeurs (ceci n'engage que moi, et ergoter sur les différences n'est pas tant mon propos que de présenter l'isolation via conteneurs sous Debian) :

- paravirtualisation/hypervision/machine virtuelle : ici, on a un noyau "hôte" sur un OS "hôte", qui va permettre de lancer des noyaux "invités" pour des OS "invités" - on va parler de paravirtualisation quand les noyaux "invités" ont été modifiés pour (ont "conscience" de) être virtualisés, et d'hypervision quand ce n'est pas le cas. Selon les possibilités du matériel, et la solution technique retenue, les noyaux invités pourront fonctionner directement sur le processeur de l'hôte, ou passer via une couche de virtualisation dans le noyau de l'hôte, voire en espace utilisateur. En guise d'exemples, on pourra citer Xen, Qemu, VirtualBox OSE, ou encore UML (je l'ai annoncé : je grossis le trait).

- isolation par conteneur : dans ce cas, on n'a qu'un seul noyau (hôte, forcément), qui va embarquer de quoi isoler une arborescence, dans laquelle fonctionneront des systèmes, dont les ressources (espace disque, arborescence, réseau, matériel spécifique, ...) seront mutuellement isolées. Je parlerai essentiellement de VServer [1] et d'OpenVZ [2], pour ce qui est des solutions que je connais le mieux (j'élude volontairement le cas des chroots, jails et cie, car je ne sais pas dans quelle mesure ça dépend du noyau ; il me semble qu'il y a dans ce dernier de quoi isoler les numéros de processus et des choses du même genre, mais je ne saurais en jurer).




1 - Intérêts

Depuis que je suis sous Etch, j'ai utilisé un noyau modifié avec les patches VServer, supportés par Debian. Concrètement, cela m'a permis d'avoir plusieurs sous-arborescences sous "/var/lib/vservers/", chacune correspondant à une machine virtuelle, avec sa propre adresse IP, ses propres utilisateurs, ses propres paquets, ses propres scripts d'initialisation, ses propres partitions, et ses propres accès à du matériel spécifique (imprimantes, scanner, cartes TV et partitions, pour l'usage que j'en ai).

D'aucuns pourraient me demander : "mais, pourquoi ne pas avoir tout mis sous la même arborescence ?" ... il y a plusieurs raisons à cela :

- maintenabilité : si je fais le con avec l'un de mes conteneurs, je n'ai a priori pas à m'inquiéter pour les autres ; par exemple, l'un des conteneurs est dédié au SqueezeCenter de chez slimdeviceslogitech... et ils ont la mauvaise pratique de ne pas signer leurs paquets : et bien, que foutre ! Seul ce conteneur accepte les paquets non signés de chez eux - je suis beaucoup plus regardant avec les autres conteneurs, en revanche. On pourrait plus globalement citer la ségrégation des ressources, mais encore faudrait-il préciser lesquelles on peut distribuer, et comment, ce que je développe plus loin.

- sécurité : bon, je ne vais pas m'avancer en prétendant que rajouter une couche de complexité est la solution miracle à tout (il y a la poudre verte, pour cela). Cela dit, l'utilisateur "root" dans un conteneur n'est "root" que dans celui-ci, et dans aucun autre (et encore moins "root" sur l'hôte). On pourrait aussi citer les "bind mounts" en lecture seule (bon, là, je triche : ce n'est disponible que, je crois, à partir des noyau 2.6.26, ie à partir de Lenny, et donc, pas sous Etch... mais c'est pour l'exemple) : SqueezeCenter n'a certainement pas besoin d'écrire sur la partition qui contient mes fichiers musicaux, contrairement à mon serveur chrooted-SFTP (pareil, je triche, un peu : disponible à partir, je crois, d'OpenSSH 5.x, soit à partir de Lenny aussi) mais uniquement de les lire. Et bien, les partitions sont, classiquement, montées dans le "/mnt" de l'hôte, puis "bind-mountées" dans les conteneurs, avec les options dont ils ont besoin : pas plus, pas moins. Reste que si quelque chose fait planter l'hôte (par exemple, un problème dans le noyau), tout tombe avec.

- versatilité : si le noyau est unique sur la machine, on peut néanmoins utiliser plusieurs distributions conjointement ; par exemple, Lenny pour une imprimante, mais Etch pour une autre ; voire de la Fedora, du CentOS, de la Mandriva ou que sais-je encore, en guise de conteneurs, sous une arborescence et un noyau hôtes Debian (et combinatoirement). Par contre, pas de conteneur BSD ou d'autres choses qui nécessitent ipso facto un noyau différent. Itout pour les architectures, bien que j'imagine qu'avec un noyau amd64, on puisse avoir des conteneurs x86 (pas testé, puisque je rappelle que mes serveur sont des Athlon-XP).




2 - VServer sous Etch vs OpenVZ sous Lenny

Pour ce qui est de cette partie comparative, je tenais à préciser que je n'ai pas testé VServer sous Lenny, et que je ne sais donc pas dans quelle mesure il aura évolué d'ici là (comptant bien remplacer mon noyau VServer par un noyau OpenVZ sur la machine où j'en ai un) : d'une, par manque de temps (je ne suis pas du tout professionnel de la chose - j'utilise du libre pour mon utilisation personnelle avant tout), de deux, par manque de machines (je pourrais avoir, en plus, un noyau VServer sur la machine où je teste OpenVZ, pour comparer sur la même révision de la distribution, mais reste le problème du temps... dont acte).

J'ai cela dit testé OpenVZ sous Etch (avant le backport, qui est depuis disponible) [3], en utilisant le noyau binaire pour Debian de chez OpenVZ (très peu), et celui de Thorsten Schifferdecker (ce que j'ai arrêté de faire après avoir galéré comme un coing pour trouver une adresse où le contacter, et ne jamais avoir reçu de réponse, une fois essayé, puisque dans l'intervalle, non borné, OpenVZ était arrivé dans Sid, ce qui par la même à fini par résoudre mes problèmes).


2-1) VServer
2-1-1) Déploiement

D'abord, pour ce qui est de VServer, celui-ci est très bien intégré dans Debian grâce aux "vserver-debiantools" (dispo depuis Sarge ! Pour laquelle des backports de noyau VServer sont d'ailleurs disponibles... bon, c'est juste pour appuyer que VServer dans Debian, ça ne date pas d'hier), qui permettent de générer un conteneur, dans "/var/lib/vservers/${NAME}" par exemple, sur un espace LVM préparé à l'avance, via :

newvserver --hostname ${NOM} --domain ${DOMAINE} --ip ${IP} --conffile ${FICHIER_CONF}

où le "conffile" va, notamment, permettre d'installer des paquets lors du déploiement du conteneur, et où l'adresse IP sera l'une des adresses IP de l'hôte (arf...).

2-1-2) Réseau

Oui, parce que ça, c'est quelque chose d'assez ennuyeux, avec VServer : les adresses des conteneurs sont en fait des adresses de l'hôte ; ce qui a pour embêtante conséquence la nécessité de devoir forcer un daemon à se lier à une adresse particulière si on veut le faire tourner sur plusieurs machines virtuelles dans la même machine physique (comme OpenSSH), ou de créer un alias entre localhost et l'adresse déclarée (ici, 192.168.0.2), car le loopback n'existe pas en tant que tel dans le conteneur (à noter que le loopback de l'hôte permet aux conteneurs de dialoguer entre eux). Niveau réseau, c'est donc plutôt limité. On pourrait dire que la pile réseau est davantage isolée que virtualisée.

2-1-3) Limites

Pour ce qui est des limites de mémoire utilisable, on peut gérer ça soit au niveau d'un fichier rlimits "/etc/vservers/name/rlimits", pour la RAM, soit via l'utilisation de l'utilitaire "vdlimit", pour les partitions. Cela dit, VServer n'est pas très exigeant quant à la spécification de ces limites, et, si on oublie de les déclarer, par exemple parce qu'on a largement assez de RAM, ou que les quotas de disque ne nous intéressent pas, vu qu'il est conseillé d'utiliser un volume logique de LVM pour chaque conteneur VServer, d'expérience, ce dernier ne mouftera pas.

2-2-4) Ressources

En cas de besoin, on peut aussi rajouter des capacités sur le noyau aux conteneurs, dans "/etc/vservers/name/bcapabilities", par exemple, "SYS_RAW_TIME", pour qu'un serveur NTP puisse accéder à l'horloge matérielle (autant le faire tourner dans un conteneur plutôt que sur l'hôte, pour lequel, moins il y a de services, moins il est vulnérable, aux plantages, aux failles, aux conneries, ...), ou "MKNOD", si on veut lui permettre de gérer des choses comme une carte TV (auquel cas, toujours selon cet exemple, il faudra faire un "cp -a" du "/dev/dvb" de l'hôte dans l'arborescence du conteneur). Si on devait accéder à /proc/bus/usb depuis le conteneur, on utiliserait la capacité "SYS_RAWIO", et on devrait aussi rajouter, dans "/etc/vservers/nom/fstab" (qui permettra aussi de monter les partitions ou de faire les "bindmounts" que l'on souhaite dans le conteneur), la ligne :

none /proc/bus/usb usbfs defaults 0 0

Pour ce qui est de jeter un œil aux ressources, un classique "top" sur l'hôte ne montrera pas ce qui se passe dans les conteneurs, mais un "vtop", avec les droits "root" montrera l'ensemble des processus et ce qu'ils consomment. De manière analogue, on aura "vps", "vpstree", "vdu", ...

Enfin, l'utilitaire générique "vserver" permet quant à lui d'agir sur les conteneurs à partir de l'hôte ("vserver ${NOM} start", "vserver ${NOM} exec", ...).

Bref, VServer est assez versatile et puissant, mais la simple isolation du réseau, en lieu et place d'une virtualisation plus avancée, est clairement un point faible.


2-2) OpenVZ
2-2-1) Déploiement

Passons maintenant à OpenVZ, fraîchement arrivé dans Lenny, il doit y avoir quelque chose comme deux mois.

L'installation d'un conteneur utilise basiquement un "profil", en fait, une archive compressée d'une arborescence, pour déployer rapidement une machine. Je le dis tout de suite : je n'aime pas du tout ça. A fortiori sur Lenny, qui, malgré la période de "freeze" bouge quand même pas mal, il est difficile de tenir une archive d'arborescence à jour, et je préfère une solution plus manuelle, mais plus efficace à mon sens : se monter un conteneur "approx" [4] (ou assimilé) en premier lieu. Ainsi, via un :

debootstrap --arch ${ARCH} ${DIST} /var/lib/vz/private/${ID} ${MIRROR}

utilisant le serveur "local" de paquets, on obtient un conteneur ("${ID}" est son numéro, 0 étant réservé, et étant conseillé d'assigner les autres aux conteneurs à partir de 1000), à jour, très rapidement, et on peut le modifier ensuite en y entrant via :

"vserver enter ${ID}"

C'est d'ailleurs la méthode qui est derrière l'utilitaire "newvserver" ("debootstrap", j'entends).

2-2-2) Limites

Bon, reste qu'il faut le configurer, ce nouveau serveur "virtuel". Tout d'abord, OpenVZ est très exigeant quant aux limites qu'on fournit à une machine... pas question de lui dire : "démerde-toi avec la RAM et l'espace disque - tu en as large assez". "/etc/vz/conf/" contient, notamment, des fichiers de la forme "${ID}.conf", définissant ce qui est possible dans chaque conteneur, et de la forme "un_nom.conf-sample", qui servent à appliquer une configuration de base aux conteneurs.

L'exhaustivité de ces fichiers peut faire peur, mais heureusement, le fidèle "vzsplit" est là pour nous permettre de confectionner une base adaptée à son matériel. Ainsi, un :

vzsplit -f un_nom -n numves -s swap_size

va créer un fichier "/etc/vz/conf/un_nom.conf-sample" qui va diviser les ressources de l'hôte entre "numves" conteneurs, pour une utilisation totale autorisée de "swap_size" la taille du swap en Kio. Ainsi, je découpe généralement les ressources de la machine en des conteneurs de la taille du plus petit (essentiellement, pour la RAM, ie 48Mo de RAM physique maximum utilisée pour mes plus petits conteneurs) que je compte utiliser, puis, je multiplie les paramètres qui m'intéressent afin de confectionner des "samples" pour les plus grosses machines (par exemple, "Tor" ou "MLDonkey" sont infiniment plus gourmands que "ntpd" ou "approx"). On peut ainsi limiter la mémoire non-swappable, la mémoire partagée, la mémoire physique, ... Chaque paramètre à une barrière (à ne pas dépasser, normalement), et une limite (au delà de la barrière, cette dernière pouvant être exceptionnellement outrepassée, si les ressources de la machine le permettent).

Les paramètres les plus importants pour la gestion de la mémoire sont probablement "oomguarpages" (quantités de pages mémoires de 4Kio utilisées à partir desquelles OpenVZ commencera à tuer les processus si la mémoire de la machine est surchargée : ici, seule la barrière a un sens), "vmguarpages" (barrière, en pages de 4Kio, de mémoire utilisable par le conteneur - la limite n'a pas de sens non plus, mais, si la barrière de "oomguardpages" n'est pas dépassée, le dépassement de la barrière de "vmguardpages" n'entraînera pas d'échec d'allocation, tant que les ressources de la machine le permettront), et "privvmpages" (quantité de pages pouvant être allouées, sans pour autant être nécessairement utilisées).

"diskspace" (en octets) et "diskinodes" permettent également de définir l'espace disque alloué au conteneur dans "/var/lib/vz/private" (il est d'ailleurs conseillé de faire une partition séparée pour ce répertoire, car les quotas de disque OpenVZ peuvent, d'après la documentation, entrer en conflit avec l'espace réservé à l'utilisateur "root", ce qui serait très gênant dans le cas de la partition racine de l'hôte). Je trouve personnellement ce système de quotas plus pratique à gérer qu'un LVM, mais après, rien n'empêche de faire les deux, si on veut. Par contre, les quotas ne marchent que sur la racine principale du conteneur, et pas encore sur les partitions de l'hôte qu'on pourrait vouloir y monter ou y "bindmounter".

Il n'est pas inutile non plus de mentionner "tcpsndbuf", "tcprcvbuf" ou encore "othersockbuf", concernant les buffers tcp et autres, qu'il peut être utile d'augmenter sur une machine très sollicitée sur le réseau. Existant un certain nombre de conditions à remplir, et la documentation d'OpenVZ sur le sujet [5] expliquant tout cela bien mieux que moi, je vous laisse vous y référer au besoin, si ce que fait "vzsplit" ne vous suffit pas, ou qu'il vous laisse perplexe.

Une fois le fichier "/etc/vz/conf/un_nom.conf-sample" créé, on peut l'appliquer au conteneur via :

vzctl set ${ID} --applyconfig un_nom --save

Barrières et limites pourront être surveillées via "/proc/user_beancounters", afin de prévenir d'éventuelles catastrophes, ou de s'assurer que les conteneurs n'ont pas besoin de plus de ressources (par exemple, si des mauvais réglages des limites de mémoires peuvent engendrer de méchants plantages, de mauvais réglages de buffers TCP dégraderont "juste" la disponibilité du conteneur, sans a priori occasionner de "oops").

2-2-3) Réseau

Reste alors à configurer le réseau via, par exemple :

vzctl set ${ID} --ipadd ${IP_ADDRESS} --save
vzctl set ${ID} --nameserver ${DNS_IP_ADDRESS} --save

Dans ce cas, l'adresse IP peut-être choisie avec de grandes latitudes. En effet, dans le cas d'OpenVZ, l'hôte fonctionne comme un routeur ; on n'oubliera donc pas d'activer le routage dans son petit noyau via :

echo 'net.ipv4.ip_forward=1'>/etc/sysctl.d/openvz.conf
sysctl -w net.ipv4.ip_forward=1

ni de déclarer les routes qu'il faut dans le reste de son réseau pour accéder aux conteneurs.

À la base, chaque conteneur dispose d'un loopback, et d'une interface réseau, en point-à-point avec l'hôte, sur un /32, chaque conteneur étant sur son sous-réseau dédié. C'est l'interface réseau de base, qui est nommée "venet" ("virtual network device", ie "périphérique réseau virtuel"). Les adresses ne peuvent cependant être spécifiées qu'à partir de l'hôte, et aucune règle iptables ou table de routage ne peut être spécifiée par le conteneur lui-même.

Mais c'est loin de s'arrêter là. En effet, il existe un autre type d'interface, "veth" (pour "virtual ethernet device", ie "périphérique ethernet virtuel"). La différence étant que "veth" permet d'avoir une carte réseau virtuelle complète, avec adresse MAC, spécification d'adresse IP, de routes, ou encore de règle iptables, à l'intérieur même du conteneur, sans oublier la possibilité de donner le contrôle d'une carte réseau ethernet physique au conteneur (je n'ai pas essayé, mais la documentation stipule que, en ce cas, l'hôte perd le contrôle de la carte réseau), ou de rajouter le "veth" à un "bridge", ie un "switch" logique (à nuancer, toutefois - je n'ai pas essayé non plus, mais il semble qu'il faille une version de "vzctl" supérieure à la 3.0.22, cette dernière étant celle de Lenny).

Niveau fonctionnement, une nouvelle interface (virtuelle, ou physique, si le nom qu'on stipule, pour le côté hôte correspond à une interface existante) apparaît du côté hôte, reliée à celle du conteneur. Pour ce qui et de la syntaxe, on fait ça via :

vzctl set ${ID} --netif_add toto0,00:12:34:56:78:9A,veth101.0,00:12:34:56:78:9B --save

On a alors "toto0" comme nouvelle interface, côté hôte, avec l'adresse MAC qui suit, et "veth101.0", côté conteneur, avec l'adresse MAC qui suit. Les adresses MAC peuvent-être omises, pour être générées automatiquement par OpenVZ, mais dans ce cas, il faut laisser les virgules quand même, de ce que j'ai compris. Ne reste plus qu'à spécifier les adresses IP, comme on le ferait pour n'importe quelle carte ethernet habituelle, par exemple, via le "/etc/network/interfaces", ainsi que les éventuelles routes et cie.

En bref, niveau réseau OpenVZ poutre littéralement. Il paraît même qu'il gère IPv6, mais je n'ai pas encore essayé.

2-2-4) Debianeries

Faute d'un "newopenvz", à-la-"newvserver", et préférant le "bootstrap" aux profils figés et compressés, il est nécessaire de faire quelques petites choses à la main, avant de lancer le conteneur créé et de le personnaliser dans le rôle qui lui est destiné.

Plutôt que de longues explications, je vais juste donner le petit bout d'un de mes scripts, exécuté sur l'hôte Debian, pour un conteneur Debian, et qui permet de faire ça :

sed -i -e '/getty/d' /var/lib/vz/private/${ID}/etc/inittab
rm -f /var/lib/vz/private/${ID}/etc/mtab
ln -s /proc/mounts /var/lib/vz/private/${ID}/etc/mtab
echo 'Aptitude::Recommends-Important "false";'> \
/var/lib/vz/private/${ID}/etc/apt/apt.conf.d/666norecommends
cp /var/lib/vz/private/${ID}/usr/share/zoneinfo/Europe/Paris \
/var/lib/vz/private/${ID}/etc/localtime
vzctl start ${ID}
vzctl exec ${ID} usermod -L root
vzctl exec ${ID} dpkg --purge module-init-tools
vzctl stop ${ID}

On pourra se référer à "/usr/share/doc/vzctl/README.Debian.gz", sur l'hôte, pour plus d'informations.

Ne reste plus qu'à gérer les utilisateurs (un super-admin via sudo, plus d'autres, éventuellement, pour ma part), rajouter ssh, less, et la complétion bash, ainsi qu'installer les locales et les configurer, ce que je fais dans un autre script, une fois à l'intérieur du conteneur, via :

vzctl enter ${ID}

2-2-5) Ressources

L'ajout de points de montage est simple : il suffit de rajouter une ligne appelant la commande mount dans "/etc/vz/conf/${ID}.mount" (qu'il faudra rendre exécutable) pour effectuer le montage au démarrage de la machine. Cela dit, OpenVZ semblant avoir été développé d'abord sur d'autres "Linux" que Debian, il semble que la gestion de "mtab" ne soit pas forcément adaptée à cette dernière distribution ; ce pourquoi je rajoute le paramètre "-n" à "mount", pour éviter des messages agaçants (mais pas problématiques) à l'arrêt (et/ou au démarrage, je ne sais plus) des conteneurs ; soit par exemple:

mount -n --bind /mnt/sur_l_hôte /var/lib/vz/root/${ID}/mnt/dans_le_conteneur

Il est à noter que "/var/lib/vz/root/${ID}" est l'arborescence virtuellement utilisée par un conteneur une fois démarré, contrairement à "/var/lib/vz/private/${ID}", où est physiquement stockée son arborescence, qu'il soit démarré ou pas.

J'ai encore assez peu (dans le sens de la durée) testé l'adjonction de périphériques à un conteneur OpenVZ, mais ce que j'en ai vu m'a satisfait. Là encore, on fait appel à "vzctl", avec deux possibilités. La première est de connaître les numéros majeurs et mineurs des périphériques, ainsi que leur nature "caractère" (c) ou "bloc" (b). Par exemple :

ls -l /dev/usb/lp0

me retourne :

crw-rw-rw- 1 root lp 180, 0 oct 21 22:31 /dev/usb/lp0

Pour l'ajouter au conteneur, on utilise donc "vzctl" :

vzctl set ${ID} --devices c:180,0:rw --save

D'aucuns trouveront ça trop lourd ; heureusement, il existe une autre méthode. Par exemple, pour la même imprimante :

vzctl set ${ID} --devnodes usb/lp0:rw --save

Plusieurs choses sont cela dit à noter (et sont tout aussi valables pour VServer) : tout d'abord, il se peut qu'il y ait besoin de changer les permissions et les propriétaires des "nodes" que l'on rajoute aux conteneurs (comme cela peut arriver sur une machine "classique"), ce que l'on peut faire à l'intérieur même des conteneurs.

En outre, dans un conteneur, en général "udev suce". Plein de problèmes peuvent arriver quand on ne se sert pas d'un "/dev" statique, dans ceux-ci ; outre le fait que "udev" nécessite la capacité noyau "raw_sysfs" (d'ailleurs, pour ça, on ferait "vzctl set ${ID} --capability raw_sysfs:on", sous OpenVZ... enfin, pour imager : "raw_sysfs" n'est justement pas disponible sous OpenVZ, contrairement à VServer), il est en général assez mal géré, et risque d'écraser des périphériques créés au lancement du conteneur (tty, ou encore random, en guise d'exemple de choses indispensables). Si, des fois, particulièrement pour les périphériques qui exigent le chargement d'un firmware, "udev" est presque indispensable, ça fait partie des choses que je fais sur l'hôte. Par exemple, pour mon imprimante laser "HP Laser Jet 1018", qui requière le chargement d'un firmware, j'installe "foo2zjs" (qui fournit le script "udev" de chargement du firmware au branchement de l'imprimante... par flemme de ne copier que lui), sans "CUPS" (dont une instance tourne, à la place, dans un conteneur, qui ne s'occupe pas du chargement du microcode), et je copie le firmware, sur l'hôte, que je laisse gérer le branchement à chaud de la bête. Ça m'évite de devoir donner des capacités inutiles au conteneur, et de charcuter le script de post-installation de "udev" dans celui-ci (j'y étais arrivé sous Etch, mais sous Lenny, il bloque à la population de "/dev" lors de l'installation, même après un peu de charcutage), sans compter les problèmes d'interférence entre la création de périphériques par les scripts de démarrage de conteneur, et "udev", qui peut écraser ce qu'ont fait les-dits scripts (et là, c'est la cata).

Une note sur "saned", pour les scanners : dans Lenny, "libsane" est capable de dépendre de "makedev" en lieu et place de "udev"... sauf que "libsane" dépend de "libsane-extras", qui ne peut pas dépendre de "makedev"... et ça, c'est la loose. Heureusement, le bug [6] est en train d'être corrigé (il l'est déjà pour amd64, dans Sid ; plus qu'à attendre). Par contre, sur ma machine, il n'y a pas de "/dev/usb/scanner0" de créé ; et donc, on peut être tenté de se servir de "/proc/bus/usb", qu'il est malheureusement impossible de monter dans un conteneur OpenVZ (alors que sous VServer, ça roulait nickel). Pas grave : "/dev/bus/usb/..." sert à la même chose, et suffit à faire marcher la bête (en prime, en l'activant dans le conteneur, "lsusb" se met à y marcher, en ne montrant que ce à quoi on lui a donné accès) ;

Par contre, il faut quand même faire un peu gaffe avec les noms de périphériques qu'on donne au conteneur, car ils ont tendance à être donnés un peu au hasard, en fonction de l'ordre de branchement, voire, de la direction du vent. Pour éviter les problèmes inhérents à l'utilisation de plusieurs périphériques sur le même bus, dans des conteneurs différents, on pourra, sur l'hôte, rajouter des règles "udev" qui créeront des alias personnalisés, qui ne laisseront pas le moindre doute, et partager ces alias. Avec l'avenir laissant imaginer une omniprésence de "udev" et la disparition totale des "vieilles" alternatives comme "makedev" on peut néanmoins espérer qu'OpenVZ et les solutions de conteneurs viendront à avoir moins de problèmes avec les "/dev" dynamiques.

Quelques derniers petits mots sur OpenVZ : autant je n'ai eu aucun problème sous VServer avec les terminaux, via l'utilisation de "vserver ${ID} exec", autant avec "vzctl exec ${ID}", c'est la cata pour "ncurses" (dommage, "dpkg"), ou pour les trucs interactifs comme "adduser" (mignon, le mot de passe de l'utilisateur que je crée, et qui apparaît en clair... mais, comment dire ?) ; bref, "vzctl exec", pour l'instant, sous Debian, je ne saurais que trop déconseiller de l'utiliser : tant que possible. Personnellement, je "debootstrap", puis je "vzctl enter ${ID}", puis j'y lance un petit script-maison qui modifie la machine selon mes besoins (en installant ce qu'il faut pour la joindre via "ssh" par la suite), et zou.

On pourrait aussi évoquer qu'un simple "top" sur l'hôte permet de voir les processus des invités (les numéros de processus ne sont pas entièrement virtualisés, bien que les conteneurs voient quand même des choses comme leur processus "init" avec le numéro 1, soit, comme il faut que ce soit).

Je serais également malhonnête de passer sous silence un vilain bug dans la série 2.6.26 du noyau [7], sous Debian (mais probablement d'autres, puisque le bug a été considéré comme venant "d'upstream" par les devs OpenVZ, donc, de Linux Vanilla - résolu dans 2.6.27, et backporté dans 2.6.26-9, sous Debian, depuis samedi matin dans Sid), et qui a la fâcheuse tendance de faire un oops jusqu'au blocage de clavier, si on fait trop intensivement utilisation du réseau... Enfin, comme je l'ai dit, c'est résolu dans Sid, et ça devrait arriver "rapidement" dans Lenny.




3) Derniers mots (si-si : promis)

Après un an et demi de Vserver et 6 mois d'OpenVZ, je dois admettre que les conteneurs sont une solution de choix, en ce qui me concerne : pas besoin de processeurs doués d'instructions spéciales pour virtualiser (ce qui permet de recycler les vieilles machines en serveurs - néanmoins, prévoir pas mal de RAM : mes deux serveurs en ont respectivement 2Go et 3Go, soit le maximum que leurs cartes mères respectives peuvent embarquer, ce qui me permet de gérer très confortablement quelques dizaines de conteneurs ; mais, c'est probablement la ressource à laquelle je dois faire le plus attention), très bonnes performances, et beaucoup des avantages possibles de la ségrégation de tâches.

Cela dit, si je devais brièvement comparer VServer et OpenVZ, plus spécialement dans Debian, je dirais que le premier est bien intégré, robuste, pas prise de tête, mais vraiment limité au niveau du réseau, d'avantage isolé que virtualisé, ce qui peut être ennuyeux pour un serveur, dont la connectivité à d'autres machines est peut-être sa caractéristique essentielle ;

Pour le deuxième, je dirais qu'il est jeune (sous Debian), avec la rugosité occasionnelle que ça implique, mais extrêmement puissant, tant au niveau du réseau ("venet" et "veth"), que de la gestion des ressources ("beancounters", barrières et limites). OpenVZ, pendant libre de la suite de virtualisation Virtuozzo (dont je ne connais en tant que telle, pour ainsi dire, rien) permet quelques autres mignoneries, comme la migration en direct (ie sans coupure de disponibilité) d'un conteneur vers un hôte sur une autre machine physique, mais bon : on ne peut pas avoir besoin de tout, et donc, pas tout tester.

Dès que j'aurai le temps, je compte donc, en avance, passer mon VServer Etch (CUPS, MythBackend, SFTP, NFS [ah oui : là, par contre, c'est uniquement en espace utilisateur, donc, via unfsd, pour le moment, ce qui peut être gênant, vu qu'il ne gère pas les "locks", ie "verrous"], SqueezeCenter, NTP et j'en passe) en Lenny (la manière de passer de VServer à OpenVZ est documentée [8], et pour ceux que ça intéresse, un noyau binaire OpenVZ est "backporté" dans Etch), et sous OpenVZ, qui m'a véritablement, je dois bien le dire, conquis.

J'ai l'impression qu'on a plus souvent tendance à parler des solutions de virtualisation avec noyaux "invités", comme Xen ou Qemu, mais bon, je poste ça sur LinuxFr, et, justement, les conteneurs permettent de faire tourner plein-plein-plein de Linux, avec moins de complexité et, souvent, de contraintes, qu'en faisant tourner plein-plein-plein de noyaux. Aussi, n'hésitez pas à donner une chance à OpenVZ (ou VServer, qui est quand même 'achement bien), d'autant que sa doc en PDF [9], son wiki [10] et son forum [11] sont vraiment géniaux ; d'autant que ses développeurs sont très réactifs, et prompts à donner un coup de main. En comparaison, je dois admettre trouver la documentation de VServer [12] [13] peut-être un peu plus légère. Enfin bref, OpenVZ, et plus généralement les conteneurs, ça roxxxe !




[1] http://linux-vserver.org/Welcome_to_Linux-VServer.org
[2] http://wiki.openvz.org/Main_Page
[3] http://wiki.openvz.org/Installation_on_Debian
[4] http://packages.debian.org/lenny/approx
[5] http://wiki.openvz.org/UBC_parameters
[6] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493698
[7] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500963
[8] http://wiki.openvz.org/Migration_from_Linux-VServer_to_OpenV(...)
[9] http://download.openvz.org/doc/OpenVZ-Users-Guide.pdf
[10] http://wiki.openvz.org/Main_Page
[11] http://forum.openvz.org/
[12] http://linux-vserver.org/Documentation
[13] http://linux-vserver.org/util-vserver:Documentation

> Lire le journal (11 commentaires, moyenne: 2,5).

Howdy journal !

Pour une meilleure compréhension de la suite, je vais d'abord commencer par un petit lexique :

- tor : logiciel de routage en oignon, permettant "d'anonymiser" sa connexion en passant par des intermédiaires, et en chiffrant ;
- exit-node/nœud de sortie : serveur Tor permettant de sortir en clair du réseau en oignon ;
- relai : serveur Tor permettant de rentrer sur le réseau en oignon, ou d'aller jusqu'à un intermédiaire, mais pas d'en sortir, s'il n'est pas aussi un exit-node ;
- bridge-relay/bridge/pont : comme un relai, au détail que son adresse n'est pas publiée sur la liste publique des relais (je me demande si on peut s'en servir pour rentrer sur Tor ; je ne sais pas, mais ça me paraîtrait bizarre).



Voilà comment débute (tôt) ma semaine : c'est encore un peu étonné, durant cette insomnie, que je souhaite te faire part du message un peu trouant que j'ai obtenu, au cours de mes divagations webesques, en arrivant sur le site marchand ldlc.fr (qui me redirige automatiquement sur ldlc.com)...

Accès refusé / Access denied
[mon IP dynamique du jour] xxx.xxx.xxx.xxx

L'accès au site vous est jusqu'à nouvel ordre refusé car l'adresse ci-dessus est (ou fait partie d'une classe d'IP) bannie à la suite d'opérations qui nous sont dommageables (ex: aspirations automatisées, préchargement massif des pages, commandes frauduleuses, etc...).

Il est également possible que vous receviez ce message...
si vous accédez au site via un proxy
si vous avez volontairement partagé votre accès internet
... et qu'il ait été utilisé précédemment pour effectuer ce type d'opérations à notre encontre.

[en rouge] Adresse IP d'un ordinateur utilisé comme relais TOR.

Si vous pensez qu'il s'agit d'une erreur, contactez dev@ldlc.com en précisant les informations suivantes :
La référence de votre compte client (exemple : I75BEEROL0093)
L'adresse IP qui apparait sur cette page
Le navigateur internet utilisé
Vos conditions de connexion (accès direct ou via proxy, depuis votre domicile/entreprise, ip fixe ou dynamique)

En effet, je fais tourner un relai Tor (0.2.0.31-1, dans un conteneur OpenVZ, sous Debian Lenny)... mais même pas un exit-node : juste un relai ; les clients Tor ne sortent pas directement de chez moi - je ne suis qu'un intermédiaire de l'oignonage : ma seule politique de sortie, c'est "ExitPolicy reject *:*". En revanche, je ne suis pas un "bridge" : mon adresse IP est donc notifiée au principal annuaire (celui là est public) de relais Tor. Sinon, il se trouve que je passe aussi par l'un de mes deux privoxy, quand je passe par Tor, mais ce n'est ostensiblement pas ce qui m'est reproché chez LDLC, vu que je n'ai pas besoin de passer par Tor pour qu'ils me giclent.

... et ce qui est probablement l'une des premières boutiques du Web sur lesquelles j'ai commencé à acheter du matos info (ma première commande chez eux doit dater de 2000/2001... et depuis, ce sont pour quelques dizaines de milliers d'euros que moi, et les gens auxquels j'ai pu les conseiller, avons acheté chez eux par la suite - d'ailleurs, c'est marrant : une bonne partie du matos que j'utilise pour faire tourner Tor, je l'ai achetée chez eux) doit probablement maintenant filtrer ce qui est listé sur cet annuaire, et me jette donc comme un malpropre...

Ah, ça ! Il est beau, le web 2.0... De prime abord, j'entrevois deux possibilités. Hypothèse 1 : En premier lieu, je vois mal ce que le but de la manœuvre pourrait être d'autre que de fragiliser Tor ; s'ils voulaient vraiment empêcher que des anonymes commandent sur leur site, ils se contenteraient de bloquer les nœuds de sortie, pas les relais... Le seul intérêt de bloquer les relais, ça me paraît être de diminuer la bande passante du réseau (d'ailleurs, ils me le précisent bien : ce qui m'est reproché, ce n'est pas d'être un nœud de sortie, ou, pour utiliser un terme générique, un "serveur", mais bien un simple relai ; ce qui fait que c'est ma première hypothèse). D'autant plus que je suis marqué en tant que "serveur rapide" ("Fast", même si je suis loin d'être le plus rapide).

Hypothèse 2 : ou alors, ils ont voulu bloquer les sorties, et dans le doute/par erreur/par zèle/ ..., ils ont tout bloqué...

Bon (façon de parler), en revanche, leurs sites "http://www.ldlc-pro.com", ou .be, ou .ch, restent accessibles (mais mon mot de passe n'y fonctionne pas... d'un autre côté, il n'y a jamais marché, donc, rien d'étonnant) ; mais sans le pro, .be, .ch et .fr m'envoient bouler. En outre, si je passe par Tor pour visiter leurs sites (Ouh ! Comme je suis méchant !), même en changeant l'exit-node que j'utilise, j'ai droit à un "Le fichier ou le dossier www.[blablabla] n'existe pas." (le nom est bien résolu), sur quelque site, et quelque page, de chez eux que ce soit, y compris les "pro". Bon, encore, qu'ils bloquent les nœuds de sortie, s'ils veulent... m'enfin, les relais... D'autant que la différence est spécifiée, entre les nœuds de sortie et les relais. [1] [2] [3]

Maintenant, soit je deviens un "pont" (non répertorié dans les annuaires publics), soit je raye un nouveau site de la liste de ceux que je pourrais visiter... dans le fond, je crois que ça va, au moins, être la deuxième option : ils n'ont ostensiblement pas envie de respecter les initiatives favorisant la protection de la vie privée sur le Net (qu'ils aient volontairement, ou pas, inclus les simples relais dans leur démarche) - je ne vois pas pourquoi j'aurais envie de faire des affaires avec eux, ou de leur faire de la (bonne) pub, comme je le faisais jusqu'ici. Qu'ils me bloquent s'ils veulent (c'est leur site, après tout : ils y sont chez eux), moi, je les vire de mes marque-pages (ils sont sur mes machines, après tout : j'y mets ce que je veux) : comme ça, on est quittes.

[1] http://torstatus.kgprog.com/
[2] http://torstatus.blutmagie.de/
[3] https://torstat.xenobite.eu/

> Lire le journal (99 commentaires, moyenne: 3,6).

Howdy journal !

En ayant un peu marre de madwifi (ça, c'est pour la confession... honte à moi d'avoir utilisé un démon proprio) qui ne me faisait que des misères sur une Sid, j'ai décidé de tenter le coup avec ath5k (la Sid est repassée en Lenny depuis... c'est de toute façon le même kernel, pour l'heure... et puis j'en ai marre de faire tourner une Sid dans le salon, maintenant juste pour LCDproc... si jamais il était mis à jour pour Lenny, étant en exception de freeze [faut dire que c'est la même version, à une révision debianesque près, depuis Sarge... mon LCD/IR Imon ne demandant qu'un LCDproc 0.5, au moins], tant mieux... sinon, tant pis, ce sera sans... au pire, je me ferai moi-même le paquet, comme j'ai fait par le passé).




Au premier abord, si madwifi me donnait l'impression d'être très sensible au bruit ambiant (d'autant plus depuis que je suis passé au 2.6.26... je ne sais pourquoi), ath5k ne m'a pas enchanté plus que ça...

Le plus gros problème étant une variation cyclique de la vitesse de la connexion, de 1Mb/s à 54Mb/s et ainsi de suite, occasionnant moult coupures... ce qui est ballot, la bête (une AR2414 en PCI, de je ne sais plus quelle marque) étant dans mon HTPC, qui n'a bien évidemment pas besoin de ça...

... bref, un peu désappointant. Et c'est là que je me suis rappelé les heures de galère avec le chip broadcom des WRT54G (oui, oui... j'ai des orties dans mon jardin ; je me flagellerai avec... et puis, maintenant, c'est le seul, unique et dernier truc proprio qui tourne sur mes CPU - et je pense depuis un moment à m'en séparer), et les services que peut rendre iwconfig.

Un petit coup de "iwconfig wlan0 rate 24M" plus tard, afin de forcer la puce à se maintenir à un taux de transfert constant, là, c'est devenu le bonheur... j'ai expérimenté diverses valeurs, et ça donne à peu près ça :

24M --> ping -c 100 mon_routeur
1.034/1.348/4.182/0.495/0.495ms, avec aucun paquet perdu...
scp un_gros_truc.avi : 2,4Mio/s (!)

36M --> ping -c 100 mon_routeur
1.269/5.679/20.555/6.013ms, avec 93% de paquets perdus
scp un_gros_truc_2.avi : 300kio/s

Au-dessus, avec un taux fixe, je perds la connexion ("Destination host unreachable").

Sans rien toucher, j'avais entre 15 et 20% de paquets perdus, et le transfert via scp (ou fish, ou sshfs... je n'utilise que ça, pour transférer, gardant NFS pour la lecture seule) commençait fort, puis tendait vers zéro, avant de lamentablement bloquer, à moins que je ne fasse tourner le proc (par exemple, en mâtant une video, auquel cas, ça allait à ~1Mio/s... vraiment bizarre)...

Ca, c'était pour l'astuce (pas grand monde ne semble lire le forum, à ce que semble confirmer une récente dépêche [1] ... et puis bon, il y aussi de la confession... et puis du retour sur un module important ; de l'émotion fébrile, quoi ! En somme, c'est un journal... 'fin je crois ;) ).




Bref, en rajoutant un petit "post-up /sbin/iwconfig wlan0 rate 24M" dans mon /etc/network/interfaces, tout va bien, dans le meilleur des mondes... j'obtiens même, avec mes antennes +7dB, une qualité de signal de 100-110% (pas sûr que ce soit pertinent... pas plus que de ce que ça veut vraiment dire, ni en quelle unité c'est, s'il y en a une), là où avant, je peinais aux alentours des 50%.

Les miniatures des répertoires de MythVideo (chopées via NFS, sur le serveur de stockage) ont maintenant le poil brillant et apparaissent aussi vite que l'éclair (bon, j'exagère... disons que c'est quand même le jou[i]r et la nuit)...

Il faut toujours que je bufferise un peu avant de lire les videos via MPlayer (MythVideo ayant toujours autant de problèmes avec les MKV et le H.264, même dans le CVS de la 0.22, en fort joli QT4, que j'ai testé avant hier... je le réserve donc pour relire les MPEG-TS des enregistrements TNT, non indexés, et donc, assez peu maniables avec MPlayer... il est beaucoup plus pratique de les streamer du backend MythTV), mais beaucoup moins qu'avant (avant, je mettais un "cache=8192" dans le fichier de conf de MPlayer... maintenant, ça passe bien avec "cache=4096", voire "cache=2048"... et en plus, le transfert va beaucoup plus vite pendant la mise en cache).

Ce genre de soucis semble en outre être connu, comme en témoigne la page d'ath5k sur linuxwireless.org, où il est annoncé que le taux de transfert est censé chuter à 1MBps, par défaut, pour l'heure, et où il est précisé qu'on est censé pouvoir le fixer jusqu'à 11MBps...

... au final, avec mes 24MBps (réels, mais pas full-duplex, et en comptant l'overhead, étant en WPA2-PSK, de ce que j'en ai testé brièvement), je peux dire que ath5k, ça progresse, et que : "çaybonmangézan" !




[1] http://linuxfr.org/2008/09/08/24193.html
[2] http://linuxwireless.org/en/users/Drivers/ath5k

> Lire le journal (22 commentaires, moyenne: 2,5).

Howdy, Journal !


C'est à la lecture d'un message dans la sous-partie "Astuces.divers" du forum [1] que je me suis décidé à t'écrire...


L'affirmation "Une passphrase sur une clé privé, c'est déjà de l'authentification forte" m'a tout particulièrement parue discutable (j'espère que l'auteur me pardonnera de répondre ici plutôt qu'à la suite de son message)...

Une clé privée avec passphrase, ce n'est pas vraiment quelque chose que l'on a et quelque chose que l'on sait, mais plutôt deux choses que l'on sait...

... la passphrase connue, le contenu de la clé privée est connu en clair... ce dont on n'a même pas besoin pour la dupliquer... on peut garder le fichier autant au chaud qu'on le veuille, il reste dupliquable (enfin, en principe), extractible, pour prendre son temps à faire sauter les deux remparts (la passphrase, et la nécessité de connaître la clé déchiffrée), sans pour autant devoir posséder autre chose...


Avec une smartcard, par exemple, si l'on y génère un couple de clés en interne, pas moyen de la récupérer, la clé privée... la clé n'est pas dupliquable, et il faut donc bien posséder quelque chose.

Après, la clé protégée par un PIN, c'est le "quelque chose à savoir"... la sécurité est d'autant plus élevée qu'au bout d'un certain nombre d'essai (3 a priori), la smartcard est bloquée (le PUK peut la réinitialiser, mais il faudra a priori régénérer les clés)... avec l'utilisation de certificat, ça offre une répudiation facile (ce que n'offrent par exemple pas des token OTP basés sur le temps, à moins d'encore avoir le token et de pouvoir le détruire physiquement, ce qui n'est pas nécessairement possible)...


Donc, non, de la clé privée avec passphrase, je ne vois pas vraiment ça comme de l'authentification forte... à la limite, on pourrait plutôt parler d'émulation logicielle d'authentification forte, ou de double secret à connaître.





Malheureusement, le support des smartcards (je ne connais pas grand chose au sujet des OTP) dans OpenSSH (dont il est question dans le sujet originel), ce n'est pas terrible...

Il y a officiellement un support pour OpenSC, dans OpenSSH, mais il ne prend pas en compte la demande d'un PIN, plutôt que d'un mot de passe (du coup, il faut patcher avec des sources que l'on trouve dans celles d'OpenSC, ce qu'utilise par exemple Gentoo, bien qu'elles soient qualifiées de "crude-hack" ["contournement grossier"] dans le "README" qui les accompagne, par leurs auteurs).

Sinon, il y a des patches non officiels qui essaient de s'intégrer upstream, notamment pour apporter le support de PKCS#11 (standard d'opérations cryptographiques via smartcard), de X.509, et de la distribution des clés via OpenLDAP (cf patches de Alon Bar-Lev [2] et de Roumen Petrov [3]).


Avec ça, on aurait authentification forte, avec facilités de répudiation. Mais bon, upstream, ie chez OpenSSH, n'a pas l'air très chaud pour intégrer ça de base, fut-ce dans la version "portable" (un autre patch OpenLDAP, ie le patch LPK n'a pas trouvé sa voie upstream non plus... ce qui a valu la perte du support d'Inverse Path Ltd, frustré de la non-communication d'upstream [4])... et comme la plupart des distros ne veulent pas (plus...) patcher OpenSSH avec de l'externe... on se mord la queue...

... et c'est vraiment dommage, parce que "oui!", du token crypto aurait permis, après la merde récente sur OpenSSL chez Debian, en se servant de clés RSA, d'avoir des clés générées proprement (dans la smartcard), et qui n'auraient pas dues être recrées, à moins que, par un incongru hasard, elles aient fait partie des clés à faible entropie (bien que du coup, le patch X.509+OpenLDAP de Roumen Petrov aurait permis des facilités de bannissement/redéploiement indéniables)...

C'est là que j'ai honte d'avouer que le bugreport que j'avais préparé avec tant d'amour, pour ma distro de prédilection [5], ait une si sale gueule... j'étais sur un PC sur lequel Kmail n'était pas configuré, et après avoir lancé reportbug-ng, pour formater mon mail comme il faut, je me dis : "Allez zou ! Je copie-colle dans yahoo mail, je l'envoie au daemon à bugs de Debian, et ça va le faire"... prout ! (que tu me le permettes ou pas, cher Journal)... chaque paragraphe sur une ligne... j'ai honte : je ne sais pas ce que j'ai pu foutre pour que ça aie cette gueule là, mais je ne me fais pas trop d'illusions sur le fait que ce sera beaucoup lu (déjà que c'est long... oui, je sais, c'est une maniaquerie : j'ai une ferme tendance au flood)...


M'enfin, l'idée était de préciser ce qu'il en est de l'antique et boitilleux support officiel d'OpenSC, et de souhaiter la création d'autres paquets, prenant en compte les patches PKCS#11 et X.509 (qui permet de la distribution via OpenLDAP aussi)...

OpenSSH est génial (je n'ai pas encore testé le support des chroots au login du 4.8p1, mais j'ai hâte), mais il pourrait être encore mieux... plus sécurisé grâce à PKCS#11, et plus gérable pour ce qui est des clés publiques autorisées grâce à X.509/OpenLDAP... des choses qui auraient pu permettre de réduire à néant l'impact du bug de packaging d'OpenSSL (j'ai fait les fraies de la plaie ; c'est aussi la mienne : je la remue si je veux)... d'autant que de plus en plus d'applications ont désormais une forme de support pour PKCS#11, au moins via le patching (OpenSSL [6], OpenVPN [7], GnuTLS [8], ... OpenSSH et autres [9])...

Mais voilà : pour le shell distant, upstream fait le sourd, et les distros font les aveugles quant à ce qui est de ces patches... ce n'est pas un coup de gueule, mais juste un souhait, que soit généralisé, au pire, un paquet openssh-pki, distinct, qui intègrerait ces deux patches, qui sont d'ailleurs écrits de façon à pouvoir fonctionner ensemble (Gentoo permet d'activer le support X.509, via le useflag idoine, mais pour ce qui est des smartcards, ils utilisent le patch goretto de chez OpenSC, bien qu'ils aient répondu à Alon Bar-Lev qu'ils ne voulaient plus rajouter des patches externes dans des paquets cruciaux comme ça, ce qui peut se comprendre, qu'on soit ou pas en ces temps d'après-mega-boulette Debianneuse).

Cela dit, si quelqu'un a le courage d'ouvrir mon bugreport de manière à le rendre lisible, et si ce quelqu'un le trouve intéressant et a les capacités de produire un patch à l'OpenSSH de Debian pour intégrer les deux que j'ai cités (capacités que je n'estime pas suffisamment avoir), pour étoffer le bugreport, et qu'il voulait bien le publier, qu'il ne se gêne pas ;)

Bon, voilà, ça, c'est fait...





Maintenant, Journal, je vais quand même faire une petite disgression sur le matériel qu'il est possible d'acquérir, pour jouer avec ce qui peut fournir de l'authentification forte... et plus particulièrement les smartcards...

Cela fait maintenant quelques années que me trotte l'idée de générer mes clés privées dans un coffre fort dont on ne peut les faire quitter (au mieux est-il possible de les effacer ou de s'authentifier/chiffrer/signer avec elles)... mais qu'en est-il sur la banquise ?

Et bien, tout d'abord, peu de cartes sont compatibles avec Linux, sans recourir à un middleware (un composant logiciel permettant de fournir une interface PKCS#11 vis à vis de l'OS qui tourne lui-même sur la smartcard, qui est factuellement un mini-ordinateur spécialisé dans la cryptographie) proprio, afin de pouvoir dialoguer avec elle... notons que le support de PKCS#11 ne permet que de réaliser des opérations cryptographiques (authentifier/chiffrer/signer), et pas de gérer les informations sur la carte elle-même (effacer des banques de données, changer les PIN, réinitialiser la carte), ce qui est le rôle de PKCS#15.


Eh bien, pour ce qui est des smartcards qui semblent être bien supportées, c'est assez pauvre : pour ce que j'ai trouvé qui se vend encore, il semble qu'il faille se diriger vers des versions particulières des Cryptoflex E-Gate 32K, qui, contrairement à certaines versions des Aladdin Etoken Pro32k (non, toutes les versions, fonction de quel OS embarque la carte, ne sont pas supportées), permettent la gestion des clés RSA de 2048 bits, ce qui est le top-moumoute qu'il semble qu'on puisse atteindre sur un client où tout est libre (à défaut de l'OS de la smartcard, mais on n'est plus vraiment sur le client... bien qu'une SmartCard complètement libre, jusqu'à ses spécifications détaillées, serait bougrement sexy).

A noter d'ailleurs que la boutique outre-Atlanticienne où j'ai trouvé ces artefacts en vente a une section dédiée à Linux [10], dans laquelle on peut d'ailleurs remarquer que tout ce qui est cartes récentes ne nous est pas conseillé... d'ailleurs, l'utilitaire pkcs15-init, du projet OpenSC, ne gère même pas, par exemple, les clés AES, que beaucoup de nouvelles smartcards peuvent manipuler.


Alors oui, une smartcard, OK, mais faut un lecteur (puisqu'il n'est pas intégré aux Cryptoflex, comme il l'est aux Etoken)... de ce côté, c'est plus simple : tout ce qui supporte la norme CCID [11] est censé pouvoir fonctionner... on peut aussi passer par OpenCT [12], via un wrapper CCID, ou non, bien que le support de matériel via d'autres méthodes semble moins large.

Et là, c'est chez Etronsec [13] que j'ai trouvé ce qui m'attirerait le plus : du lecteur de SIM et/ou de smartcard classique, combiné à de la clé USB à mémoire flash.

Avec ça, j'imagine tout un tas de libertés d’esprit cosmique vers un nouvel âge réminiscent ! Comme avoir une clé USB avec une SIM, qui me permettrait de me connecter à une machine, peut-être via un VPN, pour faire les mises à jour et la maintenance courante, dans laquelle je pourrais insérer une autre smartcard au format classique, que je garderais dans mon portefeuille, et qui me donnerait des droits autrement plus touffus. D'autres imagineront se servir d'une smartcard pour simplement se loguer [14], accéder via LUKS [15] à leur /root ou Pr0N chiffré, éventuellement en passant par SFTP ou SSHFS, ou que sais-je encore ? "Ré-mi-ni-scent", que j'ai dit !





Bref, tu l'auras compris, Journal, je vais craquer prochainement pour de la smartcard et le lecteur-kivabien, ne serait-ce que pour tester, notamment avec OpenSSL et OpenVPN... J'essaierais probablement aussi de bidouiller OpenSSH (en me réinstallant peut-être une Gentoo, au passage... c'est vrai que ça fait longtemps...)... mais c'est une toute autre histoire, et chaque chose en son temps.

L'existant ne semble pas très utilisé, bien qu'apparemment fonctionnel... mais du coup, on n'en parle pas trop et ce n'est pas très connu... tant et si bien qu'encore récemment (ça arrive une fois par an à peu près), quelqu'un a réouvert un bug chez Debian pour demander le support d'OpenSC (j'y ai dailleurs moi-même pensé aussi, avant de chercher à me renseigner un poil plus, pour finalement pondre un bugreport tout mal formaté), qui n'a en fait jamais été trop propre... bref, si vous vous le sentez de faire de la pub ou du taf dans votre distro pour ça, ou d'acheter de la smartcard pour tester, voilà un peu les infos sur ce qu'il est possible de faire, et avec quoi, que j'ai pu récolter récemment...





[1] http://linuxfr.org/forums/47/25192.html
[2] http://alon.barlev.googlepages.com/openssh-pkcs11
[3] http://roumenpetrov.info/openssh/
[4] http://dev.inversepath.com/trac/openssh-lpk
[5] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482806
[6] http://www.opensc-project.org/engine_pkcs11/wiki/QuickStart
[7] http://openvpn.net/index.php/documentation/howto.html#pkcs11
[8] http://alon.barlev.googlepages.com/gnutls-pkcs11
[9] http://alon.barlev.googlepages.com/open-source
[10] http://www.usasmartcard.com/component/page,shop.browse/categ(...)
[11] http://pcsclite.alioth.debian.org/ccid.html
[12] http://www.opensc-project.org/openct/
[13] http://www.eutronsec.it/infosecurity/Contents/ProductLine/De(...)
[14] http://www.opensc-project.org/pam_pkcs11/
[15] http://www.etokenonlinux.org/et/HowTos/eToken_and_LUKS

> Lire le journal (10 commentaires, moyenne: 2,7).

Howdy, Journal !



Peut-être connais-tu les télécommandes de la gamme Harmony... sinon, pour faire court, il s'agit de télécommandes universelles fabriquées par Logitech, plutôt bling-bling à tendance classieuse (de la télécommande de Président, farpaitement ! ) [1]...

La particularité la plus notable de ces petites bêtes est que leur configuration s'effectue via un site web [2], ce qui permet d'accéder à une grosse base de données de constructeurs (tout ce que j'ai, TV, récepteur AV, tuner TNT, récepteur IR en USB, est dans la base, sans avoir besoin de passer par quelque mode d'apprentissage que ce soit ; on peut quand même passer par un mode d'apprentissage au besoin, mais aussi configurer des macros, auxquelles on assigne un nom de tâche directement accessible via l'écran LCD). Une fois (et puis d'autres, encore, et encore, pour geekement affiner) la configuration effectuée en ligne, on peut alors télécharger un fichier la décrivant, à uploader dans la télécommande via USB.



Oui, mais voilà... si point de banquise n'était supportée, ce n'est tout de même pas le genre de chose que j'aurais achetée... Déjà qu'il faut faire avec une base de données proprio (qui peut disparaître du jour au lendemain), qu'il faut télécharger un firmware proprio (bon, ça, encore... et pourtant, je suis debianneux)... m'enfin, je relativise : 59€, port offert, pour une Harmony 555... je pourrai y survivre...

Par contre, sans le moindre support linuxien, ce serait plus difficile... et bien, si ce n'est pas chose pleinement accomplie, c'est pour le moins en bonne voie. Le projet Concordance [3] (enfin, pour l'instant, il s'appelle Harmony, mais la prochaine version, probablement 0.20, sera l'occasion d'un changement de nom, en plus d'un split entre le backend, faisant appel à libusb, et le frontend, l'officiel étant en ligne de commande, bien qu'une appli en QT soit aussi sur les rails [4]) vise en effet à permettre de configurer ces artefacts librement (j'annonce : dans une certaine mesure)...



Bien plus léger que l'homologue propriétaire (~100Mio une fois installé... ouch... l'appli libre que je présente se compilant en deux coups de cuiller à pot, et n'ayant pour cela besoin que de libusb-dev), Concordance (enfin, Harmony... enfin, vous suivez, j'imagine) est cela dit encore très jeune... il faudra en effet pour l'instant recourir à un OS propriétaire pour mettre à jour le firmware (propriétaire... décidément, quelle marotte ! ) de la télécommande, si celui-ci est plus vieux que ce que le portail Logitech exige... la mailing-list du projet fait cependant état de nombreux progrès pour intégrer cette fonction, et il semble que la version CVS puisse mettre à jour le firmware de certaines télécommandes.

Malgré tout, une fois cette mise à jour effectuée, on peut se créer un compte sur le portail web, effectuer sa configuration (en choisissant les appareils par modèles, en arrangeant les actions à enchaîner, ... ), et laisser notre petite appli jouer l'intermédiaire entre ledit portail et la télécommande... sous Linux, cette fois.

Par exemple, lorsque le portail (ouvert, mettons, dans Konqueror) demande à ce que la télécommande connectée en USB lui prouve sa présence, il nous permet de télécharger un fichier "Connectivity.EZHex" qu'un gracieux (ou pas), en tant que root (j'ai dit ou pas ! ) :
./harmony -t Connectivity.EZHex
va utiliser pour "prouver" au portail qu'une télécommande est bien branchée...

Le portail va alors permettre de télécharger le fichier de configuration "Update.EZHex" (il ne s'agit que de la configuration, pas du firmware complet) qu'un, ni plus, ni moins, gracieux (toujours en tant que root) :
./harmony -C Update.EZHex
va envoyer dans la télécommande en quelque secondes...

... et voilà : une télécommande configurée comme un manchot. Certes, ça ne manque pas encore de rugosité, le concept implique des contraintes inhérentes, mais bon, chezmoiçamarche© (enfin, pas avec la dernière stable, qui apporte apparemment une régression pour la 555, mais ça tourne avec la 0.12... désolé de ne pas avoir eu le temps de tester le CVS).



Pour terminer avec quelques mots (encore ! ) sur le projet, en tant que tel...

Niveau support, les modèles inférieurs à la 890 sont censés être supportés, bien que tous n'aient pas encore été testés [5]. Le projet a cela dit l'air plutôt actif, et le support de TCP-over-USB, nécessaire pour les modèles supérieurs semble être étudié [6].

Pour ce qui est de la documentation constructeur, c'est encore et toujours problématique... Phil Dibowitz, le développeur à l'origine de Concordance, a eu beau essayer de contacter Logitech en offrant de développer un support pour Linux [7], il semble que le silence radio soit malheureusement de mise, les quelques tentatives de contact s'étant semble-t-il soldées par un "peut-être, mais finalement : rateau"...

Cependant, Kevin Timmerman, un développeur visant à créer une interface (propriétaire), pour OS redmondien, permettant ambitieusement de supplanter le travail du site web de Logitech, avait déjà effectué une bonne partie de l'ingénierie inversée... et à défaut d'ouvrir tout son code, semble avoir beaucoup aidé Phil Dibowitz à mettre au point son backend, tant et si bien que Concordance se veut multi-plateforme (Windows, Linux, et, pour la 0.20, probablement, MacOS).

Bref (euh... façon de parler...), il y a des choses comme ça qui facilitent tout de même bien la vie d'un manchot (on sous-estime trop souvent la difficulté de jongler avec moult télécommandes quand on a des ailes atrophiées, tenant plus du moignon que d'autre chose)... si la perspective de dépendre d'une base de données propriétaire pour régler une télécommande bling-bling à tendance classieuse ne vous arrête pas, enjouaillez Concordance [8] (enfin, Harmony, pour l'instant ;) ).



[1] http://www.logitech.com/index.cfm/remotes/universal_remotes/(...)
[2] http://members.harmonyremote.com
[3] http://www.phildev.net/harmony/
[4] http://www.kde-apps.org/content/show.php/Koncordance?content(...)
[5] http://www.phildev.net/harmony/supported_models.shtml
[6] http://www.linux.com/feature/121149
[7] http://www.phildev.net/phil/blog/index.php?s=harmony&submit=(...)
[8] http://sourceforge.net/project/showfiles.php?group_id=201579

> Lire le journal (12 commentaires, moyenne: 2,6).