The Wandering Star
Illuminated by the success of Dragons Everywhere, and a late-nite palaver on the true meaning of 'wandering' (to repeatedly listen to lee marvin's a wandering star, to 'explore romantically',...); we had the idea to build a light and portable server, which serves to connect hsbxl remotely to the conference/hackmeeting/gathering -- so the folks staying at home can organize a little get together and leech the remote resources.
the wandering star is scheduled to go to Berlin for the 27C3.
Think of it: last year that project was just words in the air.
The total case should be usable for 'romantically exploring' the world & 'phone-home' back to the hackerspace, and provide a vpn + ssh + decent storage.
 Current status
Build pictures are here.
 Coming up next:
- Trimming more Debian fat:
- Reworking /var: apt cache, log files, spools,...
- Recompile a new kernel: there is way too much stuff in the stock Debian kernel
- tmpfs: the more the better. Encrypted swapspace setup coming up next.
- Make it tweet !! It already has a twitter account !
- Install fresh hard disks and test.
- Build the software part (OpenVPN, encrypted disks, remote management,...)
- IMPORTANT: Write a service manual :-)
- Profit !!
 The Wandering Star need you !!
The case need a nice decal on the sides: this is your opportunity to add your artistic touch to the project. Use this section to post your artwork. The winner will be chosen during a TechTuesday.
- with aluminium frame: 46x33 cm
- Black area only: 43,2x30,3 cm
- Care must be taken during construction: the machine need to be able to withstand some level of reasonable physical abuse. No sloppy or dodgy assembling techniques are allowed.
- Opening that compromise the structural integrity of the case should be avoided. Local reinforcement is needed when there is no alternative.
- Port replication: To protect the connectors of the motherboard, the most used ports need to be replicated to the outside (ethernet, USB, VGA at least).
- Case need to be opened for hardware maintenance or emergencies only.
- Operating system must reside on static storage (compactflash, USB stick,...)
- Air entry hole must have a filter to avoid foreign objects entering the case
- plug it on the conf' network & provide vpn link to hsb
- limited weight & size
- storage (redundant)
- encrypted disks (or some system so the traveler can't be held responsable for the contents of the system)
- gigabit networkinterface
- kensington cable + burglar alarm
- serial terminal interface for config/problemsolving
 decisions to be made
- what is 'portable' ? (< 8 kg ?)
- need for encryption ? separate encryption for each user of the system ?
- disaster recovery (recovering data in case of disk failure/system failure)
- how to do configuration (eg. no dhcp at the remote network)
- Avahi/zeroconf might help here
- network redundancy (if we got mobo with 2 network interfaces - are they both usable?)
 technical/architectural specs
 at HSB
- openvpn server on tcp 443 (openvpn is on 'Appelblauwzeegroen')
- dyndns for the public ip (hsb.dyndns.info, client is running on the router)
- script to add manually the routes easily
 wandering star
- openvpn client
- /etc/network/interfaces post up script to:
- twitter a message that it's up'n'running
- start up openvpn
- openvpn auth: using ssl client certificate
- openvpn up script: twitter message that VPN link is active + netmask of conference
- firewall script: masquerade the vpn traffic behind the IP of the box (for us to reach the network)
 User management
- A list of valid users will be downloaded from The_Gate, complete with their SSH public keys, passwords and privileges. User management will be done at The_Gate.
 what do we have
- aluminum/plastic lightweight flightcase (outside: 33 X 45,5 x 16,5 cm, inside: 31,5 X 44,3 X (9 + 5,1 cover) cm )
- workable atx backplate (that fits the lid) of the proposed case.
- An untested power supply
- An USB extension backplate with 4 USB plugs
- CF -> IDE adapter
so we'll probably end up with a bunch of donated disks, which means:
- it should be easy to add/remove disks as donations come in
- disks will fail one time or another (even if we make fixtures in silicone/gel, they will die due to shocks while travelling)
- disks are of unequal size (being random donations)
- a standard RAID container won't suit our needs: the disks being of unequal size (raid container will be constructed, taking only smallest disk size into account)
- creating a LVM partition, spanning different disks is no solution neither as one dead disk will make the whole volume unusable.
- raid-Z (ZFS) would be nice, but this means we have to go for FreeBSD or OpenSolaris (and removing disks is not possible...)
- tahoe-lafs would be great, but
- it is a lot of overhead, being a project aimed for cloud storage, so client-server based (not a local fs)
- i can't get it to run multiple nodes on one machine
- BTRFS recently got included in linux kernel - can be worth a look (as it is the linux anser to ZFS)
- only mirroring & striping support now though...