Emprisonner une debian dans un FreeBSD
Parfois on a besoin de tester des choses sous linux, parfois on a besoin d'utiliser des applications linux-only, où pour tout un tas d'autre raison on a besoin de faire tourner un linux.
Pour ça c'est vrai que l'on peut virtualiser dans un virtualbox ou un qemu, c'est bien mais c'est quand même coûteux en terme de ressources pour le host.
Sous FreeBSD nous disposons du linuxulator c'est la couche d'emulation permettant de faire tourner des applications Linux sous FreeBSD.
Ni une ni deux je me dis qu'il est possible de faire de petites choses sympathiques avec ça : une jail linux-only.
Il faut d'abord préparer le terrain :
# mkdir /home/jails/debian
# mkdir /home/jails/debian/dev
# mkdir /home/jails/debian/proc
# mkdir /home/jails/debian/sys
# kldload linux
# kldload linprocfs
# kldload linsysfs
# kldload lindev
# mount -t devfs none /home/jails/debian/dev
# mount -t linprocfs none /home/jails/debian/proc
# mount -t linsysfs none /home/jails/debian/sys
Nous allons donc utiliser /home/jails/debian comme racine de la debian que nous allons installer.
Nous chargeons tous les pilotes nécessaires (notez que lindev est apparu en FreeBSD 9 et a été MFCed en 8-STABLE il n'est absolument pas obligatoire)
On pourrait faire l'installation avec debootstrap, mais comme je suis un feignant j'ai préféré utiliser un template openvz tout fait :
# fetch http://download.openvz.org/template/precreated/debian-5.0-x86.tar.gz
Puis le depacker dans ma jail :
# tar xvfp debian-5.0-x86.tar.gz -C debian --exclude dev* --exclude proc* --exclude sys*
Pour démarrer correctement la jail il faut qu'au minimum un service tourne dans la jail (je n'ai pas réussit à faire une jail linux-only persistente). Par défaut le script de démarrage des jails essaye de lancer /etc/rc que nous allons créer et de lancer /etc/rc.shutdown pour s'arrêter.
# echo "/etc/init.d/cron start" > /home/jails/debian/etc/rc
# chmod 755 /home/jails/debian/etc/rc
# echo "/etc/init.d/cron stop" > /home/jails/debian/etc/rc.shutdown
# chmod 755 /home/jails/debian/etc/rc.shutdown
dans /etc/rc.conf on règle le lancement de la jail
jail_debian_rootdir=/home/jails/debian
jail_debian_hostname="debian"
jail_debian_ip="192.168.1.3"
jail_debian_interface="nfe0"
jail_debian_devfs_enable="YES"
jail_debian_devfs_ruleset="devfsrules_jail"
jail_debian_flags="-n debian"
on démarre la jail :
# /etc/rc.d/jail start debian
et magie :
#jls
JID IP Address Hostname Path
15 192.168.1.3 debian /home/jails/debian
#jexec debian uname -a
Linux debian 2.6.16 FreeBSD 8.0-STABLE #3: Sun Jan 10 20:39:38 CET 2010 i686 GNU/Linux
#jexec debian cat /etc/debian_version
5.0.4
Vous voila avec une belle debian emprisonnée dans un freebsd.
Attention, tout ne fonctionne pas parfaitement : sysklogd ne marche pas à cause des accès /dev par exemple, mais c'est 99% fonctionnel quand même.
Une jail 32bits sur un host 64bits
J'ai un eeepc 1000H qui fonctionne à merveille sous FreeBSD tout y est reconnu, juste un petite compilation maison pour le wifi, bref c'est pas le sujet de ce post.
Le truc c'est qu'un eeepc bah c'est lent pour la compilation, le binaire fournis par freebsd ne sont pas vraiment compilés avec les options que je souhaite, mais il s'avère que j'ai un beau Q6660 qui lui est plutôt très bien pour la compilation.
D'un autre côté je mijote toujours ma version FreeBSD de pkgin, du coup je me dis pourquoi pas compiler sur mon Q6600 les packages binaires depuis les ports et les installer via pkgin sur le 1000H, bah oui en voila une idée qu'elle est bonne.
De ce pas je me configure une jail 32bits (de la doc pour ça il y en a partout je vous laisse chercher :)) je me connecte dessus :
$ jexec eeepc /bin/sh
Je commence à compiler des ports, mais rapidement ça brotch de partout. Normal il me compile la moitié des choses en pensant avoir affaire à un amd64 :
$ uname -a
FreeBSD eeepc 8.0-STABLE FreeBSD 8.0-STABLE #3: Sun Jan 10 20:39:38 CET 2010 root@galway.lan:/usr/obj/usr/src/sys/GALWAY amd64
C'est pas du tout, mais alors pas du tout la cible que je cherche, moi je veux build de l'i386, en suivant la branche RELEASE du kernel (pour les drivers venant des ports).
Réglons les problèmes un par un.
Tout d'abord faisons fonctionner freebsd-update afin de pouvoir avoir le dernier niveau de patch de la branche RELEASE
$ freebsd-update fetch
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching metadata signature for 8.0-STABLE from update5.FreeBSD.org... failed.
Fetching metadata signature for 8.0-STABLE from update4.FreeBSD.org... failed.
Fetching metadata signature for 8.0-STABLE from update2.FreeBSD.org... failed.
No mirrors remaining, giving up.
C'est pas gagné pourtant j'ai bien installé un jail 8.0-RELEASE. Il me faut donc le lui faire savoir. Pour cela, il suffit de modifier le /etc/login.conf de la jail et remplacer :
:setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES:\
par
:setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES,UNAME_m=i386,UNAME_p=i386,UNAME_r=8.0-RELEASE-p2,OSVERSION=800107,UNAME_v=FreeBSD 8.0-RELEASE-p2:\
Une recontruction de la db est nécessaire :
$ cap_mkdb /etc/login.conf
On peut maintenant quitter l'environnement et se reconnecter à la jail, par contre pour forcer la prise en compte de login.conf il faut forcer l'utilisateur dans la ligne jexec du coup :
$ jexec -U root eeepc /bin/sh
$ uname -a
FreeBSD eeepc 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 i386
Parfait, maintenant relancez freebsd-update vous verrez qu'il fonctionne correctement.
Second problème les ports, là il en faut un peu plus.
En effet les ports vont chercher l'architecture via le sysctl :
- hw.machine
- hw.machine_arch
Là notre astuce ne fonctionne plus, de plus il est impossible de les changer depuis une jail. Du coup en cherchant un peu dans /usr/ports/Mk/*.mk on se rend vite compte que l'on peut contourner le problème via /etc/make.conf. Pour ça, il suffit de rajourer les variables suivantes :
MACHINE=i386
MACHINE_ARCH=i386
Désormais je peux tout compiler tranquilement depuis ma jail et utiliser les packages sous mon eeepc. Afin de gagner en simplicité j'utilise ma version maison de pkgin (oui un jour elle sera intégrée upstream), en générant un INDEX.bz2 de la liste de mes packages et en mettant ça à dispo sur un serveur web par exemple
PS: pour générer l'INDEX.bz2, j'ai fait un petit prog en C: pkg_index, il n'est pas aussi complet que l'INDEX.bz2 normal mais beaucoup plus simple à utiliser et suffisant pour pkgin.
$ ./pkg_index /usr/ports/packages
PS2: pour créer mes packages j'utilise portmaster c'est moins lourd qu'une tinderbox
$ portmaster -ag
Cgit et autres cgi dans nginx
Jusqu'a présent pour avoir cgit je passais pas par la méthode thttpd.
Ça ne marchait pas trop mal, mais bon ça ne me plaisait pas trop de faire tourner un serveur web complet derrière mon nginx
Et puis pour je ne sais plus quelle raison, j'étais obligé d'utiliser un virtual-root=/cgit/ qui ne me plaisait pas beaucoup plus.
Aujourd'hui dans mes recherches, je tombe sur : fcgiwrap, je récupère donc le tout :
$ git clone git://github.com/gnosek/fcgiwrap.git
Je modifie le Makefile pour y ajouter -I/usr/local/include et -I/usr/local/lib afin que gcc puisse trouver fcgi comme il faut. Et j'install le tout :
$ install -m 755 -o root -g wheel fcgiwrap /usr/local/bin
pour lancer les fastcgi, j'utilise spawn-fcgi, et pour les avoir au démarrage ma méthode est un peu gruik mais ça marche :
$ cd /usr/local/etc/rc.d
$ sed -e 's/fcgi/fcgiwrap/g' spawn-fcgi > spawn-fcgiwrap-tmp
$ sed -e 's|/usr/local/bin/spawn-fcgiwrap|/usr/local/bin/spawn-fcgi|' spawn-fcgiwrap-tmp > spawn-fcgiwrap
$ chmod 555 spawn-fcgiwrap
$ rm spawn-fcgiwrap-tmp
Puis dans /etc/rc.conf
spawn-fcgiwrap_enable="YES"
spawn_fcgiwrap_app="/usr/local/bin/fcgiwrap"
spawn_fcgiwrap_bindsocket="/tmp/fcgiwrap.sock"
Enfin pour finir je configure comme suis le nginx :
server {
access_log /var/log/nginx/git.access.log main;
server_name git.*;
location / {
rewrite ^/(.*)$ /cgit.cgi/$1 break;
include fastcgi_params;
root /usr/local/www/cgit;
fastcgi_param SCRIPT_NAME /cgit.cgi;
fastcgi_pass unix:/tmp/fcgiwrap.sock;
}
location ~ \.(png|css)$ {
root /usr/local/www/cgit;
}
}
Dans le /usr/local/etc/cgitrc il faut mettre : virtual-root=/
Le résultat est là
Convertir l'arbre CVS des ports en git (round 2)
Il y a quelques mois je cherchais tranquillement à convertir l'arbre cvs des ports FreeBSD en arbre git.
Ça avait bien marché, mais il y avait deux inconvénients majeurs :
- C'était trop long a faire
- Les mises à jours était horrible à faire.
Et puis hier, gaston me montre ça nonchalamment, puis ça, bon j'y crois pas trop mais je me lance
Récupération du CVSROOT
Créer le fichier de config suivant pour csup
*default host=cvsup.free.org
*default base=/var/db
*default prefix=/usr/portsdev/cvsroot
*default release=cvs
*default delete use-rel-suffix
*default compress
ports-all
Puis récupérer le cvsroot :
$ csup cvsroot-supfile
Installation des pré-requis
Installation des packages
$ make -C /usr/ports/devel/mercurial install clean
$ make -C /usr/ports/lang/ruby18 install clean
$ make -C /usr/ports/textproc/ruby-iconv install clean
$ make -C /usr/ports/devel/ruby-rbtree install clean
Installation de rcsparse
$ hg clone http://ww2.fs.ei.tum.de/~corecode/hg/rcsparse
$ cd rcsparse
$ ruby extconf.rb
$ make
$ make site-install
Récupération des sources de fromcvs
$ hg clone http://ww2.fs.ei.tum.de/~corecode/hg/fromcvs
Conversion du CVSROOT en git
Préparation du répertoire de destination
$ mkdir /usr/portsdev/freebsd-ports.git
$ cd /usr/portsdev/freebsd-ports.git
$ git init --bare
Conversion
$ cd /usr/portsdev/fromcvs
$ ruby togit.rb /usr/portsdev/cvsroot ports /usr/portsdev/freebsd-ports.git
2h30 (oui seulement 2h30 !!! ) après c'était fait
Le répertoire de destination fait 720Mo.
Repack du rep
$ cd /usr/portsdev/freebsd-ports.git && git repack -a -f -d
Ce coup ci ça ne dure que 5 petites minutes et le répertoire ne fait plus que 410Mo
Mise à jour de l'arbre git
Comme fromcvs fonctionne de manière incrémentale, il faudra juste relancer le csup de temps en temps et relancer la commande togit.rb pour faire très rapidement les mises à jours
Bilan du round 2
fromcvs n'est pas parfait (il n'importe pas encore les tags) en revanche il a été capable de me conserver plus de branches que ce que parsecvs avait fait, en plus il est beaucoup, beaucoup, beaucoup plus rapide :
Pour les ports la conversion passe de 17h30 à 2h30 le repack passant lui de 28h50 à 5min, la taille du repos avant repack de 4go à 710Mo.
Par contre attention togit.rb est un très gros consommateur de RAM : il a bouffé mes 4Go de RAM plus 3Go de SWAP pour convertir les ports !!!
La mise à jour fonctionne parfaitement. Autant dire que je garde cette méthode. J'ai bien essayé de modifier fromcvs afin qu'il puisse importer les tags, mais je n'y suis pas arrivé, le ruby ne m'aime définitivement pas.
Du flan oui mais convi
De plus en plus dans mon boulot je dois faire du flan, du corpo flan même je dirai, le problème c'est qu'il faut pour cela utiliser OpenOffice... Et OpenOffice bah c'est très très lourd, c'est bloat, et quand je rédige, je ne vois pas pourquoi j'utiliserai autre chose que mon convi vim.
Heureusement pandoc existe, il s'agit d'un convertisseur de document qui gère entre autre en entrée le format markdown et gère entre autre en sortie le format odt.
Je tente le coup, je rédige un début de document en markdown avec mon plus beau vim et je le converti en odt.
$ pandoc -f markdown -t conviflan.txt -o corpoflan.odt
Le résultat est presque parfait, mon document OpenOffice respecte différente hiérarchie de style. Presque parfait parce qu'il faut que j'y applique le style de la boite à ce document, quand même. Pour cela rien de plus simple.
On extrait le style d'un document corpoflan déjà existant :
$ unzip corpoflan-modele.odt styles.xml
Puis on l'insère dans le document générer :
$ zip corpoflan.odt styles.xml
Et voilà un beau document rédigé en toute légèreté qui respecte la mise en forme corpo.
Voici une autre petite astuce que j'ai trouvé pour rédiger des diagrammes simplement :
J'utilise pgf/tikz parce que ça fait très simplement de très belles choses corpo ready via LateX. Je fait donc mon diagramme en LateX et le transforme en pdf avec pdflatex, enfin, pour pouvoir le réutiliser sous la forme de png dans les documents corpoflan, imagemagick est mon sauveur :
$ convert -density 200x200 -quality 90 -trim diagramme.pdf diagramme.png
Elle n'est pas belle la vie ?
UPDATE
Si dans votre modèle de document d'origine il y a des images, pour les récupérer il faudra déterminer où elle se trouve de corpoflan-modele.odt, pour xmlstarlet peut vous aider :
$ xml sel -N draw="urn:oasis:names:tc:opendocument:xmlns:drawing:1.0" -N xlink="http://www.w3.org/1999/xlink" -t -v "//draw:image/@xlink:href" styles.xml
Pictures/100000000000004200000032A4B86058.png
d'où
$ unzip Pictures/100000000000004200000032A4B86058.png corpoflan-modele.odt
$ zip corpoflan.odt Pictures/100000000000004200000032A4B86058.png
(Il faut noter là que xml c'est le nom du binaire de xmlstarlet sous FreeBSD sous linux c'est généralement xmlstarlet le nom du binaire.
Exemple en image :
- Rédaction dans vim :
- Aperçu avant application du style
- Aperçu après application d'un style de framasoft
Une forge sous NetBSD
Installation des packages
Installation de pkgin
D'abord on installe le package pkgin en lui même via la méthode binaire "traditionnelle" NetBSD
$ export PKG_PATH=ftp://ftp.fr.NetBSD.org/pub/pkgsrc/packages/NetBSD/amd64/5.0/All
$ pkg_add -v pkgin
Il faut ensuite modifier le fichier /usr/pkg/etc/pkgin/repositories.conf pour y ajouter la ligne
ftp://ftp.fr.NetBSD.org/pub/pkgsrc/packages/NetBSD/amd64/5.0/All
Puis mettre à jour la liste des packages binaire disponibles
$ pkgin update
Installation des autres composants
Les composants dont on aura besoin sont les suivant :
- git : scmgit
- postgresql : postgresql84-server
- le connecteur postgresql pour ruby : ruby18-postgres-pr
- le binding imagemagick pour ruby : ruby18-RMagick
- le serveur web ruby : thin
On installe donc tout ça
$ pkgin install scmgit postgresql84-server ruby18-postgres-pr ruby18-RMagick thin
Quelques minutes plus tard tout est arrivé et installé
Installation des gems
Il faudra ensuite installer les Ruby On Rails via les gem
$ gem install rail -v=2.2.2
Récupération de redmine
Exemple pour la version 0.8.6 ici :
$ ftp http://rubyforge.org/frs/download.php/66633/redmine-0.8.6.tar.gz
Maintenant que tout est près passons à la configuration
Configuration
Ajouts des utilisateurs
Nous allons faire tourner chaque processus avec des utilisateurs différents :
redmine:redmine pour le serveur web thin git:git pour le daemon git
$ groupadd _redmine
$ groupadd _git
$ useradd -m -g _redmine _redmine
$ useradd -m -g _git _git
Préparation du serveur postgresql
D'abord on copie le script d'init de postgresql dans /etc/rc.d/ pour qu'il puisse être activé au démarrage :
$ cp /usr/pkg/share/examples/rc.d/pgsql /etc/rc.d/pgsql
$ echo "pgsql=YES" >> /etc/rc.conf
Puis on initialise la base :
$ /etc/rc.d/pgsql initdb -E unicode
Enfin on démarre le serveur
$ /etc/rc.d/pgsql start
On crée ensuite la base qui va bien
$ createuser -I -E -P -S -R -D redmine
Renseigner le mot de passe
$ createdb -T template0 -O redmine -E UTF8
Postgresql est maintenant utilisable
Configuration de redmine
$ tar xvfz redmine-0.8.6.tar.gz
$ mv redmine-0.8.6 redmine # non obligatoire
$ cd redmine
Configuration de la base de production redmine
$ cp config/database.yml.example config/database.yml
Il faut modifier ensuite ce fichier pour correspondre à :
production:
adapter: postgresql
database: redmine
host: localhost
username: redmine
password: mon_pwd
On initialise la base redmine :
$ RAILS_ENV=production rake db:migrate
Et on insère les données par défaut :
$ RAILS_ENV=production rake redmine:load_default_data
Afin que redmine puisse fonctionner, l'utilisateur dans lequel va tourner le serveur thin doit pouvoir accéder à certains répertoires :
$ mkdir tmp public/plugin_assets
$ sudo chown -R _redmine:_redmine files log tmp public/plugin_assets
$ sudo chmod -R 755 files log tmp public/plugin_assets
Configuration du serveur thin
Notez que ici redmine est installé dans /home/_redmine
Il faut simplement créer un script rcng pour démarrer automatiquement thin : /etc/rc.d/thin
#!/bin/sh
#
# PROVIDE: thin
# REQUIRE: DAEMON
. /etc/rc.subr
name="thin"
rcvar=$name
command="/usr/pkg/bin/$name"
stop_cmd="/usr/pkg/bin/thin -c /home/_redmine/redmine -e production stop"
command_args="-c /home/_redmine/redmine -e production -d -u _redmine -g _redmine start"
load_rc_config $name
run_rc_command $1
Puis l'activer
$ chmod 755 /etc/rc.d/thin
$ echo "thin=YES" >> /etc/rc.conf
$ /etc/rc.d/thin start
Un serveur thin tourne maintenant sur le port 3000 du serveur
le daemon git
On considère ici que les dépots git se trouveront dans /home/_git/depots Tout comme pour thin il faut simplement créer un script rcng
#!/bin/sh
#
# PROVIDE: gitdaemon
# REQUIRE: DAEMON
. /etc/rc.subr
name="git-daemon"
rcvar=$name
pidfile="/var/run/$name.pid"
command="/usr/pkg/libexec/git-core/git-daemon"
command_args="--detach --base-path=/home/_git/depot --user=_git --group=_git --pid-file=$pidfile"
load_rc_config $name
run_rc_command $1
Puis l'activer
$ chmod 755 /etc/rc.d/gitdaemon
$ echo "gitdaemon=YES" >> /etc/rc.conf
$ /etc/rc.d/gitdaemon start
Déposer les dépots git dans /home/_git/depots et ils seront automatiquement disponibles, par exemple :
Pour un depot /home/_git/depots/CBlog.git :
$ git clone git://monbeauserveur/CBlog.git
Pour plus d'information ici UnixGarden est ton ami : là et là
Conclusion
La forge est maintenant opérationnelle, pour y accéder : http://monbeauserveur:3000 .
UPDATE :
rhaamo vient de rajouter le support de mercurial
Snif c'est beau le libre : Merci !!
Un petit post pour dire merci.
Merci pourquoi ?
Alors voila la petite histoire, je ne fais pas d'autohébergement à part mon blog, or il y a quelques temps j'ai voulu faire un planet BSD francophone, ne trouvant rien d'ultra simple et léger j'ai développer le mien : CPlanet, rapidement c'est posé la question de l'hébergement.
En effet je voulais un service qui tourne tout le temps or l'auto hébergement c'est dépendant du fait que je joue ou pas avec mes machines et je joue souvent donc je br0tch souvent :).
C'est là que monsieur bsdsx en plus de contribuer à CPlanet me propose une petite jail FreeBSD toute mignonne chez lui pour héberger tout ça, depuis ça donne ça.
Pour l'hébergement de mes projets en eux même, je me suis tourné vers github qui me proposait gratuitement un bug tracker, du git, et un wiki, un petite forge sympathique en somme. Mais avec le temps ça n'allait pas du tout : impossible d'envoyer des fichiers dans la section download sans une saleté d'applet en flash qui pue à mort.
C'est là que monsieur rhaamo, en plus d'utiliser CBlog me propose un petit domU qui "of course run NetBSD" pour héberger le développement, depuis ça donne ça.
Un petit redmine+lighttpd+git-daemon+postgresql le tout propulsé par du NetBSD et installé très très rapidement grâce au beau pkgin de monsieur iMil.
Bon j'ai plus le choix maintenant il faut que je fasse une release stable de CPlanet et CBlog.
Bien sûr je vais bientôt documenter l'installation de brokk (pour info brokk est un lutin^Wnain forgeron de la mythologie Nordique)
VirtualBox sur un hôte FreeBSD
Au boulot pour les mails, nous utilisons Br0tchus Notes, un espèce de daube infâme qui te pique ta ram pire qu'un firefox dans ces mauvais jours, bref.
Mon problème c'est que mon Desktop c'est du FreeBSD et que les gens de chez IBM, il ne fournissent de clients que pour Linux (si on ne considère que les environnements libre) - le java ça ne devait pas permettre de faire des applis qui tourne chez tout le monde ??? (oui il y a des vrais morceaux d'eclipse donc de java dans les derniers clients Notes)... bref -
VirtualBox ayant été porté récemment sous FreeBSD avec le support des extensions Vt-X je me suis donc lancé dans la virtualisation d'une debian minimaliste qui n'aura pour seul but que de lancer le client Notes et de le confiner en RAM afin qu'il ne me pique pas tout ce que j'ai de disponible sur ce Desktop.
Pour cela je l'ai donc installé depuis les ports (il faudra faire attention pour lancé les VMs à bien avoir mounté /proc - oui le ports n'est pas encore super propre, mais on fera avec). Comme c'est déjà super long à compiler je l'ai compilé en enlevant le support QT4, en effet la GUI n'apporte pas grand chose à cette application et en plus elle ne permet pas d'accéder à des fonctionnalités intéressantes de VBox.
Pour finir afin d'être plus souple j'ai utilisé les volumes zfs comme disques pour l'invité.
Installation de virtualbox
$ make -C /usr/ports/emulators/virtualbox config
Choisissez les options qui vous plaisent
$ make -C /usr/ports/emulators/virtualbox install clean
Si tout ce passe bien vous disposez maintenant de virtualbox sur votre machine.
Préparation du disque d'accueil de l'invité
Règle devfs
Pour que les volumes pour l'invité puisse être modifié par l'application virtualbox, ils doivent appartenir au groupe vbox, devfs nous permet de le faire à la volée, pour cela, dans le fichier /dev/devfs.rules :
[localrules=1]
add path 'zvol/vbox/*' mode 0660 group vbox
Ne pas oublier de modifier /etc/rc.conf pour qu'il le prenne en compte :
devfs_system_ruleset="localrules"
Un petit redémarrage de devfs pour finir :
$ /etc/rc.d/devfs restart
Création du volume
5G suffirons largement pour notre installation et encore je suis très large
$ zfs create -V 5G vbox/debian
Nous disposons maintenant d'un disque qu'il ne reste plus qu'à ajouter au pool de disques VirtualBox :
$ VBoxManage internalcommands createrawvmdk -filename melebian.vmdk -rawdisk /dev/zvol/vbox/debian
$ VBoxManage registerimage disk debian.vmdk
Création de la machine virtuelle
Création de la VM sans disque
Nous allons donc créer la VM pour qu'elle support les extensions VT-x et qu'elle soit limitée à 256Mo de RAM il ne s'agirait pas non plus que notes se sente trop à son aise.
$ VBoxManage createvm -name debianVM -register
$ VBoxManage modifyvm debianVM --ostype debian -memory 256M
$ VBoxManage modifyvm debianVM --vtxvpid on
Nous allons aussi déporter le port 22 de l'invité sur le port 2222 local afin de se simplifier la tâche pour le réseau (on laisse le réseau par défaut de virtualbox)
$ VBoxManage setextradata debianVM "VBoxInternal/Devices/pcnet/0/LUN#0/Config/ssh/GuestPort" 22
$ VBoxManage setextradata debianVM "VBoxInternal/Devices/pcnet/0/LUN#0/Config/ssh/HostPort" 2222
$ VBoxManage setextradata debianVM "VBoxInternal/Devices/pcnet/0/LUN#0/Config/ssh/Protocol" TCP
Ajout du disque à la nouvelle VM et de l'iso de l'installeur
Tout d'abord on liste les disques disponibles dans le pool pour récupérer son identifiant :
$ VBoxManage list hdds
UUID: b6db4102-90fd-4073-ae61-c1c57556bb85
Format: VMDK
Location: /home/bapt/debian.vmdk
Accessible: yes
Il suffit maintenant de le rajouter :
$ VBoxManage modifyvm debianVM -hda b6db4102-90fd-4073-ae61-c1c57556bb85
On enregistre l'iso dans le pool VirtualBox :
$ VBoxManage registerimage dvd /home/bapt/Desktop/debian-501-i386-netinst.iso
Et on l'ajoute de la même manière à la VM
$ VBoxManage list dvds
UUID: b3329255-221a-4bb6-b1f4-be2d4bdc0f2f
Path: /home/bapt/Download/debian-501-i386-netinst.iso
Accessible: yes
$ VBoxManage modifyvm debianVM -dvd b3329255-221a-4bb6-b1f4-be2d4bdc0f2f -boot1 dvd
Installation de l'invité
Pour l'installation de l'invité, on démarrera en mode sdl pour la suite ça ne sera plus nécessaire :
$ VBoxManage startvm debianVM --type sdl
Ou
$ VBoxSDL startvm debianVM
il ne vous reste plus qu'à faire votre installation debian normale à laquelle vous ajouterez votre client br0tchus notes et le configurerez.
afin que votre VM puisse accéder au disque de l'hôte sans se prendre la tête, VirtualBox prévoie un mécanisme bien sympathique :
$ VBoxManage sharedfolder add debianVM -name share -hostpath /home/bapt/sharedvm
Pour y accéder depuis votre debian, il faudra installer les guestutils
$ apt-get install virtualbox-ose-guest-modules virtualbox-ose-guest-utils
Puis dans le /etc/fstab de l'invité
share /home/bapt/sharedHost vboxsf uid=bapt,gid=bapt 0 0
Maintenant lorsque vous démarrerez votre VM vous le ferez de la manière suivante :
$ VBoxManage startvm debianVM --type headless
Ou
$ VBoxHeadless startvm debianVM
Et pour se connecter à la VM depuis l'hôte :
$ ssh -Y -p 2222 bapt@localhost
lancez notes ou votre application désirée.
Comme je suis un gentil lutin j'ai partagé tout ça de manière plus générique sur GCU
CBlog bientôt une release donc un ports
Une nouvelle fonctionnalité vient de faire son apparition dans CBlog : la possibilité de pouvoir désactiver les commentaires via un simple "Comments: false" dans l'entête d'un message (à la demande de rhaamo - oui il y a au moins deux utilisateurs de CBlog :)).
En fait c'est encore mieux que ça, un nouveau champs Posts.nb.allow_comments est disponible dans le HDF (datafile) du coup vous pouvez faire ce que vous voulez avec dans votre template, il correspond au contenu de l'entête Comments:. Dans le template d'exemple si il est égale à false, il n'affiche pas le formulaire de commentaires.
Il me reste deux fonctionnalités à implémenter pour faire une release 1.0 :
- la gestion de page statiques.
- la gestion d'une page d'erreur pour afficher les problèmes plutot que le stderr.
Bien sûr il reste toujours du nettoyage a faire pour rendre plus propre et robuste le code, de la documentation :)
En ce qui concerne CPlanet il n'y a plus que du nettoyage car je ne vois pour le moment aucun besoin de rajouter de fonctionnalitées.
Dans tous les cas dès la release venue, un joli ports FreeBSD fera son entrée.
Toute contribution est la bienvenue, surtout que pour le moment le code n'a été testé que sous FreeBSD.
Reconstruire les paquets cassés
Voici un petit script ZSH pour rechercher les binaires systèmes qui ne trouvent pas les bibliothèques dont ils dépendent et les reconstruire en utilisant portmaster.
#!/usr/local/bin/zsh typeset -a torebuild rep=(/usr/local/bin/**/*(.)) rep+=(/usr/local/lib/**/*.so(.)) rep+=(/usr/local/sbin/**/*(.)) for bin ($rep) { file $bin | grep -q "ELF" && { ldd =$bin | grep -q "not found" && { torebuild+=$(pkg_info -qoW $bin) } } } portmaster -f ${(u)torebuild}