The general advice: We are all supposed to use a separate password that has at least 25 letters, numbers and special characters in it for everything we use on the net, because if we don’t, one compromised site gives an attacker access to all your other accounts using the same password. Think of a hacked twitter account resulting in all your emails on gmail made publicly available.

The reality: We are all lazy bastards so most uf us have one single password they use for all their accounts (am I not right?). Some of us have 2-3 passwords for different levels of trust, so the bank account and credit card sites get one, personal email gets one and all the other sites get another. A bit better already.

My suggestion: One password per site (hey I’ve heard this before). But here’s the trick (and the catch at the same time, because the passwords are similar and can hence be hacked more easily). I will use the following convention to generate a separate password that is (for me) easy to remember for each site:

Take some random sentence:

This is my personal very secure password for [...].

Say you need a password for twitter, this sentence becomes:

This is my personal very secure password for twitter.

The password will be the first letter of each word in the sentence, so for this example it’s Timpvspftw. I’m actually using the first two letters of the site’s name so the convention works for twitter and t*** (uhm. insert name of another website starting with t). To make things a bit more secure, you should change your scheme, e.g. use the last letters, or alternating between last and first.

Using more or less random letters from a sentence to generate a secure password is nothing new. It actually has been recommended for years (decades?). My only addition to this is to use the name of the service in that sentence, so you can have separate passwords and still remember them easily. And they should be fairly secure, as long as your scheme of choosing the letters and your sentence are random enough (I’m still using something different for my bank account though).

Of course the whole would be much easier with somethingh like OpenID everywhere, but until then go and make up some funny sentences for your passwords.

In a previous post I wrote about how we wanted to pregenerate our packed assets simply by firing up a mongrel on deployemnt and request a page so it would generate the assets by calling the stylesheet_link_tag ... :cache => true and javascript_include_tag ... :cache => true methods in our application.rhtml.

It turned out starting and stopping a mongrel during development wasn’t really a good idea. We ran into all sorts of problems with deployemnts not shutting down the mongrel or not deleting its pid file which made the next deployemnt fails and stuff like that. Plus, to be honest, this really felt like a hack from the beginning.

So what we ended up doing was this: Write a small class that calls the methods to generate the all.js/all.css files and simply call that from our capistrano script. This is how it looks (config/assets.rb):
(more…)

We have been using haproxy as a load balancer for autoki (rails) for a while. The setup was relatively simple. We had two servers full of mongrels and one haproxy was simply throwing requests at them using round robin.

Now our requirements have gotten bigger. We have extracted the game into a separate application that is being deployed on its own server independently. The problem that we want to solve with this is that while we want to deploy changes to our servers whenever we want to, the game application has to keep running all the time without interruptions by a deployment and the problems that might be caused by it. Oh, and at the same time we didn’t want to change any urls. The game has been sitting in the external_games controller, so the url was autoki.com/external_games and since we have given this url to people we wanted it to stay the same.

So now we have a new server called external_games.autoki.com with 10 mongrels running on it and we want all requests to /external_games go there and everything else still go to the old servers. The solution to this is to let the load balancer decide which servers to forward the requests to. Since version 1.3 haproxy has implemented exactly this - and calls it content switching. To get thsi to work you have to tweak the haproxy.cfg file a bit. This is the old listen section with one pool of mongrels:

First we have split up our single proxy configuration into a frontend and a backend. We will actually be using two backends - one for gaming and one for the rest, and the frontend will decide which backend to use.

The rule to decide which backend to use is implemented using an acl. The following line creates a rule with the name game that evaluates to tue, if the url contains the string external_games. The haproxy documentation has a whole list of keywords you can use to match against all the contents of a http packet.

Now all we have to do is tell the frontend when to use which backend. We do this by defining a rule for the gaming backend and set a default backend for all requests not matching our acl.

That’s it. Now when we go to http://autoki.com/haproxy?stats we’ll see the two backends up and running. (only after adding stats enable to both backends actually)

surrrrr….. RRRRRR ….. zzzzzZZZZZ …… *kreisssssssch* zzzzZZZZZ &€&@@&&& *stille* *plop* “Neiiiiiinnnn”

so klang es vorhin, als der eine Lüfter meines Laptops seine letzten Umdrehungen nahm. Jetzt ist Ruhe. R.I.P. Warten auf den 15. Januar - dann ist Macworld San Francisco und Steve beschenkt die Welt mit neuer Hardware. Bis dahin bleibt mir nur, Bücher zu lesen.