1 |
On Thu, Jan 18, 2018 at 6:46 AM, Anthony G. Basile <blueness@g.o> |
2 |
wrote: |
3 |
|
4 |
> Hi everyone, |
5 |
> |
6 |
> I'm trying to design an update system for many identical Gentoo systems. |
7 |
> Using a binhost is obvious, but there are still problems with this |
8 |
> approach. |
9 |
> |
10 |
> Unless there's some magic I don't know about (and this is why I'm |
11 |
> sending this email) each machine still needs to have the portage tree |
12 |
> installed locally (1.5 GB) or somehow mounted by a network filesystem |
13 |
> (which is not practical if the machines are not on a local network). |
14 |
> |
15 |
|
16 |
+Zac |
17 |
|
18 |
I don't believe this is true; with the correct binhost configuration |
19 |
portage should: |
20 |
|
21 |
1) Contact the binhost to get a dump of packages available on it. |
22 |
2) Use that dump to create a 'virtual portage tree' (bindb). |
23 |
3) Use the bindb for package discovery (is foo available) and dependency |
24 |
calculation. |
25 |
|
26 |
|
27 |
> Furthermore, each machine would have to run emerge locally to do the |
28 |
> calculation of what packages need updating. |
29 |
> |
30 |
|
31 |
The good news is that with a bindb; the package tree itself is much |
32 |
smaller. ::gentoo is 23000 packages. |
33 |
But you bindb is only as large as you build binpkgs for and publish them. |
34 |
So say stage3 + some other stuff. |
35 |
Around 500 packages perhaps. |
36 |
|
37 |
A couple of exciting problems might include: |
38 |
|
39 |
1) How to expose the bindb to machines? |
40 |
2) How to secure bindb updates (HTTPS?) |
41 |
|
42 |
|
43 |
> This procedure is redundant because each machine is housing the same |
44 |
> data and doing the same dependence-tree calculation. It should be |
45 |
> possible to do this calculation on a centralized binhost and simply |
46 |
> communicate the update information to the remote machines. They would |
47 |
> then only have to download the .tbz2's and install them, keeping a tidy |
48 |
> /var/db/pkg. Thus they avoid having to house the portage tree and |
49 |
> burning cpu cycles that just calculate redundant information. |
50 |
> |
51 |
|
52 |
Emerge used to have support for emerge package.tar.gz; I wonder if it still |
53 |
works? |
54 |
I haven't seen anyone use it in forever? |
55 |
|
56 |
antarus@woodpecker ~ $ emerge --help |
57 |
emerge: command-line interface to the Portage system |
58 |
Usage: |
59 |
emerge [ options ] [ action ] [ ebuild | tbz2 | file | @set | atom ] [ ... ] |
60 |
emerge [ options ] [ action ] < @system | @world > |
61 |
|
62 |
Note that 'tbz2' is still listed ;) |
63 |
|
64 |
|
65 |
> |
66 |
> I'm inspired here by OpenBSD's pkg_add which doesn't require all of |
67 |
> ports to be installed, and mender which is a |
68 |
> |
69 |
|
70 |
An alternative is that your central build hosts builds images instead of |
71 |
packages. |
72 |
You then boot your devices into a new image to get updates. This is a |
73 |
pretty common pattern for embedded devices. |
74 |
You need a secure method to deliver new images and probably a sane method |
75 |
for rollback of a bad image. |
76 |
Typically this is done with a bootloader and 3 image slots: |
77 |
|
78 |
SLOT A: Current image. |
79 |
SLOT B: Proposed update image. |
80 |
SLOT C: Recovery Image # usually RO. |
81 |
|
82 |
Bootloader boots A normally; but during update boots B. If A and B fail to |
83 |
boot, Boots C. |
84 |
|
85 |
|
86 |
> |
87 |
> Any ideas? |
88 |
> |
89 |
> -- |
90 |
> Anthony G. Basile, Ph.D. |
91 |
> Gentoo Linux Developer [Hardened] |
92 |
> E-Mail : blueness@g.o |
93 |
> GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA |
94 |
> GnuPG ID : F52D4BBA |
95 |
> |
96 |
> |