As you may have probably seen, the website has changed quite dramatically. The reason for this change is because we moved mupuf.org to a new server with a bigger storage space.
MùPùF.org
As I was to reinstall everything again, I began to look for alternatives to all these scripts and databases that constituted the previous server.
Let’s be honest, I hate scripts. People who know me sure know the extent of my hate towards these “easy” languages that blow up in your hands whenever you update anything. I’m a huge fan of statically-typed and compiled languages since they are easier to deal with from a programmer perspective AND from an administrator point of view. I should also mention that it is also much better from a security perspective.
Octopress
Anyway, I was looking into using Wt for the website but as I didn’t have enough time on my hands to do the whole porting and setting up the server in time before the end of the contract of the previous server, Timothée Ravier told me about octopress, a statically-generated website.
I was blown away by the logic behind this project! The whole concept of generating html pages and deploying them seemed perfect to me! One more key advantage is that the website framework is just a bunch of short ruby scritps, a template engine and a markdown syntax (that we already used for the previous websites). Thanks to this, I was able to create a git repo to hold all the articles and the website in general. No need to worry anymore about changing servers! It is as easy as a copy/paste to get the website up and running again.
Comments?
Using a statically-generated website kind of means you cannot let users interact with the website by, for instance, leaving comments, right?
Well, this is true but we are working on it and it isn’t something we can’t overcome. For instance, using iframes or javascript, a client could query a web service that would store and serve comments as needed.
Such services already exist, such as Disqus. However, due to some privacy concerns, we may re-implement a custom-made version using Wt. The comment WT service would just be a statically-linked program that would read and write comments to an xml file. That means, the program could be chrooted and could be running without any privilege. YEAH!
So, when it is time again to change the server, I just need to copy the WT program binary + the xml file and be done with it! When a new WT version comes out, a simple recompilation outside the server can be done and deployed if it still works.
That eases administration A LOT compared to having a database, python, python libraries and frameworks like we had on the previous website!
Don’t know about you guys, but I’m excited!
Cherokee -> Nginx
Don’t know about you guys, but Apache makes me want to throw up. Back to the RPS day (2 servers ago), I had 512 MB of RAM and Apache was usually filling those like it was nothing! Not to mention how slow it was.
I didn’t complain until I was asked by some school assignment to develop my own http server. It turned out my design was much faster, logical and easy to administrate than Apache. Thus, I began looking for alternatives.
That’s when I came across Cherokee. Again, this webserver blew my mind! It was fast, lightweight (usually took about 4MB of RAM), easy to administrate and was doing only the thing it was supposed to do: Virtualizing my IP address and dispatch http requests to the right fastcgi services.
I wanted to use this webserver again on this new server, but it turns out arch moved cherokee from [community] to AUR. The reason is because it currently being re-written and no new version will be out for a while.
As I didn’t want to use un-maintained software on my server, I decided to have a look at alternatives. Again, Timothée Ravier advised me to look into Nginx and I must admit it is awesome! The configuration file is as short as possible, accurate and don’t require you to read on thousands of pages of documentation before actually being able to configure your service. Take that Apache!
Git repo
I’ve moved away from setting up git repos by creating a user/repo, add public keys to ssh’s authorized_keys and give ssh access to trusted users. From now on, I’ll use gitolite.
It is very easy to work with and setting up a repo takes less than a minute.
Final thoughts
With most of the crap out of my server, I’m amazed at how pretty ps aux looks!
Apart from quassel-core and nginx, nothing else that shouldn’t be there runs. That’s quite an improvement over the previous state where I would need to browse through processes and schroots because I didn’t trust all the django scripts.
Anyway, I like this new design very much :)