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.

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 application Linux sous FreeBSD.

Ni une ni deux je me dis qu'il est possible de faire de petite choses sympathique 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 linuxprocfs none /home/jails/debian/proc
# mount -t linuxsysfs 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écessaire (noter que lindev est apparu en FreeBSD 9 et a été MFCed en 8-STABLE il n'est absoluement pas obligatoire)

On pourrait faire l'installation avec debootstrap, mais comme je suis un faignant j'ai préférer 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 a faire une jail linux-only persistente). Par défaut le script de démarrage des jail essaye de lance /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/gentoo
jail_debian_hostname="gentoo"
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 gentoo"

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 dans emprisonnée dans un freebsd

Attention, tout ne fonctionne pas parfaitement : sysklogd ne marche pas a cause des accès /dev par exemple, mais c'est 99% fonctionnel quand même.

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

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 a compiler des ports, mais rapidement ça brotch de partout. Normal il me compile la moitié des choses en pensant avoir affaire a 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 driver venant des ports).

Réglons les problème 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 package 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

Fred Gleason team released Rivendell 1.7.0 on monday, Debian and Ubuntu packages are now updated.

Please follow the quick start guide for your first Rivendell installation.

As usual, you can find on debian.tryphon.org :

• Debian packages : for lenny, squeeze or unstable
• Ubuntu packages : for hardy, jaunty and karmic
• both i386 and amd64 packages

At my work, we’re currently working on a new J2EE platform to host our webapp applications, based on Tomcat 6 (6.0.24 to be precise). After deployed few fully public webapps without any issue, we start to deploy some other webapps with an authenticated part. The authentication is based on OpenSSO, using REST APIs. The cookie is created to OpenSSO, then set (client side) by one of our own webapplication. This cookie is validate using isValidToken REST API on every application the user goes. However, we’re not able to get authentication working on the preproduction environment, while it working perfectly on the dev environment. After some investigations with the developpers, we notice the OpenSSO’s cookie value was truncated.

After reading this post on the tomcat’s user mailing list, we start to configure tomcat. Few hours after, I was thinking about change the tomcat configuration is only a workaround, without fixing the original problem. Thanks to the OpenSSO’s IRC channel, someone (Allan Foster) pointed me to com.iplanet.am.cookie.c66Encode configuration variable. You can enable it in the console, Configuration, servers and sites, click on default paramaters, and then advanced tab. Set the value to true, and voila! Everything is now working good!

UWS Description What is UWS? * UWS is a highly configurable windows service for starting arbitrary executables. * It combines the work of a task scheduler and monitoring specified executables. * UWS is open-source (BSD license). What does UWS do? * It continuously checks for different start events and run configured executables if one is reached. * It watches configured executables and provide reactions due to different application states. * A user script which will be cyclically executed provides more flexibility. How do I use UWS? * The Universal Windows Service requires Microsoft .Net Framework 1.1. * To use Universal Windows Service you have to install it.

UWS Description What is UWS?
* UWS is a highly configurable windows service for starting arbitrary executables.
* It combines the work of a task scheduler and monitoring specified executables.
* UWS is open-source (BSD license).
What does UWS do?
* It continuously checks for different start events and run configured executables if one is reached.
* It watches configured executables and provide reactions due to different application states.
* A user script which will be cyclically executed provides more flexibility.

How do I use UWS?
* The Universal Windows Service requires Microsoft .Net Framework 1.1.
* To use Universal Windows Service you have to install it.

Ça fait un moment que je projetais de publier une galerie photo à peu près montrable. On m’a signalé il y a quelques jours un moteur de photoblogs, Pixelpost. J’ai installé ça ce matin pour voir, mise en pratique ici.

Notes pour les admin système

À vue de nez, ça se présente comme une appli web classique. D’une part, c’est du PHP-MySQL et ça se pose sur place sans trop réfléchir. D’autre part c’est un gros foutoir qui mélange allègrement son propre code, les modules additionnels et les données. Pas encore regardé si on peut en faire une installation propre, faudra voir.

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à