GuixSD on commodity hosting platforms, hoster: IN-Berlin

GuixSD on commodity hosting platforms, hoster: IN-Berlin

[ng0]

Hi,

today I had a short message exchange with the hoster "IN-Berlin"[0], a
non-commercial group predating the widespread access of internet in
Germany.

It turns out that it could be as simple as providing them with the raw
disk image, so I will give it a try soon.

Is anyone interested in the documentation or success of this experiment?
I'm not involved with IN-Berlin and I don't want them to offer GuixSD
until it is "safe to use" on servers. The default is Debian for the
virtual server options.


0: http://in-berlin.de
-- 
ng0 -- https://www.inventati.org/patternsinthechaos/

Re: GuixSD on commodity hosting platforms, hoster: IN-Berlin

[Jan Nieuwenhuizen]

ng0 writes:

> It turns out that it could be as simple as providing them with the raw
> disk image, so I will give it a try soon.

Can you share the config.scm of that?

> Is anyone interested in the documentation or success of this experiment?

On the future of Guix-panel it was said (by Ludo'?) that getting GuixSD
on a mainstream hosting platform was very good to have.

I'm interested in how this goes and would like to try the gentle folks
of An Meaisín Dénártha (https://anmd.org) if that is useful.

Greetings,
--janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

Re: GuixSD on commodity hosting platforms, hoster: IN-Berlin

[Ludovic Courtès]

Hey!

Jan Nieuwenhuizen <janneke@gnu.org> skribis:

> On the future of Guix-panel it was said (by Ludo'?) that getting GuixSD
> on a mainstream hosting platform was very good to have.

I think that was Chris but I agree that it would be great.

Ludo’.

Re: GuixSD on commodity hosting platforms, hoster: IN-Berlin

[ng0]

On 17-02-09 21:38:27, Jan Nieuwenhuizen wrote:
> ng0 writes:
> 
> > It turns out that it could be as simple as providing them with the raw
> > disk image, so I will give it a try soon.
> 
> Can you share the config.scm of that?

What do you mean? I will just test generally if it works on their
infrastructure. Afterwards I will set up some services for myself to
have something to test the server side of things I build and package.
There will be no public config to share, only at some point afterwards
when I decide to share a stripped down config or set of configs.

In the long run it would be nice if IN-Berlin could offer GuixSD in
addition to Debian, but as we all know, there's a reason for the "beta"
and until it's marked as beta I won't get to this point of discussion.
Just a general check if it works. The way it works for the current
Debian setup, asking for GuixSD would be no problem. No problem with a
raw image, so for them it won't matter if there'll be an .iso later on.

I used IN-Berlin before, started when I offered OpenNIC resolvers and a
tor-relay, and more afterwards. For users based in Germany I can
recommend it. I say Germany, because I have no idea if their registry
system would work well for anyone not living in Germany, I don't even
know about Austria. In case anyone is interested, asking via email will
resolve questions.


> 
> > Is anyone interested in the documentation or success of this experiment?
> 
> On the future of Guix-panel it was said (by Ludo'?) that getting GuixSD
> on a mainstream hosting platform was very good to have.
> 
> I'm interested in how this goes and would like to try the gentle folks
> of An Meaisín Dénártha (https://anmd.org) if that is useful.
> 
> Greetings,
> --janneke
> 
> -- 
> Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
> Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  
> 

-- 
ng0 -- https://www.inventati.org/patternsinthechaos/

Re: GuixSD on commodity hosting platforms, hoster: IN-Berlin

[ng0]

On 17-02-10 22:48:34, ng0 wrote:
> On 17-02-09 21:38:27, Jan Nieuwenhuizen wrote:
> > ng0 writes:
> > 
> > > It turns out that it could be as simple as providing them with the raw
> > > disk image, so I will give it a try soon.
> > 
> > Can you share the config.scm of that?
> 
> What do you mean? I will just test generally if it works on their
> infrastructure. Afterwards I will set up some services for myself to
> have something to test the server side of things I build and package.
> There will be no public config to share, only at some point afterwards
> when I decide to share a stripped down config or set of configs.
> 
> In the long run it would be nice if IN-Berlin could offer GuixSD in
> addition to Debian, but as we all know, there's a reason for the "beta"
> and until it's marked as beta I won't get to this point of discussion.
> Just a general check if it works. The way it works for the current
> Debian setup, asking for GuixSD would be no problem. No problem with a
> raw image, so for them it won't matter if there'll be an .iso later on.
> 
> I used IN-Berlin before, started when I offered OpenNIC resolvers and a
> tor-relay, and more afterwards. For users based in Germany I can
> recommend it. I say Germany, because I have no idea if their registry
> system would work well for anyone not living in Germany, I don't even
> know about Austria. In case anyone is interested, asking via email will
> resolve questions.
> 
> 
> > 
> > > Is anyone interested in the documentation or success of this experiment?
> > 
> > On the future of Guix-panel it was said (by Ludo'?) that getting GuixSD
> > on a mainstream hosting platform was very good to have.

Adding to the last reply: I think with mainstream platform something
like AWS and some other cloud server solutions were targeted. My idea is
just IN-Berlin, afterwards I'm done with the topic for myself for now,
I have no intention to push this any further.


> > 
> > I'm interested in how this goes and would like to try the gentle folks
> > of An Meaisín Dénártha (https://anmd.org) if that is useful.
> > 
> > Greetings,
> > --janneke
> > 
> > -- 
> > Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
> > Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  
> > 
> 
> -- 
> ng0 -- https://www.inventati.org/patternsinthechaos/
> 

-- 
ng0 -- https://www.inventati.org/patternsinthechaos/

Re: GuixSD on commodity hosting platforms, hoster: IN-Berlin

[Jan Nieuwenhuizen]

ng0 writes:

>> > It turns out that it could be as simple as providing them with the raw
>> > disk image, so I will give it a try soon.
>> 
>> Can you share the config.scm of that?
>
> What do you mean?

I imagined you will be running something like

    guix system disk-image in-berlin.scm

It is this `in-berlin.scm' file that I was referring to.

Also, I assumed that hosting providers have some of basic set of
requirements for the images that they take.  I remember to have heard
there are several (ugh) cloud/stack standards that one could target.

That would mean that you will be spending some effort to get
`in-berlin.scm' just right, and I would like to make use of that instead
of figuring it all out again myself when I try another hosting provider.

Greetings, janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

Re: GuixSD on commodity hosting platforms, hoster: IN-Berlin

[ng0]

On 17-02-11 11:37:27, Jan Nieuwenhuizen wrote:
> ng0 writes:
> 
> >> > It turns out that it could be as simple as providing them with the raw
> >> > disk image, so I will give it a try soon.
> >> 
> >> Can you share the config.scm of that?
> >
> > What do you mean?
> 
> I imagined you will be running something like
> 
>     guix system disk-image in-berlin.scm
> 
> It is this `in-berlin.scm' file that I was referring to.
> 
> Also, I assumed that hosting providers have some of basic set of
> requirements for the images that they take.  I remember to have heard
> there are several (ugh) cloud/stack standards that one could target.

It's different with IN-Berlin:

  AH>Wir installieren die VMs mit Debian Netboot + Preseed direkt in ein LV
  AH>(RAW-Format).
  AH>
  AH>Du erhälst ja Konslolenzugriff auf eine VM und wir können dir zur Installation
  AH>auch ein beliebiges ISO einbinden.

Their VMs are installed with Debian Netboot + Preseed directly in an LV
(RAW-Format).  You get Consoleaccess to the VM (out of band, there's a
dedicated console server) and they can mount some ISO image for
installation if you wish.

> That would mean that you will be spending some effort to get
> `in-berlin.scm' just right, and I would like to make use of that instead
> of figuring it all out again myself when I try another hosting provider.
> 
> Greetings, janneke
> 
> -- 
> Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
> Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  
> 

I think what I will do is request some outputs of lshw etc, or rent a
very minimal machine so I can adapt settings myself, but my hope is
GuixSD will just work* out of the box with only an added sshd and some
other minimal changes.

* work, as in ready to start installing more software.
-- 
ng0 -- https://www.inventati.org/patternsinthechaos/

Re: GuixSD on commodity hosting platforms, hoster: IN-Berlin

[Leo Famulari]

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

On Thu, Feb 09, 2017 at 06:36:09PM +0000, ng0 wrote:
> today I had a short message exchange with the hoster "IN-Berlin"[0], a
> non-commercial group predating the widespread access of internet in
> Germany.
> 
> It turns out that it could be as simple as providing them with the raw
> disk image, so I will give it a try soon.

A few months ago I had a brief discussion with a representative of
<https://serveraptor.com> about offering GuixSD there.

They said that could accept a bootable ISO or qcow2 image.

So, we could give them the 0.12.0 GuixSD installer image, after
converting it to the qcow2 format.

I used the following command to convert the installer to qcow2:

$ xz -d guixsd-usb-install-0.12.0.x86_64-linux.xz \
&& qemu-img convert -O qcow2 guixsd-usb-install-0.12.0.x86_64-linux \
guixsd-usb-install-0.12.0.x86_64-linux.qcow2

The results are available at
<https://famulari.name/a2249a95c83f60bc75efe89b6fe4f01d/>.

I'd like for someone to try this conversion themself and verify that it
creates the same qcow2 file.

If it does, then we can ask Serveraptor to make it available for testing
on their platform.

What do you think?

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

Re: GuixSD on commodity hosting platforms, hoster: IN-Berlin

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> On Thu, Feb 09, 2017 at 06:36:09PM +0000, ng0 wrote:
>> today I had a short message exchange with the hoster "IN-Berlin"[0], a
>> non-commercial group predating the widespread access of internet in
>> Germany.
>> 
>> It turns out that it could be as simple as providing them with the raw
>> disk image, so I will give it a try soon.
>
> A few months ago I had a brief discussion with a representative of
> <https://serveraptor.com> about offering GuixSD there.
>
> They said that could accept a bootable ISO or qcow2 image.
>
> So, we could give them the 0.12.0 GuixSD installer image, after
> converting it to the qcow2 format.
>
> I used the following command to convert the installer to qcow2:
>
> $ xz -d guixsd-usb-install-0.12.0.x86_64-linux.xz \
> && qemu-img convert -O qcow2 guixsd-usb-install-0.12.0.x86_64-linux \
> guixsd-usb-install-0.12.0.x86_64-linux.qcow2
>
> The results are available at
> <https://famulari.name/a2249a95c83f60bc75efe89b6fe4f01d/>.
>
> I'd like for someone to try this conversion themself and verify that it
> creates the same qcow2 file.

The image itself is most likely not bit-reproducible, if that’s what you
mean (non-reproducible packages, uncontrolled file system layout, etc.)

> If it does, then we can ask Serveraptor to make it available for testing
> on their platform.

That would be great!

For these use cases, I wonder if it makes sense to provide the
installation image.  Wouldn’t it be more convenient if we provided, say,
the “bare-bones” image or a variant thereof?  That way, as a user, you
could directly use it as-is, or just run ‘reconfigure’ in it.

Thanks,
Ludo’.

Re: GuixSD on commodity hosting platforms, hoster: IN-Berlin

[ng0]

On 17-02-14 10:24:57, Ludovic Courtès wrote:
> Leo Famulari <leo@famulari.name> skribis:
> 
> > On Thu, Feb 09, 2017 at 06:36:09PM +0000, ng0 wrote:
> >> today I had a short message exchange with the hoster "IN-Berlin"[0], a
> >> non-commercial group predating the widespread access of internet in
> >> Germany.
> >> 
> >> It turns out that it could be as simple as providing them with the raw
> >> disk image, so I will give it a try soon.
> >
> > A few months ago I had a brief discussion with a representative of
> > <https://serveraptor.com> about offering GuixSD there.
> >
> > They said that could accept a bootable ISO or qcow2 image.
> >
> > So, we could give them the 0.12.0 GuixSD installer image, after
> > converting it to the qcow2 format.
> >
> > I used the following command to convert the installer to qcow2:
> >
> > $ xz -d guixsd-usb-install-0.12.0.x86_64-linux.xz \
> > && qemu-img convert -O qcow2 guixsd-usb-install-0.12.0.x86_64-linux \
> > guixsd-usb-install-0.12.0.x86_64-linux.qcow2
> >
> > The results are available at
> > <https://famulari.name/a2249a95c83f60bc75efe89b6fe4f01d/>.
> >
> > I'd like for someone to try this conversion themself and verify that it
> > creates the same qcow2 file.
> 
> The image itself is most likely not bit-reproducible, if that’s what you
> mean (non-reproducible packages, uncontrolled file system layout, etc.)
> 
> > If it does, then we can ask Serveraptor to make it available for testing
> > on their platform.
> 
> That would be great!
> 
> For these use cases, I wonder if it makes sense to provide the
> installation image.  Wouldn’t it be more convenient if we provided, say,
> the “bare-bones” image or a variant thereof?  That way, as a user, you
> could directly use it as-is, or just run ‘reconfigure’ in it.
> 
> Thanks,
> Ludo’.
> 

I'd include an openssh aswell, but for IN-Berlin this is what I'll be
using in March, a variant of the barebones image.
I think in their special case even the installer would work, but with
the bare-bones there's already "something".
Maybe once it works I give "just the installer" a try on a second VM.

-- 
ng0 -- https://www.inventati.org/patternsinthechaos/

Re: GuixSD on commodity hosting platforms, hoster: IN-Berlin

[Leo Famulari]

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

On Tue, Feb 14, 2017 at 10:24:57AM +0100, Ludovic Courtès wrote:
> Leo Famulari <leo@famulari.name> skribis:
> > I'd like for someone to try this conversion themself and verify that it
> > creates the same qcow2 file.
> 
> The image itself is most likely not bit-reproducible, if that’s what you
> mean (non-reproducible packages, uncontrolled file system layout, etc.)

I meant that I'd like someone to try downloading the official 0.12.0
x86_64-linux installer image that Ricardo released and attempt the
image format conversion.

If they get the same result, then it removes me from the chain of people
that Serveraptor users have to trust. Instead, they'd trust Serveraptor
to offer them the same image that I'm providing from my site.

> > If it does, then we can ask Serveraptor to make it available for testing
> > on their platform.
> 
> That would be great!
> 
> For these use cases, I wonder if it makes sense to provide the
> installation image.  Wouldn’t it be more convenient if we provided, say,
> the “bare-bones” image or a variant thereof?  That way, as a user, you
> could directly use it as-is, or just run ‘reconfigure’ in it.

Okay, I'll wait a bit for someone to try to the conversion. At the same
time, I'll ask Serveraptor what makes more sense for their platform.

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

Re: GuixSD on commodity hosting platforms, hoster: IN-Berlin

[Christopher Allan Webber]

Leo Famulari writes:

> I'd like for someone to try this conversion themself and verify that it
> creates the same qcow2 file.
>
> If it does, then we can ask Serveraptor to make it available for testing
> on their platform.

Leo and I worked on this off-list, and verified!  I was able to make the
same thing.

Advice about GuixSD on Serveraptor?

[Leo Famulari]

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

On Mon, Feb 13, 2017 at 04:47:17PM -0500, Leo Famulari wrote:
> A few months ago I had a brief discussion with a representative of
> <https://serveraptor.com> about offering GuixSD there.
> 
> They said that could accept a bootable ISO or qcow2 image.
> 
> So, we could give them the 0.12.0 GuixSD installer image, after
> converting it to the qcow2 format.
> 
> I used the following command to convert the installer to qcow2:
> 
> $ xz -d guixsd-usb-install-0.12.0.x86_64-linux.xz \
> && qemu-img convert -O qcow2 guixsd-usb-install-0.12.0.x86_64-linux \
> guixsd-usb-install-0.12.0.x86_64-linux.qcow2

I'm not sure yet, but perhaps the installation image will be
inappropriate for the Serveraptor environment.

So far, I've been able to install and reconfigure GuixSD, but I can't
re-partition the system so that the installer image's disk space can be
reclaimed afterwards. The installer is mounted as /dev/vda1, and I
installed to /dev/vda2. I can do some re-partitioning while the system
is online, but I can't move the installed system's partition "to the
left".

I also tried expanding the installer's partition while the system is
running, so that I could use `resize2fs` and then reconfigure directly
from the installer, before I realized that the installer's root
filesystem is a unionfs, which complicates things...

I had wanted to use the GuixSD installer because the image format
conversion is reproducible. So, nobody would have to trust me to provide
the right thing.

Of course, it would be a lot simpler if we made a barebones system with
`guix system vm-image`.

If we can't use the installer, how should we create and provide another
image?

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

Re: Advice about GuixSD on Serveraptor?

[Leo Famulari]

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

On Sun, Mar 12, 2017 at 08:32:52PM -0400, Leo Famulari wrote:
> I had wanted to use the GuixSD installer because the image format
> conversion is reproducible. So, nobody would have to trust me to provide
> the right thing.
> 
> Of course, it would be a lot simpler if we made a barebones system with
> `guix system vm-image`.
> 
> If we can't use the installer, how should we create and provide another
> image?

Any advice or guidance?

I can easily create an image to use for this, but I don't want to do it
if others think I am going beyond the level of trust placed in me by the
Guix project.

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

Re: Advice about GuixSD on Serveraptor?

[Christopher Allan Webber]

Leo Famulari writes:

> On Sun, Mar 12, 2017 at 08:32:52PM -0400, Leo Famulari wrote:
>> I had wanted to use the GuixSD installer because the image format
>> conversion is reproducible. So, nobody would have to trust me to provide
>> the right thing.
>>
>> Of course, it would be a lot simpler if we made a barebones system with
>> `guix system vm-image`.
>>
>> If we can't use the installer, how should we create and provide another
>> image?
>
> Any advice or guidance?
>
> I can easily create an image to use for this, but I don't want to do it
> if others think I am going beyond the level of trust placed in me by the
> Guix project.

So, if you provided the source scheme to generate the image, and signed
the image, people would both have the option to generate the image
themselves, or download your signed binary image if they trust you?

Honestly, at this point the most important thing is to get things to the
point where we have *a* documented process to install GuixSD on these
servers; once we have that, and assuming we also have documentation /
tooling where people could reproduce the whole process (even if they
used the image you provided, as long as they could reproduce that step
too) I think we're in a much better state than we are... and we could
refine further from there.

My opinion, anyway!
 - Chris

Re: Advice about GuixSD on Serveraptor?

[Leo Famulari]

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

On Tue, Mar 21, 2017 at 03:22:43PM -0500, Christopher Allan Webber wrote:
> Leo Famulari writes:
> > I can easily create an image to use for this, but I don't want to do it
> > if others think I am going beyond the level of trust placed in me by the
> > Guix project.
> 
> So, if you provided the source scheme to generate the image, and signed
> the image, people would both have the option to generate the image
> themselves, or download your signed binary image if they trust you?

Not exactly...

Serveraptor offers users a set of images to choose from, but they don't
have a method by which users can upload their own images. You'd have to
make a special arrangement for that.

So what I'm doing here is trying to provide Serveraptor with a GuixSD
image that they'd offer to users.

People could regenerate the image themselves, but it would be difficult
to verify that it matches what is offered by Serveraptor.

There are VPS providers that provide an image upload system but, as far
as I know, none of them accept raw QEMU images. They all want
ISO-formatted images.

> Honestly, at this point the most important thing is to get things to the
> point where we have *a* documented process to install GuixSD on these
> servers; once we have that, and assuming we also have documentation /
> tooling where people could reproduce the whole process (even if they
> used the image you provided, as long as they could reproduce that step
> too) I think we're in a much better state than we are... and we could
> refine further from there.

My idea is to create a bare-bones GuixSD image using `guix system
vm-image` and provide that to Serveraptor. Users would boot directly
into the system and reconfigure it to fit their needs. 

If by "install GuixSD" you mean "boot the GuixSD USB install and
initialize the system", that does work, but it's not very satisfying
because Serveraptor's management interface does not expose the
virtualized storage devices, so it's difficult (impossible?) to reclaim
the partition used by the installer.

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

Re: Advice about GuixSD on Serveraptor?

[Leo Famulari]

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

On Tue, Mar 21, 2017 at 04:46:20PM -0400, Leo Famulari wrote:
> So what I'm doing here is trying to provide Serveraptor with a GuixSD
> image that they'd offer to users.
> 
> People could regenerate the image themselves, but it would be difficult
> to verify that it matches what is offered by Serveraptor.

And to clarify my previous question: Should this QEMU image be created
by me, or should it be created by a Guix maintainer as part of the Guix
release process?

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

Re: Advice about GuixSD on Serveraptor?

[ng0]

Leo Famulari transcribed 3.0K bytes:
> On Tue, Mar 21, 2017 at 03:22:43PM -0500, Christopher Allan Webber wrote:
> > Leo Famulari writes:
> > > I can easily create an image to use for this, but I don't want to do it
> > > if others think I am going beyond the level of trust placed in me by the
> > > Guix project.
> > 
> > So, if you provided the source scheme to generate the image, and signed
> > the image, people would both have the option to generate the image
> > themselves, or download your signed binary image if they trust you?
> 
> Not exactly...
> 
> Serveraptor offers users a set of images to choose from, but they don't
> have a method by which users can upload their own images. You'd have to
> make a special arrangement for that.
> 
> So what I'm doing here is trying to provide Serveraptor with a GuixSD
> image that they'd offer to users.
> 
> People could regenerate the image themselves, but it would be difficult
> to verify that it matches what is offered by Serveraptor.
> 
> There are VPS providers that provide an image upload system but, as far
> as I know, none of them accept raw QEMU images. They all want
> ISO-formatted images.

IN-Berlin wants a raw image (they have read our documentation).
The way their system works is that you sent
them your ssh pubkey, they initialize a basic Debian system depending on
the size you chose, and you can login once you get the hostname etc.
They have an out-of-band consoleserver where the ssh key is placed
aswell for the machine.
I don't work with this non-profit organization, but having a way to
define ssh pubkeys in the system config would be super useful for this.
Right now I'm about to create my own system and just sent it to them as
soon as I feel up to it.
If they could simply create the system in their infrastructure, that
would be an incredible speedup and reproducible.
I don't know much about the out of band consoleserver, I have to ask
if that's somehow relevant or if it simply needs some initrd settings to
expose it to the server.

> > Honestly, at this point the most important thing is to get things to the
> > point where we have *a* documented process to install GuixSD on these
> > servers; once we have that, and assuming we also have documentation /
> > tooling where people could reproduce the whole process (even if they
> > used the image you provided, as long as they could reproduce that step
> > too) I think we're in a much better state than we are... and we could
> > refine further from there.
> 
> My idea is to create a bare-bones GuixSD image using `guix system
> vm-image` and provide that to Serveraptor. Users would boot directly
> into the system and reconfigure it to fit their needs. 
> 
> If by "install GuixSD" you mean "boot the GuixSD USB install and
> initialize the system", that does work, but it's not very satisfying
> because Serveraptor's management interface does not expose the
> virtualized storage devices, so it's difficult (impossible?) to reclaim
> the partition used by the installer.

Re: Advice about GuixSD on Serveraptor?

[Thomas Danckaert]

From: Leo Famulari <leo@famulari.name>
Subject: Re: Advice about GuixSD on Serveraptor?
Date: Tue, 21 Mar 2017 16:53:35 -0400

> On Tue, Mar 21, 2017 at 04:46:20PM -0400, Leo Famulari wrote:
>> So what I'm doing here is trying to provide Serveraptor with a 
>> GuixSD
>> image that they'd offer to users.
>>
>> People could regenerate the image themselves, but it would be 
>> difficult
>> to verify that it matches what is offered by Serveraptor.
>
> And to clarify my previous question: Should this QEMU image be 
> created
> by me, or should it be created by a Guix maintainer as part of the 
> Guix
> release process?

Hi,

to add my 2 cents: I think it would be fine if you provided the 
image, if you are confident that it works.

When GuixSD becomes widely available on various hosting providers, 
the Guix maintainers cannot provide all those images (or guarantee 
their correctness) anyway (I imagine that typically an employee of 
such a service would create the image?).  Even now, when you provide 
an image to Serveraptor, you have no way to verify if Serveraptor 
provides the same image to their users (I think?).

Once Serveraptor provides the image you created (or any other GuixSD 
image) to its users, the responsibility lies with them.  
Serveraptor's users will have to trust Serveraptor (and, if they use 
your image, Serveraptor has to trust you, but it sounds like they 
already do :-) ).

Thomas

Re: Advice about GuixSD on Serveraptor?

[Ricardo Wurmus]

Leo Famulari <leo@famulari.name> writes:

> On Tue, Mar 21, 2017 at 04:46:20PM -0400, Leo Famulari wrote:
>> So what I'm doing here is trying to provide Serveraptor with a GuixSD
>> image that they'd offer to users.
>>
>> People could regenerate the image themselves, but it would be difficult
>> to verify that it matches what is offered by Serveraptor.
>
> And to clarify my previous question: Should this QEMU image be created
> by me, or should it be created by a Guix maintainer as part of the Guix
> release process?

I’m not sure.  I guess it would be better for users if it was signed by
a maintainer key, but on the other hand I don’t know if we can commit to
publishing QEMU images with every release.

Could we build an image with Hydra instead and just provide the latest
build to Serveraptor?  How would updates to the image be handled?  Do
they offer some sort of API to upload new images or is this a process
that depends on humans making decisions?

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Advice about GuixSD on Serveraptor?

[Leo Famulari]

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

On Tue, Mar 21, 2017 at 09:06:09PM +0000, ng0 wrote:
> IN-Berlin wants a raw image (they have read our documentation).
> The way their system works is that you sent
> them your ssh pubkey, they initialize a basic Debian system depending on
> the size you chose, and you can login once you get the hostname etc.
> They have an out-of-band consoleserver where the ssh key is placed
> aswell for the machine.
> I don't work with this non-profit organization, but having a way to
> define ssh pubkeys in the system config would be super useful for this.
> Right now I'm about to create my own system and just sent it to them as
> soon as I feel up to it.
> If they could simply create the system in their infrastructure, that
> would be an incredible speedup and reproducible.
> I don't know much about the out of band consoleserver, I have to ask
> if that's somehow relevant or if it simply needs some initrd settings to
> expose it to the server.

Interesting! I'll probably take a look at this when I got some free
time.

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

Re: Advice about GuixSD on Serveraptor?

[Leo Famulari]

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

On Wed, Mar 22, 2017 at 08:36:19AM +0100, Thomas Danckaert wrote:

[...]

> the image?).  Even now, when you provide an image to Serveraptor, you have
> no way to verify if Serveraptor provides the same image to their users (I
> think?).

The "best" idea I had was to use a tool like mtree to hash every file on
the filesystem, and then compare it to the booted system. "Best" because
I think it's impractical :)

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

Re: Advice about GuixSD on Serveraptor?

[Leo Famulari]

On Wed, Mar 22, 2017 at 01:04:46PM +0100, Ricardo Wurmus wrote:
> Leo Famulari <leo@famulari.name> writes:
> > And to clarify my previous question: Should this QEMU image be created
> > by me, or should it be created by a Guix maintainer as part of the Guix
> > release process?
> 
> I’m not sure.  I guess it would be better for users if it was signed by
> a maintainer key, but on the other hand I don’t know if we can commit to
> publishing QEMU images with every release.

Okay.

> Could we build an image with Hydra instead and just provide the latest
> build to Serveraptor?  How would updates to the image be handled?  Do
> they offer some sort of API to upload new images or is this a process
> that depends on humans making decisions?

It's not a bad idea to build it on Hydra. Hydra already builds a
usb-image / disk-image job [0], so we could add a qemu-image job, too.

I think that updates to the image would have to be handled manually. One
of us could send them a link to the new image and they'd make it
available to their users.

My expectation is that Serveraptor would offer our latest release, and
users would be expected to update their systems, as on bare-metal.

[0]
https://hydra.gnu.org/job/gnu/core-updates/usb-image.x86_64-linux

Re: Advice about GuixSD on Serveraptor?

[Leo Famulari]

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

On Wed, Mar 22, 2017 at 01:20:53PM -0400, Leo Famulari wrote:
> It's not a bad idea to build it on Hydra. Hydra already builds a
> usb-image / disk-image job [0], so we could add a qemu-image job, too.

Actually, we used to build a qemu-image on Hydra, but we removed because
it was troublesome and unused.

https://git.savannah.gnu.org/cgit/guix.git/commit/?id=a3a27745013f3e5a287de3bf0187b2f72beb6965

Maybe we should try again :)

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

Re: Advice about GuixSD on Serveraptor?

[ng0]

Leo Famulari transcribed 2.0K bytes:
> On Tue, Mar 21, 2017 at 09:06:09PM +0000, ng0 wrote:
> > IN-Berlin wants a raw image (they have read our documentation).
> > The way their system works is that you sent
> > them your ssh pubkey, they initialize a basic Debian system depending on
> > the size you chose, and you can login once you get the hostname etc.
> > They have an out-of-band consoleserver where the ssh key is placed
> > aswell for the machine.
> > I don't work with this non-profit organization, but having a way to
> > define ssh pubkeys in the system config would be super useful for this.
> > Right now I'm about to create my own system and just sent it to them as
> > soon as I feel up to it.
> > If they could simply create the system in their infrastructure, that
> > would be an incredible speedup and reproducible.
> > I don't know much about the out of band consoleserver, I have to ask
> > if that's somehow relevant or if it simply needs some initrd settings to
> > expose it to the server.
> 
> Interesting! I'll probably take a look at this when I got some free
> time.

I'll write an email to IN-Berlin asking about the consoleserver this
week.
If it's nothing special, we could provide this bare image, and people
could download it as the GuixSD with ssh + whatever is needed for it to
work out in server context as a start.

Re: Advice about GuixSD on Serveraptor?

[ng0]

ng0 transcribed 1.3K bytes:
> Leo Famulari transcribed 2.0K bytes:
> > On Tue, Mar 21, 2017 at 09:06:09PM +0000, ng0 wrote:
> > > IN-Berlin wants a raw image (they have read our documentation).
> > > The way their system works is that you sent
> > > them your ssh pubkey, they initialize a basic Debian system depending on
> > > the size you chose, and you can login once you get the hostname etc.
> > > They have an out-of-band consoleserver where the ssh key is placed
> > > aswell for the machine.
> > > I don't work with this non-profit organization, but having a way to
> > > define ssh pubkeys in the system config would be super useful for this.
> > > Right now I'm about to create my own system and just sent it to them as
> > > soon as I feel up to it.
> > > If they could simply create the system in their infrastructure, that
> > > would be an incredible speedup and reproducible.
> > > I don't know much about the out of band consoleserver, I have to ask
> > > if that's somehow relevant or if it simply needs some initrd settings to
> > > expose it to the server.
> > 
> > Interesting! I'll probably take a look at this when I got some free
> > time.
> 
> I'll write an email to IN-Berlin asking about the consoleserver this
> week.
> If it's nothing special, we could provide this bare image, and people
> could download it as the GuixSD with ssh + whatever is needed for it to
> work out in server context as a start.
> 
I just realized the last sentence is not good.
Correction:
If IN-Berlin uses (or needs) nothing special for the consoleserver to
make use of the virtual servers within IN-Berlin infrastructure, I think
it would be best if we (as Guix) could provide an extended bare image
for servers which would include ssh-daemon on default port with password
login enabled, where the password is not empty. That's a workaround I
can imagine to be generic enough for all use cases.
For the one of IN-Berlin and maybe similar hosters who use ssh pubkeys,
it would be great to document for them how to recreate this image in
easy steps and insert the clients ssh pubkey for the root account (or an
named user) on the system.

What do you think about this?

Re: Advice about GuixSD on Serveraptor?

[Chris Marusich]

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

ng0 <contact.ng0@cryptolab.net> writes:

> If IN-Berlin uses (or needs) nothing special for the consoleserver to
> make use of the virtual servers within IN-Berlin infrastructure, I think
> it would be best if we (as Guix) could provide an extended bare image
> for servers which would include ssh-daemon on default port with password
> login enabled, where the password is not empty. That's a workaround I
> can imagine to be generic enough for all use cases.
> For the one of IN-Berlin and maybe similar hosters who use ssh pubkeys,
> it would be great to document for them how to recreate this image in
> easy steps and insert the clients ssh pubkey for the root account (or an
> named user) on the system.
>
> What do you think about this?

Instead of providing a pre-built image of a specific system with
pre-built credentials, wouldn't it be better to add a feature that, in
the spirit of a command like 'guix disk-image', builds an entire system
that can then be imported as-is into IN-Berlin?

In general, such a feature would be useful.  One can imagine leveraging
a feature like this to import custom GuixSD systems into various hosting
services - Amazon EC2, Rackspace, wherever.  Instead of starting with a
pre-built image that might be hard to reproduce or verify, and then
mutating that system to suit your needs, you could just import the exact
system that you want to deploy.  Wouldn't that be better?

-- 
Chris

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

Re: Advice about GuixSD on Serveraptor?

[Ludovic Courtès]

Hi!

Leo Famulari <leo@famulari.name> skribis:

> On Wed, Mar 22, 2017 at 01:20:53PM -0400, Leo Famulari wrote:
>> It's not a bad idea to build it on Hydra. Hydra already builds a
>> usb-image / disk-image job [0], so we could add a qemu-image job, too.
>
> Actually, we used to build a qemu-image on Hydra, but we removed because
> it was troublesome and unused.
>
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=a3a27745013f3e5a287de3bf0187b2f72beb6965
>
> Maybe we should try again :)

Yup, we could reinstate it if needed.  That said, we wouldn’t too many
downloads from hydra.gnu.org…

Ludo’.

Re: Advice about GuixSD on Serveraptor?

[Leo Famulari]

On Fri, Mar 24, 2017 at 10:36:08AM +0100, Ludovic Courtès wrote:
> Hi!
> 
> Leo Famulari <leo@famulari.name> skribis:
> 
> > On Wed, Mar 22, 2017 at 01:20:53PM -0400, Leo Famulari wrote:
> >> It's not a bad idea to build it on Hydra. Hydra already builds a
> >> usb-image / disk-image job [0], so we could add a qemu-image job, too.
> >
> > Actually, we used to build a qemu-image on Hydra, but we removed because
> > it was troublesome and unused.
> >
> > https://git.savannah.gnu.org/cgit/guix.git/commit/?id=a3a27745013f3e5a287de3bf0187b2f72beb6965
> >
> > Maybe we should try again :)
> 
> Yup, we could reinstate it if needed.  That said, we wouldn’t too many
> downloads from hydra.gnu.org…

If we took that route, I'd point the Serveraptor admin to the Hydra link
and ask them to download it once themselves, rather than having each
client download it.

But, making a qemu-image at each evaluation is not so good for
general distribution, because we won't have tested it as thoroughly as
the release image. We'd want the qemu-image to build only if all the
system tests passed.

Re: Advice about GuixSD on Serveraptor?

[ng0]

Chris Marusich transcribed 2.4K bytes:
> ng0 <contact.ng0@cryptolab.net> writes:
> 
> > If IN-Berlin uses (or needs) nothing special for the consoleserver to
> > make use of the virtual servers within IN-Berlin infrastructure, I think
> > it would be best if we (as Guix) could provide an extended bare image
> > for servers which would include ssh-daemon on default port with password
> > login enabled, where the password is not empty. That's a workaround I
> > can imagine to be generic enough for all use cases.
> > For the one of IN-Berlin and maybe similar hosters who use ssh pubkeys,
> > it would be great to document for them how to recreate this image in
> > easy steps and insert the clients ssh pubkey for the root account (or an
> > named user) on the system.
> >
> > What do you think about this?
> 
> Instead of providing a pre-built image of a specific system with
> pre-built credentials, wouldn't it be better to add a feature that, in
> the spirit of a command like 'guix disk-image', builds an entire system
> that can then be imported as-is into IN-Berlin?
> 
> In general, such a feature would be useful.  One can imagine leveraging
> a feature like this to import custom GuixSD systems into various hosting
> services - Amazon EC2, Rackspace, wherever.  Instead of starting with a
> pre-built image that might be hard to reproduce or verify, and then
> mutating that system to suit your needs, you could just import the exact
> system that you want to deploy.  Wouldn't that be better?
> 
> -- 
> Chris

Their system works in the way that you provide the key and they give you
access via ssh to the new server. My suggestion was a work-around.

Beyond that, can you please explain what exactly you mean? I don't want
to read between the lines as there are multiple ways I could interpret
this message.

Re: Advice about GuixSD on Serveraptor?

[Chris Marusich]

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

ng0 <contact.ng0@cryptolab.net> writes:

> Chris Marusich transcribed 2.4K bytes:
>> ng0 <contact.ng0@cryptolab.net> writes:
>> 
>> > If IN-Berlin uses (or needs) nothing special for the consoleserver to
>> > make use of the virtual servers within IN-Berlin infrastructure, I think
>> > it would be best if we (as Guix) could provide an extended bare image
>> > for servers which would include ssh-daemon on default port with password
>> > login enabled, where the password is not empty. That's a workaround I
>> > can imagine to be generic enough for all use cases.
>> > For the one of IN-Berlin and maybe similar hosters who use ssh pubkeys,
>> > it would be great to document for them how to recreate this image in
>> > easy steps and insert the clients ssh pubkey for the root account (or an
>> > named user) on the system.
>> >
>> > What do you think about this?
>> 
>> Instead of providing a pre-built image of a specific system with
>> pre-built credentials, wouldn't it be better to add a feature that, in
>> the spirit of a command like 'guix disk-image', builds an entire system
>> that can then be imported as-is into IN-Berlin?
>> 
>> In general, such a feature would be useful.  One can imagine leveraging
>> a feature like this to import custom GuixSD systems into various hosting
>> services - Amazon EC2, Rackspace, wherever.  Instead of starting with a
>> pre-built image that might be hard to reproduce or verify, and then
>> mutating that system to suit your needs, you could just import the exact
>> system that you want to deploy.  Wouldn't that be better?
>> 
>> -- 
>> Chris
>
> Their system works in the way that you provide the key and they give you
> access via ssh to the new server. My suggestion was a work-around.

I think your proposed solution is a good one.  It sounds like that's a
good way to get a GuixSD server running on IN-Berlin at this time.

> Beyond that, can you please explain what exactly you mean? I don't want
> to read between the lines as there are multiple ways I could interpret
> this message.

Sure, let me see if I can clarify what I was thinking.

For example, the Amazon EC2 service provides web APIs that one can call
to import an existing VM image into the service.  One can then launch
EC2 instances (virtual machines) from that image.  I'm sure that some
other services have similar APIs.  With Guix, we can declaratively
configure the entire operating system (including the pre-installation of
SSH credentials to enable remote access) and build an image (or a VM) of
that system.  In theory, it should be possible to create a tool (e.g.,
"guix deploy") which not only creates the precise system image you want
from an operating system configuration file, but also imports it into a
hosting service, like Amazon EC2, and provisions a virtual (or physical)
machine from that image.

The same principle could apply even for providers that don't currently
support programmatic importation of system images (like IN-Berlin,
maybe?).  For example, if a company offers to accept a bootable disk
image and provide you with a physical server that runs that image, you
could also "import" a system into that service by building the image and
then providing it (manually) to them.  If instead of a disk image they
require a bootable ISO-9669 file system image (i.e., a bootable CD-ROM
image) or a special VM format like OVF, then that's just an
implementation detail.  In theory it's still possible to "import" an
entire system by building an entire system in the format that they need,
and then (manually) providing it to them.

Based on your description, it sounds like IN-Berlin's process requires
manual touch points, so I think it's a fine solution to provide
IN-Berlin with your public SSH key (or a temporary password) along with
instructions for how to build the GuixSD system you want, wait for them
to provision the server, and then log in remotely to further customize
the system.  However, I think it would be really cool if you could just
specify the final, customized system (SSH keys and all) in an operating
system configuration file and then invoke a tool like "guix
deploy-to-ec2 my-system-config.scm" to build the system described by
my-system-config.scm, import it into EC2 (or some other service or
provider), and run it on there.  It would be really cool because your
system wouldn't start in a possibly stale or difficult-to-reproduce base
system, and you wouldn't need to perform additional customization after
the system starts up.  All customizations (to the extent that they are
managed by Guix - things like the contents of user home directories and
the state contained in databases running on the system are not managed
by Guix) would be declared in the operating system configuration file.

Currently, I don't think Guix has the features necessary to support this
kind of programmatic importation of GuixSD systems into service
providers like Amazon EC2.  But the potential is there, and it's good to
think big.

-- 
Chris

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

Re: Advice about GuixSD on Serveraptor?

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> On Fri, Mar 24, 2017 at 10:36:08AM +0100, Ludovic Courtès wrote:
>> Hi!
>> 
>> Leo Famulari <leo@famulari.name> skribis:
>> 
>> > On Wed, Mar 22, 2017 at 01:20:53PM -0400, Leo Famulari wrote:
>> >> It's not a bad idea to build it on Hydra. Hydra already builds a
>> >> usb-image / disk-image job [0], so we could add a qemu-image job, too.
>> >
>> > Actually, we used to build a qemu-image on Hydra, but we removed because
>> > it was troublesome and unused.
>> >
>> > https://git.savannah.gnu.org/cgit/guix.git/commit/?id=a3a27745013f3e5a287de3bf0187b2f72beb6965
>> >
>> > Maybe we should try again :)
>> 
>> Yup, we could reinstate it if needed.  That said, we wouldn’t too many
>> downloads from hydra.gnu.org…
>
> If we took that route, I'd point the Serveraptor admin to the Hydra link
> and ask them to download it once themselves, rather than having each
> client download it.
>
> But, making a qemu-image at each evaluation is not so good for
> general distribution, because we won't have tested it as thoroughly as
> the release image. We'd want the qemu-image to build only if all the
> system tests passed.

Yeah I think recent Hydra can present a release page if and only if some
other derivations also succeeded with the same commit.

Anyway, let us know what you think is the right approach for now!

Thanks,
Ludo’.

Re: Advice about GuixSD on Serveraptor?

[Ludovic Courtès]

Hi!

Chris Marusich <cmmarusich@gmail.com> skribis:

> For example, the Amazon EC2 service provides web APIs that one can call
> to import an existing VM image into the service.  One can then launch
> EC2 instances (virtual machines) from that image.  I'm sure that some
> other services have similar APIs.  With Guix, we can declaratively
> configure the entire operating system (including the pre-installation of
> SSH credentials to enable remote access) and build an image (or a VM) of
> that system.  In theory, it should be possible to create a tool (e.g.,
> "guix deploy") which not only creates the precise system image you want
> from an operating system configuration file, but also imports it into a
> hosting service, like Amazon EC2, and provisions a virtual (or physical)
> machine from that image.

Yes, I think that’s one of the targets David had in mind for ‘guix
deploy’.

[...]

> Currently, I don't think Guix has the features necessary to support this
> kind of programmatic importation of GuixSD systems into service
> providers like Amazon EC2.  But the potential is there, and it's good to
> think big.

Right, ‘guix deploy’ doesn’t exist yet.  That said, the branch is there
<https://git.savannah.gnu.org/cgit/guix.git/log/?h=wip-deploy> with
interfaces meant to support deployment to physical machines over SSH,
VMs, containers, etc., though the only backend available is VMs at this
point.

I think it’s about time to revive this branch!

Ludo’.

Re: Advice about GuixSD on Serveraptor?

[ng0]

Chris Marusich transcribed 5.9K bytes:
> ng0 <contact.ng0@cryptolab.net> writes:
> 
> > Chris Marusich transcribed 2.4K bytes:
> >> ng0 <contact.ng0@cryptolab.net> writes:
> >> 
> >> > If IN-Berlin uses (or needs) nothing special for the consoleserver to
> >> > make use of the virtual servers within IN-Berlin infrastructure, I think
> >> > it would be best if we (as Guix) could provide an extended bare image
> >> > for servers which would include ssh-daemon on default port with password
> >> > login enabled, where the password is not empty. That's a workaround I
> >> > can imagine to be generic enough for all use cases.
> >> > For the one of IN-Berlin and maybe similar hosters who use ssh pubkeys,
> >> > it would be great to document for them how to recreate this image in
> >> > easy steps and insert the clients ssh pubkey for the root account (or an
> >> > named user) on the system.
> >> >
> >> > What do you think about this?
> >> 
> >> Instead of providing a pre-built image of a specific system with
> >> pre-built credentials, wouldn't it be better to add a feature that, in
> >> the spirit of a command like 'guix disk-image', builds an entire system
> >> that can then be imported as-is into IN-Berlin?
> >> 
> >> In general, such a feature would be useful.  One can imagine leveraging
> >> a feature like this to import custom GuixSD systems into various hosting
> >> services - Amazon EC2, Rackspace, wherever.  Instead of starting with a
> >> pre-built image that might be hard to reproduce or verify, and then
> >> mutating that system to suit your needs, you could just import the exact
> >> system that you want to deploy.  Wouldn't that be better?
> >> 
> >> -- 
> >> Chris
> >
> > Their system works in the way that you provide the key and they give you
> > access via ssh to the new server. My suggestion was a work-around.
> 
> I think your proposed solution is a good one.  It sounds like that's a
> good way to get a GuixSD server running on IN-Berlin at this time.
> 
> > Beyond that, can you please explain what exactly you mean? I don't want
> > to read between the lines as there are multiple ways I could interpret
> > this message.
> 
> Sure, let me see if I can clarify what I was thinking.

Thanks, I think once guix deploy has basic functionality it would be
good to get IN-Berlin involved at my end, so that we can understand
their workflow (working with raw images + consoleserver), and integrate
GuixSD in their currently Debian-only system.
 
> For example, the Amazon EC2 service provides web APIs that one can call
> to import an existing VM image into the service.  One can then launch
> EC2 instances (virtual machines) from that image.  I'm sure that some
> other services have similar APIs.  With Guix, we can declaratively
> configure the entire operating system (including the pre-installation of
> SSH credentials to enable remote access) and build an image (or a VM) of
> that system.  In theory, it should be possible to create a tool (e.g.,
> "guix deploy") which not only creates the precise system image you want
> from an operating system configuration file, but also imports it into a
> hosting service, like Amazon EC2, and provisions a virtual (or physical)
> machine from that image.
> 
> The same principle could apply even for providers that don't currently
> support programmatic importation of system images (like IN-Berlin,
> maybe?).  For example, if a company offers to accept a bootable disk
> image and provide you with a physical server that runs that image, you
> could also "import" a system into that service by building the image and
> then providing it (manually) to them.  If instead of a disk image they
> require a bootable ISO-9669 file system image (i.e., a bootable CD-ROM
> image) or a special VM format like OVF, then that's just an
> implementation detail.  In theory it's still possible to "import" an
> entire system by building an entire system in the format that they need,
> and then (manually) providing it to them.
> 
> Based on your description, it sounds like IN-Berlin's process requires
> manual touch points, so I think it's a fine solution to provide
> IN-Berlin with your public SSH key (or a temporary password) along with
> instructions for how to build the GuixSD system you want, wait for them
> to provision the server, and then log in remotely to further customize
> the system.  However, I think it would be really cool if you could just
> specify the final, customized system (SSH keys and all) in an operating
> system configuration file and then invoke a tool like "guix
> deploy-to-ec2 my-system-config.scm" to build the system described by
> my-system-config.scm, import it into EC2 (or some other service or
> provider), and run it on there.  It would be really cool because your
> system wouldn't start in a possibly stale or difficult-to-reproduce base
> system, and you wouldn't need to perform additional customization after
> the system starts up.  All customizations (to the extent that they are
> managed by Guix - things like the contents of user home directories and
> the state contained in databases running on the system are not managed
> by Guix) would be declared in the operating system configuration file.
> 
> Currently, I don't think Guix has the features necessary to support this
> kind of programmatic importation of GuixSD systems into service
> providers like Amazon EC2.  But the potential is there, and it's good to
> think big.
> 
> -- 
> Chris