From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: Re: Advice about GuixSD on Serveraptor? Date: Sat, 25 Mar 2017 02:01:17 -0700 Message-ID: <87mvc9raqq.fsf@gmail.com> References: <20170213214717.GA11352@jasmine> <20170313003252.GA12094@jasmine> <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> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:44250) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1crhZe-0008HN-2T for guix-devel@gnu.org; Sat, 25 Mar 2017 05:01:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1crhZc-0003Pv-MF for guix-devel@gnu.org; Sat, 25 Mar 2017 05:01:26 -0400 Received: from mail-pf0-x22f.google.com ([2607:f8b0:400e:c00::22f]:34178) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1crhZc-0003Pl-Dp for guix-devel@gnu.org; Sat, 25 Mar 2017 05:01:24 -0400 Received: by mail-pf0-x22f.google.com with SMTP id p189so5471395pfp.1 for ; Sat, 25 Mar 2017 02:01:24 -0700 (PDT) In-Reply-To: <20170324163447.dmrtjiulnhhjx7q2@abyayala> (ng0's message of "Fri, 24 Mar 2017 16:34:47 +0000") 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: Leo Famulari , ng0 Cc: guix-devel@gnu.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable ng0 writes: > Chris Marusich transcribed 2.4K bytes: >> ng0 writes: >>=20 >> > If IN-Berlin uses (or needs) nothing special for the consoleserver to >> > make use of the virtual servers within IN-Berlin infrastructure, I thi= nk >> > 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 passwo= rd >> > 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? >>=20 >> 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? >>=20 >> 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? >>=20 >> --=20 >> 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. =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAljWMd0ACgkQ3UCaFdgi Rp2Vvw/9F1pXz1ZwO3K9YMYvngLJxrXU8kGGrjzzxKd5jtB9omQWA15n2UCh3piz LgPP5bbF9uvO/cZeYRx9bb/NkP1B3YPhNbDYmiEm/khmCcakZ5Can1S8DCyWWkrC E975hOU7cNYZOQDWCj5uwZF2mq3LWFfr0f2Foq2nPWS4z55SI6cQe0ujlh3dW+17 zde47Dco/j1/IqhUegujuC/XfhRy9DVnR1GVxW477rcf6LlSMnCHRNoy4rFqp44V QR6OLHvfk+IYkziWUe75bsUQjVLjJe4waC8UEPW5ehXvjGvJt3PXltFeT7VoXOj4 T7kzjkSaT/xS8O/2xenqUyiTz4CxzYb2xz+Py9RkIkPUD0EK226bdeZ5XCOYqxqJ VvPNcN2M+/WUfG//X2hlKSI0CXj1dSa9SeiF7YfMQC32/yWjSdzw+iGb2gH/x1gp aHruGwsYS2FVGMjaWBfpWIDKtPeQ3nq38T80akRCt7cv6Vfm4hUhpXQOkEc105CN zcVRl/rDVim8+IVHQ+l3GzJdMkgOcMA5dB2rwIYGakC2AWTU8oVi8qEd2Sa1U966 ixxP2fD/WYhYtGQ20Y7YFGBm03JSS2pyyabJkGMq1EBsKP8gnjAbekqNB6sRuaIL PmZwClDlARCrcIowwT1+Ef/ikUQyytvFQhEhmOHkTmupbN3ohdM= =RTVR -----END PGP SIGNATURE----- --=-=-=--