The other day I received a book — Zend Framework 1.8 – Web Application Development — for review. I’ll read through it as soon as I can and write a review that I will publish on my blog.

For a long time I have used a Debian based machine called megatron as a gateway at home. Megatron had two NIC’s where one was connected to an SDSL modem, and the other was connected to a Linksys WRT54GL router (which is running the Tomato firmware). These two switched places a while back so that the router is connected to the modem, and megatron is behind the router. There are a couple of services running on megatron that needs to be accessible from the internets, so I had to do some iptables magic on the router to be able to do this. This post is more of a reminder to myself of how to do this, but there might be someone else out there who wants to do the exact same thing.

Earlier megatron had two official ip addresses (I have 5 from my ISP) on the NIC connected to the modem. One of them is used for SSL traffic to megatron and the other is used for everything else. The setup now is that megatron only has one NIC with two internal addresses: 192.168.1.10 and 192.168.1.11. My router has three addresses. Lets say these are: 193.n.n.122, 193.n.n.123 and 193.n.n.124. The first one is the one I will let the router have and the other two I will forward to megatron.

First I had to add two addresses to the router since it only had one. To do this I logged in the router using ssh and ran the following commands:

# Add ip addresses
ifconfig vlan1:1 193.n.n.123 netmask 255.255.255.248 broadcast 193.n.n.127
ifconfig vlan1:2 193.n.n.124 netmask 255.255.255.248 broadcast 193.n.n.127

To test if these two worked I simply pinged the new ip addresses.

Now I needed to tell the router to forward traffic on these two addresses to the ip’s specified on megatron. iptables to the rescue:

# To megatron
iptables -t nat -I PREROUTING -p all -d 193.n.n.123 -j DNAT --to-destination 192.168.1.10
iptables -t nat -I PREROUTING -p all -d 193.n.n.124 -j DNAT --to-destination 192.168.1.11

# From megatron
iptables -t nat -I POSTROUTING -p all -s 192.168.1.10 -j SNAT --to-source 193.n.n.123
iptables -t nat -I POSTROUTING -p all -s 192.168.1.11 -j SNAT --to-source 193.n.n.124

# Accept all ports
iptables -I FORWARD -p tcp -d 192.168.1.10 -j ACCEPT
iptables -I FORWARD -p tcp -d 192.168.1.11 -j ACCEPT

And that’s that really. One last thing I had to do was to make these changes permanent. This can be done by putting the ifconfig and iptables commands in this post in the Administration->Scripts part of the Tomato web-gui. Click on Administration and then Scripts in the gui and enter the commands in the firewall tab:

Remember to click the save button on the bottom of the page after these changes.

Check out some photos from my trip to Kalymnos in September/October over at my flickr account.

Some previews:

Sorry about the total lack of updates from this years trip to Kalymnos. I’ve been busy doing everything else than sitting on my computer. Now we’re only a couple hours away from starting the trip back to Norway. It’s been a great month of climbing, and I’ll most likely come back some other time. I’ll try to post some pictures in a day or two!

A few more days have gone by and I’m still living the “hard” life at Kalymnos. We (as in Louis which I’m here with and myself) have been climbing today and we’ll go out again tomorrow. When tomorrow is at an end we have been here for a week and have climbed 5 days. We have done some very nice routes as well! I’ll include a tick list when I get home from this place for those who might be interested in that.

We have been bathing and swimming every day as well. It’s about 21 degress in the ocean here so it’s quite nice. It’s very refreshing to take a quick dip after climbing all day long. We are going out to eat today since we forgot to take anything out of the freezer yesterday.

You’ll hear from me later!

So, we’ve been here for a couple of days now. We arrived around 1800 on Sunday and didn’t do much that evening. The room we are staying in is not really that good. The “kitchen” is a small portable gadget with one plate to cook on and a fridge that barely works. Not too great if you want to make rice, sauce and some meat. We have been talking about looking for some other place to stay if there are better options regarding the kitchen around here. Since we’re staying here for over a month it would be nice to have a decent place to make some food.

Today we are having a resting day after a long climbing day yesterday. We went to the capitol of the island earlier today and picked up some food since there is no butcher shop around here. We also spent some hours sleeping in the sun on the beach after a short swim. It’s a hard life we are living here…

We are going to climb tomorrow and Thursday and we’ll rest on Friday again. I’ll write some more later and post some pictures as well. There won’t be too many pictures until some more of our friends arrive here. When it’s only the two of us climbing there is no opportunity to snap some photos as well.

Anyhoo, hope everyone back home is having as great a time as myself. Later everyone!

I run Ubuntu on all my workstations. I also run Spotify in Wine and use Firefox 3.0 as browser of choice. Until now I haven’t been able to click on the spotify:* links in Firefox and have it open them in Spotify. The following small changes made this possible:

Start Firefix and enter about:config in the address bar. Click past the warning that comes up, right click somewhere in the list of settings and click on new -> boolean. Create the following setting:

network.protocol-handler.expose.spotify

and set it to false.

Right click again to add another setting:

network.protocol-handler.external.spotify

Set this to true.

Now, lets create a small shell script that Firefox can use to start Spotify. I chose to place it in the Spotify installation folder:

vim ~/.wine/drive_c/Program\ Files/Spotify/spotify.sh

Enter the following:

#!/bin/bash
wine "$HOME/.wine/drive_c/Program Files/Spotify/spotify.exe" /uri "$1"

Then make the file executable with the following command:

chmod +x ~/.wine/drive_c/Program\ Files/Spotify/spotify.sh

Now, click on a spotify link (like this one for instance) and select the newly created shell script to see the magic happen!

In about 4 days I will arrive at Kalymnos, Greece for a month of sport climbing together with a friend, and I’ll stay there until the 15th of October.

Our plan is to go climbing every other day. I wanted to bring my bike so I could get some mileage done on the non-climbing days but there was no room for it on the plane from Athens to Kalymnos (which is a smaller Propeller aircraft). I’ll probably try to do some swimming and hiking instead. I also have some plans to read some books while there. I’ll bring World Without End by Ken Follett and some other smaller books.

I’ll bring my camera and some lenses as well and I’ll hopefully be able to snap some nice climbing pictures (pictures from last year is available in this set over at flickr.com). The last couple of weeks some other guys will join us there so it’ll be easier to fix myself high up in some route and take some pictures of the other guys.

When I’m really bored (can’t really see how that will happen) I’ll probably get some coding done as well. :)

I’ll keep you all updated!

Last Saturday I raced in Birkebeinerrittet which is a mountain bike race in Norway over the mountains from Rena to Lillehammer. The race is about 94,6km and it’s the worlds biggest mountain bike race with ~16.000 contestants. My group started at 13:20 so I left Fredrikstad around 07:15 together with Linda so I’d have plenty of time. I arrived early and managed to get a good 45 minute warm up by cycling around Rena before the race started. During my warm up it started to rain and I got some messages from a couple of friends of mine that the track was extremely muddy and slippery. I raced in Grenserittet earlier this year and thought that it couldn’t be much worse than that… boy was I wrong. Take a look at some pictures from the event and you’ll understand.

The trip over the mountains did not exactly go as planned though. After 3,16km’s my cycle computer stopped working. It has been this way once before and that was at the Grenserittet race. I’m guessing this computer doesn’t want me to enter these races. Now, this was only a small beginning. When I stood on the top of the so called raisin hill (Rosinbakken) at the ~55km mark I had managed to break my glasses (which was a major bummer in these conditions), puncture twice and split my chain 3 times. Since I only had one extra tube in my backpack I actually had to patch the tube the second time around which was not too easy when everything is covered in mud. I got quite cold during this ordeal as well so it wasn’t to pleasant to get back on the seat. Since my chain (and the rest of the bike for that matter) was covered in mud it’s easier to break it if you don’t have the correct oil and bit of luck. The last time I sat mending my chain some other guy broke his chain as well so we sat down and shared a laugh and a bun with raisins (which was fitting since we were sitting at the top of the raisin hill).

After all this I lost all motivation and did not ride very fast and efficient to the finish line. I finished the race in 5 hours and 54 minutes which was way more than my intentions. Hopefully the weather will be better next year and that I’ll have a bit more luck with my bike. Mats finished the race in 5.24 wihch was a big improvement from last year.

I’ve uploaded some photos of my bike after the race to flickr:

At work we have a component in our internal framework for fetching content from remote sources. The component utilizes something called availability caching which means that it will cache the remote content and use it when the remote server is down. We use Zend_Http_Client internally and to fully test our component we needed the remote server (which is not really a remote server at all in our test suite) to fail on demand.

In our tests we simply use the Zend_Http_Client_Adapter_Test adapter with the Zend_Http_Client instance instead of the default adapter. Using this we can tell the client what to return so we can make sure our own component behaves like it should. I implemented a method in the test adapter called setNextRequestWillFail() which takes a boolean flag as a parameter. The result when calling this method with boolean true is that the adapter will throw a Zend_Http_Client_Adapter_Exception exception on the next request. This allowed us to force the “remote server” to fail so we could test our availability cache.

The fix has been commited to Zend Framework trunk and will hopefully be added soon.