28/07/2011

Aujourd'hui j'ai un an

FreeBSD ports portmgr pkgng

Il y a un an jour pour jour que je faisais mon premier commit dans les ports FreeBSD sous le mentorat jadawin@ et tabthorpe@ merci à eux :).

Ça passe vite... :)

Le bilan de cette première année est plutôt positif je pense malgré quelques ratés. Plein de bonnes choses mais aussi quelques trucs que je pensais faire que je n'ai pas encore réussi à pousser.

Je vais commencer par les échecs et finir par les réussites c'est toujours mieux de finir par les bonnes choses :)

Pas Bien

Il y a un moment déjà que je bossai sur un framework d'options pour les ports qui viserai à remplacer l'actuel en offrant plus de fonctionnalités: groupe d'options, options incompatibles, options dépendantes d'autres options etc. Dans ce cahier des charges, il fallait aussi que le nouveau framework puisse remplacer le vieux de manière transparente.

La première étape je l'ai atteinte assez facilement, la complication est venue quand il a fallu faire la seconde. Du coup un an après je n'ai toujours pas pu pousser mon framework et il reste toujours le vieux dans l'infrastructure. J'espère pouvoir changer ça rapidement, j'ai une idée à creuser sous le coude :).

Un autre loupé pour le moment c'est le fakeroot ou pkgdir. J'aimerai bien pouvoir construire des packages sans avoir à les installer. J'aimerai aussi que l'on ne puisse pas installer de packages depuis les ports dont le PLIST est foireux. Je me suis donc lancé dans la création d'un patch fakeroot (en fait j'ai piqué dans un premier temps ce que nos voisins de midnightbsd avaient fait quand ils ont forké notre système de ports). Au final j'ai obtenu quelque chose qui marche dans 80% des cas. C'est pas mal, mais c'est complexe et je n'aime pas ne pas proposer de choses simples. Donc il n'a pour le moment pas été plus loin. En revanche j'ai récemment eu de nouvelles idées à ce sujet et devrait apporter de bonnes choses :). Wait and See.

Moyen pas bien ou moyen bien au choix

Passons des loupés de cette année aux choses mitigées: libreoffice. J'ai fait le port de la version 3.3 avec succès. J'avais 2 motivations pour ça: réutiliser au maximum ce qui est déjà dans les ports (ajouter les ports nécessaires si besoin) et pouvoir tourner sur pointyhat. Dans les deux cas c'est réussit.

En revanche, du côté de 3.4 c'est une autre paire de manches. Pour des raison qui m'échappent pour le moment je n'arrive pas à le compiler :( alors que la version 3.5 (git) compile sans trop de difficultés je galère sur la version 3.4. En même temps je ne consacre pas beaucoup de temps à libreoffice du coup je ne suis pas de près les évolutions et découvre les problèmes sur le tard. J'ai créé il y a peu une équipe office@ pour en prendre soin, en espérant que à plusieurs personnes, on arrive à toujours rester synchronisés avec l'upstream. Pour le moment la mayonnaise à l'air de prendre.

Bien

Les réussites maintenant:

Je suis portmgr@ maintenant, ce qui veut dire que mes démarches pour essayer d'améliorer les choses ont été bien acceptées :). Je ne m'attendais vraiment pas à devenir portmgr et encore moins aussi rapidement. Comme quoi s'investir est payant :)

Les campagnes de "deprecation". Les ports sont tout sauf dictatoriaux, du coup tout le monde peut y mettre ce qu'il veut ou presque. Mais le problème c'est que très peu de gens pensent à enlever les ports morts. Ceux, dont il n'y a plus de distfile publiquement dispo, dont le projet est totalement abandonné, etc. Tout le monde laisse traîner ça dans ports@. Moi je n'aime pas laisser traîner les vieux trucs partout comme ça, j'ai donc lancé 2 campagnes de "deprecation" la première a déjà viré environ 500 ports, la seconde devrait en virer 200 dans quelques jours, je pense que c'est une réussite et je vais le renouveler régulièrement. :)

Enfin last but not least, PKGNG :). Il y a un peu plus d'un an je tentai de porter pkgin sur FreeBSD. Je pense avec un certain succès dans le sens où ça a fonctionné pour de vrai.

Mais j'étais déçu par le côté trop pkgsrc (logique en même temps :)) de l'outil et par les tours de magie qu'il aurait fallu réaliser pour le faire fonctionner vraiment correctement sur FreeBSD. La faute n'est pas à pkgin mais plutôt aux différences entre les ports et pkgsrc.

Bref de là je me dit qu'il faudrait tout refaire "from scratch", en profiter pour avoir une architecture autour d'une bibliothèque et tout et tout. En gros je pensais partir sur une n-ième libpkg-qui-n-aboutira-jamais(c)(tm), pas très motivant :). Heureusement je n'étais pas seul à m'intéresser au sujet. Deux personnes qui ne sont pas motivées à l'idée de faire un projet qui n'aboutira pas et qui si même si il aboutissait ne serait jamais accepté ... Bah c'est assez con pour se lancer dedans :). Julien Laffaye et moi nous lançons donc dans le projet (aidé, surtout au début, de Philippe Pépiot), de longs mois plus tard, et toujours pas convaincu de ne pas faire ça pour rien, on décide de parler du projet pour le faire connaître. En effet nous avions quelque chose de viable et espérions ramener ainsi du monde sur le projet. Ce fut une très bonne idée ce mail :), dans la foulée nous avons été invité à participer au BSDCan pour présenter pkgng, et participer au groupe de travail sur pkgng. Le baptême du feu :). Préparé à recevoir des volées de critiques sur le pourquoi de SQLite, ou de tel autre choix, nous pensions devoir défendre notre bout de gras.

Bilan: pkgng a été accepté sans trop de discussions (grosse surprise :), et est maintenant clairement vu que le remplaçant des pkg_* tools. Dans quelques jours, on devrait sortir l'alpha2 avec beaucoup d'évolutions. Mais pas de teasing pour le moment :).

PS: pkgng c'est ici que ça se passe :)

0 commentaire(s)

07/04/2011

En attendant pkgng...

FreeBSD poudriere package binary portmaster jails ports

pkgng c'est cool, ça va être tout beau tout ça, mais voila c'est pas encore fini, il y a beaucoup de boulot à prévoir dessus encore pour que ça rentre en production.

En attendant des babasses FreeBSD on en veut toujours en production.

Voici donc comment je gère mes machines FreeBSD en full binaires.

La machine de build

Tout d'abord il vous faut une machine de build. (Je n'aime pas prendre les packages officiels, parce que je veux des versions plus récentes ou des set d'options différents, parce que avoir un mirroir avec 22000 packages ça ne me sert à rien sinon bouffer de l'espace disque.)

Faire les packages à la main n'est pas non plus très industriel, ni très sérieux.

Utiliser tinderbox me donne des boutons.

J'ai donc réutilisé un outil maison poudriere.

J'y ai rajouté une fonction bulk.

Petit rappel pour commencer, poudriere est un outil très simple ne nécessitant rien qui ne soit pas dans base. Son but est de permettre le test et la génération de packages pour FreeBSD.

Avec cette fonctionnalité de bulk, l'utilisateur donne une liste de packages à manger à poudriere et celui-ci va tous les générer, ainsi que leurs dépendances. Il va présenter le tout sous la forme d'un répertoire de packages identique à ceux officiels.

Commençons donc par créer nos environnements de build en considérant poudriere comme déjà installé.

Voici le fichier de configuration de mon poudriere:

ZPOOL=data
FTPHOST=ftp.free.org
IP=192.168.1.58
ETH=nfe0
PORTSDIR=/usr/local/poudriere/ports
POUDRIERE_DATA=/usr/local/pdata
WRKDIRPREFIX=/tmp/wrk
MFSSIZE=4G

poudriere utilise zfs il suffit de lui donner un zpool il se débrouille avec. Ici nous avons choisi "data". poudriere utilise les jails, il a donc besoin de connaître un host ftp pour récupérer les éléments nécessaires à la construction automatique des jails, une adresse IP et une interface réseau sur laquelle rajouter en alias l'adresse IP donnée.

Il a besoin de connaître l'arbre des ports sur lequel il va travailler, et où il va générer ses données: packages et logs.

Enfin quelques informations comme le WRKDIRPREFIX seront nécessaires si l'on veut tout construire en RAM (mdmfs et tmpfs possibles).

poudriere est maintenant utilisable, préparons donc les machines de build:

# poudriere createjail -v 8.2-RELEASE -n 82amd64 -a amd64 -s

Voila c'est tout ! Vous disposez désormais d'une machine de build pour FreeBSD 8.2-RELEASE pour l'architecture amd64. Vous pouvez en rajouter autant que vous voulez bien sûr.

Le bulk

Il s'agit maintenant de construire ses premiers packages. poudriere souhaite une liste, alors allons y:

# cat ~/listpkgs
ports-mgmt/portmaster
editors/vim
www/newsbeuter
www/elinks
devel/git

C'est déjà pas mal pour tester. Il est bien sûr possible de spécifier des options de compilation via: /usr/local/etc/poudriere.d/make.conf pour les options globales et/ou /usr/local/etc/poudriere.d/82amd64-make.conf pour les options spécifiques à la jail 82amd64.

# cat /usr/local/etc/poudriere.d/82amd64-make.conf
NOPORTDOCS=yes
WITHOUT_NLS=yes
WITHOUT_X11=yes
NO_GUI=yes

C'est prêt on peut lancer le build:

# poudriere bulk -f ~/listpkgs -j 82amd64

Si l'option -j n'est pas donnée alors il fera sur le boulot sur chacune des jails disponibles.

Ce que fait poudriere là c'est construire dans la jail vierge (merci les snapshots zfs) tous les packages demandés, en ayant pris soin de supprimer tout résidu d'un précédent bulk. Puis il va générer l'INDEX et le compresser en bzip2.

Cette étape peut donc être très longue.

Une fois terminée les résultats se trouveront dans : /usr/local/pdata/packages/bulk-82amd64

Le Répertoire étant utilisable tel quel.

Le client maintenant

On part donc d'une installation toute fraiche de freebsd sans l'arbre des ports

# export PACKAGESITE=http://monjoliserver/avec/mes/packages/
# pkg_add -r portmaster

Quelques options pour le portmaster.rc

# cat /usr/local/etc/portmaster.rc
MASTER_SITE_INDEX=http://monjoliserver/avec/mes/packages/
LOCALBASE=/usr/local
PACKAGESITE=http://monjoliserver/avec/mes/packages/
PM_PACKAGES=only
PM_INDEX=yes
PM_INDEX_ONLY=pm_index_only

Comme portmaster recherche encore quelques informations sur l'arbre des ports et que l'on ne souhaite pas ce comportement :

# mkdir /usr/ports/Mk
# touch /usr/ports/Mk/bsd.port.mk

portmaster est maintenant utilisable:

# portmaster www/newsbeuter
[...]
===>>> The following actions will be taken if you choose to proceed:
	Install www/newsbeuter
	Install devel/gettext
	Install converters/libiconv
	Install devel/pkg-config
	Install devel/stfl
	Install ftp/curl
	Install security/ca_root_nss
	Install textproc/libxml2
	Install databases/sqlite3

===>>> Proceed? y/n [y]

[...]
===>>> The following actions were performed:
	Installation of converters/libiconv (libiconv-1.13.1_1)
	Installation of devel/gettext (gettext-0.18.1.1)
	Installation of devel/pkg-config (pkg-config-0.25_1)
	Installation of devel/stfl (stfl-0.21_1)
	Installation of security/ca_root_nss (ca_root_nss-3.12.9)
	Installation of ftp/curl (curl-7.21.3_1)
	Installation of textproc/libxml2 (libxml2-2.7.8_1)
	Installation of databases/sqlite3 (sqlite3-3.7.5)
	Installation of www/newsbeuter (newsbeuter-2.4)
#

Voila retour/docs/patchs bienvenus, as usual :)

0 commentaire(s)

29/03/2011

Nano jails

jails FreeBSD CBlog

A la demande populaire voici un micro howto sur comment créer des nanos jails(8).

Pour cela je vais vous monter comment tourne mon blog (à base de cblog).

Quelques petites commandes pour bien montrer de quoi on parle

$ jls -j cblog
JID  IP Address      Hostname                      Path
1  10.50.0.1       cblog                         /zdata/jails/cblog/
$ du -hs /zdata/jails/cblog/
2,3M    /zdata/jails/cblog

c'est tout rien de plus.

Il y a même des choses en trop par exemple cette jail n'a pas besoin de réseau pour fonctionner normalement.

En fait une jail n'a pas besoin de grand chose pour fonctionner et depuis que l'on dispose des jails persistantes elles ont même besoin de rien du tout.

Examinons un peu le contenu de cette jail : 

/zdata/jails/cblog
/zdata/jails/cblog/bin
/zdata/jails/cblog/bin/cblog.fcgi
/zdata/jails/cblog/data
/zdata/jails/cblog/data/*
/zdata/jails/cblog/usr/local/etc
/zdata/jails/cblog/usr/local/etc/cblog.conf
/zdata/jails/cblog/libexec
/zdata/jails/cblog/libexec/ld-elf.so.1
/zdata/jails/cblog/lib
/zdata/jails/cblog/lib/libfcgi.so.0
/zdata/jails/cblog/lib/libz.so.5
/zdata/jails/cblog/lib/libc.so.7

Nous y retrouvons donc le strict nécessaire pour faire tourner cblog.

pour en arriver là il faut préparer le fs. (je suis utilisateur de zfs :))

$ zfs create /zdata/jails/cblog
$ mkdir /zdata/jails/cblog/bin
$ mkdir /zdata/jails/cblog/lib
$ mkdir /zdata/jails/cblog/libexec

Je dépose ensuite le binaire cblog.fcgi (je l'ai pris dans le paquet officiel)

$ cp /tmp/cblog-0.1.15/libexec/cblog.fcgi /zdata/jails/cblog/bin

Je regarde ce que demande ce binaire:

$ ldd /zdata/jails/cblog/bin/cblog.fcgi
/zdata/jails/cblog/bin/cblog.fcgi:
libfcgi.so.0 => /usr/local/lib/libfcgi.so.0 (0x80066b000)
libz.so.5 => /lib/libz.so.5 (0x800775000)
libc.so.7 => /lib/libc.so.7 (0x80088a000)

Je rajoute donc ce qui va bien dans ma future jail:

$ cp /lib/libz.so.5 /zdata/jails/cblog/lib
$ cp /lib/libc.so.7 /zdata/jails/cblog/lib
$ cp /usr/local/lib/libfcgi.so.0 /zdata/jails/cblog/lib

J'ai vérifié les dépendances de la libfcgi et elle ne ramène rien d'autre.

Le paquet cblog est compilé avec comme prefix /usr/local du coup il cherche son fichier de conf dans /usr/local/etc/cblog.conf (vu de la jail)

$ mkdir /zdata/jails/cblog/usr/local/etc

Je prévoie de mettre les données que le binaire va manipuler dans /data (vu de la jail)

$ mkdir /zdata/jails/cblog/data

Je prépare le fichier de conf de mon cblog pour lui dire de trouver ses données dans /data (je zappe cette partie ce n'est pas le but de ce post). Le fichier de conf est déposé dans /zdata/jails/cblog/usr/local/etc sous le nom cblog.conf comme attendu.

C'est là que ça devient intéressant. Il est impossible de faire tourner une jail sans son runtime link-editor.

$ cp /libexec/lib-elf.so.1 /zdata/jails/cblog/libexec/ld-elf.so.1

Ici j'ai pris celui du système hôte car les binaire sont ceux du même format que ceux de l'hôte. Dans le cas d'un jail linux par exemple, il faudra prendre l'équivalent au format linux.

Nous pouvons maintenant démarrer la jail en question.

Ne surtout pas passer par /etc/rc.d/jail qui est complètement dépassé maintenant.

$ jail -c persist name=cblog path=/zdata/jails/cblog/ host.hostname=cblog ip4.addr=10.50.0.1

Si vous ne voulez pas d'adresse ip ni de hostname

$ jail -c persist name=cblog path=/zdata/jails/cblog/

jls vous montrera la jail qui tourne.

Démarrons le cblog pour qu'il écoute sur une socket unix.

$ jexec cblog /sbin/cblog.fcgi unix:/cblog.sock

Il suffit de donner le chemin /zdata/jails/cblog/cblog.sock à nginx par exemple dans sa config fastcgi pour que votre cblog soit accessible au plus grand nombre.

Pour stopper la jail:

$ jail -r cblog
0 commentaire(s)

30/08/2010

/me est puni

FreeBSD ports github bav

Voila ça m'apprendra, à vouloir faire des trucs, j'ai été puni depuis fin juillet.

Maintenant je dois pousser moi-même mes modifications, il va donc falloir que je fasse attention.

Heureusement, pendant quelque temps on ne tape pas que sur moi si je casse tout, mais on tape aussi et surtout sur mes mentors : jadawin et tabthorpe :)

<bav>

Après 1 mois de ce nouveau statut, j'ai accumulé beaucoup de bave contre github, il me faut l'exprimer, il parait que c'est thérapeutique :

De plus en plus de développeurs utilisent github, c'est pas mal en soit: du git, une interface moderne kikooweb3.0.

Mais ça serait bien de NE PAS UTILISER LES TAGS COMME FICHIER RELEASE!!!! Bordel, github fait de la grosse merde avec ça !!!

Donc si vous êtes utilisateurs de github, s'il vous plaît fournissez une vraie archive tout ce qu'il y a de plus classique distribuée via un système qui autorise un téléchargement par lien direct.

</bav>

Pour revenir à ma punition, voila les projets que j'aimerai mener à bien concernant FreeBSD:

Dans tous les cas je tiens à remercier particulièrement jadawin et tabthorpe pour leur patience et les conseils qu'ils me donnent lors de la revue/validation de mes commits : "pas trop usant ? :)"

2 commentaire(s)

15/07/2010

How tout casser chez tout le monde épisode 1

FreeBSD ports ZFS tinderbox jail

Afin de m'assurer que lorsque je joue avec mes ports, je casse bien tout, càd sur toutes les version supportées : 7.3, 8.0, 8.1 et celles à venir. Pour pouvoir bien vérifier que je mets le dawa aussi bien sur i386 que amd64, je me suis enfin décidé à poser une tinderbox.

La tinderbox officielle de freebsd ne me convient pas. Je la trouve démeusurément complexe pour ne pas dire tordu rapport à mes besoins, Elle a besoin d'une base de données (bon à la rigueur un petit postgresql ne me dérangerai pas plus que ça) mais pour la webui il faut aussi PHP et là faut pas déconner, je n'ai pas envie de me faire chier avec du PHP sur mes machines (comment ça je suis obtu ?).

Je suis donc parti pour me pondre la mienne. Je ferai ici l'état de l'avancée de ma tinderbox maison.

Episode 1 : principe et création des environnements.

Ma tinderbox sera moins automatisée que la tinderbox officielle, il faudra se faire à la main ses jails souches etc.

concepts :

Que va faire le script :

maintenant que les concepts sont présentés passons à l'étape préparation des jails.

ici les jails sont dans /home/jails/tinderboxes celui ci étant un FS ZFS : system/jails/tinderboxes pour être précis. pour créer ces jails nous allons avoir besoin de : lftp et de zsh.

Oui comme je suis une loutre, je ne vais pas me lancer dans une compilation des sources pour créer mes jails, je vais directement partir des sets officiels.

for arch (i386 amd64) {
	for version (7.3-RELEASE 8.0-RELEASE 8.1-RC2)  {
		zfs create system/jails/tinderboxes/${version%-*}-$arch
		cd /home/jails/tinderboxes/${version%-*}-$arch
		export DESTDIR=/home/jails/tinderboxes/${version%-*}-$arch
		/usr/local/bin/lftp -c "open ftp://ftp.free.org/pub/FreeBSD/releases/$arch/$version/; mirror base"
		/usr/local/bin/lftp -c "open ftp://ftp.free.org/pub/FreeBSD/releases/$arch/$version/; mirror src"
		cd base
		yes | ./install.sh
		cd ../src
		./install.sh all
	}
}

J'ai donc maintenant à ma disposition 6 FS contenant chacun des images minimales freebsd il faut maintenant finir la config et les mettre à jours avec freebsd-update

pour chacune des jails il faudra forcer des variables d'environnement pour qu'elles sachent quel est leur version. Pour cela il faut modifier le login.conf de chacune d'entre elles et remplacer :

:setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES:\

par

:setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES,UNAME_r=7.3-RELEASE,OSVERSION=703000,UNAME_v=FreeBSD 7.3-RELEASE:\

Il faut adapter le 7.3-RELEASE pour chacune des jails.

Pour déterminer la bonne valeure pour OSVERSION, un petit awk à la racine de la jail va pouvoir nous aider : 

awk '/\#define __FreeBSD_version/ { print $3 }' usr/include/sys/param.h

Pour les jails i386 il faut rajouter dans la ligne du login.conf

UNAME_m=i386,UNAME_p=i386

Pour que tout ceci soit pris en compte, ne pas oublier :

cap_mkdb login.conf

Toujours pour les jails i386, il ne faut pas oublier de mettre dans etc/make.conf

MACHINE=i386
MACHINE_ARCH=i386

Avant de démarrer les jails on ajoute 2 lignes sur le etc/rc.conf de chacunes d'entres elles afin qu'elles ne démarrent ni sendmail ni cron dont nous n'avons pas besoin. Pour le moment on garde la syslog pour que la jail reste fonctionnelle.

sendmail_enable="NO"
cron_enable="NO"

sur la machine hôte on peut ajouter les lignes nécessaires au démarrage des jails dans le rc.conf : 

jail_73i386_rootdir=/home/jails/tinderboxes/7.3-i386
jail_73i386_hostname="tinder73i386"
jail_73i386_ip="192.168.1.51"
jail_73i386_interface="nfe0"
jail_73i386_devfs_enable="YES"
jail_73i386_devfs_ruleset="devfsrules_jail"
jail_73i386_flags="-n tinder73i386"

faire de même pour chacune des jails.

une fois les jails démarrées, il faut effectuer les mises à jours, toujours aider de zsh :

for arch (i386 amd64) {
	for version (73 80 81) {
		jexec -U root tinder${version}${arch} /usr/sbin/freebsd-update fetch install
	}
}

Le -U root est important pour que login.conf soit pris en compte.

Un fois les mises à jours faites il est possible d'actualiser les fichiers login.conf afin de refléter les nouvelle version 7.3-RELEASE-p1 par exemple, mais ce n'est pas obligatoire.

maintenant il faut arrêter toutes les jails et faire un snapshot zfs qui nous servira de référence et permettera de repartir de bases propres : 

zfs snapshot system/jails/tinderboxes/7.3-amd64@propre

recommencer l'opération pour toutes les jails.

Ceci est la fin du premier épisode (je sais ça a un air de déjà vue avec un post précédent, mais la suite sera différente :))

0 commentaire(s)

17/06/2010

One-liner again

ZSH FreeBSD ports

Je voulais pouvoir récupérer la liste complète des ports outdated de FreeBSD, pour ça nous disposons de portscout mais ce dernier ne présente que la liste par mainteneur, or je voulais la liste complète... mais portscout propose un flux rss qui, si il est appelé sans le paramètre ?m=, liste tous les ports outdated (attention le fichier est gros).

J'ai donc pris quelques armes :

le résultat :

feed=(${(f)"$(fetch -q -o - http://portscout.org/rss/rss.cgi)"}) && for item ({1..$(xml sel -t -v "count(//item)" =( print -lr $feed))}) { xml sel -t -v //item[$item]/title =( print -lr $feed) | html2text } > portscout.txt

avec cette ligne je récupère un fichier portscout.txt donc le contenu est :

categorie/port: ancienne_version -> nouvelle_version

tout simplement

UPDATE :

Voici une version plus zshienne (plus besoin de xmlstarlet ni de html2text) en revanche elle est moins souple mais plus rapide : 

feed=(${(f)"$(fetch -q -o - http://portscout.org/rss/rss.cgi)"}) && for item ({0..$#feed}) { [[ -z ${feed[$item]:#\<item\>*} ]] && { print ${${${${feed[$item + 1]}/&#x3E;/>}/\<\/title\>/}/\<title\>} } } > portscout.txt
0 commentaire(s)

30/04/2010

Permission de sortie : 30 minutes

FreeBSD pf at

Le Besoin

Les ingrédients

Recette

PF

scrub in all
set skip on lo0
pass out all
block in all
table <allowips> persist
pass in quick inet proto tcp port https keep state
pass in quick inet proto tcp from <allowips> to port 8080 keep state

Voila tout simple tout beau, en gros on bloque tout sauf le https. On autorise toutes les ips qui sont contenu dans la table allowips

Problème : comme rajouter des adresses IPs dans la table allowips et surtout comment les supprimer au bout de 30 minutes

CGI shell

Nous créons donc un script cgi qui après une authentification "ultra basique" ajoutera l'adresse IP du demandeur dans la table allowips et schedulera la supression de celle ci

#!/bin/sh
if [ "$REQUEST_METHOD" = "POST" ];then
	query="dd count=$CONTENT_LENGTH bs=1 2> /dev/null"
else
	echo "Bad request"
	return
fi

# Ceci n'est pas super clean, il y a mieux à faire mais flemme :)
eval $query

if [ -z $passwd ]; then
	echo "Bad request"
	return
fi

decodedpasswd=$(echo $passwd | awk '"'BEGIN{for(i=0;i<10;i++)hex[i]=i;hex["A"]=hex["a"]=10;hex["B"]=hex["b"]=11;hex["C"]=hex["c"]=12;hex["D"]=hex["d"]=13;hex["E"]=hex["e"]=14;hex["F"]=hex["f"]=15;}{gsub(/\+/," ");i=$0;while(match(i,/%../)){;if(RSTART>1);printf"%s",substr(i,1,RSTART-1);printf"%c",hex[substr(i,RSTART+1,1)]*16+hex[substr(i,RSTART+2,1)];i=substr(i,RSTART+RLENGTH);}print i;}'"')

if [ -f /usr/local/etc/authpasswd ]; then
	read encryptpasswd < /usr/local/etc/authpasswd
else
	echo "No password file"
	return
fi

cryptpasswd=$(echo $decodedpasswd | /sbin/sha256)
if [ "$cryptpasswd" = "$encryptpasswd" ]; then
	/usr/local/bin/sudo /sbin/pfctl -t allowips -T add $REMOTE_ADDR
	echo "/usr/local/bin/sudo /sbin/pfctl -t allowips -T delete $REMOTE_ADDR" | /usr/bin/at now + 30 minute
	echo "Acces granted for 30 minutes"
else
	echo "Acces refused"
fi

C'est pas terrible mais suffisant : le mot de passe de référence est stocké dans /usr/local/etc/authpasswd et est en sha256

Il faut maintenant autoriser l'utilisateur www à pouvoir utiliser at :

$ echo "www" > /var/at/at.allow

Ensuite rajouter les entrées sudo qui vont bien dans /usr/local/etc/sudoers

%www	ALL=NOPASSWD:	/sbin/pfctl -t allowips *

Il vous reste à faire un fichier html qui appelle le script CGI via la méthode POST en lui fournissant le mot de passe donné dans une variable "passwd". Mettre le tout à dispo via un serveur web supportant le CGI.

Après on me demande pourquoi j'aime les Unix...

EDIT : alors on me dit dans l'oreillette que pfctl -t allowips -T expire 1800 lancé toutes les minutes dans une crontab ferait le même boulot mais je préfère ma solution à coup de at puisque at est géré par cron sous FreeBSD et que ce n'est exécuté qu'au besoin et non toutes les minutes

0 commentaire(s)

27/02/2010

Emprisonner une debian dans un FreeBSD

FreeBSD jail Linux debian

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.

2 commentaire(s)

25/02/2010

Une jail 32bits sur un host 64bits

FreeBSD jail pkgin

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 :

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
0 commentaire(s)

25/11/2009

Convertir l'arbre CVS des ports en git (round 2)

FreeBSD git CVS ports

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 :

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.

1 commentaire(s)

Pages : 1 2 3 4