Entries : Category [ OpenBSD ]
[OpenBSD]  [BSD]  [FreeBSD]  [Linux]  [Security]  [Python]  [Zope]  [Daily]  [e-shell]  [Hacks]  [PostgreSQL]  [OSX]  [Nintendo DS]  [enlightenment]  [Apache]  [Nintendo Wii]  [Django]  [Music]  [Plone]  [Varnish]  [Lugo]  [Sendmail]  [europython]  [Cherokee]  [self]  [Nature]  [Hiking]  [uwsgi]  [nginx]  [cycling]  [Networking]  [DNS] 

16 octubre

Soekris order (just ordered!)

or how to help some project buying its stuff

This morning I ordered some stuff from Wim again, just some minutes after placed the order, the confirmation email arrived:

[ ... ]

Subject: Order confirmation Soekris
Date: Tue, 16 Oct 2007 13:47:41 +0200

[ ... ]

Dear Francisco,

Thank you for your Soekris Order!

Have a look at the order below, is that what you had in mind?

                                      Units ordered:
2+   with discount
soekris_10550160 (net5501-60 Board and 1 slot case   EUR 237.00): 01
soekris_10550170 (net5501-70 Board and 1 slot case   EUR 279.00): 01
soekris_14550110 (2.5 Parallel ATA hard drive kit    EUR  11.00): 01
soekris_31201225 (Power Supply, 12V, 2.5A, .eu cable EUR  20.00): 02
kit_rala_9       (802.11Abg miniPCI RAL, 1 Pigt9dBi  EUR  75.00): 02
hole_rptnc       (3 drilled holes for RP-TNC connect EUR   6.00): 02
belkin_nullmodem (1.8m null modem cable FDB9 to FDB9BEUR   4.00): 01
usb_serial       (USB-Serial adapter                 EUR  10.00): 01
tshirt_openbsd   (Puffy the Kid Shirt size M         EUR  20.00): 01
tshirt_openbsd   (The Because Security Matters Back LEUR  20.00): 01
tshirt_openbsd   (Hackers of the Lost Raid Shirt L   EUR  20.00): 01

[ ... ]

Yes, two net5501 with some extra stuff (cables, adapters, etc) and some nice OpenBSD t-shirts.

This is not my first OpenBSD order, but the first time I order soekris hardware, and I can't wait to have them here and begin to use and test them.

Posted by wu at 14:16 | Comments (0) | Trackbacks (0)
24 octubre

Soekris arrived!

or how wim do his job once again...

Yes, YES, YEEESSSSS! My latest order from OpenBSD is here! As I wrote here, last week I ordered some Soekris hardware from Wim, as well as some nice OpenBSD t-shirts.

Well, just a week later I got the package:


Excited, I just took a picture of it and I proceeded opening it.

Just to find inside everything from my order. The soekris stuff, the rubber duck antennas, the usb-to-serial adapter, the null-modem cable and the t-shirts. Everything OK.

Now I only have to find some time to install OpenBSD in one of the net5501-70 to use it as my primary AP/Firewall/whatever device here, and then I'll install OpenBSD, FreeBSD and Linux in the net5501-60, just for testing purposes of the three operating systems.

So, more to come about this soekris topic, meanwhile relax with some pics of them:

http://www.e-shell.org/img/samples/obsd_soekris/soekris_front_far_thumb.png http://www.e-shell.org/img/samples/obsd_soekris/soekris_front_thumb.png http://www.e-shell.org/img/samples/obsd_soekris/soekris_back_far_thumb.png http://www.e-shell.org/img/samples/obsd_soekris/soekris_back_thumb.png http://www.e-shell.org/img/samples/obsd_soekris/soekris_open_far_thumb.png http://www.e-shell.org/img/samples/obsd_soekris/soekris_open_thumb.jpg http://www.e-shell.org/img/samples/obsd_soekris/obsd_sticker_thumb.png

Posted by wu at 18:05 | Comments (0) | Trackbacks (0)
01 noviembre

OpenBSD 4.2 released

and some other news about the project


The OpenBSD project just announced some hours ago the release of the latest version of the OpenBSD operating system. The 4.2 release is dedicated to one of the well known developers from the team, Jun-ichiro "itojun" Itoh Hagino, who passed away recently.

From here, I would like to thank Itojun for all his work in the project, as well as all the help he gave those years to everybody that asked him about both IPV6 and embedded systems support in OpenBSD. We will miss him for sure.

Some of the highlights from this new release are:

Those are only some of the new features and improvements I would like to highlight, you can see all the stuff here:


I would like to highlight that this is the first version of OpenBSD that ships with Xenocara, an effort to get a clean way to build and install X.org 7.2 with some external addons in OpenBSD.

Posted by wu at 11:07 | Comments (0) | Trackbacks (0)
31 marzo

OpenBSD to the rescue

or how to set up a quick firewall + ap solution...

This weekend I've been at my girlfriend parent's. The father of one of our close friends died last week, so we went there to be with her.

Anyway, we (specially my girlfriend) had a lot of work to be finished before monday, so we carried on our laptops. At home they had a cable modem and a computer connected to it. We needed Internet access, but that computer couldn't be disconnected from the Internet.

Luckily, I had there a soekris box with me, with OpenBSD 4.2 installed on it. On less than 15 minutes, I had a functional firewall, gateway and Wireless Access Point up and running, and sharing the Internet connection between two laptops and a desktop computer.

First, I got access to the soekris box from my MacBook using an usb-to-serial adapter and a null-modem cable.

OpenBSD/i386 (Arvak.e-shell.org) (tty00)


Then I logged into the OpenBSD 4.2 system.

# uname -ap
OpenBSD Arvak.e-shell.org 4.2 GENERIC#375 i386 Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class)

Once there, I set up the configuration files for the network interfaces:

# cat /etc/hostname.vr1
# cat /etc/hostname.vr2
inet NONE
# cat /etc/hostname.ral0
inet NONE mediaopt hostap mode 11g nwid OpenBSD_AP chan 11 -nwkey

being vr1 the interface connected to the cable modem (will get all the settings from a dhcp server), vr2 the interface connected to the windows computer and ral0 the interface that will act as the wireless access point link.

Next, I needed to set up a dhcp server for vr2, so the windows computer still get's the network settings from dhcp (as if it was still connected to the cable-modem). Easy, just opened /etc/dhcpd.conf and change the default settings a little bit:

shared-network LOCAL-NET {
        option  domain-name "codigo23.net";
        option  domain-name-servers,,;

        subnet netmask {
                option routers;


I only added the domain name, and three nameserver ip addresses from the ISP.

After edited the dhcpd configuration I edited /etc/rc.conf to change that line:

dhcpd_flags=NO          # for normal use: ""


dhcpd_flags=""          # for normal use: ""

(so dhcpd will be started at boot time)

Now I was editing rc.conf, I decided to change one more line:

pf=NO                  # Packet filter / NAT


pf=YES                  # Packet filter / NAT

(to enable the OpenBSD packet filter)

Ok, next step was to activate ipv4 packet forwarding, changing one line in /etc/sysctl.conf:

#net.inet.ip.forwarding=1        # 1=Permit forwarding (routing) of IPv4 packets


net.inet.ip.forwarding=1        # 1=Permit forwarding (routing) of IPv4 packets

Fine, only one more step to go, I needed to set up PF, so I opened /etc/pf.conf and wrote some lines in it:


set optimization normal
set block-policy return

scrub in on $ext_if all

nat on $ext_if from $int_if:network to any -> ($ext_if)
nat on $ext_if from $wi_if:network to any -> ($ext_if)

block in all

pass in quick on $int_if from $int_if:network to any keep state
pass out quick on $int_if from any to $int_if:network

pass in quick on $wi_if from $wi_if:network to any
pass out quick on $int_if from any to $wi_if:network

pass out quick on $ext_if from ($ext_if) to any keep state

Which basically means map all packets coming from the wireless link and from the internal network to the Internet as if they were from the firewall itself. Block all packets coming from the Internet that weren't a reply to the outgoing packets.

After a reboot, everything was running smoothly, the windows computer didn't notice the change and both laptops had Internet access.

Well, I only had one problem, it seems like the house walls were made of some material that block the Wireless radio signal, so we found some problems to connect to the wireless access point on some points of the house.

As wiwi would tell, it's OpenBSD, it's easy!

Posted by wu at 00:16 | Comments (0) | Trackbacks (0)
04 abril

OpenBSD to the rescue (II)

or how to help a friend using OpenBSD...

Some days ago, I wrote about how I used OpenBSD to quickly set up a firewall to share an internet connection between a computer and some laptops and back then, I didn't think about what would happend later on this week.

Today, I visited an old friend of mine. After some talk, I noticed that he still has a little embedded computer which size is similar to one of my soekris.

Some months ago we talked about installing something there that could be configured as a firewall and router. The problem we found at that time was that the device only has a limited storage capability (128Mb) in a Industrial Grade flash card.

The 128Mb flash card

I recommended him to use OpenBSD for that, but we found out that the base system didn't fit in only 128Mb, we would have to create our own install sets.

But today I had another idea, we could use flashdist to directly put a running image of an OpenBSD system into the 128Mb flash card. With that, we will get a complete OpenBSD system (without some binaries anyway).

But we had a problem to do that, that kind of flash card couldn't be accessed using a USB card reader, and we needed direct access to it in order to use dd and put the image into the flash card.

The only way we could access the flash card directly was booting some operating system directly on the embedded device, an unix-like system that could mount an USB storage device (where the flashdist image was) and a system with the dd tool (to dump that image into the card.

So, we thought about netboot the OpenBSD installer...

Luckily, pAvl0 already has both dhcpd and tftp servers running on a Ubuntu box, so it was a matter of getting the installation files for OpenBSD, put them in the main directory of the tftp server and activate netboot on the embedded device.

Once the installer booted, we selected the (S)hell option and we used that shell within the installer to mount the USB storage device:

An usb disk attached to the embedded device
# mount -t msdos /dev/sd0i /mnt

(to know the correct partition to mount, we used disklabel to know the partitions avaliable)

and to dump the flashdist image:

# dd if=flashimg-20080308.GENERIC.console of=/dev/wd0c bs=64k
dd dumping the image into the device

After dumped the image, we restarted the device and... it worked!. We got the usual OpenBSD boot prompt, and the system booted smoothly. It was even OpenBSD 4.3!! (-beta of course).

it was openbsd 4.3!

Only after the system was booted, we noticed that the whole system was read-only (loaded into RAM), so we couldn't modify nor the network configuration files neither the PF files.

One more thing to do, tweak our image file before dumping it into the flash card. That's pretty easy, although we didn't have more time to keep playing with that.

Tomorrow I'll try to mount the flashdist image as a normal disk, touch the needed configuration files and then dump again the image into the flash card.

Posted by wu at 00:55 | Comments (0) | Trackbacks (0)
07 abril

Mounting SMB/CIFS shares in OpenBSD

yes!, it works!

Found how just some minutes ago. I was preparing a backup solution for a windows-based network using OpenBSD and rdiff-backup. The idea is very simple:

doing incremental backups from a windows server into an openbsd box

Some windows workstations store some data into a windows (or unix+samba) file server. The data needs to be backed up, just in case. All the information we will backup regularly are the user profiles and a backup directory shared through the whole network (so everyone could put in there everything they need to backup).

As those shares/folders/directories are exported using the SMB/CIFS protocol, I can mount them in the OpenBSD host using sharity-light, an userland implementation of smbfs (which operates in kernel space).

To mount a windows share using sharity-light, you only need an empty directory on your filesystem and do something like:

# shlight //windowsserver/backup /mnt/backup -U windows_user -P someuglypassword

NOTE: here windowsserver is a name pointing to the ip address of the windows server, while windows_user and someuglypassword are the user credentials needed to access (in this case) the backup share.

NOTE2: sharity does not allow ip addresses as the server name, and it will fail if you try to use the server.domain.ext naming convention, so you will probably need to add something like that to your /etc/hosts file: windowsserver.mydomain.net windowsserver

After using calling the shlight script, you will be able to access the windows share just as any other mounted file system in OpenBSD:

# df -h
Filesystem       Size    Used   Avail Capacity  Mounted on

[ ... ]

shlight-31463    298G   93.8G    204G    31%    /mnt/backup

In my case, now I can safety run rdiff-backup to create an easy-to-recover full backup (with incrementals) on my local filesystem.

Posted by wu at 19:03 | Comments (0) | Trackbacks (0)
01 mayo

OpenBSD 4.3 released

once again, puffy is back!


Yes, the new release of OpenBSD have seen the light some hours ago. OpenBSD 4.3 have a lot of new things/features/upgrades and you can read about both in undeadly and in ONLamp (another nice interview with openbsd developers from Federico Biancuzzi). Of course, you could read the release announcement too.

This release theme is inspired by the Odyssey from Homer and, of course, there is a song (as with every release since 3.0). You can read the lyrics and see the usual comic here.

Posted by wu at 20:16 | Comments (0) | Trackbacks (0)
23 enero

OpenBSD, PyCha and the Memory Error.

you are missing the fonts!, tha's the key!

From the PyCha website:

Pycha is a very simple Python package for drawing charts using the great Cairo library.

And it is the perfect replacement for pychart, an old library to render charts that I've been using in my projects since near 2003.

Of course pychart is still a fine option to create charts from your python scripts, but the result is quite better with PyCha (you only have to take a look over the examples on both projects' websites to know what I mean).

PyCha depends on pycairo which depends on cairo, while pychart depends on ghostscript, and you can run both of them mostly without a problem in any unix-like operating system, like OpenBSD.

Well, that's True partially. Some weeks ago I've found an interesting problem with PyCha running on an OpenBSD server. I installed both pycairo and cairo from packages and PyCha from sources (as there was no package for my openbsd version, OpenBSD 4.4 already has a package).

I set up my python project (a django app in this case that asks users for some data and then creates some nice-looking charts from it) and I do some tests on it, just to check everything is running fine.

As soon as my app tried to generate a chart, I got an ugly Memory Error message:

Memory Error Pycha OpenBSD

At first I thought about some python memory limitation (as you can set some settings on compilation time), but it sounded somehow strange. I've been using python in OpenBSD machines for a long time now, and I've never found such problem.

A little more digging over the internet and I found a ticket in the project trac site, related to a MemoryError in FreeBSD, which pointed directly to cairo:

I installed cairo without x11, so I had no fonts installed. Installed freefont-ttf and now it works. I think cairo has no detection, if a font is missing, so it just crashes.

Nice error checking guys! There is no font, why we should show a "there is no fonts available", it is by far much better to crash the thing!.

As I've said, this is a server, so I've no X* install sets in it (more information about install sets here). That means no X11 fonts. Problem found!.

The solution:

I follow the instructions from the OpenBSD FAQ on adding a file set after install, I just grabbed the xfont42.tgz from ftp.openbsd.org and unpacked it on the root of the server:

# cd /
# tar xzvphf xfont42.tgz

A restart on the app server and it worked fine since then.

Posted by wu at 14:50 | Comments (0) | Trackbacks (0)
07 diciembre

OpenSSH based VPNs

The poor man VPN setup

VPN (Virtual Private Network) is probably something most of you already know about. I guess most of you are familiar with terms like ipsec, pptp or OpenVPN and probably some of you know how setting up any of those feels like... yeah, a PITA.

So, this is a post for those who would like to be able to set up a VPN quickly, without having to install additional dependencies or having to mess up with complicated certificates/CAs or configuration files.

What if you could set up a fully functional VPN using just OpenSSH?

The blues fishes, from the OpenBSD project for the release of OpenBSD 5.7

I'm assuming you have a recent version of OpenSSH installed in the systems that will be part of the VPN (most systems have it nowadays) and that you have some knowledge about Unix-like systems and Shell Scripting.

For more details, you can check the manual page of ssh(8) from the OpenBSD project. Look for the section SSH-BASED VIRTUAL PRIVATE NETWORKS.

As you can see in the docs, this setup will work for a point-to-point VPN link between 2 hosts. If you want to add multiple remote hosts to the VPN, you will have to repeat the process for each of the remote hosts.

Long story short, the VPN will be initiated when one of the systems (let's call it client) starts an SSH connection to the other system (let's call it server). When that connection is opened, a virtual network interface is set up, creating the encrypted link between the two points of the VPN.

Preparations: private and public keys for ssh authentication

Before going any further, first thing we have to do is to generate the private and public keys that will be used to authenticate against the OpenSSH server (in case you did not have them already). If you want all the details, take a look at the ssh-keygen man page. Basically we can generate them with:

ssh-keygen -b 2048

This will generate RSA keys, check the man page to see how to choose other types of keys.

Once we have our public key ready, we have to authorize such key in the OpenSSH server. In the home directory of our user in such server, we have to add the public key to the file ~/.ssh/authorized_keys. I'm not going to explain all the details here (there are plenty of tutorials out there about this topic).

Setup the "server"

On the machine that will act as our "server", we need a shell script that will bring our virtual interface up. This is how I do it in OpenBSD:

/sbin/ifconfig tun1 netmask

This brings up a tun interface with an assigned ip address linked on the other end of the VPN to ip address Depending on the operating system you are using there, the syntax to ifconfig may be different, just check the man page for ifconfig and you learn how to do it.

Then, this script has to be executed every time the client system connects to the server system. To do that, we can add a call to the script to the beginning of the line where our public key is stored in our ~/.ssh/authorized_keys file in the server:

tunnel="1",command="~/bin/start_vpn" ssh-rsa AAAAB3Nza ...

Here I've saved the shell script as start_vpn inside my ~/bin directory and I tell ssh to execute that command after each connection is made. I also tell SSH to use the first tun device for connections authenticating using that key (if you want more users to use the vpn you have to use more tun devices).

Setup the "client"

On the "client" machine we will need another shell script, something like this:

/sbin/ifconfig tun0 netmask
/sbin/route add -net

Similar to what we did on the server, here we tell the system to bring up a virtual device - in this case tun0 - with an assigned ip address connected to the ip address on the other end of the VPN.

Here we also tell the system to route all traffic for the network through the VPN. You can route traffic for specific hosts, more subnets or even route all traffic through the VPN.

Again, as it happens in the case of the "server", we have to tell ssh to execute this script every time we connect to the server. The easiest way to do that is adding en entry for the server in the file ~/.ssh/config in the home directory of our user in the client system.

The entry should be something like this:

Host vpnserver
 HostName vpn.example.net
 User root
 Tunnel yes
 TunnelDevice 0:1
 PermitLocalCommand yes
 LocalCommand ~/bin/start_vpn

This would allow us to connect to the vpn server by simply doing:

ssh vpnserver

It will connect to host vpn.example.net as user root and will start tunnel device forwarding between the two systems using the interfaces tun0 (local) and tun1 (remote), executing the LocalCommand upon successful connection to the remote system. That local command is our shell script that brings up the tun0 device and sets the proper routing of traffic through the VPN.

For more information about tunnel device forwarding, check the man page for ssh(8), look for the -w parameter when invoking the ssh client.

Setup ready, running the VPN

Ok, setup ready. Now we can start the vpn. In a shell in the client system run:

ssh -vf vpnserver true

Parameter -v will make the ssh client more verbose, showing information about the connection, authentication and tunnel setup. You can provide up to 3 v (like, -vvv) so it shows more information. Using -vv can be specially handy for VPNs, as it will report things like packet size adjustments while the VPN is running.

Parameter -f tells the ssh client to fork to the background before executing any command.

Finally, I pass true as the command to be executed on the server as we do not want the ssh connection to be a shell session.

Connect as root, seriously?

I left this one for the end of the post on purpose. Yeah, I'm connecting as root, which means you have to set your OpenSSH server to accept connections as the super user. Recommendation, look for the option PermitRootLogin in the sshd_config(5) man page and learn how to adjust/secure a bit root logins.

The reason for using root to start the ssh connection, and hence the VPN, is that in order to start the vpn both users in the client and server systems will need privileges to bring up the tun interfaces, as well as modify routing (on the client). Feel free to deal with this through sudo (or doas in recent OpenBSD systems) if you don't feel like doing this as root.

Bonus: bypassing proxy+firewall setups

One neat trick I've learnt some time ago is that you can use this quick OpenSSH VPNs to bypass setups where you are limited to connections to hosts on port 80, through a proxy+firewall.

I found that kind of places in my travels. You connect to the wifi network in some hotel, public library or coworking space and suddenly you notice you cannot connect to your OpenSSH servers from there, maybe you can't even connect your mail client to your imaps server. Web traffic (both http and https) work fine though.

Well, there is a solution for that (without having to mess with ptunnel, for example). Before travelling, add this rule to pf on the OpenBSD box that acts like the VPN server:

# allow connections on ports 80/443, redirecting to 22, useful to bypass
# firewalls in some places
pass in quick on $ext_if inet proto tcp from any to ($ext_if) \
     port { 80, 443 } rdr-to port 22

Et voilà, all traffic to the default http and https ports will be redirected transparently to your OpenSSH server.

If the server is running another operating system without pf support, check the docs for any packet filtering solution available to your system, or simply put the OpenSSH server listening on those ports too.

Now in your client system (your laptop, most probably) add another entry to ~/.ssh/config, something like:

Host vpnhttp
 HostName vpn.example.net
 Port 80
 User root
 Tunnel yes
 TunnelDevice 0:1
 PermitLocalCommand yes
 LocalCommand ~/bin/start_vpn

Same thing as we had already, but setting a different port. If we connect now to that server:

ssh -vvf vpnhttp true

The VPN will be created and the traffic will be tunneled through it, going out through that connection to port 80 (or 443, depending on which one you choose), bypassing the limitations of that wifi network.

Some final notes

As stated in the ssh(8) man page:

Since an SSH-based setup entails a fair amount of overhead, it may be more suited to temporary setups, such as for wireless VPNs. More permanent VPNs are better provided by tools such as ipsecctl(8) and isakmpd(8).

This means that this won't be the most efficient VPN you can use, but I think it is the easiest and quickest VPN to setup you can get.

I hope some of you will find this one useful, thanks for reading!

Posted by wu at 08:53 | Comments (0) | Trackbacks (0)