Fresh blood needed for LibreOffice
For some time now, I have been maintaining pretty much alone the LibreOffice port for FreeBSD, trying to provide all the features LibrOffice has to our users.
I managed to port the 3.3.x series of LibreOffice to FreeBSD some time ago and tried to keep updating it as fast as possible as soon as new releases were out.
At the beginning I was thinking about maintaining 2 concurrent of LibreOffice at the same time: legacy and "normal" to reflect the upstream support. But this take too much time, I'll kill libreoffice-legacy in the next weeks.
The problem is that it is really time consuming, not that it is really complex, the LibreOffice upstream is really nice and really responsive, other maintainers from the BSD community, has also been really helpful.
Some time ago, I decided to create office@ to help maintaining every office related ports maintained on FreeBSD, it worked quite well, sunpoet@ taking good care for examples of the different hunspell/hyphen/mythes dictionnaries/thesaurus, pfg and maho taking care of Apache OpenOffice and all of us working on the third party libraries/fonts/etc needed by all those big office project.
But I'm still missing help on LibreOffice itself, I just committed 3.5.2 some days ago, and 3.5.3 is almost there.
We also still have known issues on 3.5.2:
- Doesn't build on recent -HEAD (problem with clang 3.1): all the fixes are in the upstream git, but need to be tracked and backported.
- Doesn't work propertly with base lpd.
- Doesn't build using the WITH_DEBUG option
- Doesn't build with gcc from ports (gcc from base is too old for libreoffice)
All the libreoffice work is done on redports svn
if you have an account and are willing to help tell me so that you can have access to the office svn on redports.
From git to fossil
I recently killed git.etoilebsd.net, while I still appreciate git, and will keep it for pkgng I was looking for a new solution to be able to share my other projects.
The main problem I have with hosting git, is that I need lot of third party tools, to have some kind of project management.
To display in a web browser my git projects, I was using cgit which does its job very well, and is simple to maintain: simple and clean configuration files, just a simple C cgi, all what I do like. But for those projects I was also needing 2 others things, a simple web page, if possible maintainable within the git repository itself which cgit can do and a ticket system (some users complained not being able to report bug/feature request).
I first tried to setup and install roundup, it is quite simple and does its job quite well, it can use sqlite, to avoid me running a useless database, it doesn't require too much dependencies so it was great but badly integrated with git (I don't want to spend time tunning too much the software I use)
I also had a look to all those forge available, like chiliproject or redmine, or the old but still good trac. While I did like trac, it requires too much dependencies for my small hostings needs. The two first are even worst in that area plus I find their url completely illogical to me.
The others available were using php or java and were most of them needing a mysql/postgresql database, I rejected them because I don't want any php or java software running on my small server, and I don't want any database constantly running on it either.
For a while now I am following the development of an alternative scm, named fossil, it is a small all-in-one project: scm, wiki, events, ticket contained in a single binary. It is really easy to use, requires nearly no administration, have all the modern features you can expect from a DVCS. And not that important for me but still good, it is BSD licensed.
To migrate from git to fossil it was really easy:
$ cd poudriere
$ git fast-export --all | fossil import --git poudriere.fossil
That is all, I know have a fully working poudriere.fossil.
To serve the fossil repositories on my server here is what I did:
Add an entry to /etc/services:
$ echo "fossil 8080/tcp" >> /etc/services
$ services_mkdb /etc/services
Add an entry to inetd:
$ echo fossil stream tcp nowait.1000 www /usr/local/bin/fossil /usr/local/bin/fossil http /data/fossil" >> /etc/inetd.conf
$ echo "inetd_enable=YES >> /etc/rc.conf
$ service inetd start
Add a simple virtual host to nginx:
server {
server_name fossil.etoilebsd.net;
listen 80;
listen 443 ssl;
location / {
access_log /var/log/nginx/fossil.access.log main;
proxy_pass http://127.0.0.1:8080/;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
That's all now, your fossil repositories are served properly, you can now access them from the fossil cli using both ssh or http (I only serve http for now in my case)
My fossil repositories are:
Home made pkgng repositories
By popular demand I have been requested a tutorial about how to maintain your own pkgng repositories.
Currently the best solution for that is to use poudriere (ports-mgmt/poudriere).
Let say you want to maintain 2 repositories: 8.2-RELEASE i386 and 9.0-RELEASE amd64.
For that you will need an amd64 (to support both amd64 and i386 box with 9.0 binary support and 8.2 binary support, a default 9.0-RELEASE amd64 should be enough :)
poudriere only depends on zfs and sh, so you won't need much, just a zfs pool available.
First: install poudriere:
$ make -C /usr/ports/ports-mgmt/poudriere install clean
To be able to build the repository the host would also need to have pkgng installed (no need to convert it to pkgng anyway.)
$ make -C /usr/ports/ports-mgmt/pkg install clean
Now configure your poudriere, defining some configuration to /usr/local/etc/poudriere.conf:
BASEFS=/poudriere
ZPOOL=myzpool
FTPHOST=ftp.freebsd.org
POUDRIERE_DATA=/poudriere_data
RESOLV_CONF=/etc/resolv.conf
DISTFILES_CACHE=/usr/ports/distfiles
This should be enough (see poudriere.conf.sample for more informations)
Create the default ports tree:
$ poudriere ports -c
Create the two jails (in fact it will be chroot :))
$ poudriere jails -c -j 82i386 -v 8.2-RELEASE -a i386
$ poudriere jails -c -j 90amd64 -v 9.0-RELEASE -a amd64
Make them pkgng aware
$ mkdir /usr/local/etc/poudriere.d
$ echo "WITH_PKGNG=yes" > /usr/local/etc/poudriere.d/82i386-make.conf
$ echo "WITH_PKGNG=yes" > /usr/local/etc/poudriere.d/90amd64-make.conf
Add the list of packages you want to build:
$ cat ~/mylist1
editors/vim
www/nginx
$ cat ~/mylist2
www/firefox
editors/libreoffice
If you want special options just add them to you different make.conf in poudriere.d
to share options between all the jails managed by poudriere, add them to /usr/local/etc/poudriere.d/make.conf
You can now create your packages:
$ poudriere bulk -f ~/mylist1 -j 82i386
$ poudriere bulk -f ~/mylist2 -j 90amd64
When finished you will get 2 pkgng repositories in /poudrieredata/packages/82i386-default and /poudrieredata/packages/90amd64-default
You can now provide them through your webserver.
On you client boxes just:
$ echo "packagesite: http://yoururl/82i386-default" >> /usr/local/etc/pkg.conf
or
$ echo "packagesite: http://yoururl/90amd64-default" >> /usr/local/etc/pkg.conf
If your client box already has packages from an old installation, first convert it to pkgng
$ fetch http://yoururl/90amd64-default/Latest/pkg.txz
$ tar xf ./pkg.txz -s ",/.*/,,g" "*/pkg-static"
$ ./pkg-static ./pkg.txz
$ pkg2ng
Now you can forget about pkg_install and pkg2ng
Just use pkgng (for example):
$ pkg update
$ pkg upgrade
$ pkg install firefox
To update your repository:
$ poudriere ports -u # this update your default ports tree
$ poudriere bulk -f ~/mylist1 -j 82i386 -k
$ poudriere bulk -f ~/mylist2 -j 90amd64 -k
bonus poudriere will rebuild only what has changed and what is impacted by this change.
Once it is done simply upgrade your client box:
$ pkg update
$ pkg upgrade
More informations on poudriere here
Full binary upgrade with pkgng 1.0-beta7
My laptop (a small eeepc 1000H) is running FreeBSD 8.2-RELEASE for a while now, I didn't upgraded it to 9 because it would have taken eons to rebuild all the packages I use on this laptop.
Of course this laptop has been converted to pkgng long time ago, and I'm happily using it in a full binary way: building packages and preparing pkgng repositories on a build box using poudriere (ports-mgmt/poudriere).
In the git version of pkgng (what would become soon 1.0-beta7) one of the new feature is the ability to reinstall the whole set of packages. This allow us to now perform a full binary upgrade of the system.
Here is how I performed an upgrade from 8.2-RELEASE to 9.0-RELEASE without building anything on that small laptop:
Create a 9.0-RELEASE repository
First you need to prepare a set of packages for 9.0-RELEASE on poudriere:
# create the new jail:
$ poudriere jail -c -j eeepc9 -a i386 -v 9.0-RELEASE
# copy the make.conf from the old to the new jail:
$ cp /usr/local/etc/poudriere.d/eeepc-make.conf /usr/local/etc/poudriere.d/eeepc9-make.conf
# build the set of packages:
$ poudriere bulk -f ~/bulkeeepc -j eeepc9 -k
Now that your repository of packages is ready just expose it in your http server and you are done with that part.
Upgrading the laptop
Update to the lastest 8.2-RELEASE
You need to upgrade your 8.2-RELEASE to the latest version available if not already done (it contains a fix for freebsd-update which is necessary to perform the upgrade to 9.0)
$ freebsd-update fetch
$ freebsd-update install
Upgrade to 9.0-RELEASE
You can now upgrade to 9.0:
$ freebsd-update -r 9.0-RELEASE upgrade
$ freebsd-update install
$ reboot
$ freebsd-update install
Once you are here your system now upgraded to 9.0-RELEASE but still have some old shared object files, it is the moment when you should perform the upgrade of the packages.
Edit your /usr/local/etc/pkg.conf file and adjust the url of the PACKAGESITE to the new eeepc9 repository
$ pkg update
$ pkg upgrade -fy
you can now remove the old shared object:
$ freebsd-update install
In case you would have forgotten to perform the package upgrade, pkg-static is there to save your life, you can still do it now:
$ pkg-static update
$ pkg-static upgrade -fy
Aujourd'hui j'ai un an
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 :)
Quand c'est beau faut le dire
Je voulais monter une jolie mailing liste pour quelques uns de mes projets dont poudriere. Alors je commence à faire le tour du marché pour me rendre compte que soit c'est indécent niveau nombre de dépendances, soit c'est complètement bloat : obligation de passer par les WebUIs, un SGBD etc.
Bref je veux juste une mailing liste quoi !!!
Mais dans ce monde qui ne jure de plus en plus que par les aberrations sous prétexte de modernité et par les solutions tordues parce que c'est "user friendly"... J'avais peur de ne pas trouver de solutions.
J'avais tort et il existe des solutions légères et réellement simples, par exemple :
Vous l'avez compris du coup je suis parti sur mlmmj :)
Alors voila comment mettre en place mlmmj simplement avec du postfix.
Pour commencer l'installation :
$ make -C /usr/ports/mail/mlmmj install clean
$ zfs create -o mountpoint=/data/mailing_lists zdata/mailing_lists
Ayant déjà un utilisateurs mail je vais le réutiliser :
$ chown -R mail:mail /data/mailing_lists
Création de la mailing liste poudriere en tant que user "mail":
$ mlmmj-make-ml.sh -s /data/mailing_lists -L poudriere
Quelques finitions :
$ echo "[POUDRIERE] " > /data/mailing_lists/poudriere/control/prefix
$ cat << EOF >> /data/mailing_lists/poudriere/control/customheaders
Reply-To: poudriere@etoilebsd.net
X-Mailinglist: poudriere
List-Help: <mailto:poudriere+help@etoilebsd.net>
List-Unsubscribe: <mailto:poudriere+unsubscribe@etoilebsd.net>
List-Subscribe: <mailto:poudriere+subscribe@etoilebsd.net>
List-Id: Discussions related to poudriere <poudriere.etoilebsd.org>
List-Post: <mailto:poudriere@etoilebsd.net>
EOF
Vérifier que la crontab de l'utilisateur mail contient bien les entrées pour la maintenance de la mailing liste :
$ crontab -u mail -l
0 */2 * * * "/usr/local/bin/mlmmj-maintd -F -L /data/mailing_lists/poudriere/"
La liste est maintenant prête il faut configurer postfix. Le but ici est de mapper tous les poudriere*@etoilebsd.net vers mlmmj.
Le plus simple pour ce mapping c'est de passer par des regexp. Dans main.cf:
virtual_alias_maps = regexp:/usr/local/postfix/virtual/user.regexp
transport_maps = regexp:/usr/local/etc/postfix/virtual/transport.regexp
Le fichier user.regexp contient la regexp suivante :
/^(poudriere)(\+.+)?@(etoilebsd\.net)$/ ${1}${2}@${3}
La doc officielle présente des exemples plus simple genre:
/^(poudriere.*)$/ ${1}
Mais attention une adresse poudriere@foo.bar matchera et foutera la grouille (oui je me suis fait avoir :)).
Le fichier transport.regexp :
/^poudriere(\+.+)?@(etoilebsd\.net)$/ mlmmj:poudriere
Maintenant tous les mails à destination de la mailing liste chercheront un transporteur nommé mlmmj, il faut donc le spécifier dans master.cf :
mlmmj unix - n n - - pipe
flags=DORhu user=mail argv=/usr/local/bin/mlmmj-recieve -F -L /data/mailing_lists/$nexthop/
A noter que l'entrée dans /etc/aliases préconisée par mlmmj est complètement inutile dans notre cas, car on ne tombera jamais dans ce cas.
Pour s'inscrire à la liste poudriere, il vous suffit d'envoyer un mail à : poudriere+subscribe@etoilebsd.net
mohawk is in da ports
Je vous avais déjà entretenu du petit mohawk. Ayant plein de projets en tête je ne m'en suis pas beaucoup occupé ces derniers temps.
Mais le sieur bsdsx ne l'entendait pas de cette oreille, il a continué à peaufiner le petit mohawk, corrigeant des bugs de ci, de là, ajoutant quelques petites fonctionnalités (support du x_forwarded_for par exemple) améliorant les logs, la conf, etc.
Bah tout ça, ça nous donne une jolie version 0.8.
Mais comme il est très sympa bsdsx, il nous fourni aussi une jolie documentation dans la langue de molière: documentation générale, documentation complete du fichier de configuration (c'est beau un fichier de conf au poils de yacc non?)
Du coup je ne pouvais pas rester dans mon coin, je l'ai ajouté dans les ports FreeBSD: www/mohawk
En attendant pkgng...
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 :)
Nano jails
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
No future ftw <3
Je voulais jouer un peu avec quelques convivialités bsdiennes commde kqueue(2) mais je n'avais pas trop d'idées sur quoi développer qui pourrait partir de ça. C'est là que le sieur bsdsx me parle de son envie de forker mini_httpd pour y apporter quelques améliorations. L'idée m'a paru géniale.
On a sorti nos vim, git, gcc et mohawk est né.
En effet même si nginx est juste génial il ne supporte pas les CGI nativement. De plus avoir un serveur http très très léger peut vraiment être intéressant pour les jails ou l'embarqué.
Voila donc le mini cahier de charges:
- Pas de thread ni de fork: tout en événementiel (bah oui je voulais jouer avec kqueue(2)).
- Un mapping d'url possible pour les CGI afin d'utiliser facilement de jolies url comme 'http://bla/truc/beau' au lieu de 'http://bla/truc?pas&beau'
- un fichier de conf convivial (comme ça on peut jouer avec lex/yacc)
- l'envoi de fichier via sendfile(2)
- un footprint ultra léger
- réutiliser au maximum ce que nous offre la libc et libutil (pidfile, properties, etc.)
- aucune dépendances qui ne soit pas dans base.
Même si ce n'est pas encore parfait ça marche et ça marche bien :). On n'atteint pas les performances ni la montée en charge d'un lighttpd ou d'un nginx, mais celles-ci restent correcte pour une empreinte mémoire vraiment réduite
le ps:
bapt 45335 0,0 0,0 8020 1556 ?? Is 14:20 0:00,00 ./mohawk -c mohawk2.conf
dans top:
45335 bapt 1 44 0 8020K 1556K kqread 0 0:00 0.00% mohawk
Le tout est donc très fortement lié au monde des BSDs et peut être même plus particulièrement FreeBSD (pas testé sur les autres :)).
Le code compile aussi bien avec gcc que clang, et est testé sur arm, ia64, amd64 et i386.
Pour une fois j'ai même pris du temps à faire de la doc vous trouverez donc un mohawk(8) complet
Tout ce passe ici
Bientôt un ports FreeBSD :)
Petite cerise sur le gâteau dans le source mohawk un petit htpasswd.sh (et la doc associée htpasswd(1)) qui est un implémentation de htpasswd en shell utilisant openssl et ed pour générer les fichiers d'authentification (avec le même niveau de fonctionnalité que celui d'apache même si dans notre cas seul crypt() est supporté)