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:
--- /home/marusich/guix/gnu/system/examples/bare-bones.tmpl 2016-04-02 13:35:30.226642261 -0700
+++ /home/marusich/bare-bones-with-ssh.scm 2016-11-30 04:59:23.447719406 -0800
@@ -10,11 +10,10 @@
(timezone "Europe/Berlin")
(locale "en_US.UTF-8")
- ;; Assuming /dev/sdX is the target hard disk, and "my-root" is
- ;; the label of the target root file system.
- (bootloader (grub-configuration (device "/dev/sdX")))
+ ;; Install GRUB to the loopback device so it goes into our disk.img.
+ (bootloader (grub-configuration (device "/dev/loop0")))
(file-systems (cons (file-system
- (device "my-root")
+ (device "root")
(title 'label)
(mount-point "/")
(type "ext4"))
@@ -25,8 +24,9 @@
;; empty password.
(users (cons (user-account
(name "alice")
- (comment "Bob's sister")
+ (comment "Down the rabbit hole we go")
(group "users")
+ (password "$1$JoT5zkpN$1CEM/T/UZ5a4nP1Kh8QoZ/")
;; Adding the account to the "wheel" group
;; makes it a sudoer. Adding it to "audio"
@@ -43,5 +43,7 @@
;; Add services to the baseline: a DHCP client and
;; an SSH server.
(services (cons* (dhcp-client-service)
- (lsh-service #:port-number 2222)
+ ;; Don't use lsh since it requires manual
+ ;; interaction at first boot.
+ (service openssh-service-type (openssh-configuration))
%base-services)))
* 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 [email protected]:/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 [email protected] (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 [email protected] * 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
