1 |
On Wed, 28 Dec 2016 02:37:53 +0100 |
2 |
Sebastian Pipping <sping@g.o> wrote: |
3 |
|
4 |
> Hi there! |
5 |
> |
6 |
> |
7 |
> My impression is that: |
8 |
> |
9 |
> * a large number of people still sync /usr/portage using plain |
10 |
> rsync, |
11 |
> |
12 |
> * it is not a trivial choice which source to switch to. |
13 |
> |
14 |
> Do we have documentation comparing options for syncing /usr/portage? |
15 |
> |
16 |
> |
17 |
> The rest of this mail is a collection of methods that I am aware of. |
18 |
> It could become the start of a wiki page if missing or so. |
19 |
> |
20 |
> Best |
21 |
> |
22 |
> |
23 |
> |
24 |
> Sebastian |
25 |
> |
26 |
> |
27 |
> === |
28 |
> |
29 |
> Sync options that I am aware of include: |
30 |
> |
31 |
> * Plain rsync |
32 |
> |
33 |
> * Git: 4x direct source (Ebuilds + DTD + GLSA + News) |
34 |
> |
35 |
> * Git: combined mirror [1] |
36 |
> |
37 |
> * webrsync: Plain |
38 |
> |
39 |
> * webrsync: With GPG [2] |
40 |
> |
41 |
> * ..? |
42 |
> |
43 |
> |
44 |
> The key questions for differences and picking I see are: |
45 |
> |
46 |
> * Does it use secure transport, e.g. SSL? |
47 |
|
48 |
The webrsync module needs to be re-written in python to better fit the |
49 |
new plugin-sync system. It can then take advantage of gkeys use of the |
50 |
ssl-fetch lib which layman and mirrorselect are using for verified ssl |
51 |
connections and downloads, complete with gpg verification. Zac made a |
52 |
patch for the current webrsync module that uses gkeys for verification, |
53 |
but it is waiting for a stable release of gkeys before it will be |
54 |
released. |
55 |
|
56 |
> |
57 |
> * Does it verify GPG signatures? |
58 |
|
59 |
Currently, Only GPG enabled webrsync. The meta-manifest system code |
60 |
from gsoc-2016 is in the process of being worked on and will be merged |
61 |
into portage very soon. It needs a couple updates for the Changelog |
62 |
changes (I believe) and I am working to get another gkeys release out |
63 |
that should be able to go stable. With that the meta-manifest code and |
64 |
gkeys use will go into portage, so the new system will be capable of |
65 |
normal rsync with partial tree downloads. It will then gpg verify |
66 |
everything in the local tree. |
67 |
|
68 |
|
69 |
> |
70 |
> * Does it support incremental updates? |
71 |
|
72 |
|
73 |
A new meta-manifest enabled rsync tree will support both gpg |
74 |
verification as well as partial tree downloads. |
75 |
|
76 |
> |
77 |
> * Does it come with metadata/md5-cache pre-generated? |
78 |
> |
79 |
> * How much delay does it have? |
80 |
> |
81 |
> |
82 |
> [1] https://github.com/gentoo-mirror/gentoo |
83 |
> [2] |
84 |
> http://blog.siphos.be/2011/07/emerge-webrsync-and-gpg-verification/ |
85 |
> |
86 |
|
87 |
I hope to get a gkeys release out by the end of the current holidays |
88 |
which includes all teh gsoc-2016 work. Plus some other changes that |
89 |
should make gkeys stable (including a semi-automated update system for |
90 |
users. With a little help, the gkeys-ldap portion of the repo will begin |
91 |
to get merged into infra to auto-generate the seed files. |
92 |
|
93 |
Also, infra had been looking at getting keycards for new infra |
94 |
openpgp keys which will be used as part of the gpg process. |
95 |
|
96 |
-- |
97 |
Brian Dolbec <dolsen> |