Gentoo Archives: gentoo-user

From: n952162@×××.de
To: gentoo-user@l.g.o
Subject: Aw: Re: [gentoo-user] local mirrors
Date: Fri, 26 Apr 2019 05:42:39
Message-Id: trinity-46ac49ff-c2d6-4a42-a947-60246e6f69d4-1556257338347@3c-app-webde-bs09
In Reply to: Aw: Re: [gentoo-user] local mirrors by n952162@web.de
1 What I'm hoping for, though, is a configuration flag that causes any of:
2 - inhibits a theoretical traversal of repos.conf databases (e.g. also /usr/share/porrage/...)
3 - inhibits trying to upgrade beyond what's already installed in the mirror server
4
5 > Gesendet: Freitag, 26. April 2019 um 07:32 Uhr
6 > Von: n952162@×××.de
7 > An: gentoo-user@l.g.o
8 > Betreff: Aw: Re: [gentoo-user] local mirrors
9 >
10 > Thank you for the explanation. I wonder what the local mirror page means when it talks about saving bandwidth. What *does* it serve if not the distfiles? And when /etc/portage/repos.conf points to my local server, why would portage disregard that?
11 >
12 > The rsync server on the mirror host points to the gentoo portage installation on that local mirror host. How can any metadata there know about anything that's not already resolved there?
13 >
14 > At the very least, I suspect that that local mirror page is wrong and rather refers to something that *could* be implemented (without extra packages being installed, just by configuration), but isn't yet.
15 >
16 > > Gesendet: Freitag, 26. April 2019 um 00:35 Uhr
17 > > Von: "Rich Freeman" <rich0@g.o>
18 > > An: gentoo-user@l.g.o
19 > > Betreff: Re: [gentoo-user] local mirrors
20 > >
21 > > On Thu, Apr 25, 2019 at 5:44 PM <n952162@×××.de> wrote:
22 > > >
23 > > > So, I set up the rsync deamon on my "mirror server" host and the /etc/portage/repos.conf/gentoo.conf file on the client machine, run the recommended test and everything is just as described. I sync my client, and am very happy.
24 > > >
25 > > > By coincidence, I happen to look in /var/log/emerge-fetch.log on the client and discover that everything got fetched remotely, from, like gentoo.org and rubygems.org, etc.
26 > > >
27 > > > What a disappointment! Is there something I still have to do?
28 > > >
29 > >
30 > > The repository and distfiles both need to be separately mirrored.
31 > > Maintaining a distfiles mirror is a bit more complex as all your hosts
32 > > probably don't have the same packages installed, and fetching
33 > > distfiles for all the packages would use a ton of space (and
34 > > bandwidth). For Gentoo official mirrors this is exactly what is done,
35 > > but of course they get used by many users.
36 > >
37 > > What I have done at times is run apache on one host and serve out its
38 > > local distfiles cache, and then list this as the first mirror in the
39 > > list for my other hosts. So, they try to fetch from that host before
40 > > going out to the internet. However, that doesn't do anything to
41 > > ensure that the needed files are on that host. It just helps with
42 > > @system packages and other packages the hosts have in common. That is
43 > > an approach that doesn't really cost you anything and probably
44 > > provides 75% of the benefit. It is also easy to do if you have a
45 > > bunch of identical hosts and then yields 100% of the benefit (if
46 > > they're truly identical I'd go a step further and set up a binpkg
47 > > mirror as there is no point in building the same thing many times with
48 > > the same flags).
49 > >
50 > > If you really want to run a full distfiles mirror I'm sure the infra
51 > > scripts are floating around somewhere. It probably just amounts to
52 > > running an ebuild fetch on every ebuild in the repo.
53 > >
54 > > --
55 > > Rich
56 > >
57 > >
58 >
59 >

Replies