Quand Fédéric Baille et Laurent Bervas m’ont contacté en 2007, suite à Solution Linux, le Linutop 1 avait fait ses premiers pas, livré avec un système Xubuntu Edgy (LiveCD) sur clé USB. C’était vaguement utilisable, pas du tout optimisé. Un gros challenge était là : partir d’une solution fonctionnelle mais lourde (1 processeur AMD LX700 et 256M de RAM), pour réussir à obtenir un système plus léger, robuste et utilisable par plus ou moins tout le monde – sans parler de la réduction du temps de boot, 3 minutes, c’est long.

La robustesse est une des idées essentielles du Linutop. Pas de pièces mobiles (disque dur, ventilateur…), un boitier solide, donc pas de casse. Le LiveCD pour l’OS était le penchant robuste du côté logiciel. Peu importe ce qui est fait durant la session, un reboot remet tout en place.

Ceci étant, on est vite limité sans persistance, et c’est d’autant plus dommage quand l’OS est fourni sur clé USB ! D’où la première modification importante, la création d’une seconde partition sur la clé, destinée à héberger les données de l’utilisateur (bookmarks, documents office, photos, j’en passe). Résultat, /dev/sda1 faisait office de système de base (via les techniques de LiveCD), l’écriture système était faite en RAM, et finalement un /dev/sda2 était monté sur /home pour la sauvegarde des documents. Plusieurs avantages à ce système :

• un système de base intouchable et facilement restoré (reboot)
• l’écriture des logs et données de fonctionnement de l’OS en RAM limitent l’usure de la clé USB
• un formattage de la seconde partition restaure la session utilisateur de base

Cette utilisation d’un système de base (à base de squashfs + unionfs à l’époque) sur une partition, et de gestion des données sur la seconde est encore aujourd’hui utilisée, avec des évolutions.

Parmi ces évolutions, la persistance complète. Certains utilisateurs de Linutops ont voulu ajouter des logiciels, ou modifier les configurations sytème par défaut. Problème : comment faire quand tout est écrit en RAM ? Solution : ne plus écrire en RAM

Le mode persistant du Linutop est une simple extension du principe d’unionfs, en unifiant un système en squashfs avec une partition physique. Cette fois la partition sda2 contient les changements faits au système de base, y compris les données utilisateur. Le passage d’un mode à l’autre est possible (moyennant un reboot), et les données utilisateur conservées. Évidemment cette solution éloigne un peu l’OS de son idée première : la robustesse. L’OS réagit comme un OS standard, si sa configuration n’est pas bonne, il ne bootera pas. La solution de restauration est pourtant toujours possible, puisque le système de base est toujours contenu dans un fichier squashfs indisponible en écriture. Une option de restauration au boot a été ajoutée pour pouvoir simplement rétablir le système initial.

La dernière évolution a été un retour au concept de base. La persistance permettait plus de souplesse, mais apportait ses problèmes. Par sa “puissance” le Linutop implique une mono-utilisation du système (kiosk web, affichage, monitoring). C’est d’autant plus vrai que ce système s’adresse plus à un marché professionnel que consumer. Avoir une possibilité de figer le système dans une configuration est apparue nécessaire, et en accord avec l’idée première du Linutop. Le passage d’unionfs à aufs a fortement facilité l’ajout d’une 3ème couche au système d’unification, c’était le grand retour le la RAM. Le Linutop Lock superpose 3 parties distinctes du système :

• le système de base (squashfs)
• la configuration système et utilisateur (2nde parition de la clé)
• la couche d’écriture  (RAM)

Le principe du Linutop Lock est simplement celui d’un LiveCD auquel on a ajouté une couche de configuration modifiable (configuration au sens large, l’ajout/suppression d’applications est aussi possible). Ce mode est idéal pour placer la machine à disposition d’utilisateurs de non-confiance (pour un kiosk internet par exemple). Si jamais l’utilisateur arrive à endommager le système, les dégats ne sont présents qu’en RAM, et un reboot suffit à tout restaurer. Résultat : 0 maintenance du matériel, 0 maintenance du système.

Un autre élément qu’a apporté ce système de partitionnement est une simplicité de déploiement. La plupart des clients Linutop déploient des machines sur de nombreux sites, systématiquement avec la même configuration. Des outils simplissimes d’utilisation permettent en 2 clics (ou une commande, je reste un geek quand même) de dupliquer intégralement un système sur clé USB bootable. L’opération est faisable en sens inverse bien évidemment. 1 Linutop maître est configuré, dupliqué sur une clé USB, et cette clé contenant le système bootable est utilisée comme source d’installation pour tous les autres Linutop ! Idéal pour diffuser une nouvelle version, ou une clé de restauration à des dizaines de sites. L’automatisation du “flashage” du disque interne permet à n’importe quel utilisateur de faire une installation d’un système préconfiguré en 3 minutes. Pas de prise de main à distance, pas de déplacement, et des connaissances plus que minimum nécessaires pour installer (je pense qu’à peu près tout le monde peut brancher une clé USB et appuyer sur le bouton de power !).

Le matériel Linutop a vraiment été conçu pour réduire les coûts de maintenance, son OS a suivi la même voie, et je pense que le résultat n’est pas mauvais

Parallèlement au développement de l’architecture, celui de l’interface a été le résultat de nombreuses réflexions sur ce que l’utilisateur attend en démarrant son Linutop. Plus du détails dans un prochain post…

Je quitte donc mon poste chez Ulteo, et la place est libre (si vous êtes debianeux/ubuntero, que vous codez et que vous connaissez bien les hyperviseurs et la virtualisation en général, le boulot est fait pour vous).

Toujours dans le domaine du libre, u-classroom est au point mort, et je compte bien ressusciter un peu le tout dès que possible. Le chan freenode voit régulièrement arriver des visiteurs curieux de savoir quand sera la prochaine session… pas drôle de leur répondre que rien ne tourne en ce moment. L’idéal sera sans doute de redémarrer en réitérant des sessions passées, mais les propositions de nouvelles sessions, et les nouveaux intervenants sont les bienvenus !

Autres trucs en vrac et orientés “mylife” :

• je ne suis plus développeur Ubuntu ; pas la peine d’avoir son nom dans les équipes LP si on ne fait plus rien
• j’ai l’intention d’essayer une nouvelle fois de contribuer à Debian (via Objectif Libre)
• pour la première fois depuis des années j’ai autre chose que Debian sur certains de mes PCs (OpenSuSE pour le portable, Fedora pour le “media center”, et les deux fonctionnent vraiment bien !)
• IMAP c’est mieux que POP
• résolution du nouvel an : bloguer un peu plus (mouais… qui tient ses résolutions ?)

• le Linutop 3 est dispo (yay \o/), et le Linutop OS 3.0 est sur le point de sortir ;
• Solutions Linux avec Linutop s’est bien passé, on a rencontré pas mal de monde intéressant (ça a été un vrai plaisir de passer un peu de temps avec Christophe et Didier au passage) ;
• Ulteo OVD 1.0 rc2 est également sorti, de manière discrète. N’hésitez pas à tester ! La finale devrait arriver dans les jours ou semaines qui viennent ;
• pour l’occasion j’ai eu la joie de compiler et patcher un programme Windows pour la première fois de ma vie. Après 3 jours de setup de l’OS…
• ça bouge sur u-classroom, un grand merci à illovae pour l’organisation des cours tty. J’ai entendu dire que skateinmars prépare un cours sur Ruby. Avis aux amateurs ;
• j’essaie de trouver l’énergie pour préparer un TP autotools pour ma part (didrocks devait le faire mais bon… :p)
• la nouvelle gestion du recovery après crash sur firefox 3.[15] est bien foutue, moins il y a de popups mieux je me sens ;
• Thunderbird 3.0 utilise des onglets (mr_pouit ne voit pas l’intérêt mais il est d’humeur négative en ce moment, il passe trop de temps sous Windows) !

• ne pas écrire de bot IRC en perl, sinon on finit par le ré-écrire en python (mais en mieux, donc ça va) ;
• mettre des espaces dans du code C… Merci vim et les regexps pour ajouter un espace entre nom de fonction et parenthèse ouvrante :
  :%s/\([^ |_]\)(/\1 (/g
• ne pas rester trop longtemps sans session U-Classroom (n’oubliez pas de venir nous voir jeudi soir si le packaging debian/ubuntu vous intéresse).

Je me suis donc construit un chroot CentOS 5, disponible pour les users grâce à dchroot. Ca s’installe en 10 minutes, alors pourquoi s’en priver ?

# Préparation de l'environnement
su
export CHROOT=/var/chroot/centos
 
# Construction du système de base
mkdir -p $CHROOT
apt-get install rinse
rinse --distribution centos-5 --directory $CHROOT
 
# Fstab
cat >> /etc/fstab <<EOF
# centos chroot
proc  $CHROOT/proc    proc    defaults    0 0
/home $CHROOT /home    none    bind        0 0
/tmp   $CHROOT/tmp     none    bind        0 0
/dev  $CHROOT/dev     none    bind        0 0
devpts $CHROOT/dev/pts devpts  defaults    0 0
EOF
mount -a
 
# Dchroot:
apt-get install dchroot
echo "centos $CHROOT" > /etc/dchroot.conf
echo CentOS > $CHROOT/etc/debian_chroot # le bashrc de debian affichera un joli prompt
chroot $CHROOT passwd # mot de passe root
chroot $CHROOT useradd -u uid_user user # pour éviter les problèmes de permission
chroot $CHROOT passwd user

C’est maintenant possible de tester :

exit
dchroot -c centos # en tant qu'user

Vous devriez voir un prompt du style :

(CentOS)gauvain@zero:~$


J’ai eu quelques soucis avec urxvt, mais il existe un workaround :

cat >> ~/.bashrc <<EOF
# urxvt terminal in centos
if [ "$TERM" = "rxvt-unicode" ] && grep -qi centos /etc/issue; then
  TERM="rxvt"
  export TERM
fi
EOF

Après avoir installé les paquets nécessaire dans le chroot, un simple wrapper (/usr/local/bin/rpmbuild par exemple) pour rpmbuild me permet de lancer des builds de rpms de manière transparente :

#!/bin/sh
 
dchroot -c centos -d "rpmbuild $@"

Après avoir créé le dépôt svn et avoir commité une architecture initiale (du genre depot/app1/trunk, depot/app2/trunk, etc), il suffit d’utiliser un petit script (à lancer dans /home/you/tailor pour cet exemple), qui récupère chaque révision bzr pour la commiter dans le dépôt svn:

#!/bin/sh
 
ORIG=/path/to/bzr/
DIRS="app1 app2 app3 app4"
 
for D in $DIRS; do
  # clean the work dir otherwise bzr will not be happy
  rm -rf work
  mkdir work
 
  # set a tailor conf file for this conversion
  cat > conf <<EOF
[DEFAULT]
verbose = True
 
[project]
target = svn:target
start-revision = INITIAL
root-directory = /home/you/tailor/work
state-file = tailor.state
source = bzr:source
subdir =
 
[bzr:source]
repository = $ORIG$D/mainline
 
[svn:target]
repository = file:///path/to/svn/repo
module = /$D/trunk
EOF
 
  tailor --configfile=conf
done

Après un petit moment tout est inclus dans le dépôt svn !

dpkg-source: avertissement: fichier ooo-build/bin/a2az.pl sans caractère nouvelle ligne terminal (soit l’original soit la version modifiée)

Si vous ne l’avez jamais fait, lisez un build log utilisant gcc ou g++, ça vaut le détour.
PS : ne me dites pas de passer mon système en anglais, c’est déjà le cas. J’ai eu ce message en utilisant un serveur dont la langue est le français par défaut.

C’est sans doute enfoncer une porte ouverte mais je le répète quand même, avoir des logiciels open source dans des cas aussi critiques résoudrait probablement une partie des problèmes (probablement pas tous, ok, mais quand même).

• Olivier Fourdan a repris une partie du code de Xfkc pour l’intégrer dans le plugin de config du clavier Xfce. Yay ! Je vais probablement abandonner le développement, qui n’était de toute manière plus très actif.
• Linutop OS 2.2.2 devrait sortir d’ici peu (un jour je ferai un post sur mon taff chez Linutop, promis). Une beta/rc/whatever est dispo en ligne of course (cf notre wiki pour les updates).
• Regardez ce qui se passe chez Ulteo, il devrait y avoir des news sympas d’ici peu.
• OpenOffice 3 est sorti, vous pouvez le tester sans l’installer sur le bureau en ligne Ulteo (faudra que je parle de ce que je fais là bas aussi…).
• J’ai mis en place un wiki avec quelques code snippets, sorte de mémo un peu en vrac pour le moment. Je m’en servirai peut être pour préparer des potentiels cours pour la classroom. Si vous avez des choses à ajouter, allez-y (mais pas d’ajouts du genre “installer google earth sous Hardy” s’il-vous-plaît-merci).

Ce sera tout pour ce soir.