[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Hosting a GuixSD server on commodity hosting platforms, a journey
From: |
Chris Marusich |
Subject: |
Re: Hosting a GuixSD server on commodity hosting platforms, a journey |
Date: |
Wed, 30 Nov 2016 08:41:17 -0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
Hi,
Reading Chris' report, I was inspired to try the same thing on EC2. I
don't know much about Linode or Rackspace, but I do know EC2. I'm happy
to report that I was successfully in creating a GuixSD EC2 instance.
Here's what I did. Essentially, all I wanted to do was run "guix system
init" on the root device of an EC2 instance. I accomplished that by
running "guix system init" on a loopback device (on my laptop), copying
the file which backed the loopback device onto an EC2 instance, writing
the file to an EBS volume attached to the instance, and then replacing
the EC2 instance's root EBS volume with the newly written EBS volume.
Here are the steps I took, in detail. Hopefully it's clear enough for
someone else to try it out if they want to.
(From the AWS Management Console)
* Launch an instance. I used an EBS-backed Ubuntu AMI using HVM
virtualization in the us-west-2 region. This one: ami-cbd276ab. It
needs to be EBS-backed because I want to be able to detach and attach
the volumes easily; it needs to be HVM virtualization because that way
it will boot using the GRUB I will install in the GuixSD system's root
device (paravirtualized EC2 instances follow a different boot
process). In the web UI, before launching the instance, I removed the
ephemeral storage from it (since I didn't need it), and I added an
extra 30 GiB EBS volume (this will become the GuixSD system's root
device). I also gave the instance a name tag to keep track of it in
the AWS Management Console. I used an m3.medium type instance, since
that is the smallest type which would give me consistent performance.
Here's a quick link to launch the AMI I used:
https://console.aws.amazon.com/ec2/home?region=us-west-2#launchAmi=ami-cbd276ab
(On my local computer)
* Generate a hashed password for use in the operating system config (see
"(guile) Encryption" for details). Here, the password is
57HdiXRftjV55zpXh5k3 (don't worry, I've changed it :-)):
--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> (crypt "57HdiXRftjV55zpXh5k3" "$1$JoT5zkpN")
$2 = "$1$JoT5zkpN$1CEM/T/UZ5a4nP1Kh8QoZ/"
scheme@(guile-user)>
--8<---------------cut here---------------end--------------->8---
* Make the following changes to the "bare-bones" operating system
configuration file that comes with Guix
(gnu/system/examples/bare-bones.tmpl), in order to enable remote login
using that password:
patch
Description: Text Data
* Make a sparse file (to save space) to be our disk image:
dd if=/dev/zero of=disk.img bs=1 count=0 seek=30GiB
* Partition it (I suspect that toggling the boot flag is unnecessary,
but I did it just to be safe):
parted -s disk.img mklabel msdos
parted -s disk.img mkpart primary ext4 10M 100%
parted -s disk.img toggle 1 boot
parted -s disk.img print
* Set up a loopback device:
sudo losetup -P /dev/loop0 disk.img
* Make a file system:
sudo mkfs.ext4 -L root /dev/loop0p1
* Mount it:
sudo mount /dev/loop0p1 /mnt
* Init the system:
sudo guix system init ~/bare-bones-with-ssh.scm /mnt
* Grab some coffee.
* Unmount it:
sudo umount /mnt
* Detach the loopback device:
sudo losetup -d /dev/loop0
* Compress the disk image, so we can copy it to the instance faster.
gzip disk.img
* Copy the image to the instance:
scp -i ~/.ssh/marusich-ec2.pem disk.img.gz address@hidden:/tmp
* Log into the instance (Ubuntu EC2 images always use the "ubuntu" user,
and the marusich-ec2.pem key is the one that I generated when
launching the instance using the AWS Management Console earlier).
ssh -i ~/.ssh/marusich-ec2.pem address@hidden
(While logged into the instance)
* Write the disk image to the target (30 GiB) EBS volume (/dev/xvdf is
where it's attached):
sudo bash -c 'gzip -d -c /tmp/disk.img.gz > /dev/xvdf'
* Grab another cup of coffee. This takes a while.
(From the AWS Management Console)
* Stop the instance.
* Detach all its EBS volumes.
* Attach the target (30 GiB) volume to the instance as '/dev/sda1'.
This will actually attach the volume at '/dev/xvda'. I don't know why
EC2 requires us to attach it as '/dev/sda1', but it does; it's weird.
* Start the instance.
* Now ssh into your new EC2 instance running GuixSD!
ssh address@hidden
* From here, you can reconfigure to your heart's content. I've
confirmed that running "guix system reconfigure" works.
Some thoughts about the experience:
* The "get console screenshot" and "get system log" features (of Amazon
EC2) don't work with the GuixSD instance; not sure why, but it made
troubleshooting a little harder. Maybe tty settings need tweaking?
* It would have been nice if I could have done this without relying on
an existing EC2 instance. In the future, we could consider using the
EC2 APIs to import an image, similar to what is described here:
http://docs.aws.amazon.com/vm-import/latest/userguide/import-vm-image.html
* There was some discussion in IRC about whether or not it would make
sense to have a "base AMI" for GuixSD. Dave made a good case for
avoiding that practice [1], which goes against the spirit of GuixSD.
Instead, for using GuixSD with virtualization services like EC2, in
the long term, it seems preferable to make it easy to init the system
you want (including the ssh keys and all) and then import that system
into the EC2 service (or other virtualization service). That's
basically what I did here, albeit via a hacky manual method.
* There is currently no support for declaring a user's authorized_keys
for SSH. Just like we have a way to declare a user's password, it
would be great to have a way to declare a user's authorized_keys.
There was some discussion about this on IRC also [1], with some
promising paths forward.
[1] https://gnunet.org/bot/log/guix/2016-11-30
--
Chris
signature.asc
Description: PGP signature