Wednesday 27 March 2013

Javascript calculator

First hit for javascript calculator is so sweet:






From JavaScript Kit

Upgrading xen server from Etch to Wheezy

One of the issues with Xen, which has since been addressed by PyGRUB, is that the kernel used by a VM is controlled by the dom0, not by the vm. So, like me, you can cheerfully dist-upgrade within a vm, to no effect.

Ideally we want to got from Etch to Lenny to Squeeze.

http://www.debian.org/releases/squeeze/amd64/release-notes/ch-information.en.html#xen-upgrades

As a half way house lets try to get an unused vm to work with a squeeze kernel.

I have an unused vm! Update /etc/apt/sources.list to use squeeze. Oh, the debian keyring has changed:


apt-get install debian-archive-keyring

Now try to get a copy of the kernel image we need, as per above release notes.


apt-get install xen-linux-system-2.6-xen-amd64

Fat chance, as the vm is running an old kernel.

On the vm install xen-linux-system-2.6.26-2-xen-amd64, then copy to dom0


cd /boot
scp root@dom.context-computing.co.uk:/boot/vmlinuz-2.6.26-2-xen-amd64 .
scp root@dom.context-computing.co.uk:/boot/initrd.img-2.6.26-2-xen-amd64 .
xm shutdown dom.context-computing.co.uk
cd /etc/xen
mv dom.context-computing.co.uk.cfg dom.context-computing.co.uk.cfg-18
mv dom.context-computing.co.uk.cfg-26 dom.context-computing.co.uk.cfg
xm create dom.context-computing.co.uk.cfg

Whilst the config works (no Error 22), ie we have a xen enabled kernel, the machine crashes, and does so early: no output on console.

Revert to a lenny system running an etch kernel.

Tuesday 19 March 2013

Cleaning a work computer when you leave

When you leave a post what is a reasonable level to disinfect your computer to, so that there is little risk of your information leaking when your work machine is no longer under your control?

When I left my previous post I booted from a usb and shredded the whole disk, however this time I want to leave the Ubuntu installation intact.

Tasks in Order

✔ Create some new users: we are going to wipe the current administrative user.

✔ Unlink the machine from Dropbox, or files will either reappear, or get deleted on Dropbox.

✔ Pass a copy of the password safe to another member of the team.

✔ In Chrome disconnect your account.

✔ Change user password.

✔ Shred home directory: we are not trying to resist a determined attack, just trying to make sure that trivial use of google things is no longer possible.

find -type f -print0  |xargs -0 shred -u
find -depth -print0 |xargs -0 rmdir