To be completely honest, the internet scares me. Or better, the amount of scary stuff that is on it, scares me. So now that my son is old enough to have his own PC in his bedroom, I looked around to see what was available to make sure that he doesn’t get exposed to material that is well above his age. They grow up quick enough anyway.

Now as someone who runs Ubuntu on his server, and OS X on his MacBook, I am already one step ahead of most parents, who have to deal with a Microsoft Windows environment of some sort. Good luck to you. This blog post depends on a Linux server of some sort, and although the client can be any operating system, I strongly advice you to stick to a *nix based desktop.

After dismissing most options available (things like OpenDNS, and a variety of dedicated applications to block any harmful content), I decided that however I was going to implement it, it would have to be by using a whitelist, rather than the normal practice of a blacklist. The reasoning behind this is that the amount of harmful content changes every minute, and no amount of blacklisting will catch 100% of it. With a whitelist, everything has to be vetted by me, but it ensures total control over their web experience. I also wanted to be able to approve/deny new websites as my son requests them, with little effort required on my side.

Something that sits between the client and the internet would be the perfect solution, and I quickly stumbled upon TinyProxy. As the name implies, the application is small, efficient, easy to manage and it supports blacklisting and whitelisting. Perfect.

• A server running your favourite Linux distribution. I personally use Ubuntu, but for the purpose of this guide, it doesn’t matter.
• TinyProxy as installed by your favourite package manager. For Ubuntu that’s as easy as apt-get install tinyproxy, but obviously that will be different if you run something else. Make a note of the version number of TinyProxy though, as we’ll need version 1.6.5 or later.
• A webserver running on your server. Apache2 is what I use, but as long as it supports PHP, then it doesn’t matter. What does matter though, is that the webserver should be able to access your TinyProxy whitelist file, which if you have both TinyProxy and the webserver running on the same server will be the case.
• A client configured to use TinyProxy. This can be Firefox, Internet Explorer, Chrome, Opera, or any other browser you like to use. Be aware though that as soon as your child learns what a proxy is and how to remove it from his PC/laptop, the whole plan falls apart.

Before you continue with the next section, make sure that your webserver is able to serve some pages, and that you have confirmed that TinyProxy is working correctly for you.

Installation

Grab the tinyproxy-admin.tar.gz package and unpack it somewhere on your server. There are a number of files in there, each of them I will describe below.

tinyproxy.32
tinyproxy.64 – These two binaries are the 1.6.5 binary patched with a small change to allow TinyProxy’s child processes to refresh their filter list when the parent receives a SIGHUP signal and when the whitelist file is changed. These changes have also been submitted to the development version of TinyProxy, but because apt-get on my Ubuntu system installs 1.6.5, I have used that code base. Eventually these patches will appear in the Ubuntu package manager, but until then, these will do. The extension indicates whether the binary is for 32-bit, or 64-bit *nix.

tinyproxy – This is the TinyProxy start file (usually found in /etc/init.d), which contains a couple of changed lines. The permission on the tinyproxy.log files is by default set to restrictive. It needs to be read by the webserver’s user, which means that setting it to 644 everytime we start TinyProxy is required.

The files below need to be put in your TinyProxy configuration directory, usually /etc/tinyproxy.

tinyproxy.conf – This contains only the required changes to your distribution’s version. The ErrorFile, PidFile and Filter locations need to match your installation, and to switch from blacklisting to whitelisting, the FilterDefaultDeny parameter needs to be set to Yes.

whitelist – This contains just a single line; localhost. You need to whitelist the domain that your webserver runs on, otherwise it won’t work. If your local webserver can be reached through a proper domain name, then change localhost to that instead.

403.html – This is the file referred to by the ErrorFile directive in the tinyproxy.conf file. It contains two variables which need to be changed to match your system.

The following files are part of the administration interface and will need to be put in a directory that can be served by your local webserver. For instance, if your webserver uses /var/www as the root directory, put these in a new directory called /var/www/tinyproxy. The pages should then be able to be accessible by navigating to the http://your.webserver.domain/tinyproxy url.

config.php – This is the configuration for the administration interface. Make sure that the variables match your configuration, and if you want it to notify you by Twitter each time a new domain approval request is made, enter your details in there too.

style.css
filter.html
admin.html
filter.php
img (dir) – These are the remaining files which do not require any modification.

How it all works

Whenever a client is requesting a webpage from a domain, the request is done through TinyProxy. If it finds a line in the whitelist file for the domain, it lets the request pass through, but if it doesn’t, an error 403 occurs (Forbidden) and the 403.html page is served to the client. The included 403.html file calls the filter.html file internally and passes it the website that the client is trying to access.

When the request is made, the domain gets added to the whitelist file, but with a prefix of M|, therefore still not matching a proper whitelisted domain name. And it is this mechanism which allows me to approve or deny domains whilst keeping the whitelists all in one place. The admin interface simply drops the M| prefix if the domain gets approved, or changes it to D| if it remains denied. Easy peasy :o)

• Install TinyProxy using package manager
• Install webserver
• Confirm the above are working
• Download tinyproxy-admin.tar.gz
• Amend config.php
• Move config.php, style.css, filter.html, admin.html, filter.php and the img directory to a subdirectory beneath your webserver
• Amend TinyProxy startup script: tinyproxy
• Amend TinyProxy configuration file: tinyproxy.conf
• Amend whitelist and move it to the TinyProxy configuration directory
• Amend 403.html and move it to the TinyProxy configuration directory
• Replace tinyproxy binary with patched version
• Restart TinyProxy
• Breath out ;o)

So here it is, the third (and hopefully last) instalment: The Eee PC Digital Picture Frame aka The Eee PF.

I’ve divided it up in four sections, for easy digesting ;) All pictures can be enlarged, and the complete set of pictures can be found in the gallery.

Part 1: Disassembling the Eee PC
Part 2: Mounting the LCD
Part 3: Building the frame
Part 4: Finishing touches

It starts off with an Asus Eee PC 701 2G, which is perfectly small, yet cheap enough to destroy in the name of science.

Push the three tabs at the top of the keyboard in and lift the keyboard up to reveal the keyboard connector at the bottom of the keyboard. Using a small flat screwdriver, push the two locks open and remove the keyboard completely. Next to the keyboard connector is the touchpad connector which should be disconnected as well.

With the keyboard removed, the bottom half of the case is next. Remove the nine screws as indicated in the pictures. Turn the Eee PC over and remove the six remaining screws. For good measure, also remove the battery by sliding the two latches outwards, and slide the battery out. Flip the Mini over again and open the lid again. Using a plastic wedge (or your finger nails if you have them), pry the case open using some gentle force along the sides. Be patient at this point as the plastic latches inside the case, are fragile and will snap if you exercise too much force.

Now we just need to remove the motherboard. Disconnect the speaker and display connectors. There are two latches holding it in place, located at the bottom edge of the PCB. Lift the motherboard up at the right hand side and then pull it out up and sideways.

Time to separate the LCD from the bezel. Six screws are hidden underneath the plastic covers which are stickied in place. Use a plastic wedge along the side of the bezel but be very careful, it is very fragile. Take your time and be gentle. Just four screws and four sticky metal tape strips to remove before you can lift the LCD clean out.

Voilà, the Eee PC naked! Now we are ready for some serious modding ;)

Part 2: Mounting the LCD

Whatever you do, make sure you buy a frame and mount which have a high WAF since it needs to live in the living room. You don’t want to find yourself building something like this and then SWMBO tossing it in the bin because is clashes with the design ;) Take the mount and measure the dimensions of the LCD and frame and carefully cut it to size. As usual; measure twice, cut once :)

The LCD driver board sits neatly underneath the LCD, but when you mount the display into the frame, it doesn’t fit. Cutting away a bit of the frame allows it to be sunken into it and sit flush with the frame. Some double sided tape holds the mount in place.

On to the motherboard. This needs to be mounted with enough clearance above the LCD so that heat can escape and to do this I made my own spacers using normal motherboard spacers which I had plenty of from my PC building days. The screw holes on the Eee PC are tiny, so cut away at the top of the spacers to make them small enough to fit. Looks rather neat, eh?

Part 3: Building the frame

Before we create the frame, we need to think about an alternative heat sink. Normally, the bottom of the keyboard would dissipate the heat, so after doing some testing, I settled on an Akasa Southbridge cooler and some tiny Maplin heat sinks. Tests showed that the temps remained nicely around the 50ºC mark, which will rise to about 65ºC once the back cover will be on. Well within the limits :)

Using some 4mm Pine Stripwood cut to length, mark out all the ports and crevices that need to be carefully removed from the frame to allow access once everything is closed up again.

Here’s a quick mock up of how it all will fit together once we’ve painted the frame and glued it to the photo frame’s back.

Because the power switch would be covered up when the back is glued on, we need to move the switch’s function to somewhere more convenient. Reading this blog post over at Infinity Squared on an external power switch, I decided to go for the smallest I could find at Maplin. My soldering is definitely not the best, so a bit of heat shrink camouflages most of it ;)

I also wanted to have some sort of visual indication that the frame is on or off (other than the tell-tale display ;)). But how to get the minuscule surface mounted LEDs displayed through the frame? I had seen something previously, where light was transported using a small transparent acrylic tube. And when I was killing some time wandering around my local Tesco, I found my 48p answer… translucent golf markers! Remove the heads, drill a few holes and Bob is a relative.

Almost there. Using some left over black paint, paint all the sides and make sure that once assembled, all the small blemishes are hidden. Well, most of them ;)

Ready for assembly! Some glue, some patience and some skilful balancing of weighty items on top of the corners and all that is left to do is add the back cover.

Part 4: Finishing touches

A sheet of hardboard has been cut to be the approximate size and then using patience and lots of sanding made to fit exactly. The space at the bottom of the frame is perfect for the speakers, so using a small drill, create lots of small holes where the sound can penetrate through. It won’t be high fidelity, but it’s good enough for announcements. At the top of the frame, the microphone has been mounted, so we may be able to support voice commands in the future! A quick lick of paint finishes it off.

We’re re-using the stand from the picture frame, but instead of hammering it in the backboard, we have to glue it. I’ve used Araldite, which should create a long lasting strong bond.

And that is it! I’m quite pleased with the result, and even SWMBO commented on how nicely it looks in the living room… result!

As a final note, I haven’t mentioned at all what software the frame is running, so before you bombard me with questions, I better list them here ;)

#!/usr/bin/perl
# /usr/local/bin/cc-classic.pl
 
use Device::SerialPort qw( :PARAM :STAT 0.07 );
 
$port = "/dev/currentcost";
 
$ob = Device::SerialPort->new($port)
      or die "Can not open port $port\n";
$ob->baudrate(9600);
$ob->write_settings;
$ob->close;
 
open(SERIAL, "+>$port");
while ($line = <SERIAL>)
{
  if ($line =~ m!<ch1><watts>0*(\d+)</watts></ch1>.*<tmpr>\s*(-*[\d.]+)</tmpr>!)
  {
     $watts = $1;
     $temperature = $2;
     print "watts:$watts temp:$temperature";
     last;
  }
}
close(SERIAL);

This would give me the two values I am interested in; watts and temperature (since it sits in the garage node 0 ;)) in Cacti’s format:

$ /usr/local/bin/cc-classic.pl
watts:761 temp:11.3

But today, I received my new unit, a Current Cost CC128. It’s main benefit is that it supports individual appliance monitors, which makes the output even more useful. So, armed with a draft copy of the CC128 XML output document, I prepared my script to read as follows:

#!/usr/bin/perl
# /usr/local/bin/cc-cc128.pl
 
use Device::SerialPort qw( :PARAM :STAT 0.07 );
 
$port = "/dev/currentcost";
 
$ob = Device::SerialPort->new($port)
      or die "Can not open port $port\n";
$ob->baudrate(57600);
$ob->write_settings;
$ob->close;
 
open(SERIAL, "+>$port");
while ($line = <SERIAL>)
{
  if ($line =~ m!<tmpr>\s*(-*[\d.]+)</tmpr>.*<ch1><watts>0*(\d+)</watts></ch1>!)
  {
     $watts = $2;
     $temperature = $1;
     print "watts:$watts temp:$temperature";
     last;
  }
}
close(SERIAL);

And guess what… that works just fine ;)

For those who read diff:

$ diff /usr/local/bin/cc-classic.pl /usr/local/bin/cc-cc128.pl 
2c2
< # /usr/local/bin/cc-classic.pl
---
> # /usr/local/bin/cc-cc128.pl
10c10
< $ob->baudrate(9600);
---
> $ob->baudrate(57600);
17c17
<   if ($line =~ m!<ch1><watts>0*(\d+)</watts></ch1>.*<tmpr>\s*(-*[\d.]+)</tmpr>!)
---
>   if ($line =~ m!<tmpr>\s*(-*[\d.]+)</tmpr>.*<ch1><watts>0*(\d+)</watts></ch1>!)
19,20c19,20
<      $watts = $1;
<      $temperature = $2;
---
>      $watts = $2;
>      $temperature = $1;

Please note, the above only works with 1 sensor (the main transmitter), so it is likely to change in the future. For now it suits my need.

So I investigated writing some udev rules for them, but unfortunately, the PL2303′s are completely identical to the server, except that their position on the USB host would change. And although I tried to find out a consistent way of determining the correct udev rule, I miserably failed. The only way I was able to find out which device was which, was to issue a

$ cat /dev/ttyUSB0

and waiting if some output would appear on the terminal. The Current Cost unit spits out its data every 6 seconds, so if something showed up, that would be the right one to pick for the cacti data source. The UPS would not show anything at all using the above command.

Reading a bit further on udev rules I noticed that you can also use external programs to name devices. This got me thinking. I would need a small program that would listen on the /dev/ttyUSB* node and timeout if nothing was received within a reasonable time.

Let’s start off with the udev rule that invokes the script:

# /etc/udev/rules.d/60-local.rules
# Determine APC UPS and Current Cost USB ports
KERNEL=="ttyUSB*", \
    ATTRS{idVendor}=="067b", ATTRS{idProduct}=="2303", \
    PROGRAM="/usr/local/bin/usb-dev-test.pl %k", \
    SYMLINK+="%c"

The %k parameter will be ttyUSB0, ttyUSB1, etc, and the script usb-dev-test.pl should output a single word, which will be substituted by udev in the %c parameter. With the help of Device::SerialPort it becomes trivial ;)

#!/usr/bin/perl
# /usr/local/bin/usb-dev-test.pl
 
use Device::SerialPort qw( :PARAM :STAT 0.07 );
 
my $argument = $ARGV[$0];
my $port=Device::SerialPort->new("/dev/$argument");
my $STALL_DEFAULT=8; # how many seconds to wait for new input
my $timeout=$STALL_DEFAULT;
 
$port->read_char_time(0);     # don't wait for each character
$port->read_const_time(1000); # 1 second per unfulfilled "read" call
 
my $chars=0;
my $buffer="";
while ($timeout>0) {
  my ($count,$saw)=$port->read(255); # will read _up to_ 255 chars
  if ($count > 0) {
    $chars+=$count;
    $buffer.=$saw;
 
    # Check here to see if what we want is in the $buffer
    # say "last" if we find it
    last;
  }
  else {
    $timeout--;
  }
}
 
if ($timeout==0) {
  print "apcups";
}
else {
  print "currentcost";
}

And look at the result… Magic!

$ ls -la /dev/ttyUSB* /dev/currentcost /dev/apcups
lrwxrwxrwx 1 root root         7 Jan 26 13:10 /dev/apcups -> ttyUSB0
lrwxrwxrwx 1 root root         7 Jan 26 13:10 /dev/currentcost -> ttyUSB1
crw-rw-rw- 1 root dialout 188, 0 Jan 26 14:09 /dev/ttyUSB0
crw-rw-rw- 1 root dialout 188, 1 Jan 26 11:54 /dev/ttyUSB1

Anyway, here’s the compulsory screen shot and configuration files.

Take the zip file and unzip it in your home directory. It should create a directory ~/conky, which contains three files:

startconky.sh – script to start Conky after a 20 second delay to alllow the Compiz window manager to finish its stuff, before Conky puts its pseudo transparent window on top of it.
myip.sh – script to retrieve your public IP address.
main – the Conky configuration file.

Add the startconky.sh script to your Startup Programs (System->Preferences->Sessions) and the next time you boot… Conky goodness! ;)

Update 23.8.2007

Still no sign of that promised 2nd refund… A polite email is already heading their way :)

Update 4.9.2007

Finally! This morning (after chasing this for the past month) the 2nd £11.75 arrived on my credit card. About time too!

Hi,

I’ve just taken delivery of my Dimension C521 which came with a copy of the Microsoft Vista Basic operating system. As I will be using the Ubuntu linux operating system, I have not agreed to the Microsoft EULA and installed Ubuntu linux on the PC. Could you please forward me an address where I can send the Microsoft Vista Basic operating system CD to for a refund? Please note, I am not looking to return my PC, just the accompanying Microsoft operating system.

I hit the Submit button and the website told me to expect a reply within 24 hours…

So imagine my surprise that I received a reply within 4 hours from Dell:

Thank you for contacting Dell on-line customer care.

Please be informed that you need not return the CD and I will arrange for the refund of £10, which is the cost of the CD.

I will call you on 27th July with an update regarding the same. If you have any further queries do not hesitate in responding directly to this mail and I will be glad to assist you further.

Woohoo! Result!

Of course, by now I had realised that I had forgotten to mention the Microsoft Works 8.5 CD that came with the order, so I replied with:

Thank you very much for the quick reply. Is it also possible to receive a refund for the Microsoft Works 8.5 CD that came with my PC? Again, I am quite happy to return the CD unopened to you if you forward me an address to send it to.

Nothing ventured, nothing gained ;)

Sure enough, within 30 minutes another reply arrived:

Further to your email, Iam also arranging for the refund of £10 for the works CD. I will call you on 27th with an update regarding the refund.

Please be informed that you need not return the CD. If you have any further queries do not hesitate in responding directly to this mail and I will be glad to assist you further.