Planet HantsLUG

Syndicate content
Planet HantsLUG -
Updated: 15 min 41 sec ago

Adam Trickett: Bog Roll: Using Less

Sat, 16/08/2014 - 11:36

Since we moved into our current house we have continually aimed to reduce our gas and electricity use year on year. We started with a number of behaviour changes relative to the previous owners - which saved 50% on gas an electricity on the first year. Since then we have gradually replaced old/worn out/inefficient things with modern/highest efficiency replacements/alternatives and significantly improved the insulation in the loft space and under the ground floor.

Year kWh Total Electricity Gas kWh·m-2 2009 5 000 22 000 233 2010 3 000 19 000 188 2011 2 675 13 945 137.4 2012 3 526 9 606 108.5 2013 2 391 9 402 97.5 2014 1 295 3 749 41.7

The 2009 and 2010 years are estimated and 2010 contains both our and the previous owners usage. 2014 contains only 61% of the year, so isn't comparable yet. I could also do with a scaling factor for the weather as some winters are radically different from others and that makes a big difference to the winter gas figure.

Even though the 2009 figure is an esitmate it's still only about two thirds the EPC survey the house came with when we bought it of E/48 - 314 kWh·m-2, and we're already loads better the best estimate of D/55 - 275 kWh·m-2.

Categories: LUG Community Blogs

Debian Bits: Debian turns 21!

Sat, 16/08/2014 - 09:45

Today is Debian's 21st anniversary. Plenty of cities are celebrating Debian Day. If you are not close to any of those cities, there's still time for you to organize a little celebration!

Happy 21st birthday Debian!

Categories: LUG Community Blogs

Steve Kemp: A tale of two products

Fri, 15/08/2014 - 12:14

This is a random post inspired by recent purchases. Some things we buy are practical, others are a little arbitrary.

I tend to avoid buying things for the sake of it, and have explicitly started decluttering our house over the past few years. That said sometimes things just seem sufficiently "cool" that they get bought without too much thought.

This entry is about two things.

A couple of years ago my bathroom was ripped apart and refitted. Gone was the old and nasty room, and in its place was a glorious space. There was only one downside to the new bathroom - you turn on the light and the fan comes on too.

When your wife works funny shifts at the hospital you can find that the (quiet) fan sounds very loud in the middle of the night and wakes you up..

So I figured we could buy a couple of LED lights and scatter them around the place - when it is dark the movement sensors turn on the lights.

These things are amazing. We have one sat on a shelf, one velcroed to the bottom of the sink, and one on the floor, just hidden underneath the toilet.

Due to the shiny-white walls of the room they're all you need in the dark.

By contrast my second purchase was a mistake - The Logitech Harmony 650 Universal Remote Control should be great. It clearly has the features I want - Able to power:

  • Our TV.
  • Our Sky-box.
  • OUr DVD player.

The problem is solely due to the horrific software. You program the device via an application/website which works only under Windows.

I had to resort to installing Windows in a virtual machine to make it run:

# Get the Bus/ID for the USB device bus=$(lsusb |grep -i Harmony | awk '{print $2}' | tr -d 0) id=$(lsusb |grep -i Harmony | awk '{print $4}' | tr -d 0:) # pass to kvm kvm -localtime .. -usb -device usb-host,hostbus=$bus,hostaddr=$id ..

That allows the device to be passed through to windows, though you'll later have to jump onto the Qemu console to re-add the device as the software disconnects and reconnects it at random times, and the bus changes. Sigh.

I guess I can pretend it works, and has cut down on the number of remotes sat on our table, but .. The overwhelmingly negative setup and configuration process has really soured me on it.

There is a linux application which will take a configuration file and squirt it onto the device, when attached via a USB cable. This software, which I found during research prior to buying it, is useful but not as much as I'd expected. Why? Well the software lets you upload the config file, but to get a config file you must fully complete the setup on Windows. It is impossible to configure/use this device solely using GNU/Linux.

(Apparently there is MacOS software too, I don't use macs. *shrugs*)

In conclusion - Motion-activated LED lights, more useful than expected, but Harmony causes Discord.

Categories: LUG Community Blogs

Martin Wimpress: Installing Willie IRC Bot on Debian

Sat, 09/08/2014 - 10:11

Willie is an IRC bot written in Python that I've recently started using. This blog post describes how to install Willie on Debian and as usual I will be using virtualenv to isolate this Python application from the rest of the system.

Installing Python

First you'll need Python.

sudo apt-get install libpython2.7 python2.7 python2.7-dev python2.7-minimal

The following will also be required to enable all the features Willie supports.

sudo apt-get install enchant python2.7-dev libxslt1-dev libxml2-dev

Remove any apt installed Python packages that we are about to replace. The versions of these packages in the Debian repositories soon get stale.

sudo apt-get purge python-setuptools python-virtualenv python-pip python-profiler

Install pip.

wget sudo python2.7

Use pip to install virtualenv.

sudo pip install virtualenv --upgrade The Snakepit

Create a "Snakepit" directory for storing all the Python virtual environments.

mkdir ~/Snakepit Create a virtualenv for Willie

The following will create a new virtualenv called willie using Python 2.7 as the interpreter.

virtualenv -p /usr/bin/python2.7 ~/Snakepit/willie Working on a virtualenv

Activate the virtualenv for Willie.

source ~/Snakepit/willie/bin/activate

Your shell prompt will change, something like (willie)user@host:~$, while a virtualenv is being worked on to indicate which virtualenv is currently active.

While working on a virtualenv you can pip install what you need or manually install any Python libraries safe in the knowledge you will not upset any other virtualenvs or the global packages in the process. Very useful for developing a new branch which may have different library requirements than the current stable release.

When you are finished working in a virtualenv you can deactivate it by simply executing deactivate.

Install Willie

I've decided to use Python 2.7 to run Willie and therefore have to install backports.ssl_match_hostname which is not required if you use Python 3.3.

pip install willie backports.ssl_match_hostname Additional functionality

Willie has no external dependencies, besides Python. However, some of the modules do have external dependencies. So install the following Python modules so that I can make use of everything Willie can do.

pip install feedparser pytz lxml praw pyenchant pygeoip ipython --upgrade Configure Willie

I am not going to explain to how to configure Willie because all that good stuff is very well documented by the project.

But for reference, my default.cfg looks something like this:

[core] nick = nicofyourbot user = nicofyourbot name = Give You Bot A Name host = use_ssl = true verify_ssl = true port = 6697 owner = nicofthebotowner channels = #example nickserv_password = ************ prefix = \. timeout = 120 [db] userdb_type = sqlite userdb_file = /home/username/.willie/willie.db Willie as a daemon

From this point on I assume you've completed the first run configuration of Willie and have .willie/default.cfg in your home directory.

Add the following to /etc/init.d/willie.

#!/bin/sh ### BEGIN INIT INFO # Provides: willie # Required-Start: $local_fs $remote_fs # Required-Stop: $local_fs $remote_fs # Should-Start: $network # Should-Stop: $network # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Willie IRC Bot. # Description: Start and stops the Willie IRC bot for a given user. ### END INIT INFO # NOTE! Replace with the user you want to run Willie. willie_USER="yourusername" HOMEDIR=$(getent passwd $willie_USER | awk -F: '{print $6}') DAEMON="$HOMEDIR/Snakepit/willie/bin/willie" CONFIG="$HOMEDIR/.willie/default.cfg" startd() { if [ -f ${CONFIG} ]; then echo "Starting Willie for $willie_USER" start-stop-daemon -c $willie_USER -u $willie_USER -x $DAEMON -S -- --config ${CONFIG} --fork --quiet else echo "Couldn't start Willie for $willie_USER (no $CONFIG found)" fi } stopd() { echo "Stopping Willie for $willie_USER" willie_PID=$(pgrep -fu $willie_USER $DAEMON) if [ -z "$willie_PID" ]; then echo "Willie for USER $willie_USER: not running." else kill -15 $willie_PID fi } status() { willie_PID=$(pgrep -fu $willie_USER $DAEMON) if [ -z "$willie_PID" ]; then echo "Willie for USER $willie_USER: not running." else echo "Willie for USER $willie_USER: running (pid $willie_PID)" fi } case "$1" in start) startd ;; stop) stopd ;; restart|reload|force-reload) stopd && startd ;; status) status ;; *) echo "Usage: /etc/init.d/willie {start|stop|reload|force-reload|restart|status}" exit 1 ;; esac exit 0

Set the permissions.

sudo chmod +x /etc/init.d/willie

Check that you can start/stop Willie.

sudo /etc/init.d/willie start sudo /etc/init.d/willie status sudo /etc/init.d/willie stop

Add willie to the startup/shutdown sequence.

sudo update-rc.d willie defaults

And that's it. Willie is now running as a daemon inside a virtualenv.

Categories: LUG Community Blogs

Steve Kemp: Rebooting the CMS

Sat, 09/08/2014 - 08:59

I run a cluster for the Debian Administration website, and the code is starting to show its age. Unfortunately the code is not so modern, and has evolved a lot of baggage.

Given the relatively clean separation between the logical components I'm interested in trying something new. In brief the current codebase allows:

  • Posting of articles, blog-entries, and polls.
  • The manipulation of the same.
  • User-account management.

It crossed my mind the other night that it might make sense to break this code down into a number of mini-servers - a server to handle all article-related things, a server to handle all poll-related things, etc.

If we have a JSON endpoint that will allow:

  • GET /article/32
  • POST /article/ [create]
  • GET /articles/offset/number [get the most recent]

Then we could have a very thin shim/server on top of that whihc would present the public API. Of course the internal HTTP overhead might make this unworkable, but it is an interesting approach to the problem, and would allow the backend storage to be migrated in the future without too much difficulty.

At the moment I've coded up two trivial servers, one for getting user-data (to allow login requests to succeed), and one for getting article data.

There is a tiny presentation server written to use those back-end servers and it seems like an approach that might work. Of course deployment might be a pain..

It is still an experiment rather than a plan, but it could work out:

Categories: LUG Community Blogs