On Tue, 2003-11-11 at 22:45, Ron OHara wrote: > Chris Gianelloni wrote: > > >On Mon, 2003-11-10 at 23:39, Ron OHara wrote: > > > > > >>Chris Gianelloni wrote: > >> > >> > >> > >>>On Sun, 2003-11-09 at 22:46, Ron OHara wrote: > >>> > >>> > >>> > >>> > >>>>Lisa Seelye wrote: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>On Sun, 2003-11-09 at 22:00, Ron OHara wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>Hi, > >>>>>> > >>>>>>I want to raise an issue resulting from my experience so far in using > >>>>>>Gentoo as the basis of production systems. Some may ask why? - but > >>>>>>basically 'portage' seems to offer the very best framework for ongoing > >>>>>>maintenance/admin of systems, though it's not perfect in that role. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>There are a couple things you may want to look into. > >>>>> > >>>>>First, have you considered setting up your own rsync repository? > >>>>>Second, how about using PORTAGE_OVERLAY to save ebuilds. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>An rsync repository is another part of the production deployment issues, > >>>>(especially for bandwidth issues) but ideally the overall process should > >>>>not force me to duplicate the managment effort that already goes into > >>>>maintaining the Gentoo portage 'repository'. That work is already being > >>>>done so it seems silly to have to manually administer a downstream > >>>>repository just to preserve 'old' ebuilds - and even then, the true > >>>>repository of which ebuilds are needed for a specific system is held on > >>>>that system .. not on another server. > >>>> > >>>>To a degree, the same thing applies to the PORTAGE_OVERLAY setting - > >>>>that tree may be a suitable place to preserve older ebuilds that are > >>>>being removed from the central portage, but I dont want to maintain it > >>>>manually on hundreds of systems. > >>>> > >>>> > >>>> > >>>> > >>>Two words... > >>> > >>>NFS mounts > >>> > >>>=] > >>> > >>> > >>> > >>> > >>>>-- > >>>>[EMAIL PROTECTED] mailing list > >>>> > >>>> > >>>> > >>>> > >>Hmmm ... NFS works when the systems are all nicely connected with > >>bandwidth, but most of these will be unique nodes on a private microwave > >>network (to avoid the local Telco charges .a.k.a 'gouging' - at $0.19 > >>per megabyte of traffic) > >> > >> > > > >That makes a big difference. In that case, I would run your own rsync > >mirror for portage and have all the machines sync to your mirror. I > >would also make a packages mirror, where you store your packages, and > >have all the machines pull their packages from that site. That way > >nothing gets added or removed from portage, except what you specifiy, > >and you also get the added upgrade speed and ease of binary packages. > > > > > > > I am assuming the deployment of a private rsync mirror (and packages > mirror) - BUT - the current setup removes .ebuilds unless I manually > intervene. Something I want to avoid. I just want to accumulate ebuilds > by default to match the exact version of compiled code on each box. Then > any given machine can be recompiled if required, without regard to > accessing an external repository.
Well, what I would do is have the rsync mirror *not* mirror the "official" Gentoo tree into its rsync, but rather into the normal /usr/portage. I would then manually move ebuilds for security fixes and any upgrades I wanted into the rsync tree. The same would be true of the packages. That way you only have *exactly* what you want and have approved available to the client machines. e.g. /usr/portage is normal portage tree, /usr/portage/packages is normal package tree, /var/rsync/portage is YOUR portage tree. I would publish the packages via a web server. The nice thing about this is that you can standardize on quite a bit of packages. If you wanted everyone using KDE, for example, you simply don't copy any of Gnome's ebuilds to your /var/rsync/portage tree. -- Chris Gianelloni Developer, Gentoo Linux Games Team Is your power animal a pengiun?
signature.asc
Description: This is a digitally signed message part
