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 :)

I’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 :)

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:

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.

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!

Google announced yesterday that they will stop censoring search results on google.cn. There can only be one response to that: finally! It is definitely the right way to go, as the Chinese government is hell-bent on ignoring all concerns from foreigners (as well as from critical voices in their own country), meaning that any “influencing them slowly” is futile.