how to "install" guixsd on a digitalocean server

how to "install" guixsd on a digitalocean server

[Andy Wingo]

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 root@your-ip.

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.

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

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

[ng0]

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 root@your-ip.
> 
> 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
> 

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

[Pjotr Prins]

Nice one, I'll use that.

On Fri, Apr 07, 2017 at 02:07:16PM +0200, Andy Wingo wrote:
> 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.

I think that is the symlink issue which was documented somewhere.

Pj.

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

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 813 bytes --]

On Fri, Apr 07, 2017 at 12:31:16PM +0000, Pjotr Prins wrote:
> On Fri, Apr 07, 2017 at 02:07:16PM +0200, Andy Wingo wrote:
> > 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.
> 
> I think that is the symlink issue which was documented somewhere.

We fixed it in b812da70594f5d40647d156f69be0eb169d6be19 and
613d0895b92c677e0639d5e77c55043e38e020c8, but it's not in a release yet.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 388 bytes --]

On Fri, Apr 07, 2017 at 02:07:16PM +0200, Andy Wingo wrote:
>  (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.

lsh is a GNU project and we did not have an OpenSSH service until a few
months ago. I'm in favor of changing the OS declaration templates to use
OpenSSH.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> On Fri, Apr 07, 2017 at 02:07:16PM +0200, Andy Wingo wrote:
>>  (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.
>
> lsh is a GNU project and we did not have an OpenSSH service until a few
> months ago. I'm in favor of changing the OS declaration templates to use
> OpenSSH.

I agree with this change (lsh upstream hasn’t been receiving the
attention I was hoping for.)

Ludo’.

Use OpenSSH in the bare-bones GuixSD template [was Re: how to "install" guixsd on a digitalocean server]

[Leo Famulari]

On Fri, Apr 07, 2017 at 09:57:56PM +0200, Ludovic Courtès wrote:
> Leo Famulari <leo@famulari.name> skribis:
> 
> > On Fri, Apr 07, 2017 at 02:07:16PM +0200, Andy Wingo wrote:
> >>  (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.
> >
> > lsh is a GNU project and we did not have an OpenSSH service until a few
> > months ago. I'm in favor of changing the OS declaration templates to use
> > OpenSSH.
> 
> I agree with this change (lsh upstream hasn’t been receiving the
> attention I was hoping for.)

Here's a patch for discussion.

Re: Use OpenSSH in the bare-bones GuixSD template [was Re: how to "install" guixsd on a digitalocean server]

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 776 bytes --]

On Sat, Apr 08, 2017 at 09:42:17PM -0400, Leo Famulari wrote:
> On Fri, Apr 07, 2017 at 09:57:56PM +0200, Ludovic Courtès wrote:
> > Leo Famulari <leo@famulari.name> skribis:
> > 
> > > On Fri, Apr 07, 2017 at 02:07:16PM +0200, Andy Wingo wrote:
> > >>  (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.
> > >
> > > lsh is a GNU project and we did not have an OpenSSH service until a few
> > > months ago. I'm in favor of changing the OS declaration templates to use
> > > OpenSSH.
> > 
> > I agree with this change (lsh upstream hasn’t been receiving the
> > attention I was hoping for.)
> 
> Here's a patch for discussion.

And the patch...

[-- Attachment #2: 0001-doc-Use-OpenSSH-instead-of-lsh-in-bare-bones-templat.patch --]
[-- Type: text/plain, Size: 1016 bytes --]

From bac586572af3fdc720f1ff2c873864fd4c1ebf05 Mon Sep 17 00:00:00 2001
From: Leo Famulari <leo@famulari.name>
Date: Sat, 8 Apr 2017 21:38:54 -0400
Subject: [PATCH] doc: Use OpenSSH instead of lsh in bare-bones template.

* gnu/system/examples/bare-bones.tmpl (services): Use openssh-service-type
instead of lsh-service.
---
 gnu/system/examples/bare-bones.tmpl | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gnu/system/examples/bare-bones.tmpl b/gnu/system/examples/bare-bones.tmpl
index 222ddda57..f7b8823d4 100644
--- a/gnu/system/examples/bare-bones.tmpl
+++ b/gnu/system/examples/bare-bones.tmpl
@@ -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)
+                   (service openssh-service-type
+                            (openssh-configuration
+                              (port-number 2222)))
                    %base-services)))
-- 
2.12.2

Re: Use OpenSSH in the bare-bones GuixSD template [was Re: how to "install" guixsd on a digitalocean server]

[ng0]

Leo Famulari transcribed 2.1K bytes:
> On Sat, Apr 08, 2017 at 09:42:17PM -0400, Leo Famulari wrote:
> > On Fri, Apr 07, 2017 at 09:57:56PM +0200, Ludovic Courtès wrote:
> > > Leo Famulari <leo@famulari.name> skribis:
> > > 
> > > > On Fri, Apr 07, 2017 at 02:07:16PM +0200, Andy Wingo wrote:
> > > >>  (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.
> > > >
> > > > lsh is a GNU project and we did not have an OpenSSH service until a few
> > > > months ago. I'm in favor of changing the OS declaration templates to use
> > > > OpenSSH.
> > > 
> > > I agree with this change (lsh upstream hasn’t been receiving the
> > > attention I was hoping for.)
> > 
> > Here's a patch for discussion.
> 
> And the patch...

What you added here is opensshd listening on port 2222 with
password-logins allowed, correct?

> From bac586572af3fdc720f1ff2c873864fd4c1ebf05 Mon Sep 17 00:00:00 2001
> From: Leo Famulari <leo@famulari.name>
> Date: Sat, 8 Apr 2017 21:38:54 -0400
> Subject: [PATCH] doc: Use OpenSSH instead of lsh in bare-bones template.
> 
> * gnu/system/examples/bare-bones.tmpl (services): Use openssh-service-type
> instead of lsh-service.
> ---
>  gnu/system/examples/bare-bones.tmpl | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/gnu/system/examples/bare-bones.tmpl b/gnu/system/examples/bare-bones.tmpl
> index 222ddda57..f7b8823d4 100644
> --- a/gnu/system/examples/bare-bones.tmpl
> +++ b/gnu/system/examples/bare-bones.tmpl
> @@ -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)
> +                   (service openssh-service-type
> +                            (openssh-configuration
> +                              (port-number 2222)))
>                     %base-services)))
> -- 
> 2.12.2
> 

Re: Use OpenSSH in the bare-bones GuixSD template [was Re: how to "install" guixsd on a digitalocean server]

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 414 bytes --]

On Sun, Apr 09, 2017 at 09:08:45AM +0000, ng0 wrote:
> What you added here is opensshd listening on port 2222 with
> password-logins allowed, correct?

Yes, and the rest of the defaults can be found here:

https://www.gnu.org/software/guix/manual/html_node/Networking-Services.html#index-openssh_002dconfiguration

My intention is that it behaves the same way as the current bare-bones
template using lsh-service.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Use OpenSSH in the bare-bones GuixSD template [was Re: how to "install" guixsd on a digitalocean server]

[ng0]

Leo Famulari transcribed 1.4K bytes:
> On Sun, Apr 09, 2017 at 09:08:45AM +0000, ng0 wrote:
> > What you added here is opensshd listening on port 2222 with
> > password-logins allowed, correct?
> 
> Yes, and the rest of the defaults can be found here:
> 
> https://www.gnu.org/software/guix/manual/html_node/Networking-Services.html#index-openssh_002dconfiguration
> 
> My intention is that it behaves the same way as the current bare-bones
> template using lsh-service.

Okay, I was just making sure what your intentions are. I know the
openssh service.

The changes look good to me.
-- 
PGP and more: https://people.pragmatique.xyz/ng0/

Re: Use OpenSSH in the bare-bones GuixSD template [was Re: how to "install" guixsd on a digitalocean server]

[Leo Famulari]

On Sun, Apr 09, 2017 at 02:21:50PM +0000, ng0 wrote:
> Leo Famulari transcribed 1.4K bytes:
> > On Sun, Apr 09, 2017 at 09:08:45AM +0000, ng0 wrote:
> > > What you added here is opensshd listening on port 2222 with
> > > password-logins allowed, correct?
> > 
> > Yes, and the rest of the defaults can be found here:
> > 
> > https://www.gnu.org/software/guix/manual/html_node/Networking-Services.html#index-openssh_002dconfiguration
> > 
> > My intention is that it behaves the same way as the current bare-bones
> > template using lsh-service.
> 
> Okay, I was just making sure what your intentions are. I know the
> openssh service.
> 
> The changes look good to me.

I've pushed the change as eea2f45369f49d244e99257fcc71a9f367fdf0fd.

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

[myglc2]

On 04/07/2017 at 14:07 Andy Wingo writes:

> 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.
[...]

Hi Andy,

I upgraded Debian to GuixSD on a physical server in a similar way ...

https://lists.gnu.org/archive/html/guix-devel/2016-03/msg00354.html

... but I used 'guix system init' instead of 'guix system reconfigure'.

I wonder, could that approach have been used in this situation to avoid
the need to "clean up the remaining Debian bits"?

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

[Andy Wingo]

Hi :)

On Fri 07 Apr 2017 16:04, myglc2 <myglc2@gmail.com> writes:

> On 04/07/2017 at 14:07 Andy Wingo writes:
>
>> 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.
> [...]
>
> I upgraded Debian to GuixSD on a physical server in a similar way ...
>
> https://lists.gnu.org/archive/html/guix-devel/2016-03/msg00354.html
>
> ... but I used 'guix system init' instead of 'guix system reconfigure'.
>
> I wonder, could that approach have been used in this situation to avoid
> the need to "clean up the remaining Debian bits"?

Neat.  For me the answer is, I don't know :)  I thought with guix system
init you had to do a bunch of partitiony type things?  Certainly if I
had a blank scratch space I could do that.

In hindsight it is something of a miracle that "reconfigure" worked on a
previously non-GuixSD system.  Strange.  I will accept it though :)

Andy

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

[ng0]

Andy Wingo transcribed 1.0K bytes:
> Hi :)
> 
> On Fri 07 Apr 2017 16:04, myglc2 <myglc2@gmail.com> writes:
> 
> > On 04/07/2017 at 14:07 Andy Wingo writes:
> >
> >> 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.
> > [...]
> >
> > I upgraded Debian to GuixSD on a physical server in a similar way ...
> >
> > https://lists.gnu.org/archive/html/guix-devel/2016-03/msg00354.html
> >
> > ... but I used 'guix system init' instead of 'guix system reconfigure'.
> >
> > I wonder, could that approach have been used in this situation to avoid
> > the need to "clean up the remaining Debian bits"?
> 
> Neat.  For me the answer is, I don't know :)  I thought with guix system
> init you had to do a bunch of partitiony type things?  Certainly if I
> had a blank scratch space I could do that.
> 
> In hindsight it is something of a miracle that "reconfigure" worked on a
> previously non-GuixSD system.  Strange.  I will accept it though :)
> 
> Andy
> 

Okay, you have to provide a config.scm and you have to have root or
sudo, in which case you already have the rights to cause total
destruction on the machine... but should we point that out that it is
possible to "accidentally" run a succesful guix system init on a system
which is let's say Debian or whatever, ever if it is just for curiosity
of discovery?
And why would we point it out? Is there any harm in it or do we trust
sudo/root users to know that this can happen?

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

[myglc2]

[-- Attachment #1: Type: text/plain, Size: 3380 bytes --]

On 04/07/2017 at 14:31 ng0 writes:

> Andy Wingo transcribed 1.0K bytes:
>> Hi :)
>> 
>> On Fri 07 Apr 2017 16:04, myglc2 <myglc2@gmail.com> writes:
>> 
>> > On 04/07/2017 at 14:07 Andy Wingo writes:
>> >
>> >> 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.
>> > [...]
>> >
>> > I upgraded Debian to GuixSD on a physical server in a similar way ...
>> >
>> > https://lists.gnu.org/archive/html/guix-devel/2016-03/msg00354.html
>> >
>> > ... but I used 'guix system init' instead of 'guix system reconfigure'.
>> >
>> > I wonder, could that approach have been used in this situation to avoid
>> > the need to "clean up the remaining Debian bits"?
>> 
>> Neat.  For me the answer is, I don't know :)  I thought with guix system
>> init you had to do a bunch of partitiony type things?  Certainly if I
>> had a blank scratch space I could do that.
>> 
>> In hindsight it is something of a miracle that "reconfigure" worked on a
>> previously non-GuixSD system.  Strange.  I will accept it though :)
>> 
>> Andy
>> 
>
> Okay, you have to provide a config.scm and you have to have root or
> sudo, in which case you already have the rights to cause total
> destruction on the machine... but should we point that out that it is
> possible to "accidentally" run a succesful guix system init on a system
> which is let's say Debian or whatever, ever if it is just for curiosity
> of discovery?

I think we should. Because an inadvertent 'guix system init' can easily
produce a machine that no longer boots.

> And why would we point it out?

It is useful. Here are some examples ...

1) Before installing GuixSD, our users may well install Guix to check it
   out (I did with both with nix/nixOS and guix/GuixSD). Once they do,
   'guix system init' is easier than USB install because ...

   - it's quicker.

   - they don't have to find a USB key.

   - they can do install steps (edit config.scm, fdisk, etc) on a fully
     functional OS rather than a less functional install image.

   - If installing a server, they can do it all over ssh. This is way
     easier than plugging in a USB key + monitor or fiddling around with
     remote management tools.

2) As Andy has demonstrated, 'Guix Binary install + guix system init'
   works in situations where the USB install may be inconvenient or may
   not work.

3) In my experience (several headless server installs over the last
   year, including testing the graphical USB installer), I have found
   that 'Guix Binary install + guix system init' is more convenient. A
   simple makefile (attached) makes it even more convenient.

Note: None of this meant as a criticism of our USB install, or the
upcoming Graphical GuixSD installer.

> Is there any harm in it or do we trust sudo/root users to know that
> this can happen?

In my experience, the most likely "bad outcome" with 'guix system init'
is that the system hangs because of a problem with the
grub-configuration or file-system "device" fields. See for example ...

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23072

If a user experiences this they may be better off with the USB install
since can reboot from USB and try again. So maybe we should recommend
making a "GuixSD USB rescue key" before trying 'guix system init' for
the first time ;-)


[-- Attachment #2: makefile --]
[-- Type: application/octet-stream, Size: 2688 bytes --]

# quick and dirty makefile to install guix on debian 8
# usage
# sudo make install

SHELL  := /bin/bash

BLDDIR = /tmp

.PHONY: install
install: hydra

guixbuild: /gnu

guixbuilder1 guixbuilder2 guixbuilder3: guixbuild

guix-daemon: guixbuilder1 guixbuilder2 guixbuilder3 \
                guixbuilder4 guixbuilder5 guixbuilder6 \
                guixbuilder7 guixbuilder8

guixcommand: guix-daemon

hydra: guixcommand

/gnu:
	# download
	mkdir -p $(BLDDIR)
	cd $(BLDDIR) && wget ftp://alpha.gnu.org/gnu/guix/guix-binary-0.9.0.x86_64-linux.tar.xz
	cd $(BLDDIR) && tar  --warning=no-timestamp -xf guix-binary-0.9.0.x86_64-linux.tar.xz
	cd $(BLDDIR) && rm -f guix-binary-0.9.0.x86_64-linux.tar.xz
	# move into place
	cd $(BLDDIR) && mv var/guix /var/
	cd $(BLDDIR) && mv gnu /
	# make root provile avail
	ln -sf /var/guix/profiles/per-user/root/guix-profile /root/.guix-profile

guix-daemon:
	# Run the daemon and set it to run automatically after restart.
	cp /root/.guix-profile/lib/systemd/system/guix-daemon.service /etc/systemd/system/guix-daemon.service
	systemctl enable guix-daemon
	systemctl start guix-daemon

guixbuild:
	# guix builder group
	-groupadd --system guixbuild

guixbuilder%:
	# guix builder account
	-useradd -g guixbuild -G guixbuild      \
            -d /var/empty -s `which nologin`    \
            -c "Guix build user $i" --system    \
            guixbuilder$*

guixcommand:
	# make guix command avail to users
	-mkdir -p /usr/local/bin && \
                cd /usr/local/bin && \
                ln -s /var/guix/profiles/per-user/root/guix-profile/bin/guix
	# make guix Info avail to users
	mkdir -p /usr/local/share/info && \
                cd /usr/local/share/info; \
                for i in /var/guix/profiles/per-user/root/guix-profile/share/info/* ; \
                do ln -s $$i ; done

hydra:
	# authorize use of substitues from hydra
	guix archive --authorize < /root/.guix-profile/share/guix/hydra.gnu.org.pub

# TK maybe not appropriate for root?
locales:
	guix package -i glibc-locales
	# 2 packages in profile
	# The following environment variable definitions may be needed:
	#   export PATH="/root/.guix-profile/bin:/root/.guix-profile/sbin"
	# TK: add to profile?
	export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale

uninstall:
	-rm -r /gnu
	-rm -r /var/guix
	-rm -r /var/log/guix
	-rm -f /root/.guix-profile
	-rm -r /etc/guix
	-rm -f /usr/local/bin/guix
	-rm -r /usr/local/share/info
	-rm -f /etc/systemd/system/guix-daemon.service
	-rm -f /etc/systemd/system/multi-user.target.wants/guix-daemon.service
	# TK is this correct: -rm -r /var/log
	-rm -r /root/.config
	# kill the daemon
	-pkill guix-daemon
	# TK remove the buixbuilderNN users

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

[Ludovic Courtès]

Hi Andy,

Andy Wingo <wingo@igalia.com> skribis:

> 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.

Thanks a lot for the detailed report!  It shows just how much room for
improvement there is.  Some of the issues are not simple to fix, but we
should do something about it.

> 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

In
<https://git.savannah.gnu.org/cgit/guix.git/commit/?id=1165b08f8683b2a8c12753eb6fd26c2451bce81c>,
I fixed it by adding ‘glibc-utf8-locales’ and ‘glibc-final’ to the
tarball, and also documenting ~/.guix-profile/etc/profile.

We have to be aware that this will only placate people whose locale is
in this set, but that’s already an improvement, I think.

> OK.  Only problem now is that ~/.guix-profile/etc/profile has absolute
> paths in it, instead of pointers into the user's $HOME.  Humm.

Yeah, one has to define GUIX_PROFILE.

> 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:

Yeah.  :-/

>     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 -A emacs’ or ‘guix package -s emacs | grep ^name’ would
have helped, but not that convenient, I agree.

>     (operating-system
>       (host-name "guix-potluck")

Oh oh!  :-)

> That's all.  Hope yall find this useful.  Now, to clean up the remaining
> Debian bits!

Neat, congrats!

If DigitalOcean supports it, we could ship a GuixSD qcow2/whatever image
that’s directly usable without having to go through this Debian step, as
Leo suggested recently.

Ludo’.

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

[ng0]

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 root@your-ip.
> 
> Having done this, I proceeded to the binary Guix installation:
> 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
> 

Could this be applied to linode as well? Or does linode function
differently?
-- 
PGP and more: https://people.pragmatique.xyz/ng0/

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

[Andy Wingo]

On Thu 13 Apr 2017 17:28, ng0 <contact.ng0@cryptolab.net> writes:

> Andy Wingo transcribed 6.6K bytes:
>> 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.
>
> Could this be applied to linode as well? Or does linode function
> differently?

Hi,

I think it can apply directly to linode as well:

  http://www.linode.com/docs/tools-reference/custom-kernels-distros/run-a-distribution-supplied-kernel-with-kvm

Apparently there is the option to use DHCP as well, which is nice:

  https://www.linode.com/docs/networking/linux-static-ip-configuration

Andy

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

[ng0]

Andy Wingo transcribed 0.7K bytes:
> On Thu 13 Apr 2017 17:28, ng0 <contact.ng0@cryptolab.net> writes:
> 
> > Andy Wingo transcribed 6.6K bytes:
> >> 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.
> >
> > Could this be applied to linode as well? Or does linode function
> > differently?
> 
> Hi,
> 
> I think it can apply directly to linode as well:
> 
>   http://www.linode.com/docs/tools-reference/custom-kernels-distros/run-a-distribution-supplied-kernel-with-kvm
> 
> Apparently there is the option to use DHCP as well, which is nice:
> 
>   https://www.linode.com/docs/networking/linux-static-ip-configuration
> 
> Andy
> 

Cool, thanks.
I'll write about it if it works.
One of the next steps I have in server documentation, is to ask 1984 ehf
if they have special requirements, what could work out for them in best
case scenario, etc.
-- 
PGP and more: https://people.pragmatique.xyz/ng0/