PHP session on disk with lighttpd, and write access

On HappyLife, we used to use Memcache to handle the php sessions. We discovered a while back after much trouble that Memcache might not have been the best solution for sessions on a high traffic site. But this will be the subject of another post.

Anyway, I switched back to classical session, stored on disk.

Here's the relevant php.ini config

[Session]
session.save_handler = files
session.save_path = '/tmp/php'

/tmp/php should be writable by www-data, so

$ chown www-data:www-data /tmp/php

Working on Wednesday #11 : First steps with my Dreamplug

A while back, I ordered a Dreamplug. It's a micro computer more or less the size of a hard drive. It uses very little electricity, has ethernet, usb, sata and sd ports as well as bluetooth and wifi connectivity.

I wanted one to primarily work as a git and mercurial server to host my repos, as well as host a few websites I might be working on. As it's not the more powerful of device and will be using my home ADSL connection, it's also a good fit for testing web performance optimisations.

Actually, I have a lot of ideas for this plug (ssh tunnel, dropox-like server, etc).

First, let's establish a connection

To do any of that, you first have to log into your device. This first step might have been the one that caused me the much trouble.

I simply wanted to connect to the plug through SSH. I didn't want to plug it to my router because it would then have emit an open wifi network. Instead, I wanted to access it through a simple ethernet cable.

To do that I had to plug the Ethernet cable on the second slot (the one the closer to the lights) on the plug, then turn it on. I didn't manage to connect with the cable in the other plug nor if I plugged it after turning the device on.

What took me a while to figure is that the Dreamplug have its own ip address : 10.0.0.1. To enable transfer between your host and the plug, you have to set a fixed ip address to your ethernet (mine was eth0)

$ sudo ifconfig eth0 10.0.0.2

I chose 10.0.0.2 because it's close to the Dreamplug address and I will remember it better, but you can actually choose anything you want, it absolutely does not matter.

Connect through ssh

Once the first step is done, you are now able to connect to the device through SSH.

$ ssh root@10.0.0.1

The default password is nosoup4u. I chose to keep it for now, as I'll have to type it a lot, but I'll change it once everything is installed.

First thing you should do is create a new user. Using root for the day to day activities is a bad habit.

$ adduser pixelastic

You'll be prompted for password and other misc informations. Once done, we will give sudo power to this user.

On others Ubuntu machines, I usually do a adduser pixelastic admin or adduser pixelastic sudo, but this didn't work here. There wasn't even an admin group, and adding to sudo didn't seem to change anything.

Instead, I had to edit the /etc/sudoers file, using visudo.

If you've never used vi before, press i to enter edit mode, and vi will acts as a common editor. Press Esc when you've finished, then :x to save and exit

I added a new line just below the one starting with root and copied it, simply by changing the user name.

root    ALL=(ALL) ALL
pixelastic ALL=(ALL) ALL

Your new user should now have the sudo powers.

Unfortunatly, on my build one more thing was missing. It might not be the case on your plug, but we'd better check.

$ which sudo
 /usr/bin/sudo
$ ls -l /usr/bin/sudo
 -rwxr-xr-x 1 root root 114976 2011-02-14 08:08 /usr/bin/sudo

Check the permissions, if you have this output, then something is wrong. The sudo executable should have the s permissions, otherwise it won't work.

$ chmod u+s /usr/bin/sudo

Now, we can logout from the root session, and login back with our new user

$ ssh pixelastic@10.0.0.1
$ sudo pwd
 /home/pixelastic

What next ?

Now, one last sensible thing to do is to change the root password for something stronger, and even disable login as root through ssh. To do that, simply edit the /etc/ssh/sshd_config file and set PermitRootLogin to no.

You could also add your keys to the plug to avoid typing your password, install your softs, and link the plug to your router to make it accessible from the outside.

I plan to replace Ubuntu for Debian on my Dreamplug, I'll post about that later.

Keeping your plugins with any new Firefox version

The new Firefox cycle version is such that you might lose all your beloved plugins on each new release.

Fortunatly, most of the plugins still work even when the version updates, so you can still use them.

The easiest way to automatically enable them all is to update a boolean value in about:config that will tell Firefox to not disable older plugins.

The key changes for each version, but is called extensions.checkCompatibility.X.Y where X and Y are the version number (like X=7 and Y=0 for the 7.0 release).

Create the key (as a boolean value), and set it to false.

Working on Wednesday #10 : Mercurial improved

Today I enjoyed the nice blue sky and moved to the park at the end of my street to finish reading the Mercurial guide.

I skipped the last chapters about patches and queues. I know this would be useful, but I'd rather get back to them when I'll need them instead of try them without any real world example.

Tweaking Mercurial

I updated my .hgrc to configure it as best as I could.

I set vimdiff to handle the conflicted merge. vim is quite hard to get (but it is coming easier the more you use it), but it seems so powerful that I'm willing to spend some time learning it.

I've also added a cm alias to commit -Am. This basically is the same as calling hg addremove; hg commit which I happen to do all the time before.

I've create two simple styles and matching templates for my new two aliases peek and hist that repectively display a peek at the last 4 commits, and display the latest 10 commits in history in a concise way. I still have to manage to find how I could add coloring to those.

I've also added a discardlocal alias to remove all local commit and get the repo back as it is on the remote repo. I never actually had to use it, but I found the code on Stack Overflow and thought I might need it later.

I finally wrote a custom resurect method. It will bring back a deleted file (obviously, the file needs to be tracked by hg). I simply find the changeset that deleted the file, and then revert the file to the parent changeset of that changeset. I might post the exact code later as I'm quite happy with the result.

A note on laptop screens

Also, I've spent the last few weeks working on my netbook when at home. This is very tiny thing, the screen is really small (compared to my two 21" at work for example). But (and I was the first surprised of it), you actually get accustomed to it after a while.

Now that I'm writing this post on my 13" other laptop, I feel like it's huge. The more I use the netbook, the more I like it. I didn't quite use it back when it was running Windows because it was way too slow. Now with Ubuntu on it, it's a whole new story !

Next week

I still have some zsh to learn. I still don't quite get the quote and double quote differences, and a few other quirks (arithmetic, arrays, etc).

I've kinda dropped the Rails tutorial. I liked it. Really, I liked it a lot. But I'm not sure I want to start again learning a framework for making websites. I've made a living doing websites for clients, I still do partly that today, and I'd like to change.

I have a lot of personnal project on my mind that I'd like to achieve. Almost all of them could be achieved using the traditional way of making websites that both cake and Rails would allow. But one of them might need another way to look at things. And for this one, I might better need node.

So.. maybe I'll start learning node next week. This is actually something I'd love to do, so this might happen. I'm currently refactoring the JS code of my work app in Backbone at the moment, so I guess there's no perfect time for some JS practice.

Working on Wednesday #9 : Mercurial

I'm feeling like I'm getting more and more behind schedule for what I intended to do at first. I still haven't tried Rails more than that and have gone on different learning side projects.

_I've been reading the _Mercurial : Definite Guide the past few days to get a correct grasp of the soft.

I've been using Mercurial for the pas two years, but through a GUI and without using any "advanced" features. I never branched a project, and always worked alone.

Commands

Now that I'm working on a Linux machine every day, I can use hg through the command line.

hg commit -Am "commit message" is the same as hg addremove; hg commit -m "commit message".

hg rollback will remove the last local commit. Useful if you forgot files in the commit, or if you inserted a typo in your commit message

hg revert can revert a file or set of files to the state they were at the last commit. This can also cancel a hg add or hg remove

hg backout can "forget" a commit in the history. It will not really forget the commit (ie. will not let you alter the history). Instead, it will create a new commit where the specified changeset is removed (through a merge). It can easily backout the tip, but may involve more merge work if we want to backout an old changeset.

Automation

Also, I've learned about two great tools of Mercurial.

hg bisect let you isolate a specified commit in your history where you introduced a specific bug. You write a piece of code that, given a changeset, returns true or false based on the bug presence, and hg bisect will cleverly scan the history to find the revision that introduced the bug.

hooks where also very interesting. One can script automatic command on specific hg command like commit, pull, push. Or even before those commande to refuse the command if something does not work as expected.

The classical examples where running a build process after a commit, refusing a commit if no bug id where specified, or if the tests didn't pass. Another use case would be to push changes to a remote server on commit.

Git

Why am I learning Mercurial while all the cool guys are using git ?

Well, I've read a lot of papers comparing hg to git. What I've read the more is that git is an awesome toolbox that lets you do whatever you want with your version control, through its 100+ tools.

On the other hand, Mercurial is far easier to learn and has built-in command for the day to day work. As I was already quite familiar with Mercurial, I stick with it, but know that I'll learn git also eventually.