Re: Advice about GuixSD on Serveraptor?

[Chris Marusich]

ng0 <address@hidden> writes:

> Chris Marusich transcribed 2.4K bytes:
>> ng0 <address@hidden> 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

signature.asc
Description: PGP signature