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.

Il est là, il est chaud, et il contient deux articles de mon cru:

• 3NMP: NetBSD, Nginx, Naxsi, MySQL, PHP
• Nouvelles commandes et nouveaux démons dans NetBSD 6.0 Enjoy!

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.

While migrating the GCU-Squad! website to nginx, I wanted to keep the configuration as small as possible. In order to keep sites configuration files thin, I used this trick to automatically create log files using site’s FQDN:

But I quickly noticed that some unwanted FQDN’s where appearing on the log directory. In order to keep control on the created files, I figured out a simple way to ensure unwanted domains to be logged in the general access.log:

And voila, I knew this was going to happen, I finally switched to tmux. I will not explain here why this software is better than GNU screen, simply put, tmux is now part of the base system of nearly all BSD derivative operating systems (NetBSD among them), and it makes my life easier.

Instead, I’ll point out here all the resources that helped me switching rather quickly:

• Generic hands-on https://wiki.archlinux.org/index.php/Tmux
• Commented example http://www.doknowevil.net/2010/10/18/sorry-screen-tmux-is-better-but-here-are-some-screen-lik-hotkeys/
• Playing with the statusbar http://jasonwryan.com/blog/2011/06/10/setting-tmux-statusbar-if-in-x/, this author has other very good resources on the topic
• Fixing the 256colors mess (without using tmux -2) http://benjaminthomas.org/2012-03-28/256-colors-in-tmux.html
• Another well documented configuration file http://www.sheevaboite.fr/articles/show-me-your-tmux-conf
• Screen-to-tmux helper (in french, but easy to comprehend) http://wiki.soolbox.net/wiki/SysadminTips/tmux
• Very well written customization guide http://blog.hawkhost.com/2010/07/02/tmux-%E2%80%93-the-terminal-multiplexer-part-2/ (author has also written a comprehensive guide on how to basically use tmux)
• Enable mouse pane focus and resize http://tangledhelix.com/blog/2012/07/16/tmux-and-mouse-mode/

Here’s my ~/.tmux.conf, which is pretty much the standard screen-keys.conf available with the package, with only some small customizations like the status bar and some fixes:

Je le savais… je le savais que je devais pas mettre les doigts là dedans, et maintenant quoi ? je brûle des heures à électrifier des apprentis et couper en deux des monstres à l’aide de mon SABRE LASER ROUGE AHAHAHAH!! kSHHRTTRHHSHHFFFHrhRHHHH

Et sinon oui, ça tourne sous Wine, ça marche très bien. Trop bien même. Si vous aussi vous souhaitez cramer de précieuses heures: c’est par ici.

I’ve been searching for a Web-based SSH for quite a while, and I recently read about GateOne on the dedicated Wikipedia page. Not only GateOne does what I was searching for, but it also comes up with nice features like interpreting images on-the-fly.

The remote server on which I intended to run this software is, of course, a NetBSD 6.0 domU, and as I anticipated, some work was needed in order to make GateOne work on this platform.

So you want to use Naxsi but you’re too lazy to analyze your nginx’s error log in order to write your own whitelists, and you’re definitely not brave enough to run a learning mode for a week. Relax, they’ve got something for you too. Rendez-vous in the Downloads area of Naxsi’s website and retrieve latest naxsi-ui archive. Within that tarball, you will only need 2 python scripts, nx_intercept.py and nx_extract.py. The first one will read and record all Naxsi matches from the error log, while the second will generate the whitelist. In order to make those scripts work, you will need python-twisted, which is available for pretty much every decent UNIX-like I’m aware of. Default configuration file, naxsi-ui.conf, will do the job as it is. Here’s a tiny piece of script which reads all of your log files, pass them to the nx_* scripts and will display all the associated whitelist rules to stdout:

And voila! iMil.net has now migrated to a brand new (well, actually recycled) server, which is incidentally hosted by myself, in my company’s server room.

What are the news? on the architecture side, nothing revolutionary, my good old setup composed of a Debian (squeeze, yeah I don’t like to play) GNU/Linux dom0, which hosts various NetBSD 6.0/amd64 domUs (now SMP!).

Main news is the activation of naxsi, the Web Application Firewall on the nginx reverse proxy. I don’t like to waste IPv4 public addresses, so the websites I host are all served by an nginx reverse proxy that connects to domUs private IPs. Naxsi’s rules are detailed in this post. Apart from that, nginx configuration is rather classic, here’s a vhost example:

GNU/Linux Magazine France numéro 156 est sorti, vous y trouverez un article de mon cru sur l’histoire et l’utilisation de l’infrastructure rc.d. Bonne lecture !