guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: how to "install" guixsd on a digitalocean server


From: ng0
Subject: Re: how to "install" guixsd on a digitalocean server
Date: Fri, 7 Apr 2017 12:27:57 +0000

Hi,

thanks for documenting this on the list, it's really cool and useful.
It looks to some parts
applicable to many DigitalOcean-like hosters :)

Andy Wingo transcribed 6.6K bytes:
> Hi,
> 
> I just "installed" GuixSD on a DigitalOcean droplet.  You can't actually
> install GuixSD; you have to mutate an existing installation into
> GuixSD.  But fine.
> 
> So I installed the latest Debian x86_64 image that they offer.  All fine
> and easy.  You tell DigitalOcean your SSH key, then you can SSH directly
> to address@hidden
> 
> Having done this, I proceeded to the binary Guix installation:
> 
>     wget ftp://alpha.gnu.org/gnu/guix/guix-binary-0.12.0.x86_64-linux.tar.xz
>     gpg --keyserver pgp.mit.edu --recv-keys 
> BCA689B636553801C3C62150197A5888235FACAC
>     wget 
> ftp://alpha.gnu.org/gnu/guix/guix-binary-0.12.0.x86_64-linux.tar.xz.sig
>     gpg --verify guix-binary-0.12.0.x86_64-linux.tar.xz.sig
> 
>     cd /tmp
>     tar --warning=no-timestamp -xf ~/guix-binary-0.12.0.x86_64-linux.tar.xz
>     mv var/guix/ /var/
>     mv gnu/ /
>     ln -sf /var/guix/profiles/per-user/root/guix-profile ~root/.guix-profile
>     groupadd --system guixbuild
>     for i in `seq -w 1 10`; do useradd -g guixbuild -G guixbuild -d 
> /var/empty -s `which nologin` -c "Guix build user $i" --system guixbuilder$i; 
> done
> 
> Debian uses systemd so as the manual tells me, I did:
> 
>     ln -s ~root/.guix-profile/lib/systemd/system/guix-daemon.service 
> /etc/systemd/system/
>     systemctl start guix-daemon && systemctl enable guix-daemon
> 
> This gave an error for the "enable" part; apparently that doesn't work.
> But starting the daemon worked fine.  In the future when I would reboot
> the machine I would have to manually do a "systemctl start guix-daemon"
> again.

Yeah, I found out about this when I set up a new Debian 8 with Guix.
There's a solution for Debian 8 here:
https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00810.html

> So then:
> 
>     ~root/.guix-profile/bin/guix archive --authorize < 
> ~root/.guix-profile/share/guix/hydra.gnu.org.pub
> 
> But at this point it started carping about locales.  The manual doesn't
> mention what you need to do until later on, but what you do is this:
> 
>     ~/.guix-profile/bin/guix package -i glibc-utf8-locales
>     export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale
> 
> Then what init file do you add to for the environment variables?  I
> think it's ~/.profile but IDK.  I did this:
> 
>     echo 'source ~/.guix-profile/etc/profile' >> ~/.profile
> 
> However this didn't include the LOCPATH thing, so you have to do this
> too:
> 
>     echo 'export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale' >> ~/.profile
> 
> OK.  Only problem now is that ~/.guix-profile/etc/profile has absolute
> paths in it, instead of pointers into the user's $HOME.  Humm.
> 
> Anyway!  Off to update my Guix:
> 
>     guix pull
> 
> Unfortunately this failed due to lack of memory.  I had installed on the
> smallest instance with 512MB memory.  So for now I bumped it up to 1G
> and retried and was able to upgrade.  Then:
> 
>     guix package -i emacs
> 
> but I found that was installing X things and cancelled; had to ask on
> IRC what was the right thing because guix package --search=emacs showed
> too much info for me to find emacs-no-x :)
> 
>     guix package -i emacs-no-x
> 
> OK.  So I edit a new os-config.scm because I'm going to be trying to
> install GuixSD.  Here is what I ended up with.  Three notes:
> 
>  (1) I used the stock template but you have to customize to use
>      "/dev/vda", which is what DigitalOcean gives you.
> 
>  (2) DigitalOcean doesn't use DHCP, and instead fills in some static
>      information in /etc/networking/interface apparently.  I read that
>      and made the static networking config.
> 
>  (3) Why do we promote lsh by default?  It took me quite some looking to
>      figure out why my authorized_keys wasn't working.  The fix was to
>      just use OpenSSH.
> 
>     (use-modules (gnu))
>     (use-service-modules networking ssh)
>     (use-package-modules admin)
> 
>     (operating-system
>       (host-name "guix-potluck")
>       (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/vda")))
>       (file-systems (cons (file-system
>                             (device "/dev/vda1")
>                             (mount-point "/")
>                             (type "ext4"))
>                           %base-file-systems))
> 
>       ;; This is where user accounts are specified.  The "root"
>       ;; account is implicit, and is initially created with the
>       ;; empty password.
>       (users (cons (user-account
>                     (name "wingo")
>                     (group "users")
>                     ;; Adding the account to the "wheel" group
>                     ;; makes it a sudoer.
>                     (supplementary-groups '("wheel"))
>                     (home-directory "/home/wingo"))
>                    %base-user-accounts))
> 
>       ;; Globally-installed packages.
>       (packages (cons tcpdump %base-packages))
> 
>       (services (cons* (static-networking-service "eth0" "46.101.231.54"
>                         #:netmask "255.255.192.0"
>                         #:gateway "46.101.192.1"
>                         #:name-servers '("8.8.8.8" "8.8.4.4"))
>                        (service openssh-service-type
>                                 (openssh-configuration
>                                 (permit-root-login 'without-password)))
>                        %base-services)))
> 
> I don't know if I _had_ to do this, but I think it was necessary: you go
> into the DigitalOcean "control panel" to the "Kernel" section and you
> choose the "GrubLoader" kernel.  Apparently it used to be the case in DO
> that kernels were always configured outside the VM.  You have to switch
> to a GrubLoader kernel to let the VM choose.  That's what I wanted so I
> did that.
> 
> OK, time to build the image:
> 
>     guix system build os-config.scm
> 
> Great, it built just fine!  Now reconfigure:
> 
>     guix system reconfigure os-config.scm
> 
> Lol whoops.  For some reason the builders were behind so I had to build
> grub2 which needs qemu-minimal at build-time due to tests, but
> qemu-minimal also needed to be built but *its* tests wouldn't run
> because they ran out of memory on the 1G instance.  So I bumped RAM
> again to 2G.  I would recommend in hindsight for people to (a) start
> with the smallest instance, as you can resize CPU/RAM back and forth
> with no problem but you can't shrink the disk apparently; then (b)
> immediately size-up CPU/RAM so your builds go faster and actually
> complete; then (c) shrink CPU/RAM to what you need.
> 
> When it finally built, then it failed to reconfigure because some things
> were conflicting between /etc/ssl from the Debian install and what
> GuixSD wanted.  But you can't just move /etc out of the way because that
> has /etc/passwd etc which the build daemon needs for "guixbuild" :P  So:
> 
>     mv /etc /old-etc
>     mkdir /etc
>     cp /old-etc/{passwd,group,shadow,gshadow,mtab} /etc/
> 
> Then finally:
> 
>     guix system reconfigure os-config.scm
> 
> Now once you reboot, it works :)
> 
> That's all.  Hope yall find this useful.  Now, to clean up the remaining
> Debian bits!
> 
> Andy
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]