Planet HantsLUG

July 28, 2014

Adam Trickett

July 27, 2014

Adam Trickett

July 26, 2014

Chris Dennis

Website version control with Git

Some notes on using git to manage development and production versions of a website on a Linux server, based on Using Git to manage a web site.  There seem to be several web pages with similar ideas out there: I don’t know who wrote it down first.  And also with reference to Version Control with Git by Jon Lodger.

I’ve adapted those ideas for the way I like to do things:

  • I SSH in to the server, and do the editing there, using vim.
  • I have separate domains for development and production versions of my sites.  For the purposes of these notes, they’re called and  So the development version is also an active real-world website: my nginx configuration makes it only visible to me.
  • The document roots are /var/www/website and /var/www/website-dev respectively.
  • The ‘bare’ production git repository can be anywhere on the server.  I’ll put it at /var/www/website.git.  It’s a git convention to use the .git extension for bare repositories.

The steps for setting it up are as follows.  I’ll leave the setting of suitable permissions and use of sudo as an exercise for the reader.

  1. Put some web pages in /var/www/website-dev.
  2. mkdir /var/www/website
    cd /var/www/website-dev
    git init
    git add <all the appropriate files and directories>
    git commit -a -m "a message"
    mkdir /var/www/website.git
    cd /var/www/website.git
    git --bare init
  3. Create /var/www/website.git/hooks/post-receive containing:
GIT_WORK_TREE=/var/www/website git checkout -f
  • In the following, I’ve used ‘live’ as an alias for the production environment; you could use ‘prod’ or whatever you fancy.
  • chmod +x /var/www/website.git/hoots/post-receive
    cd /var/www/website-dev
    git remote add live file:///var/www/website.git
    git push live +master:refs/heads/master
    git push --set-upstream live master
    git push live
  • And, as if by magic, the files from the master branch of /var/www/website-dev are now in /var/www/website.
  • Then whenever you’ve got new code ready to into production, all that’s required is:
  • git push live

    by chris at July 26, 2014 08:59 PM

    Adam Trickett

    July 25, 2014

    Steve Kemp

    The selfish programmer

    Once upon a time I wrote a piece of software for scheduling the classes available to a college.

    There was a bug in the scheduler: Students who happened to be named 'Steve Kemp' had a significantly higher chance (>=80% IIRC) of being placed in lessons where the class makeup was more than 50% female.

    This bug was never fixed. Which was nice, because I spent several hours both implementing and disguising this feature.

    I'm was a bad coder when I was a teenager.

    These days I'm still a bad coder, but in different ways.

    July 25, 2014 01:16 PM

    Adam Trickett

    July 24, 2014

    Anton Piatek

    The department of dirty

    I quite like the Open Rights Group‘s new campaign against internet filtering

    The Department of Dirty is working with internet and mobile companies to stop the dirty internet. We are committed to protecting children and adults from online filth such as:

    • Talk to Frank: This government website tries to educate young people about drugs. We all know what ‘education’ means, don’t we? Blocked by Three.
    • Girl Guides Essex: They say, ‘guiding is about acquiring skills for life’. We say, why would young girls need skills? Blocked by BT.
    • South London Refugee Association: This charity aims to relieve poverty and distress. Not on our watch they don’t. Blocked by BT, EE, Sky and VirginMedia
    We need you to help us take a stand against blogs, charities and education websites, all of which are being blocked [1]. It’s time to stop this sick filth. Together, we can clean up the

    by Anton Piatek at July 24, 2014 09:03 AM

    July 23, 2014

    Adam Trickett

    July 22, 2014

    Adam Trickett

    July 21, 2014

    Steve Kemp

    An alternative to devilspie/devilspie2

    Recently I was updating my dotfiles, because I wanted to ensure that media-players were "always on top", when launched, as this suits the way I work.

    For many years I've used devilspie to script the placement of new windows, and once I googled a recipe I managed to achieve my aim.

    However during the course of my googling I discovered that devilspie is unmaintained, and has been replaced by something using Lua - something I like.

    I'm surprised I hadn't realized that the project was dead, although I've always hated the configuration syntax it is something that I've used on a constant basis since I found it.

    Unfortunately the replacement, despite using Lua, and despite being functional just didn't seem to gell with me. So I figured "How hard could it be?".

    In the past I've written softare which iterated over all (visible) windows, and obviously I'm no stranger to writing Lua bindings.

    However I did run into a snag. My initial implementation did two things:

    • Find all windows.
    • For each window invoke a lua script-file.

    This worked. This worked well. This worked too well.

    The problem I ran into was that if I wrote something like "Move window 'emacs' to desktop 2" that action would be applied, over and over again. So if I launched emacs, and then manually moved the window to desktop3 it would jump back!

    In short I needed to add a "stop()" function, which would cause further actions against a given window to cease. (By keeping a linked list of windows-to-ignore, and avoiding processing them.)

    The code did work, but it felt wrong to have an ever-growing linked-list of processed windows. So I figured I'd look at the alternative - the original devilspie used libwnck to operate. That library allows you to nominate a callback to be executed every time a new window is created.

    If you apply your magic only on a window-create event - well you don't need to bother caching prior-windows.

    So in conclusion :

    I think my code is better than devilspie2 because it is smaller, simpler, and does things more neatly - for example instead of a function to get geometry and another to set it, I use one. (e.g. "xy()" returns the position of a window, but xy(3,3) sets it.).

    kpie also allows you to run as a one-off job, and using the simple primitives I wrote a file to dump your windows, and their size/placement, which looks like this:

    shelob ~/git/kpie $ ./kpie --single ./samples/dump.lua
    -- Screen width : 1920
    -- Screen height: 1080
    if ( ( window_title() == "Buddy List" ) and
         ( window_class() == "Pidgin" ) and
         ( window_application() == "Pidgin" ) ) then
         xy(1536,24 )
         size(384,1032 )
    if ( ( window_title() == "feeds" ) and
         ( window_class() == "Pidgin" ) and
         ( window_application() == "Pidgin" ) ) then
         xy(1,24 )
         size(1536,1032 )

    As you can see that has dumped all my windows, along with their current state. This allows a simple starting-point - Configure your windows the way you want them, then dump them to a script file. Re-run that script file and your windows will be set back the way they were! (Obviously there might be tweaks required.)

    I used that starting-point to define a simple recipe for configuring pidgin, which is more flexible than what I ever had with pidgin, and suits my tastes.

    Bug-reports welcome.

    July 21, 2014 02:30 PM

    July 19, 2014

    Steve Kemp

    Did you know xine will download and execute scripts?

    Today I was poking around the source of Xine, the well-known media player. During the course of this poking I spotted that Xine has skin support - something I've been blissfully ignorant of for many years.

    How do these skins work? You bring up the skin-browser, by default this is achieved by pressing "Ctrl-d". The browser will show you previews of the skins available, and allow you to install them.

    How does Xine know what skins are available? It downloads the contents of:

    NOTE: This is an insecure URL.

    The downloaded file is a simple XML thing, containing references to both preview-images and download locations.

    For example the theme "Sunset" has the following details:

    • Download link:
    • Preview link:

    if you choose to install the skin the Sunset.tar.gz file is downloaded, via HTTP, extracted, and the shell-script is executed, if present.

    So if you control DNS on your LAN you can execute arbitrary commands if you persuade a victim to download your "corporate xine theme".

    Probably a low-risk attack, but still a surprise.

    July 19, 2014 08:48 PM

    Martin Wimpress

    Monitorix on Debian

    I have a few Debian servers that run at home and on VPSs. I wanted to add some basic systems monitoring to them, but didn't want anything too complicated to look after. I found Monitorix.

    Monitorix is a free, open source, lightweight system monitoring tool designed to monitor as many services and system resources as possible. It has been created to be used under production Linux/UNIX servers, but due to its simplicity and small size can be used on embedded devices as well.

    Install Monitorix

    This install has been tested on Debian Squeeze and Wheezy. First install the dependencies.

    sudo apt-get install rrdtool perl libwww-perl libmailtools-perl \
    libmime-lite-perl librrds-perl libdbi-perl libxml-simple-perl \
    libhttp-server-simple-perl libconfig-general-perl libio-socket-ssl-perl

    Now Monitorix itself.

    wget -c "" -O monitorix_3.5.1-izzy1_all.deb
    sudo dpkg -i monitorix_3.5.1-izzy1_all.deb

    At this point Monitorix is installed and running. Point your browser to and enjoy!

    Configuring Monitorix

    Everything in /etc/monitorix/monitorix.conf is comprehensively documented, just get tweaking.

    Each time you update the configuration Monitorix will require a restart.

    sudo service monitorix restart

    nginx status

    If you run nginx then you'll want to drop the following into /etc/nginx/conf.d/status.conf so that Monitorix can monitor nginx.

    server {
        listen localhost:80;
        location /nginx_status {
            stub_status on;
            access_log off;
            deny all;

    by Martin Wimpress at July 19, 2014 11:00 AM

    Adam Trickett

    July 18, 2014

    Adam Trickett

    July 17, 2014

    Adam Trickett

    July 16, 2014

    Steve Kemp

    So what can I do for Debian?

    So I recently announced my intention to rejoin the Debian project, having been a member between 2002 & 2011 (inclusive).

    In the past I resigned mostly due to lack of time, and what has changed is that these days I have more free time - primarily because my wife works in accident & emergency and has "funny shifts". This means we spend many days and evenings together, then she might work 8pm-8am for three nights in a row, which then becomes Steve-time, and can involve lots of time browsing reddit, coding obsessively, and watching bad TV (currently watching "Lost Girl". Shades of Buffy/Blood Ties/similar. Not bad, but not great.)

    My NM-progress can be tracked here, and once accepted I have a plan for my activities:

    • I will minimally audit every single package running upon any of my personal systems.
    • I will audit as many of the ITP-packages I can manage.
    • I may, or may not, actually package software.

    I believe this will be useful, even though there will be limits - I've no patience for PHP and will just ignore it, along with its ecosystem, for example.

    As progress today I reported #754899 / CVE-2014-4978 against Rawstudio, and discussed some issues with ITP: tiptop (the program seems semi-expected to be installed setuid(0), but if it is then it will allow arbitrary files to be truncated/overwritten via "tiptop -W /path/to/file"

    (ObRandom still waiting for a CVE identifier for #749846/TS-2867..)

    And now sleep.

    July 16, 2014 08:49 PM