Latest Publications

Router scripting

Another thing that’s been bugging me for a while on the tech side of things at home is my router. It’s a Zyxel 2602 and while the interface is shiny and the setup is fairly easy, the damn thing has a tendency to atrophy and die after some days of uptime … if there’s been quite a bit of traffic going through it. In the spirit of new energy I wanted to do something about it.

Now, although I’m clearly a geek and like my gadgets, I’m not loaded with money, so buying a new shiny toy is not an option. Apart from that, I have a hard time accepting that it shouldn’t be possible to make the Zyxel do the job properly. Well, maybe not properly – I have no intension of messing with the firmware (apart from updates whenever one’s available/needed).

No, what I had in mind was scripting the router to reboot regularly. As I’ve just moved my company site off the server at home there’s no problem if the router goes down for about a minute a day, in the middle of the night. So the question became one of: how to script it?

Possible Solution 1

I’ve been using Selenium for various projects, testing frontends and general functionality. Selenium allows you to script actions and it’s basically ideal for a task like this: log into the webclient, find the right tab, click the right button, done.

Only problem is that installing this to run headless on my server every night means installing SeleniumRC and various other things … in short, much too much work for just scripting a router reboot. If I already had Selenium installed there, then no problem – but unfortunately I don’t.

Possible Solution 2

Instead of installing Selenium, one could also give wget a try – installing is a simple

sudo apt-get install wget

if the program isn’t already installed, that is. After that, toying with various command line options got me logged into the routers webclient and requesting the reboot … but no dice. For anyone interested, the options you’ll need are

  • –save-cookies file / –load-cookies file
  • –keep-session-cookies
  • –post-data=’blah=blah&moreblah=moreblah’

It didn’t particularly look as if Zyxel actually cares about the cookies, but you never know if they’ll come in handy later.

Possible Solution 3

At this point I started looking for alternative ideas – and that’s when I remembered that Zyxel routers provide quite a few different protocols for access (like most other routers). So I checked out the telnet interface and quickly found myself wondering exactly what was going on … the only help provided is lists of commands. No description, no anything. In my battle to find out how to reset things, this led me among other things to a factory reset of settings … fairly annoying (don’t issue sys default unless you’ve got settings backed up!). However, googling for info on Zyxel routers finally led me to a pdf with some goodies, although for a different model. It was worth a shot though, as the command looked as if it might work – and indeed, the Zyxel 2602 will happily respond to a sys reboot issued over telnet. That meant the task was down to scripting telnet – which turned out quite easy. Here’s the oneliner I ended up with

(cat /path/to/passwordfile; sleep 1; echo sys reboot; sleep 1) | telnet 192.168.1.1

The first bit echoes the details needed for the router – after the pipe there’s the actual connection. The sleep commands are there to allow the router to echo back a response before reacting on it – without them you wouldn’t do anything. To avoid having the password stored in the shell history I use a file for storing it in … not that much more secure, but at least you don’t get surprised by where it moves to.

Done

A little bit of researching, some vim’ing and there: a script to restart my router every night at 5. Only thing left is scheduling the cron job :)

Back from holidays

After great holidays on the Canarian Islands I’m now back in front of the trusty computer. The trip was super, resulting in some much needed extra energy and motivation for … well, lots of things, really :) The first bigger thing I’ve done after coming back is moving plphp.dk from a server I have at home to my VPS. The reason is rather simple, really: the connection here is simply not stable enough for me to have my company site running over it (it’s a combination of crappy router plus wrong linux install, I think).

Before moving stuff I thought it might take a bit of effort getting things working without problems but it turned out I had no reason to worry. A combination of git and gitosis made the basic transfer easy and the rest was handled with a database dump + import and a new virtualhost for Apache. Replicating the install looked like this:

Step 1 – setup local repo

Make sure the site you’re moving is in a git working repo. Skip this if you’re in a working git repo, otherwise just do something like

git init
git add --all
git commit -am "setting up git repo for myproject"

Your repo is now ready to move – need a place to move it to, though.

Step 2 – add group to gitosis

If you’ve not already setup gitosis on your server (local or remote) have a read on the scie.nti.st blog. When gitosis is running, you need to modify your gitosis.conf to add a new group for the site you want to move (unless you’ve got one group for everything, which I wouldn’t recommend though). In your gitosis.conf, add

[group mygroup]
writable = myprojectname
members = user1 user2 user3@host

Save and move on.

Step 3 – add remote repo to your local working directory

If like me your gitosis daemon is running on a remote server, you need to do something like

git remote add remote_repo_name ssh://git@host/myproject.git

If gitosis is running locally, you can do away with the ssh protocol bit

Step 4 – push

Time to do the actual copy. Do

git push remote_repo_name master

Your repo is now copied to gitosis.

Step 5 – clone

Check out a working copy by cloning the site to where you need it – i.e. do

cd /var/www
git clone /path/to/gitosis/repos mysite

If your new site is on the same server as the gitosis server, that is. Otherwise, use the ssh protocol for the path.

Step 6 – dump database

PL PHP is running on MySQL – hence, dumping the database and copying it across to the new site can be done by

mysqldump -u user -p database > dump.sql && scp dump.sql user@host:~/

Step 7 – setup proper user

Setup a user with access to the database using the same details as on the current site – a create ‘user’@'localhost’ will probably suffice.

Step 8 – import database

Create the database, then import using your sql

mysql> create database mydb default charset utf8;

and

bash:~/$ mysql -u user -p -D mydb < dump.sql

And done

Step 9 – create new virtualhost

Get Apache to serve up the site by creating a new virtualhost file. Then check your Apache config with apache2ctl configtest – if it’s working fine, then restart apache.

Step 10 – change DNS records

Last thing is to switch DNS records so your domain points to the new IP.

That’s it – 10 steps and PL PHP was migrated to a different server with the added benefit of having a repo copy added to my gitosis daemon. If you skip the gitosis bit then you can truncate step 1-5 – just clone the repo straight away.

On the other hand, if your site is bigger than PL PHP, you probably want to add some extra steps, such as having your current site proxy the new site, so that no traffic will hit the current site (and thus the current database). An alternative to this would be to setup the new site to use the current database and only migrate the database when you’re sure DNS records have been changed (i.e. when you no longer see hits on the old IP).

With this out of my mind, I can focus on other interesting stuff, such as the Typo3 book review I’ll be doing (expect that in a little over a week) and an interesting project focusing on the craft community which I’m doing with my fiancee :)

Typo3 book review

Typo3 4.3 Multimedia CookbookI’ve been given the chance to review the new Typo3 Multimedia Cookbook that Packt is publishing. Right now it should be in the mail on it’s way to me and hopefully will arrive in a week or so. After that, I’ll be enjoying some serious tech reading on Typo3 :) I found the Typo3: Enterprise Content Management book from Packt quite useful, so I’m hoping the Multimedia Cookbook will be even better – we’ll see. The description of the book certainly does inspire a certain appetite for reading:

The book gives you a step-by-step process for organizing an effective multimedia system. It also gives solutions to commonly encountered problems, and offers a variety of tools for dealing with multimedia content.

There’ll be a minor delay before the review goes online, though, as I’m off on holidays next week for two weeks – so I expect I’ll be done with the review start March or so. Come back for more reading then :)

User management fail 2

Hot on the heels of yesterday’s User management fail post comes User management fail 2! More shocking discoveries! Blood! Gore!

Well, perhaps not, but still a fairly massive security fail.

Background

I’m interviewing for a project doing Zimlets for Zimbra and as part of the preparation I’m looking at existing Zimlets to see how they’re done (the Zimlets are located at gallery.zimbra.com should you be interested in having a look). One of the Zimlets I looked at seemed to have code useful to the project and I wanted to download it – but found no download button. Instead, I spied a login/register combo and figured I had to register first, which I then did. Back on the original page, I then tried to login with my new info.

Fail

When trying to log in, I got an error message, something about lacking permissions for a given area. Not a huge fail, but not really smart either (I registered using the button right next to the login button that doesn’t let me in – if I cannot register for the area the login button controls, then DON’T DISPLAY a register button there). No, the real fail lies with the error output – have a look at the image below:

Displays a problematic error message from Zimbra's login form

It’s always good to have descriptive error outputs, and if you’re debugging stuff, then extra output is fantastic. But even though I have seemingly managed to get the ‘eleet’ ID, it’s less than stellar performance that they choose to tell me. And the fact that they’re outputting password hash is downright stupid. Though, of course, the password hash itself wouldn’t get you far, because at Zimbra, passwords are also protected by salts, making a bruteforce attack very hard … unless you know the salt. Which Zimbra happily displays right alongside the password hash on the login fail screen.

There is a factor mitigating this: the output is only displayed for logins that are successful, i.e. you actually have to know the proper user/pass combination to get it, so you cannot just start leeching password hashes from the site. The good news only goes so far, though: any man-in-the-middle has free access to all the data, as the login happens over http and not https.

Note: I have contacted Zimbra about this.

User management fail

I recently subscribed gocomics/ucomics – wanting to get Doonesbury, Non Sequitur, etc by email delivery (I subscribe to the feeds but forget to read them). And I did finally get en email with Doonesbury … but as I didn’t get all the strips I wanted it was a failure. Not a failure worthy of a blog post, though.

However, trying to get out of the gocomics system has proven hard. The emails that gocomics send out do contain links both for unsubscribing and logging in, however:

  • trying to unsubscribe yields: no success, something when wrong
  • trying to login yields: username or password wrong
  • trying to get a new password sent results in: email address unknown

Now, the fun part comes when you then look at the unsubscribe link in the email sent to you. Normally, for unsubscribe emails, you either expect username/email (insecure, but would work) or a temporary token (the norm). Here’s the link from gocomics:

http://www.gocomics.com/email_manager?user_code=abcdefghijklmnopqrstuvwxyz123456

Yup, that’s right. Gocomics keep sending emails to people without any way for them to unsubscribe. Something tells me this policy runs danger close of being spam … and that’s exactly what I’ve told Gmail that these emails are.

Sending out emails with broken unsubscribe links: fail!