This is me, Wu!
July 2015
Sun Mon Tue Wed Thu Fri Sat
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
This site is an effort to share some of the base knowledge I have gathered through all this years working with Linux, FreeBSD, OpenBSD, Python or Zope, among others. So, take a look around and I hope you will find the contents useful.
Recent Entries
Recent Comments
Recent Trackbacks
OpenBSD (8 items)
BSD (0 items)
FreeBSD (19 items)
Linux (3 items)
Security (3 items)
Python (18 items)
Zope (13 items)
Daily (139 items)
e-shell (9 items)
Hacks (14 items)
PostgreSQL (3 items)
OSX (7 items)
Nintendo DS (0 items)
enlightenment (0 items)
Apache (3 items)
Nintendo Wii (1 items)
Django (23 items)
Music (12 items)
Plone (7 items)
Varnish (0 items)
Lugo (2 items)
Sendmail (0 items)
europython (7 items)
Cherokee (1 items)
self (1 items)
Nature (1 items)
Hiking (0 items)
uwsgi (0 items)
nginx (0 items)
bikes (0 items)
Networking (1 items)
DNS (0 items)

Syndicate this site (XML)

RSS/RDF 0.91

14 julio

Juniper NetworkConnect for OSx

nice to know if you need to quickly connect to a Juniper VPN

Some days ago I got this support request from a customer, asking me if I could take a look at some servers in trouble (someone got in and they wanted to see if any backdoor was left behind, even if they already cleaned the server).

"Sure" - I replied - "just gimme access over SSH and I'll take a look"

All I got instead was an email with an https address, user, password and the words it is a Juniper VPN.

"Ok" - I thought - "let's get a client to connect to that vpn"

It wasn't that easy though. I went to Juniper's downloads website, but in order to download anything, it seemed that first I should know which kind of Juniper product they had installed there.

Reading a bit more, it seems those VPNs over https work directly from the browser. You only had to open that url and identify yourself, and a plugin should run some kind of Java application and open the connection to the VPN.

Well, that did not work for me. For some reason it kept telling me I had a missing plugin and when trying to find out which plugin that was, it was sending me to the Java download page (even if I've Java installed already).

This being a momentary access to a server I won't be accesing anymore, the least thing I wanted was to start installing stuff on my laptop "a lo loco". So I was in kind of a dead end, and I could not connect to the server.

Searching a bit further down Internet Lane, I found this post here: Manually download the Juniper VPN client for mac, which probed to be quite useful.

It seems you can get the proper version of NetworkConnect for OSx directly from the VPN service itself. All you have to do is open the VPN url in your browser, log in, and then access this url:


For example, if the address of the VPN is https://my-juniper-vpn, it should be something like:


Download that and proceed with the install. After opening it for the first time, you will have to provide the https url for the vpn, then the login credentials. Done.

Finally I had access to the server and I was able to confirm there were some backdoors in there, time for some clean up!

Also, a ver interesting link for the time you are done with the Juniper VPN, if you don't need it anymore, how to uninstall/remove it completely:

Posted by wu at 06:26 | Comments (1) | Trackbacks (0)
30 junio

Bogons in your DNS setup

Nothing is forever, you know

This morning, on IRC, my friend betabug reported that he had some problems while trying to resolve a domain name which DNS servers are under my control.

Each time he queried any of those servers, he got a timeout.

We went through a debugging process, but we weren't lucky. We found nothing that could have been causing such a behaviour.

Until I asked the magic question, which opened the door to where the problem was laying:

10:00 < Wu> betabug: which is your ip address there?
10:01 < betabug> Wu:
10:02 < Wu> public ip address ;D
10:02 < betabug> hahahaha
10:02 < betabug> 2.84.XX.XXX
10:02 < betabug> nice ip

Somehow that ip address in the block looked a bit suspicious. I checked the named.conf file in one of the DNS servers and...

acl "bogon" {;;;;;;;

And a bit further down the config file:

blackhole { bogon; };

This means that any ip address in those ranges will be kind of blacklisted for the DNS server.

And now, probably, you are asking yourself why this guy blocks those ranges?. Well, to understand why, first you have to know what a bogon is. One good explanation can be found here:

A bogon route is a type of route which shouldn't exist on the
global Internet. More specifically, "bogon" (derived from the
word "bogus") refers to an advertisement for a prefix within a
reserved or otherwise unallocated IP network.

Team Cymru has also a couple of interesting pages about bogons:

So, it seems that in the last days of the ipv4 era, registrars are opening/releasing blocks that have been reserved since the beginning. This means that my DNS servers have been blocking queries from licit ip addresses on those ranges for some time.

Removing them was easy, problem solved.

Reminder: Even as this all will change when the last of the ipv4 block is sold out, take care, as stated in The bogon reference that:

It is important to realize that the bogon and fullbogon lists are NOT static lists.

Posted by wu at 10:20 | Comments (0) | Trackbacks (0)
19 febrero

Setup chroot for bind 9 in FreeBSD 10

simple instructions if you are upgrading from freebsd 8.x or 9.x

FreeBSD 10 has been released some days ago and this new version comes with lots of new stuff (just take a look at the release notes to learn more about it).

One of those changes is the removal of BIND from the base system, being it replaced by Unbound. More information about this move from the FreeBSD project can be found here:

Maybe you would find interesting this thread from the freebsd-stable mailing list too:

(also available here:

There some people complain about the differences between the scripts and setup we had in the base system vs what is available in the bind9 port. Setting up a chrooted dns server was quite easy when BIND was in the base system, as the configuration files and rc.d scripts were already prepared for such a setup, but it seems that what is installed by the port does not handle that so well.

Or so it seems...

These are the steps I followed to keep my BIND servers chrooted after upgrading to FreeBSD 10:

Warning: The following assumes you have a default BIND setup, chrooted under /var/named and with all the config files in /etc/namedb, which should be a symbolic link to /var/named/etc/namedb.

  1. Install BIND 9.x from ports:

    cd /usr/ports/dns/bind99 && sudo make install clean

    or, if you prefer to use pre-built packages:

    sudo pkg install bind99
  2. The port/package will install the configuration files under /usr/local/etc/namedb, move them aside:

    sudo mv /usr/local/etc/namedb /usr/local/etc/namedb.default
  3. Link the existing configuration from our previously chrooted setup to the place where the port will look for them:

    sudo ln -s /var/named/etc/namedb /usr/local/etc/namedb
  4. Now, as the configuration files have been moved from /etc/namedb to /usr/local/etc/namedb, we have to recreate such a route inside the chroot environment, ensuring the management scripts will find the configuration files:

    sudo mkdir -p /var/named/usr/local
    cd /var/named/usr/local && sudo ln -s ../../etc .
  5. Remove the old link under /etc:

    sudo rm /etc/namedb
  6. Create a custom devfs ruleset to be used with our chroot environment, adding the following to /etc/devfs.rules:

    # Custom rules for the named chroot dev
    add hide
    add path run unhide
    add path random unhide
  7. Mount the devfs filesystem from the chroot environment. First add the following to /etc/fstab:

    devfs             /var/named/dev  devfs   rw,ruleset=4      0     0

    Then mount it:

    sudo mount /var/named/dev
  8. Enable chroot when starting BIND, adding the following line to /etc/rc.conf:

    named_flags="-t /var/named"

    You don't have to set the -u flag, because it is already passed by the rc.d script (user bind).

  9. Fix the /usr/local/etc/rc.d/named script, so it will be able to find the proper pidfile when stopping the daemon. Add the following line inside the named_stop() function, just below find_pidfile:

    test "${named_flags#*-t}" != "$named_flags" && pidfile="/var/named${pidfile}"

    This will check for the presence of the -t flag in the provided flags and, if exists, will add the path of our chroot directory to the already existing pid file path.

  10. Start BIND:

    sudo /usr/local/etc/rc.d/named start

et voilà, BIND should be running now, chrooted under /var/named as user bind, just like in your previous setup.

UPDATE 2014-02-25: Added the mount of the devfs filesystem as mentioned by APz in the comments.

Posted by wu at 12:08 | Comments (11) | Trackbacks (0)
09 agosto

Got a new bike

and it took damned too long to get it!

Me and the new bike

I already wrote some stuff about my habit of moving around town by bycicle (here and here too for example) so this won't be a surprise.

For the last few years I've been riding an old mountain bike that wasn't even mine to begin with (dolo's brother wasn't using it at all, so I just borrowed it) and lately I've been riding my father's old trekking bike, which was nicer than the mountain bike, but not my bike:

This is the old MTB I've been ride for some time This is my father's old trekking bike

Also, after getting the bike trailer for lara, we have been doing rides^excursions more often now (dolo, lara and me) and we didn't have a bike that was really comfortable for dolo, so we started to think about getting a new bike for both of us (a proper one for her, and one for me so we could return those bikes to their real owners).

So, for now we have bought a Giant Argento rs4 GTS (from a local dealer, mtcbicis). The plan is that I will use this one when going for lone rides, and dolo will use it during family rides. This will get me back to the old mountain bike, but I don't think it will take too much time for dolo to decide herself about which new bike we should get for her.

The argento, tron-style The same pic as before, but without using the flash to take it Another shot of the new bike, different perspective.

UPDATE: This evening I did a test ride (around 7.5 kms) and the bike is really really good. Fast, comfortable... Really worth the money we've put in it.

Posted by wu at 09:41 | Comments (1) | Trackbacks (0)
07 mayo

Hey there!

Yes, I'm still alive.

Hey there!

Wow, look at the date of my last post... 06/11/2011, that was like 548 days ago!

Well, I'm still alive, as you can see, but I've been way too busy to write stuff publicly here in the blog (I've been writing some tweets from time to time here though).

Too many things happened during the past few months to be able to write about them all here. One of the main reasons I did stop writing stuff here is that my workload increased a lot, and the other one is that I've a daughter now. Probably you can imagine how much life has changed for me.

I can't tell you how many times I've thought "wow, I should write something in my blog about this" during those 548 days. Really, that happened a lot.

So, here I am, taking 5 minutes to say hello. Let's hope I can be back to this healthy habit of writing about what happens to me everyday.

Hi! I'm glad to be back!

Posted by wu at 14:23 | Comments (4) | Trackbacks (0)
06 noviembre

Arduino Barcamp 2011, Ordes

Talking, learning and doing things with arduino for a whole day

Yesterday was indeed a good day, and a long day too. I woke up at 08:00 (being my soul completely exhausted, as I got to bed around 3:00 the night before) and I met @r0sk, @MarcosBL, @mameyugo and @apvila30 at 08:45 to get on the road again on our way from Lugo to Ordes, where an Arduino Barcamp was being prepared by our friends of the Inestable Linux User Group.

The Barcamp started at 10:00, and we arrived a little bit later (around 10:20 or so), because we had some trouble finding the place.

The first thing that did struck me was the ammount of people attending the Barcamp, a lot more than expected. The guys from the Inestable lug said we were about 70 people in there, amazing (even more because they were expecting around 15 people or so).

You can get an idea on how much people we were just taking a look at these pictures:

Everybody was listening carefully to the first talk of the day. It was crowded during @TCRobotics's talk about Orugas, his personal project using arduino and some robotics knowledge

After meeting some of the Inestable guys (like @nikageek) we attended the first two talks of the day. First one covering basic knowledge about electronics and the second one showing some aspects of the programming language you can use to communicate/interact with your Arduino board. Both talks were performed by Jose [1] from the Inestable lug.

Then we had a coffee break (about 45 minutes or so). Perfect time to met some old friends like @toniousli or @javier_fazouro and talk about different ideas and projects using arduino boards.

The barcamp was talking place in "A casa da cultura", property of the Ordes city council, a nice place with plenty of room and some really nice paints outside:

This was painted on a wall opposite the place where the barcamp was taking place. I found it amazing Another paint, this one was near what seemed to be a kindergarten or something like that.

Back inside the talks room, @TCRobotics led a workshop about setting up the development environment you need to play with arduino, that is, downloading and installing the software from and teaching us how to use the environment, where are the docs, etc.

r0sk had his own arduino board with him, so we were able to have some fun Lot of people attending @TCRobotics' workshop

In the picture on the left you can see @r0sk playing with his arduino board. It seems he was having some fun ;P

After a break for lunch two groups of people were formed. One of the groups was attending @TCRobotics' talk about Orugas, his personal project that consist on a rover-like robot that can be controlled using a Wii nunchuk (in a previous version) or a PlayStation2 (in its latest version). He also showed us a video of one of the first versions of the project, where the robot was able to move by itself, recognizing objects and obstacles.

It was really interesting to hear how this kind of projects are done, understanding the whole process, the problems you can find and how you can solve them with a bit of imagination and thinking.

I got a seat quite close to @TCrobotics while he was talking about Orugas Orugas v2.5, we were able to take a look at it quite closely

The Orugas project involves much more stuff, like lasers, proximity sensors, etc. If you want to learn more, just visit Alex blog:

Orugas v2.5, that's what you can do with an arduino board and some time, imagination and patience Another shot of the version 2.5 of the Orugas robot

The other group was attending a talk about arduino's XBee shield, a small board that adds wireless communication support to your arduino board. Oscar (one of the guys behind Bricogeek) gave this talk (sorry, I've no pictures of this talk). Another good talk.

The Barcamp finished near 21:00, or at least we left it at that time (I'm quite sure some people keep talking and sharing experiences and thoughts for some more time).

It was really a good experience. The only thing I'd missed was a real workshop, like the one I attended some months ago in Santiago, where there was a table, some arduino boards and material and both people willing to learn and people willing to teach, something more like a jam session. That would be really amazing, but I understand that being 70 people that would be almost imposible.

Don't misunderstand me, it was great and I enjoyed every single talk during the barcamp, I'm just giving an idea for the next-to-be arduino barcamp (as I'm quite sure there is going to be a next one soon).

We got back in the car and drove our way back to Lugo, arriving at 23:00 or so. We had dinner in one of the usual places (dotmas) and then I came back home BUT @r0sk, @MarcosBL and @mameyugo had other plans... They went to @MarcosBL's place and they kept themselves busy during the night, until they published this video in youtube:

[ no-comments ]

Oh!, I almost forgot, you can take a look at the pictures I took visiting this album.

[1]anyone has Jose´s blog/twitter/whatever urls?

Posted by wu at 22:48 | Comments (0) | Trackbacks (0)
18 agosto

How to install a patched uwsgi package in FreeBSD

and how to do it cleanly, so you can keep track of later updates

What I'm going to explain in this post is not uwsgi-specific, you can follow this intructions to install patched versions of any package available in the FreeBSD ports collection.

In my case, I needed a patched version of the uwsgi package because I found a bug on my current version (0.9.8) that was already fixed in the -current/trunk version of uwsgi, but it hasn't been backported to any stable release yet (hopefully it will be in

So, to fix the bug I needed the latest -current/trunk code or the latest stable release ( + the needed patch.

Installing -current/trunk means compiling the sources and installing the binaries by myself, which will lead to some problems next time I had to upgrade the packages and ports in that server, so it seemed like a much better option to install the latest stable version using the ports tree. Anyway, I still would need to apply the patch to the sources before installing... this is what I've done to add the patch cleanly.

I ran all the commands as root, if needed use sudo or some other tool to gain root privileges in order to use the ports tree.

First I got the sources of uwsgi using the ports tree:

# cd /usr/ports/www/uwsgi
# make fetch

That saved the source tarball into /usr/ports/distfiles:

-rw-r--r--  1 root  wheel  351168 Jul 23 06:28 /usr/ports/distfiles/uwsgi-

Then I extracted the sources:

# make extract

That extracted the sources into /usr/ports/www/uwsgi/work/:

drwxr-xr-x  18 root  wheel  3072 Aug 18 15:47 work/uwsgi-

At this point we have two options, we could download an already existing patch or we can generate the patch ourselves. In my case, I generated the patch manually because the already existing patch didn't work.

To generate the patch I renamed the file that was going to be patched:

# cd work/uwsgi-
# mv plugins/python/wsgi_headers.c plugins/python/wsgi_headers.c.orig

Then I downloaded a copy of the patched version of the file:

# fetch -o plugins/python/wsgi_headers.c ""

And finally I generated the patch:

# diff -ruN plugins/python/wsgi_headers.c.orig plugins/python/wsgi_headers.c > ../../files/patch-wsgi_headers.c

As explained in the patching section of the FreeBSD porters handbook:

"Each patch you wish to apply should be saved into a file named patch-* where * indicates the pathname of the file that is patched, such as patch-Imakefile or patch-src-config.h. These files should be stored in PATCHDIR (usually files/, from where they will be automatically applied. All patches must be relative to WRKSRC (generally the directory your port's tarball unpacks itself into, that being where the build is done)."

Once the patch was created, I cleaned up the work directory:

# make clean

And finally I install the new uwsgi package:

# make install clean

The bug was fixed and everything is running smoothly now.

Just some final considerations:

  • If you would like to know if your patch was applied properly, check the output of make install, you should see something like:

    ===>  Patching for uwsgi-
    ===>  Applying FreeBSD patches for uwsgi-

    Any errors that could have happened while applying the patch would be logged there.

    You can build the package before installing it too:

    # make

    and then you can check the file that should be patched (in this example it was /usr/ports/www/uwsgi/work/uwsgi- to see if it has been patched properly before proceeding with make install.

  • Remember that before installing the new package, you will have to delete the old one, use pkg_delete or make deinstall to do it.

  • In this case, the patch will be imported into the next uwsgi release ( and so it will be available by default in the next upgrade of the uwsgi port, but, if you think that the patch will not be available directly from the official sources of the project, you should contact the author of the FreeBSD port and tell him/her about the patch and how you could help importing it into the ports tree. You can read more about this in the FreeBSD porters handbook.

Posted by wu at 16:31 | Comments (0) | Trackbacks (0)