On Thu, Jan 18, 2018 at 6:46 AM, Anthony G. Basile <[email protected]> wrote:
> Hi everyone, > > I'm trying to design an update system for many identical Gentoo systems. > Using a binhost is obvious, but there are still problems with this > approach. > > Unless there's some magic I don't know about (and this is why I'm > sending this email) each machine still needs to have the portage tree > installed locally (1.5 GB) or somehow mounted by a network filesystem > (which is not practical if the machines are not on a local network). > +Zac I don't believe this is true; with the correct binhost configuration portage should: 1) Contact the binhost to get a dump of packages available on it. 2) Use that dump to create a 'virtual portage tree' (bindb). 3) Use the bindb for package discovery (is foo available) and dependency calculation. > Furthermore, each machine would have to run emerge locally to do the > calculation of what packages need updating. > The good news is that with a bindb; the package tree itself is much smaller. ::gentoo is 23000 packages. But you bindb is only as large as you build binpkgs for and publish them. So say stage3 + some other stuff. Around 500 packages perhaps. A couple of exciting problems might include: 1) How to expose the bindb to machines? 2) How to secure bindb updates (HTTPS?) > This procedure is redundant because each machine is housing the same > data and doing the same dependence-tree calculation. It should be > possible to do this calculation on a centralized binhost and simply > communicate the update information to the remote machines. They would > then only have to download the .tbz2's and install them, keeping a tidy > /var/db/pkg. Thus they avoid having to house the portage tree and > burning cpu cycles that just calculate redundant information. > Emerge used to have support for emerge package.tar.gz; I wonder if it still works? I haven't seen anyone use it in forever? antarus@woodpecker ~ $ emerge --help emerge: command-line interface to the Portage system Usage: emerge [ options ] [ action ] [ ebuild | tbz2 | file | @set | atom ] [ ... ] emerge [ options ] [ action ] < @system | @world > Note that 'tbz2' is still listed ;) > > I'm inspired here by OpenBSD's pkg_add which doesn't require all of > ports to be installed, and mender which is a > An alternative is that your central build hosts builds images instead of packages. You then boot your devices into a new image to get updates. This is a pretty common pattern for embedded devices. You need a secure method to deliver new images and probably a sane method for rollback of a bad image. Typically this is done with a bootloader and 3 image slots: SLOT A: Current image. SLOT B: Proposed update image. SLOT C: Recovery Image # usually RO. Bootloader boots A normally; but during update boots B. If A and B fail to boot, Boots C. > > Any ideas? > > -- > Anthony G. Basile, Ph.D. > Gentoo Linux Developer [Hardened] > E-Mail : [email protected] > GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA > GnuPG ID : F52D4BBA > >
