Pkgsrc

Not so long ago, I wrote about using pkgsrc on Debian GNU/Linux, and assumed you’d start an installed service using rc.d. When I setup the new iMil.net server, I decided to give a try to kvm as it is easier to maintain, has good performances (sometimes better than Xen), nice administration tools, plus NetBSD now has a good VirtIO driver but no PVHVM support yet.

The first thing I do when setting up a Debian Jessie server is getting rid of systemd, whose philosophy and quality don’t match my personnal taste; but in that case, I wanted to use libvirtd so I could manage my virtual machines with virt-manager, and as a matter of fact, libvirtd has a hard dependency on systemd. There was no escape this time, I had to learn and use it.

While I tend to appreciate debian GNU/Linux, its tendency to be quite late on software versionning is sometimes annoying. Also, as a pkgsrc developer, I am used to have greater control over the packages I install, for example regarding the options I’d like to include.

For these reasons and a couple more, I sometimes choose to use pkgsrc along with apt to deal with particular packages. In this article, I’ll show how to achieve that task.

Snoopy is a pretty cool piece of software that can log every exec(3) call to syslog. When it comes to security, that feature can be really handy.

Yesterday (Dec. 5), I commited security/snoopy to pkgsrc. The package comes with GNU/Linux related scripts in order to modify /etc/ld.so.preload so libsnoopy is loaded before libc and achieve its role. NetBSD doesn’t have a ld.so.preload file, instead, we use a flexible /etc/ld.so.conf configuration file which has the following syntax:

I recently switched pkgin’s repository from SourceForge’s CVS to GitHub. Long story short, I heard here and there that SF was considering to drop CVS support and I found GitHub service to be more responsive and elegant. Also, I was looking for an excuse to learn git :)

Anyway, GitHub interface may be sexy, they used to have some kind of “upload” section which has been dropped. That may sound like a simple story, but the fact is when it comes to packaging a GitHub-hosted application, things are not that simple when the author has not explicitly tagged a specific release. Another use case, in which I actually am, is when you have an ongoing development, like pkgin in pkgsrc WIP and do not want to tag every test-release.

Damn I love pkgsrc. Let me tell you this story as an example…

A while ago, a couple of pkgin users told me it was a shame that /usr/pkg/etc/pkgin/repositories.conf was still pointing to a 5.0 URL when pkgin is freshly installed. Thing is, pkgin does support the $osrelease variable, but on NetBSD, the result of kern.osrelease can be 6.0_SOMETHING, which would lead to:

and this does dot exists on the repository.

Tout ça, c’est la faute à Guigui2. Et à Nils aussi.

Y’a quoi, 2/3 semaines, ces deux là me disent que ce serait tellement bieeeen si on avait conky dans pkgsrc et que patati le challeeenge et que patata tellement c’est beau tellement y’a des thèmes de ouf et j’en passe et des meilleures.

Et je regarde.

Et c’est l’engrenage.

Deux semaines plus tard donc, je viens d’importer sysutils/conky dans pkgsrc current avec le support des sensors usuels, CPU (SMP), load, mémoire, réseau, disque ainsi que batterie et température. Et ces deux derniers, c’étaient pas les plus simples.

Dans ma boîte, l’équipe sécurité a publié voila quelques mois de cela un module pour nginx: un firewall applicatif du nom de naxsi.

Ce module, sous licence GPLv2, je viens de le publier dans pkgsrc current sous la forme d’une option de www/nginx. Je me propose de vous montrer ici comment sécuriser simplement votre serveur web / proxy inverse nginx grâce à naxsi.

Premièrement, si comme moi (et comme il se doit) vous utilisez une branche stable de pkgsrc, mettez simplement à jour www/nginx comme ceci:

!@#!@# de bug.

Des mois que je cherchais au mauvais endroit, en effet, uniquement chez certains utilisateurs (évidemment), un pkgin up / fug proposait d’installer l’univers. Problème dans le moteur de dépendances me dis-je; que de temps perdu à décortiquer ce qui fonctionnait parfaitement, pour finalement tomber sur ceci:

Il ne faut PAaaaaaaas coder avec de l’alcool dans le sang, il ne faut pas, parce qu’après, on se retrouve avec des bouts de trucs ni faits ni à faire qui supposent que les membres d’une structure seront forcément alignés, et des effets de bords qui n’ont rien à voir.

Pour une partie de mon parc de machines, je fais mon propre bulk build. Ce dernier ne construit pas l’ensemble des packages, mais un petit subset (environ 600 packages) avec mes propres préférences. Parmi elles, il en est une qui fout un merdier sans nom dans le build, converters/libiconv. Comme je l’expliquais ici il y a quelques temps, j’ai besoin de construire converters/php-iconv avec la version pkgsrc de la libiconv. Cet impératif a un impact non négligeable dans la configuration de mon /etc/mk.conf, aussi je vous livre ce dernier, final et fonctionnel:

I’ve just commited 0.5.2.1. As the version shows, it is a bugfix release; is@ got a very nasty bug that took me a while to figure out. For 3 years, the only pkg_summary(5) format I’ve seen was:

or, in case of conflicting packages:

Well it turns out that we can also find: