Re: Advice about GuixSD on Serveraptor?

[ng0 <contact.ng0@cryptolab.net>]

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