Le BlankoJoueb

Introduction

Dans certain cas nous aimerions installer un service ou une application sans avoir d'incidence sur les services annexes d'une machine. On peut vouloir tester un outil, devoir utiliser une application sur une version particulière de notre distribution ou encore, dans notre cas, installer un serveur MySQL sur une machine Debian sur laquelle nous ne voulons pas influer.

Pour ces cas - et bien d'autres encore - une solution existe : les chroots. Le chroot est un espace isolé du reste de l'environnement et possède ses propres bibliothèques, outils, applications, etc. Il peut communiquer avec le reste du monde, la machine hôte, etc. Mais il ne peut pas influer sur autre chose que lui-même.

Installation

Je vais donc vous décrire rapidement les commandes effectuées pour créer un chroot avec MySQL dedans. Pour des informations complémentaires je laisse les liens des tutoriels suivis dans le chapitre Liens de ce même article.

Voici donc les étapes successives (faites sur une Debian Squeeze) :

• Installation de l'outil debootstrap
• Création d'un répertoire /srv/chroot/squeeze
• Initialisation de la variable CHROOT nécessaire à toutes les opérations
• Création du chroot
• Montage des répertoires importants
• Identification sur le chroot
• Mise à jour du chroot
• Installation des locales et de nano
• Modification de l'invite de commande pour savoir que nous sommes dans un chroot
• Sortie puis entrée dans le chroot pour vérifier la modification de l'invite de commande
• Installation de MySQL
• Édition du fichier de configuration de MySQL
• Redémarrage de MySQL
• Édition de la configuration MySQL côté machine hôte

Et les différentes commandes :

su - root
apt-get install debootstrap
mkdir -p /srv/chroot/squeeze
CHROOT=/srv/chroot/squeeze
debootstrap --arch i386 squeeze $CHROOT http://ftp.fr.debian.org/debian/
mount -t proc proc $CHROOT/proc
mount -t devpts devpts $CHROOT/dev/pts
chroot $CHROOT /bin/bash --login
apt-get update
apt-get install locales nano
dpkg-reconfigure locales
echo "(CHROOT)" > /etc/debian_chroot
exit
chroot $CHROOT /bin/bash --login
apt-get install mysql-server mysql-client php5-mysql
nano /etc/mysql/my.cnf

On édite les lignes suivantes :

bind-address    = localhost

puis on redémarre le serveur MySQL :

service mysql restart

Ensuite on quitte le chroot et on édite le fichier de la machine hôte :

exit
nano /etc/mysql/my.cnf

On édite les lignes suivantes :

[client]
port    = 3306
socket    = /srv/chroot/squeeze/var/run/mysqld/mysqld.sock

puis plus loin dans le même fichier :

bind-address    = localhost

et on ajoute la ligne suivante :

chroot = /srv/chroot/squeeze

Vous voilà désormais avec un chroot contenant MySQL !

Conclusion

Créer un chroot n'est finalement pas compliqué. L'utiliser et installer des applications non plus. MySQL reste cependant particulier car il faut connaître l'option chroot du fichier de configuration. On rencontre aussi quelques difficultés avec PhpMyAdmin, mais ils peuvent être résolus via un tutoriel de l'accès PhpMyAdmin à un chroot MySQL sur le Quicky Blanko.

Liens

• Installer un chroot
• Installer MySQL dans un chroot

Introduction

Il y a quelques années de cela, un groupe de personnes ayant travaillé dans différentes communautés du Libre ont décidé de sortir un livre nommé Open Advices - littéralement Libres Conseils.

Ce sont des conseils de personnes avisées et expérimentées qui soulignent les éléments majeurs de la réussite d'un projet au sein d'une communauté Libre.

Libres Conseils chez Framablog

Récemment le Framablog s'est décidé à publier une version francophone du célèbre livre Open Advice. À cet effet, chaque semaine un nouvel article sort jusqu'à ce que nous arrivions à la période des RMLL qui devraient se dérouler à Bruxelles cette année.

Pour me remémmorer les conseils rapides donnés dans chaque article, j'ai fait un texte explicatif de chaque section du livre.

Synthèse des chapitres/sections

Voici donc la synthèse des articles du Famablog :

« Libres conseils », une, première ! (Introduction) : C'est un recueil de 42 auteurs qui devrait permettre à n'importe qui de mettre toutes les chances de son côté pour qu'un projet libre aboutisse vraiment, gagne en notoriété, entre dans une logique commerciale, et procure amour, gloire et beauté.

1. Du code avant toute chose : Une idée c'est bien. Avoir du code pour appuyer son idée, c'est mieux !
2. Tous les autres pourraient avoir tort, mais c'est peu probable : Si le logiciel n’est que pour vous-même, vous pouvez garder le code source et les infrastructures qui l’entourent comme terrain de jeu personnel. Mais si vous voulez que votre logiciel soit utilisé, qu’il compte pour les autres personnes, qu’il change (peut-être) le monde, alors vous allez devoir construire une saine et solide communauté d’utilisateurs, de contributeurs principaux, d’administrateurs et de développeurs de modules. Les utilisateurs ont besoin d’avoir l’impression de posséder le logiciel, de la même façon que vous.
3. Les projets open source s'épanouissent à l'air libre : Il convient de créer une communauté autour du projet pour que celui-ci s'épanouisse. Pour cela il faut disposer d'une bonne méthode de communication (blog, journaux, etc.) et d'outils permettant l'échange comme un wiki, un bugtracker, un site web officiel, etc.
4. *Prévoir l'avenir d'un projet open source * : Du fait de nombreux arrivées/départs de contributeurs dans un projet, il vaut mieux prévoir un standard de codage, des bonnes pratiques, documenter le code, développer les principales lignes directrices de son projet, vérifier le code orphelin pour qu'il ne le reste pas, laisser des astuces en tout genre et des commentaires sur ce qu'on a fait.
5. Du bon usage des mentors : Avis aux nouveaux arrivants d'un projet : n'attendez pas trop longtemps avant de demander de l'aide ; si demande d'aide il y a, donnez vos réflexions et la procédure suivie ; dès qu'un problème est résolu, prenez en note et mettez à jour la documentation officielle du projet afin que les nouveaux arrivants puissent s'y retrouver.
6. Pour que le Libre aille vers l'Université : Les étudiants sont des sujets vifs, curieux, plein d'énergie. Il est intéressant de créer un partenariat avec une université afin de créer un échange avec ces derniers. Ces étudiants apporteront du sang neuf dans votre communauté, des idées et un peu de temps libre dédié à votre projet. Par ailleurs le projet gagne en renommée.
7. Inviter à l'audace : Invitez fréquemment l'une ou l'autre personne du projet à participer à quelque chose. Ceci de manière positive, conviviale et ouverte. Vous impliquerez davantage les personnes dans cette grande aventure qu'est un projet libre.
8. Être administrateur systèmes : ne pas s'enfermer dans une spécialité ? : Multiplier ses compétences au sein d'un projet permet à celui-ci de toujours avoir une personne disponible en cas de problème, notamment en terme d'administration système. Avoir plusieurs administrateurs systèmes est plus que conseillé, même s'ils n'ont pas de compétences approfondies dans la matière. Il faut laisser chacun découvrir de nouveaux horizons.
9. Sauvegardes et garde-fous : On ne le dira jamais assez : faites des sauvegardes ! Une fois validées (vérifier qu'elles fonctionnent), ne plus avoir peur de mettre à jour le système fréquemment pour pallier aux trous de sécurité. Pensez aussi à avoir des sauvegardes dans plusieurs lieux et chez plusieurs personnes.
10. Comment s'attaquer aux problèmes : Pour résoudre un problème il faut :
    1. formuler la bonne question pour poser le problème en bonne et due forme,
    2. décomposer le problème afin de localiser les lieux où survient le problème,
    3. vérifier que les conditions préalables à l'arrivée d'un cas précis soient réunies,
    4. utiliser les bons outils pour les bons usages
11. D'un projet à l'autre, franchissez les frontières : Ne vous cantonez pas à votre propre projet. D'autres projets existent avec des idées différentes mais parfois avec des besoins communs aux votres ! Franchissez le pas et aller vers eux. Les échanges inter-projets sont bénéfiques !
12. Cent fois sur le métier remettez vos correctifs… : Pour écrire des correctifs :
    • suivez les normes de style de codage du projet à corriger
    • utilisez un outil de contrôle de version décentralisé (DVCS)
    • faites des diffs unifiées
    • faites de petits correctifs qui font UNE et UNE seule chose à la fois
    • faites un suivi de votre correctif pour en avoir le retour, les modifications éventuelles et finalement l'impact qu'il a sur le projet
13. *Tests contre Bogues : une guerre sans fin * : Fournissez à vos testeurs de quoi se mettre sous la dent ! Les tests ne se résument pas à de simples essais manuels façon maison, ce sont des choses plus complexes qui peuvent être faites de manière plus élaborées. Par exemple donner aux testeurs les endroits qui n'ont pas encore été testés, ou la liste des tests en cours, les résultats des tests précédents, etc. Plus le testeur a du retour sur ce qui a été fait, plus il mettra en œuvre ses compétences pour mettre à l'épreuve votre logiciel sur des points sensibles ou encore non-testés.
14. Remue-ménage dans le triage : Un suivi régulier des tickets de bugs est un bon moyen de réduire leur nombre et de stabiliser votre projet par la même. C'est aussi un lieu atypique pour participer et diminuer considérablement la tâche des développeurs qui ont - probablement - déjà assez à faire.
15. Faire un test à la fois vous met sur la bonne voie : Faites des tests unitaires et des tests d'intégration. Pour chacun d'eux, suivez la procédure décrite ici :
    1. Écrivez un test qui fait échouer votre code, mais qui, selon vous, sera passé quand la fonctionnalité sera implémentée ou que le bogue sera corrigé. Mode expert : pendant l’écriture du test, pensez à l’exécuter de temps en temps, même s’il n’est pas encore fini, et tentez de deviner le message d’erreur effectif que le test renverra. À force d’écrire des tests et de les faire tourner, cela devient plus facile ;
    2. Bidouillez le code ;
    3. Exécutez le test. S’il marche, passez au point 4, sinon retournez au point 2 ;
    4. C’est fini ! Dansez le sirtaki.
16. RTFM ? - mais où est-il, votre manuel ? : Les débutants et futurs contributeurs ont besoin de documentation pour accéder facilement à votre projet et potentiellement y participer. Prenez soin d'eux, prenez donc soin de la documentation !
17. Restons courtois ! : Ne considérez pas les questions posées comme des questions idiotes. Soyez moins arrogant, soyez polis avec vos utilisateurs/contributeurs/interlocuteurs !
18. Documenter c'est s'enrichir : La documentation permet à tout à chacun de s'enrichir d'un point de vue personnel comme social ou tout simplement sur un projet. Faire de la documentation peut se faire via l'idée de sprint (de brusques dépenses d’énergie avec un public ciblé et un but précis). Il est intéressant d'avoir une liste des documentations existantes et des contributeurs (ou non) du projet pour se situer dans un projet.

Note: RTFM = Read The Fine Manual

Conclusion

S'il y a bien un conseil à donner, c'est celui de lire ce recueil et d'appliquer les avis de ces 42 auteurs !

Vous mesurerez vous-même les répercutions que cela aura eu sur votre projet, mais je suis sûr que s'aura été bénéfique pour votre projet, votre communauté et au final pour vous.

Liens

• Open Advices
• Framablog
• Ma mise à jour de la synthèse ci-présente

Image sous Licence Creative Commons CC-BY-NC-ND 2.0 trouvée sur une galerie photo de umop_episdn.