From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 1D968138206 for ; Fri, 19 Jan 2018 18:13:35 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0F9B7E0930; Fri, 19 Jan 2018 18:13:29 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 9E7C5E08FC for ; Fri, 19 Jan 2018 18:13:28 +0000 (UTC) Received: from [10.128.17.34] (unknown [100.42.98.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: zmedico) by smtp.gentoo.org (Postfix) with ESMTPSA id D41D7335C37; Fri, 19 Jan 2018 18:13:26 +0000 (UTC) Subject: Re: [gentoo-dev] Re: Managing updates on many identical Gentoo systems To: gentoo-dev@lists.gentoo.org, "Anthony G. Basile" References: <2686de8e-334c-084b-4828-6109b10dd536@gentoo.org> From: Zac Medico Message-ID: <052a50fb-f878-4468-c065-6ff1b0fadc8e@gentoo.org> Date: Fri, 19 Jan 2018 10:13:23 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PGnLmWZrr0E6zPCqFp2vmQyaox8HS9St8" X-Archives-Salt: ca508b15-2241-45a8-993f-0c8c0a30f9c3 X-Archives-Hash: 5aa90dc42baeb3fbe8c4a91e360a2e75 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PGnLmWZrr0E6zPCqFp2vmQyaox8HS9St8 Content-Type: multipart/mixed; boundary="6Gp9zUucB9NEc5oTtnRNJzVPXV9UHGrkx"; protected-headers="v1" From: Zac Medico To: gentoo-dev@lists.gentoo.org, "Anthony G. Basile" Message-ID: <052a50fb-f878-4468-c065-6ff1b0fadc8e@gentoo.org> Subject: Re: [gentoo-dev] Re: Managing updates on many identical Gentoo systems References: <2686de8e-334c-084b-4828-6109b10dd536@gentoo.org> In-Reply-To: --6Gp9zUucB9NEc5oTtnRNJzVPXV9UHGrkx Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 01/19/2018 07:03 AM, Anthony G. Basile wrote: > On 1/19/18 9:45 AM, Alec Warner wrote: >> On Thu, Jan 18, 2018 at 5:13 PM, Bill Kenworthy w= rote: >> >>> On 18/01/18 23:36, Duncan wrote: >>>> Anthony G. Basile posted on Thu, 18 Jan 2018 06:46:53 -0500 as excer= pted: >>>> >>>>> I'm trying to design an update system for many identical Gentoo sys= tems. >>>>> Using a binhost is obvious, but there are still problems with this= >>>>> approach. >>>>> >>> >>> I'd suggest go for a semi diskless OS - boot them from one central im= age >>> with an individual overlay filesystem with local customisations. NFS= >>> mount the common directories. >>> >>> you just have a one central host to build for and don't need to worry= >>> about portage everywhere. >>> >>> Worked ok with a small number of mythtv frontends. >>> >> >> It doesn't work if you have a WAN; NFS needs low latencies between the= NFS >> server and the client or you will have a bad time. >> >> >=20 > Zac pretty much nailed the requirements in bug #644990. You should not= > need the portage tree at all, neither locally nor via any network > filesystem. He mentions there that it is currently possible via "a > dummy profile", but I'm not sure what he means by that yet or how to se= t > one up. The dummy profile consists of making a /etc/portage/make.profile/ directory that is nearly empty, containing only a make.defaults file with minimal settings like these: ARCH=3D"amd64" ACCEPT_KEYWORDS=3D"**" ACCEPT_LICENSE=3D"*" You also need a big IUSE_IMPLICIT setting in there if you don't have this patch that's in portage-2.3.19: https://gitweb.gentoo.org/proj/portage.git/commit/?id=3D2382082dcfce5e6c2= be7c4dd6aed7c32e1d20616 With the dummy profile, you can install all of the packages available in the binhost. Currently, there's not a really good way to tell emerge to install all packages from the binhost, but you can parse them all from ${PORTAGE_BINHOST}/Packages and write the list to /var/lib/portage/world or something similar. Then `emerge -vuGD @world`. I've described my currently planned sequence of steps here: https://bugs.gentoo.org/644990#c3 If you try the dummy profile approach, then if there are any in-place package moves in the binhost then you may have problems with file collisions, but I've described how I plan to handle that in the above bug comment. --=20 Thanks, Zac --6Gp9zUucB9NEc5oTtnRNJzVPXV9UHGrkx-- --PGnLmWZrr0E6zPCqFp2vmQyaox8HS9St8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iHEEARECADEWIQSG5RNTeMgVEruefzL96O+FrlcZowUCWmI1QxMcem1lZGljb0Bn ZW50b28ub3JnAAoJEP3o74WuVxmjo3sAmQEfc8HlnkiN4zCnxQkcYiHlVhmHAJwK 2r1K4hlq25O2F5N8h8RzekCuqQ== =Mq1n -----END PGP SIGNATURE----- --PGnLmWZrr0E6zPCqFp2vmQyaox8HS9St8--