Chris Marusich transcribed 5.9K bytes: > ng0 <contact....@cryptolab.net> writes: > > > Chris Marusich transcribed 2.4K bytes: > >> ng0 <contact....@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
