From mboxrd@z Thu Jan 1 00:00:00 1970 From: ng0 Subject: Re: Advice about GuixSD on Serveraptor? Date: Sun, 26 Mar 2017 11:54:56 +0000 Message-ID: <20170326115456.dpbo6ji42nae6l5e@abyayala> References: <20170321180638.GA3027@jasmine> <87mvcenzvw.fsf@dustycloud.org> <20170321204620.GA30143@jasmine> <20170321210609.rmugh5l26eqicrhd@abyayala> <20170322171538.GA6011@jasmine> <20170322192023.ij2mzykimne7lfii@abyayala> <20170322210106.f6z7vwavsna3qfg4@abyayala> <87k27fcmwx.fsf@gmail.com> <20170324163447.dmrtjiulnhhjx7q2@abyayala> <87mvc9raqq.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:48085) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cs5ph-00069w-Vg for guix-devel@gnu.org; Sun, 26 Mar 2017 06:55:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cs5pe-0007sl-Tt for guix-devel@gnu.org; Sun, 26 Mar 2017 06:55:38 -0400 Received: from fragranza.investici.org ([178.175.144.26]:45708) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cs5pe-0007rn-C9 for guix-devel@gnu.org; Sun, 26 Mar 2017 06:55:34 -0400 Content-Disposition: inline In-Reply-To: <87mvc9raqq.fsf@gmail.com> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Chris Marusich Cc: guix-devel@gnu.org Chris Marusich transcribed 5.9K bytes: > ng0 writes: > > > Chris Marusich transcribed 2.4K bytes: > >> ng0 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