Search Results: "kims"

19 April 2020

Russ Allbery: Review: Beyond the Galaxy

Review: Beyond the Galaxy, by Ethan Siegel
Publisher: World Scientific
Copyright: 2016
ISBN: 981-4667-16-1
Format: Kindle
Pages: 370
In the preface of this book, Ethan Siegel recounts his experience as a new college professor in 2009, thrilled to learn that he would be teaching the college's introductory astronomy class. The only disappointment was that he could not find a textbook that described astronomy the way that he wanted to teach it. Siegel did not want to simply describe the current astronomical understanding. He wanted to start at the beginning and tell a story. What questions did we start with? How did we answer them? What new questions did those answers provoke? I enjoyed Sabine Hossenfelder's Lost in Math, but I'm even happier that she included in it a recommendation of Beyond the Galaxy as a good introduction to modern astronomy. I am completely in agreement with Siegel: Astronomy is interesting however it is described, but the best presentation for the interested lay person who does not intend to become a professional astronomy is chronological. (I feel the same way about physics and mathematics.) The narrative structure of scientific discovery draws me in every time. It's so satisfying to see our knowledge growing, breakthrough by breakthrough, only to meet the next puzzling inconsistency. It also is a natural fit for bringing someone up to speed on a field, since the history of the field starts with simpler questions and problems, and the complications of later discoveries build on the gaps left by earlier theories. Siegel tells that story well. Beyond the Galaxy starts with observations of seasonal changes in the path of the Sun through the sky and phases of the moon, quickly moves on to Eratosthenes's calculation of the circumference of the Earth, and continues at pace through early astronomy. The first chapter brings the reader up to the start of the 20th century, after which Siegel slows down and spends the remaining 10 chapters on the last 100 years: special and general relativity, the expansion of the universe, the Big Bang, dark matter, dark energy, the inflationary period, and more. For me, this was perfect. The story of early astronomy and the fight over the heliocentric model of the universe is worth telling, but it's been told many times before and features prominently in history books outside of science classes. The weight of material in this book matched my interest: What new developments have there been after general relativity and the Big Bang theory? What inconsistencies are dark matter and dark energy explaining? What is the inflationary period and how did it modify the Big Bang theory? (My half-formed impression of this part of astronomy from news articles turned out to be almost entirely wrong.) And how do we know all of this? The question of how we know as much as we do about the early origins of the universe turned out to be far more interesting than I had realized. It's one of those pieces of science where, when given only the conclusions, it's hard to imagine how our theories could be as complete as they are. Siegel is a bit repetitive in how he talks about theory development and occasionally skims over the details to avoid getting too deep into techniques and math, but he does a great job explaining the predictions of a theory, the design of experiments to prove or disprove those predictions, and the implications for the boundaries of what we know. This is the first time someone has explained the theorized origin of matter-antimatter asymmetry in sufficient detail that I was able to understand and internalize it. Dark matter and dark energy are the current topics of astronomy that get the most press, and the coverage of both is very good here. I was particularly fascinated by the link between dark matter and the superstructures of the universe that we've discovered. Astronomy does scale in a way that no other science can manage, and the scale of structure we've discovered and been able to map has gone up considerably since the last time I refreshed my astronomical knowledge. If you're looking for a math-light, comprehensive introduction to modern astronomy, I can wholeheartedly recommend this book. That goes double if you, like me, prefer a chronological view of scientific discovery so that you can understand what questions people were trying to answer and how our understanding changed over time. One note on format: Astronomy being what it is, this book is very heavy on pictures. It is not at all suitable for a dedicated ebook reader. The Kindle tries, but the combination of a small screen and black and white e-ink fail miserably. I switched to reading on a tablet, and that was a far better experience. The Kindle app still struggles to put the figures next to the text that discusses them, but that's a typesetting problem that I often have with physical books as well. If you don't have a tablet and you aren't willing to read on a computer screen, you probably want a physical copy of this one (which, sadly, means academic textbook pricing). Rating: 8 out of 10

26 April 2017

Russ Allbery: Review: Zero Bugs and Program Faster

Review: Zero Bugs and Program Faster, by Kate Thompson
Publisher: Kate Thompson
Copyright: 2015
Printing: December 2016
ISBN: 0-9961933-0-8
Format: Trade paperback
Pages: 169
Zero Bugs and Program Faster is another book I read for the engineering book club at work. Unlike a lot of the previous entries, I'd never heard about it before getting it for the book club and had no idea what to expect. What I got was a lavishly-illustrated book full of quirky stories and unusual turns of presentation on the general subject of avoiding bugs in code. Unfortunately, it's not a very deep examination of the topic. All that an experienced programmer is likely to get out of this book is the creative storytelling and the occasionally memorable illustration. I knew that this may not be a book aimed at me when I read the first paragraph:
If two books in a bookstore teach the same thing, I take the shorter one. Why waste time reading a 500-page book if I can learn the same in 100 pages? In this book, I kept things clear and brief, so you can ingest the information quickly.
It's a nice thought, but there are usually reasons why the 500-page book has 400 more pages, and those are the things I was missing here. Thompson skims over the top of every topic. There's a bit here on compiler warnings, a bit on testing, a bit on pair programming, and a bit on code review, but they're all in extremely short chapters, usually with some space taken up with an unusual twist of framing. This doesn't leave time to dive deep into any topic. You won't be bored by this book, but most of what you'll earn is "this concept exists." And if you've been programming for a while, you probably know that already. I learned during the work discussion that this was originally a blog and the chapters are repurposed from blog posts. I probably should have guessed at that, since that's exactly what the book feels like. It's a rare chapter that's longer than a couple of pages, including the room for the illustrations. The illustrations, I must say, are the best part of the book. There are a ton of them, sometimes just serving the purpose of stock photography to illustrate a point (usually with a slightly witty caption), sometimes a line drawing to illustrate some point about code, sometimes an illustrated mnemonic for the point of that chapter. The book isn't available in a Kindle edition precisely because including the illustrations properly is difficult to do (per its Amazon page). As short as this book is, only about two-thirds of it is chapters about programming. The rest is code examples (not that the chapters themselves were light on code examples). Thompson introduces these with:
One of the best ways to improve your programming is to look at examples of code written by others. On the next pages you will find some code I like. You don't need to read all of it: take the parts you like, and skip the parts you don't. I like it all.
I agree with this sentiment: reading other people's code is quite valuable. But it's also very easy to do, given a world full of free software and GitHub repositories. When reading a book, I'm looking for additional insight from the author. If the code examples are beautiful enough to warrant printing here, there presumably is some reason why. But Thompson rarely does more than hint at the reason for inclusion. There is some commentary on the code examples, but it's mostly just a discussion of their origin. I wanted to know why Thompson found each piece of code beautiful, as difficult as that may be to describe. Without that commentary, it's just an eclectic collection of code fragments, some from real systems and some from various bits of stunt programming (obfuscation contests, joke languages, and the like). The work book club discussion showed that I wasn't the only person disappointed by this book, but some people did like it for its unique voice. I don't recommend it, but if it sounds at all interesting, you may want to look over the corresponding web site to get a feel for the style and see if this is something you might enjoy more than I did. Rating: 5 out of 10

8 February 2014

John Goerzen: Migrated from Hetzner to OVH hosting

Since August 2011, my sites such as complete.org have been running on a Xen-backed virtual private server (VPS) at Hetzner Online, based in Germany. I had what they called their VQ19 package, which included 2GB RAM, 80GB HDD, 100Mb NIC and 4TB transfer. Unlike many other VPS hosts, I never had performance problems. However, I did sometimes have hardware problems with the host, and it could take hours to resolve. Their tech support only works business hours German time, which was also a problem. Meanwhile, OVH, a large European hosting company, recently opened a datacenter in Canada. Although they no longer offer their value-line Kimsufi dedicated servers there starting at $11.50/mo they do offer their midrange SoYouStart servers there. $50/mo gets a person a 4-core 3.2GHz Xeon server with 32GB RAM, 2x2TB SATA HDD, 200Mbps bandwidth. Not bad at all! The Kimsufi options are still good for lower-end needs as well. I signed up for one of the SoYouStart servers. I ve been pleased with my choice to migrate, and at the possibilities that having hardware like that at my disposal open up, but it is not without its downside. The primary downside is lack of any kind of KVM console. If the server doesn t boot, I can t see the Grub error message (or whatever) behind it. They do provide hardware support and automatic technician dispatching when the server isn t pingable, but they state they have no KVM access at all. They support many OS flavors, and have a premade image for them, but there is no using a custom ISO to install; if you want ZFS on Linux, for instance, you can t very easily build it into root. My server was promised within 72 hours, but delivered much quicker: within about 1. I had two times they said they had to replace a motherboard within the first day; once they did it in 30 minutes, and the other took them 2.5 hours for some reason. They do have phone support, which answers almost immediately, but the people there are not the people actually in the datacenter. It was frustrating with a server down for hours and nobody really commenting on what was going on. The server performs quite well, and after the initial issues, I ve been happy. I was initially planning an all-ZFS installation. SoYouStart does offer a rescue environment, but it doesn t support ZFS, so I figured I better stick with an ext4 root at least. The default Debian install uses RAID1 on md-raid, with a 20GB root partition and the rest of the 2TB drive in /home, and then a swap partition on each drive (mysteriously NOT in the RAID!) So I broke the mirror on /home and converted those into the two legs of a mirrored vdev for a zpool. I run all of the real work inside KVM VMs, so that should minimize the number of times I have to do anything to the root filesystem that could cause trouble. SoYouStart includes 100GB of space on a separate FTP server for backup purposes. I have scripts that upload nightly tarballs of the root filesystem, plus full zfs send streams of everything else. Every hour, it uploads an incremental zfs send stream as well. This all works quite nicely; even if the machine is a complete loss, I d never lose more than an hour s work, and could restore it completely from a rescue environment. Very nice! I ll write more in a few days about the ZFS setup I m using, and some KVM discoveries as well.

22 August 2013

Martín Ferrari: Setting up my server: re-installing on an encripted LVM

Very long post ahead (sorry for the wall of text), part of a series of posts on some sysadmin topics, see post 1 and post 2. I want to show you how I set up my tiny dedicated server to have encrypted partitions, and to reinstall it from scratch. All of this without ever accessing the actual server console.

Introduction As much as my provider may have gold standards on how to do things (they don't, there are some very bad practises in the default installation, like putting their SSH key into root's authorized_keys file), I wouldn't trust an installation done by a third party. Also, I wanted to have all my data securely encrypted. I know this is not perfect, and there are possible attacks. But I think it is a good barrier to have to deter entities without big budgets from getting my data. I have done this twice on my servers, and today I was reviewing each step as he was doing the same thing (with some slight differences) on his brand new server, so I think this is all mostly correct. Please, tell me if you find a bug in this guide. This was done on my 12 /month Kimsufi dedicated server, sold by OVH (see my previous post on why I chose it), and some things are specific to them. But you can do the same thing with any dedicated server that has a rescue netboot image. The process is to boot into the rescue image (this is of course a weak link, as the image could have a keylogger, but we have to stop the paranoia at some point), manually partition the disk, set-up encryption, and LVM; and then install a Debian system with debootstrap. To be able to unlock the encrypted disks, you will have to ssh into the server after a reboot and enter the passphrase (this is done inside the initrd phase). Once unlocked, the normal boot process continues. If anything fails, you end up with an unreachable system: it might or might have not booted, the disk might or might not be unlocked, etc. You can always go back into the rescue netboot image, but that does not allow you to see the boot process. Some providers will give you real remote console access, OVH charges you silly money for that. They used to offer a "virtual KVM", which was a bit of a kludge, but it worked: another netboot image that started a QEMU connected to a VNC server, so by connecting to the VNC server, you would be able to interact with the emulated boot process, but with a fake BIOS and a virtual network. For some unspecified reason they've stopped offering this, but there is a workaround available. The bottom line is, if you have some kind of rescue netboot image, you can just download and run QEMU on it and do the same trick.

The gritty details Start by netbooting into your rescue image. For OVH, you'd go to the control panel, in the Services/Netboot section and select "rescue pro". Then reboot your server. OVH will mail you a temporary password when it finishes rebooting. Connect to it, without saving the temporary SSH key:
$ ssh -oUserKnownHostsFile=/dev/null -oStrictHostKeyChecking=no root@$ IP 
For the rest of the text, I am assuming you have one hard drive called /dev/sda. We start by partitioning it:
# fdisk /dev/sda
Start a new partition table with o, and then create two primary partitions: a small one for /boot at the beginning (100 to 300 MB would do), and a second one with the remaining space. Set both as type 83 (Linux), and don't forget to activate the first one, as this servers refuse to boot from the hard drive without that. Create the file system for /boot, and the encrypted device:
# mkfs.ext4 /dev/sda1
# cryptsetup -s 512 -c aes-xts-plain64 luksFormat /dev/sda2
The encryption parameters are the same as the ones used by the Debian Installer by default, so don't change them unless you really know what you are doing. You will need to type a passphrase for the encrypted device, be sure not to forget it! This passphrase can later be changed (or secondary passphrases added) with the cryptsetup tool. Look up the crypt device's UUID, and save it for later:
# cryptsetup luksDump /dev/sda2   grep UUID:
UUID:           xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Open the encrypted device (type the passphrase again), and set up the LVM volume group:
# cryptsetup luksOpen /dev/sda2 sda2_crypt
# pvcreate /dev/mapper/sda2_crypt
# vgcreate vg0 /dev/mapper/sda2_crypt
Create the logical volumes, this is of course a matter of personal taste and there are many possible variations. This is my current layout, note that I put most of the "big data" in /srv.
# lvcreate -L 500m -n root vg0
# lvcreate -L 1.5g -n usr vg0
# lvcreate -L 3g -n var vg0
# lvcreate -L 1g -n home vg0
# lvcreate -L 10g -n srv vg0
# lvcreate -L 500m -n swap vg0
# lvcreate -L 100m -n tmp vg0
Some possible variations:
  • You can decide to use a ramdisk for /tmp, so instead of creating a logical volume, you would add RAMTMP=yes to /etc/default/tmpfs.
  • You can merge / and /usr in one same partition, as neither of them change much.
  • You can avoid having swap if you prefer.
  • You can put /home in /srv, and bind mount it later.
Now, create the file systems, swap space, and mount them in /target. Note that I like to use human-readable labels.
# for i in home root srv tmp usr var; do 
  mkfs.ext4 -L $i /dev/mapper/vg-$i; done
# mkswap -L swap /dev/mapper/vg0-swap
# mkdir /target
# mount /dev/mapper/vg0-root /target
# mkdir /target/ boot,home,srv,tmp,usr,var 
# mount /dev/sda1 /target/boot
# for i in home srv tmp usr var; do
  mount /dev/mapper/vg-$i /target/$i; done
# swapon /dev/mapper/vg-swap
Don't forget to set the right permissions for /tmp.
# chmod 1777 /target/tmp
If you want to do the /home on /srv, you'll need to do this (and then copy to /etc/fstab):
# mkdir /target/srv/home
# mount -o bind /target/srv/home /target/home
The disk is ready now. We will use debootstrap to install the base system. The OVH image carries it, otherwise consult the relevant section in the Install manual for details. It is important that at this point you check that you have a good GPG keyring for debootstrap to verify the installation source, by comparing it to a good one (for example, the one in your machine):
# gpg /usr/share/keyrings/debian-archive-keyring.gpg
pub  4096R/B98321F9 2010-08-07 Squeeze Stable Release Key <debian-release@lists.debian.org>
pub  4096R/473041FA 2010-08-27 Debian Archive Automatic Signing Key (6.0/squeeze) <ftpmaster@debian.org>
pub  4096R/65FFB764 2012-05-08 Wheezy Stable Release Key <debian-release@lists.debian.org>
pub  4096R/46925553 2012-04-27 Debian Archive Automatic Signing Key (7.0/wheezy) <ftpmaster@debian.org>
Now, for the actual installation. You can use any Debian mirror, OVH has their own in the local network. In OVH's case it is critical to specify the architecture, as the rescue image is i386. I didn't notice that and had to painfully switch architectures in place (which was absolutely not possible a couple of years ago).
# debootstrap --arch amd64 wheezy /target http://debian.mirrors.ovh.net/debian
After a few minutes downloading and installing stuff, you almost have a Debian system ready to go. Since this is not D-I, we still need to tighten a few screws manually. Let's mount some needed file systems, and enter the brand new system with chroot:
# mount -o bind /dev /target/dev
# mount -t proc proc /target/proc
# mount -t sysfs sys /target/sys
# XTERM=xterm-color LANG=C.UTF-8 chroot /target /bin/bash
The most critical parts now are to correctly save the parameters for the encrypted device, and the partitions and logical volumes. You'll need the UUID saved before:
# echo 'sda2_crypt UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx none luks' \
  > /etc/crypttab
Create the file systems table in /etc/fstab. Here I use labels to identify the devices:
# file system   mount point type    options             dump    pass
LABEL=root      /           ext4    errors=remount-ro   0       1
LABEL=tmp       /tmp        ext4    rw,nosuid,nodev     0       2
LABEL=var       /var        ext4    rw                  0       2
LABEL=usr       /usr        ext4    rw,nodev            0       2
LABEL=home      /home       ext4    rw,nosuid,nodev     0       2
# Alternative home in /srv:
#/srv/home      /home       auto    bind                0       0
LABEL=srv       /srv        ext4    rw,nosuid,nodev     0       2
LABEL=boot      /boot       ext4    rw,nosuid,nodev     0       2
LABEL=swap      none        swap    sw                  0       0
You can also just use the device mapper's names (/dev/mapper/<volume_group>-<logical_volume>), be sure not to use the /dev/<volume_group>/<logical_volume> naming, as there are some initrd-tools that choked on them.
# file system           mount point type    options             dump    pass
/dev/mapper/vg0-root    /           ext4    errors=remount-ro   0       1
/dev/mapper/vg0-tmp     /tmp        ext4    rw,nosuid,nodev     0       2
/dev/mapper/vg0-var     /var        ext4    rw                  0       2
/dev/mapper/vg0-usr     /usr        ext4    rw,nodev            0       2
/dev/mapper/vg0-home    /home       ext4    rw,nosuid,nodev     0       2
# Alternative home in /srv:
#/srv/home              /home       auto    bind                0   0
/dev/mapper/vg0-srv     /srv        ext4    rw,nosuid,nodev     0   2
/dev/sda1               /boot       ext4    rw,nosuid,nodev     0   2
/dev/mapper/vg0-swap    none        swap    sw                  0   0
Some tools depend on /etc/mtab, which now is just a symbolic link:
# ln -sf /proc/mounts /etc/mtab
Now configure the network. You most surely can use DHCP, but you might prefer static configuration, that's personal choice. For DHCP, it is very straightforward:
# cat >> /etc/network/interfaces
auto eth0
iface eth0 inet dhcp
For static configuration, first find the current valid addresses and routes as obtained by DHCP:
# ip address
# ip route
And then store them:
# cat >> /etc/network/interfaces
auto eth0
iface eth0 inet static
    address AAA.BBB.CCC.DDD/24
    gateway AAA.BBB.CCC.254
    pre-up /sbin/ip addr flush dev eth0   true
Note that pre-up command I added; that is to remove the configuration that is to be done by the kernel during boot (more on that later), otherwise ifupdown will complain about existing addresses. If your provider does IPv6, add it too. For OVH, the IPv6 set-up is a bit weird, so you need to add the routes in post-up. Your default gateway is going to be your /64 prefix, with the last byte replaced by ff, and then followed by :ff:ff:ff:ff. As you can see, that gateway is not in your network segment, so you need to add an explicit route to it. They have some information, but it is completely unreadable. If your IPv6 address is 2001:41D0:1234:5678::1/64, you will add:
iface eth0 inet6 static
    address 2001:41D0:1234:5678::1/64
    post-up /sbin/ip -6 route add 2001:41D0:1234:56ff:ff:ff:ff:ff dev eth0
    post-up /sbin/ip -6 route add default via 2001:41D0:1234:56ff:ff:ff:ff:ff
You probably don't want the auto-configured IPv6 addresses, so disable them via sysctl:
# cat >> /etc/sysctl.conf
# Disable IPv6 autoconf 
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.eth0.autoconf = 0
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.eth0.accept_ra = 0
To have a working DNS resolver, we can use the local server (OVH in this case):
# cat > /etc/resolv.conf 
search $DOMAIN
nameserver 213.186.33.99
The most important part of a new install: choose a host name (and make the system use it).
# echo $HOSTNAME > /etc/hostname
# hostname $HOSTNAME
# echo "127.0.1.1 $HOSTNAME.$DOMAIN $HOSTNAME" >> /etc/hosts
If we want to speficy the BIOS clock to use UTC:
# echo -e '0.0 0 0.0\n0\nUTC' > /etc/adjtime
Set up your time zone:
# dpkg-reconfigure tzdata
Configure APT with your preferred mirrors. I also prevent APT from installing recommends by default.
# echo deb http://ftp2.fr.debian.org/debian wheezy main contrib non-free \
  >> /etc/apt/sources.list
# echo deb http://ftp2.fr.debian.net/debian wheezy-updates main contrib non-free \
  >> /etc/apt/sources.list
# echo deb http://security.debian.org/ wheezy/updates main contrib non-free \
  >> /etc/apt/sources.list
# echo 'APT::Install-Recommends "False";' > /etc/apt/apt.conf.d/02recommends
# apt-get update
Before installing any package, let's make sure that the initial ram disk (initrd) that is going to be created will allow us to connect. There will be no chance of using the root password during boot. Your public key is usually found in $HOME/.ssh/id_rsa.pub.
# mkdir -p /etc/initramfs-tools/root/.ssh/
# echo $(YOUR_PUB_RSA_KEY) > /etc/initramfs-tools/root/.ssh/authorized_keys
If you change this, or the host key stored at /etc/dropbear/dropbear_*_host_key, the /etc/crypttab, or any other critical piece of information for the booting process, you need to run update-initramfs -u. Now we can install the missing pieces:
# apt-get install makedev cryptsetup lvm2 ssh dropbear busybox ssh \
  initramfs-tools locales linux-image-amd64 grub-pc kbd console-setup
During the installation you will have to choose where to install grub, I recommend directly on /dev/sda. Also, the magic initrd will be created. We want to double check that it has all the important pieces for a successful boot:
# zcat /boot/initrd.img-3.2.0-4-amd64   cpio -t conf/conf.d/cryptroot \
  etc/lvm/lvm.conf etc/dropbear/\* root/.ssh/authorized_keys sbin/dropbear
etc/lvm/lvm.conf
etc/dropbear/dropbear_dss_host_key
etc/dropbear/dropbear_rsa_host_key
sbin/dropbear
root/.ssh/authorized_keys
conf/conf.d/cryptroot
All these files need to be there. Most critically, we need to check that the cryptroot file has the right information to access the root file system:
# zcat /boot/initrd.img-*   cpio -i --to-stdout conf/conf.d/cryptroot
target=sda2_crypt,source=UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx,key=none,rootdev,lvm=vg0-root
If all that was correct, now we need to tell the kernel to configure the network as soon as possible so we can connect to the initrd and unlock the disks. This is done by passing a command-line option though grub. This should match what was done in /etc/network/interfaces: either DHCP or static configuration. For DHCP, this line should be changed in /etc/default/grub:
GRUB_CMDLINE_LINUX="ip=:::::eth0:dhcp"
For static configuration:
GRUB_CMDLINE_LINUX="ip=MY_IP_ADDR::MY_DEFAULT_GW:MY_NETMASK::eth0:none"
It is also a good idea to disable the quiet boot and graphical boot splash, in case we need to use QEMU to fix some booting issue:
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_TERMINAL=console
And make the changes effective:
# update-grub2
Having fsck fix problems automatically can be a life-saver too:
# echo FSCKFIX=yes >> /etc/default/rcS
Get some very useful packages:
# apt-get install vim less ntpdate sudo
Create an user for yourself, possibly make it an administrator:
# adduser tincho
# adduser tincho sudo
# adduser tincho adm
This is mostly done, exit the chroot, and unmount everything.
# exit  # the chroot.
# umount /target/ dev,proc,sys,boot,home,srv,tmp,usr,var 
# umount /target
# swapoff -a
# lvchange -an /dev/mapper/vg0-*
# cryptsetup luksClose sda2_crypt
Disable the netboot option from your administration panel, reboot, and hope it all goes well. If you followed every step carefully, a few minutes later you should be able to ping your server. Use this snippet to enter the password remotely:
$ stty -echo; ssh -o UserKnownHostsFile=$HOME/.ssh/known_hosts.initramfs \
  -o BatchMode=yes root@"$HOST" 'cat > /lib/cryptsetup/passfifo'; \
  stty echo
It is very important that you close the pipe (with control-D twice) without typing enter. For my servers, I have a script that reads the passphrase from a GPG-encrypted file and pipes it directly into the remote server. That way, I only type the GPG passphrase locally:
$ cat unlock.sh 
#!/bin/sh
BASE="$(dirname "$0")"
HOST="$1"
gpg --decrypt "$BASE"/key-"$HOST".gpg   \
    ssh -o UserKnownHostsFile="$BASE"/known_hosts.initramfs -o BatchMode=yes \
        root@"$HOST" 'cat > /lib/cryptsetup/passfifo'
It might be a good idea to create a long, impossible to guess passphrase that you can use in the GPG-encrypted file, and that you can also print and store in somewhere safe. See the luksAddKey function in the cryptsetup(8) man page. Once again, if everything went right, a few seconds later the openSSH server will replace the tiny dropbear and you will be able to access your server normally (and with the real SSH host key). Hope you find this article helpful! I would love to hear your feedback.

28 April 2013

Mart&iacute;n Ferrari: Moving my stuff away from home

TL;DR version: I want to get rid of the small server running at home, I tell you here about the service I've chosen, and why I like it. In following posts, I'll explain how did I set it up remotely. Disclaimer: I am in now way affiliated with the companies I mention here (except for Picasa, as I am a Google employee), and don't get any bonuses for this post. I am only sharing this because I think it might be useful information for other people.
Being a frequent migrant means possessions are a burden. In my previous place of residence (in France), I originally intended to only stay for 6 months, and so I arrived with just a couple of suitcases, and in the end that was enough for me to live for almost 2 years. The last time, on the other hand, I was removing my stuff completely from Argentina. I emptied my house, gave away some stuff, send some boxes to my parents' place, and carried the rest with me. That was a lot of stuff, but since the company was paying for the relocation, it was not much of a problem. Later I realised my mistake, and knowing that my time in Ireland is limited, I started to try and get rid of stuff I don't need. I know I will just sell or give away much of my stuff when I finally leave, but there are some things that are not so easy to part with. The main one being my home server, which hosts this website, my VCS repositories, pictures, and many other things I need to have on the net. This all used to be located in a home-made PC tucked in a data centre, co-located by a friendly company. But that computer died almost 2 years ago, and so canterville became abhean, and my stuff started being hosted with my aDSL connection. It worked well for some time, but now I realised I had to revert that change. With this in mind I set off to find a cheap place to host my stuff. I had a few requirements: I don't have that many photos, nor they are too big, but these requirements made it clear that most VPS offerings were not going to work for me. For some reason I fail to understand, local storage in VPS offerings is usually prohibitively expensive. This is OK for most use cases, but not for mine. A friend of mine, with a similar use case, is a happy VPS customer. He told me his trick: he only hosts in the server low-quality versions of the pictures, and keeps the originals (and back-ups) at home. This was a great idea, but with two fatal flaws: I want to only carry around a laptop and one or two external hard drives; and I want to have back-ups that are not physically with me. I was starting to think about hosting my files in Amazon s3 or something like that, since most dedicated servers are way too expensive. But then I heard about two French companies offering dirt-cheap servers: OVH and Online.net. Both of them offered small servers for about 12 a month, cheaper than most VPS offerings! Online seems to mainly cater to the French market, and for some silly reason, they charge a 50 set-up fee to customers outside of France. OVH, on the other hand, has many local branches, including an Irish one, so I went with them. The offering is a low-cost line called Kimsufi, and the smallest one is still very decent for a personal server: Once I had paid the fee for one month, it took a while for it to be activated (their payment system is pretty bad), but it finally was enabled about 24h later. Then the real fun started. On one hand, I was happy to see a wide selections of operating systems to choose from, including Debian stable and testing, and a web console with many functionalities, including some basic monitoring; but on the other hand, I realised that the installed image was not pristine, the online docs are not very good, and the web application is a bit buggy and really awkward to navigate. Having sub-par docs is not something I would usually care much about, but it made it a bit more difficult to me to understand some of the very cool functionalities their system offers (more on that in a bit), and more importantly, it made it clear to me that I won't trust their image: the procedures detailed there were not exactly best-practices, and they allow themselves to log-in as root into my server. I want to describe here what I think are their most interesting features, that made it possible to me to do risky operations, like encrypting the root partition, and setting up a firewall; and being able to fix problems that would usually require physical access. These are found in their web console: a hardware reset, and configurable netboot support with many offered images, including a rescue image based on Ubuntu and one that serves as a virtual KVM. (It is surprising that these servers don't have a serial console, but at least the kernel does not detect any). With these in hand, I didn't have to fear being locked out of my server for ever. Just set up a netboot image and hard-reboot the machine! Also, it made it very simple to install my system from scratch with debootstrap. The virtual KVM is a very interesting trick. It is a netboot image that runs some tests, and fires up a web browser. You get an email with the URL and a password to access it, and then you open a page that offers you what is basically a Qemu connected to a VNC server which will boot from your real hard drive. It is super slow, but that allows you to get console access to your server, which can be very handy to debug booting problems, unless it is some issue with the real hardware. It also offers the possibility of downloading an ISO image off the network and booting that, so it can be used to run a stock installer CD too. In another post I'll describe how I reinstalled my server remotely, and some of the pitfalls that I've encountered in the process.

24 March 2009

Josselin Mouette: Dear lazyweb,

Due to the repeated tendency of our friends of the MPAA beloved government to create laws that turn computer and Internet users into criminals, I m considering to shutdown any kind of non-encrypted communications that I initiate from France. Therefore, I m looking for cheap dedicated hosting in an Internet-friendly country, in a way similar to what we have here with OVH or Iliad. My requirements are: I m fine with blades, but not with virtual hosting. Suggestions are welcome. I m currently considering hosting solutions in the Netherlands, but I d appreciate some advice.

21 May 2006

Andrew Pollock: [life/americania] Time flies when you're having fun

Half a year ago yesterday, I stepped off a plane in the United States. It's been an eventful 6 months, as can be seen from reviewing my blog, and I thought I'd summarise the top 10 things I like and dislike about living in this country as opposed to Australia. Ten things I like about living in California:
  1. Plenty of sunshine Love the sunshine. It was a bit wet in winter and early spring, but I'm told that it should be pretty much rain (and cloud) free for the rest of the year. Daylight saving also helps make enjoying the copious amounts of sunshine easier, it doesn't get dark until well after 8pm.
  2. The public transport options, particularly in San Francisco are vast Particularly in San Francisco, your options for getting around the city are huge. You've got the BART, the Muni (which covers about three distinct forms of public transport in itself), and the VTA overhead electric and petrol powered buses. Elsewhere in the Bay Area, you've got the Caltrain, and VTA light rail and buses.
  3. Petrol pumps You need never darken the door of a petrol station. Everywhere has pay at the pump (with plastic of course), and the pumps all have the automatic latch, so you don't even need to stand at the side of the car holding the handle while it fills up.
  4. Free parking This was a big change, coming from Canberra, which has a love affair with pay and display parking. Even the multi-storey and underground carparks in the downtown areas are free.
  5. Pedestrian crossings that countdown No excuse to get skittled because you thought you could make it in time. You known exactly how long you've got before you'll get mowed down before you step off the side of the road.
  6. The postal system Saturday delivery. Every mailbox is an outgoing mailbox (just put the little flag up).
  7. Right turns on red This is a real time saver. I can't see why Australia couldn't adopt this for left turns. The only downside is you can spend so much time looking to your left for a break in the traffic to dart out in, that you miss your green arrow (but that's what the guy behind you and his horn is for).
  8. Corporately run rental apartment complexes Instead of having an apartment complex where individual landlords own each apartment, the entire complex (and they tend to be larger) is owned by a mega-corporation that employs half a dozen people to maintain it and run it as a business. The upside is they tend to have better facilities, an onsite office (great for receipting packages delivered during the week), onsite maintenance (some places even have a service-level agreement). This offers some economies of scale that you wouldn't otherwise have.
  9. At least the perception of a low cost of living I haven't done the sums, and it's probably partially because the bills come monthly instead of quarterly, but all the utility bills seem fairly low and reasonable. Dollar for dollar, petrol is also cheaper, even though it's jumped a dollar a gallon in the time we've been here.
Of course, one must take a balanced look at these things... Ten things I don't like about living in the United States:
  1. The currency Not a big fan of the notes. I miss the one and two dollar coins, and the distinctiveness between each denomination. I figure that vending machines over here must be so much more expensive because they have to have a note reader, and even then, the treasury decides to produce some new oddball note that half of the readers don't recognise... I blame tipping. If there were no tipping, the utility of one dollar bills would diminish enormously.
  2. The government bureaucracy As my blog records, I haven't exactly had a smooth run with the system over here...
  3. The banking system The banking system in general is woeful by comparison. The cheque (or check) still reigns supreme, whereas it's nearly obsolete in Australia. There's no such animal as BPay (and oh how I miss it). In fact, the equivalent system here often involves the bank cutting a cheque on your behalf and mailing it to the biller. How ridiculously antediluvian is that? Oh, and I miss vaguely decently authenticated electronic payments. I've been at cafes were I've paid by credit card, and haven't even had to provide a signature. Given that the credit card is actually a debit card, it's pretty disturbing how easily someone can clean out your bank account.
  4. Ex-tax pricing I'm so glad that when they introduced the GST in Australia, they required by law that all prices include it. Most prices here don't, but the occasional food outlet does (like Subway for example), so it's sufficiently confusing that you can't budget for how much you're going to actually fork out.
  5. ATM fees The ATM fees are more in your face. Instead of the bank charging you a fee at the end of the month for every transaction conducted at an ATM that isn't theirs, the ATM itself tacks on an extra amount to the withdrawal and effectively skims the money. I've seen fees as high as $5 a transaction, but $2 is fairly common. It's kind of weird seeing an ATM withdrawal of $42 on your bank statement... So having a bank account that doesn't charge you feeds for non-bank ATM withdrawals is all well and good, but it doesn't stop the ATM from charging you.
  6. Inaudible pedestrian crossings Oh, the number of times I haven't been paying attention and missed the walk light at a pedestrian crossing... In some places, they do make noises like birds, or talk to you when you can walk, but they're definitely not the norm.
  7. The road surface For the highways, they seem to have gone for quantity and not quality, or they're too busy to take offline to resurface. Either way, the road surface quality is pretty poor.
  8. Sugar Everything is loaded with sugar. Absolutely everything.
  9. Alcohol labelling Light beer is low calorie, not low alcohol. I miss Australia's concept of "standard drinks". Makes it very hard to drink and drive responsibly.