Getting started with google app engine and bottle.py

Always late to to the party - I decided to give google app engine a go using my favorite language python.

Anyway here is how I got started.

1. Go to https://console.developers.google.com/start/appengine
2. Should prompt you for a google username password
3. Click 'Try it now'
4. Choose a project name - choose python, bottle, click 'Download your code'
5. Go to https://console.developers.google.com/
6. Create a new project and choose a useful project id - PROJECTID
7. open a terminal and follow the prompts to install : 'curl sdk.cloud.google.com | bash'
8. restart terminal or just run '. .bashrc' to get the changes 
9. sign into google cloud using: 'gcloud auth login'
10. run 'gcloud components update app' to install additional tools.
11. extract the preview code into a directory called PROJECTID
12. run 'gcloud config set project PROJECTID'
13. run 'gcloud preview app run PROJECTID' to run a local copy of the instance
14. run 'gcloud preview app deploy PROJECTID' to push it onto the server.
15. you should be able to access the deployment under http://PROJECTID.appspot.com

Next step write some code that uses the ndb to store things.

Setting up our printers

1. Open http://localhost:631/admin
2. Click 'Manager Printers' to see what printers are installed.
3. If the printer is not installed go back and choose 'Add Printer'
4. Choose 'Internet Printing Protocol (http)'
5. Type in 'socket://192.168.2.5:9100'
6. Choose a name (I use LaserJet4L), then next
7. Then select Make 'HP', continue.
8. Select Model 'HP Laserjet 4L Fommatic/ljet4 (recommended) (en)
9. Click Add Printer.
10. Job Done!

Launch vino-server via ssh

Sometimes I want to log onto a computer but don't like the idea of leaving vino-server running all the time. To launch vino-server from remote server you need to do the following:

export DISPLAY=:0.0
/usr/lib/vino/vino-server &


You may need to ssh -X onto the computer first and launch vino-preferences to make sure the settings are correct.

Fun fun!

Update to the fancontrol script

One final annoyance when starting up the qnap was that my /etc/rc.local never finished and so the led at the front of the box would never settle down to all green.

Now that I am happy with the scripts I thought I would make them into a daemons. A quick google led to Tony's Cafe blog who described beautifully how to create a debian script for the fancontrol. So I modified his instructions slightly:

Copy /etc/init.d/skeleton to /etc/init.d/fancontrol

Edit /etc/init.d/fancontrol

Change:

NAME=fancontrol
DAEMON=/usr/local/sbin/$NAME
DAEMON_ARGS=""

All seemed to be fine except that when I ran /etc/init.d/fancontrol the script would just hang... A bit more googling made me realise that I was no longer running '/usr/local/sbin/fancontrol &' I was running it without the & flag. A quick modification to the start of my fancontol script to have this at the top (take from linuxquestions) :

if [ "x$1" != "x--" ]; then
$0 -- 1> /dev/null 2> /dev/null &
exit 0 fi

Dell Studio 1558 fan problems

So we have a dell studio 1558. It's a beast of a laptop, quad core, radeon hd 5400, and in windows land can play quite a few games at a respectable fps.

Now therein lies the problem - this is one hell of a power hungry laptop

The Debian install has been a bit of a nightmare: the fan was on all the time, frequent hard lockups especially when on battery power and add to that the flaky broadcom wifi drivers. It has been an interesting year with this beast.

The only stable configuration seemed to be to run the laptop with the closed source fglrx and leave the laptop plugged into the wall. Anything else was tempting fate.

Recently kernel 2.6.39 hitting testing I though I would try the open source radeon KMS drivers. Last time there was no power control so the gpu was running hot so the fan was always flat out. Installing the flgrx drivers fixed the overheating problem, but the laptop was still quite flakey.

I uninstalled the fglrx drivers and enabled KMS by changing /ect/modprobe.d/radeon-kms.conf to:
options radeon modeset=1


I rebooted and once again got the dreaded maxed out fan. This time I knew it was most probably the kernel running the gpu at maximum speed. A quick look at the following (mount -t debugfs debugfs /sys/kernel/debug/,cat /sys/kernel/debug/dri/0/radeon_pm_info) showed:

default engine clock: 750000 kHz
current engine clock: 750000 kHz
default memory clock: 800000 kHz
current memory clock: 800000 kHz
voltage: 900 mV
PCIE lanes: 16

The gpu was running flat out. A quick google later gave me the following commands to stick into my rc.local:

echo profile > /sys/class/drm/card0/device/power_method
echo low > /sys/class/drm/card0/device/power_profile

Now cat /sys/kernel/debug/dri/0/radeon_pm_info gives:

default engine clock: 750000 kHz
current engine clock: 156990 kHz
default memory clock: 800000 kHz
current memory clock: 199960 kHz
voltage: 900 mV
PCIE lanes: 16

Now the computer seems to be running a lot cooler - I have yet to get it to crash on battery power and if I do have any problems I will hopefully get some help. I did a quick test with fullscreen flash video and there was no significant screen fps problems to hopefully the majority of our problems with this machine are over.

I'm going to do a bit more googling to see if I can reduce the number of PCIE lanes or even the voltage but for the time being at least I have a useable laptop.

The only unsolvable problem seems to be if I try and change the brightness too quickly I get a total crash....

Replacing a hard drive on my QNAP debian install

My replacement drive arrived - time to add it to the existing raid. From my exisiting hard drive I get the following output:

Partition Table: gpt
Number  Start   End     Size    File system  Name  Flags
 1      17.4kB  3000MB  3000MB               Root  raid
 2      3000MB  4000MB  1000MB               Var   raid
 3      4000MB  4512MB  512MB                Swap  raid
 4      4512MB  2000GB  1996GB               Data  raid

Here are the commands I issued in parted:

mktable gpt
mkpart Root 17.4kB 3000MB
toggle 1 raid true
mkpart Var 3000MB 4000MB
toggle 2 raid true
mkpart Swap 4000MB 4512MB
toggle 3 raid true
mkpart Data 4512MB 100%
toggle 4 raid true

To add the partitions to the existing, degraded arrays you have to first drop the old drive and add the new one using mdadm. Double check which drive you are replacing and type the following:

mdadm /dev/md0 --fail /dev/sdb1 --remove /dev/sdb1
mdadm --manage --add /dev/md0 /dev/sdb1
mdadm /dev/md1 --fail /dev/sdb2 --remove /dev/sdb2
mdadm --manage --add /dev/md1 /dev/sdb2
mdadm /dev/md2 --fail /dev/sdb3 --remove /dev/sdb3
mdadm --manage --add /dev/md2 /dev/sdb3
mdadm /dev/md3 --fail /dev/sdb4 --remove /dev/sdb4
mdadm --manage --add /dev/md3 /dev/sdb4

I found that for some reason the /dev/md2 (swap partition) didn't seem to be happy - so I totally deleted /dev/md2: and created a new one from scratch

swapoff /dev/md2
mdadm --stop /dev/md2
mdadm --create /dev/md2 --level=1 --raid-devices=2 /dev/sda3 /dev/sdb3
mkswap /dev/md2
swapon /dev/md2

I used the new UUID information to alter the /etc/fstab info to amke sure swap came on every reboot.

Read only root and dhclient

To make my read only root viable I have a separate /var directory and /tmp mapped to /var/tmp

In my quest to get my read only root I encountered a problem with the dhclient trying to write to resolv.conf - unfortunately what the standard dhclient does is create a new /etc/resolv.conf.dhclient-new then uses mv to overwrite the existing resolv.conf.

I'm not a great fan of hacking debian scripts as 2 years down the line an upgrade will nuke said script and then I'm back to square one. My solution was to unlock the root fs for a short time during the dhclient magic.

I already had two existing scripts in /usr/local/sbin called lock and unlock which basically run:

lock:

mount -o remount,ro /

and unlock:

mount -o remount,rw /

Add some symlinks in /etc/dhcp/dhclient-enter-hooks.d/ and  /etc/dhcp/dhclient-exit-hooks.d/ as follows:

ln -s /usr/local/sbin/unlock /etc/dhcp/dhclient-enter-hooks.d/aunlock
ln -s /usr/local/sbin/unlock /etc/dhcp/dhclient-exit-hooks.d/zlock

I guessed that the dhclient script runs the hooks in alphabetical order and it seems to be the case, but I could not find any definitive proof for this.