[Spacewalk-list] Re: Need for a lightweight mirroring solution

[Michael DeHaan]

Michael DeHaan wrote:
> Many questions I get on cobbler's mailing list deal with using 
> yum_rhn_plugin to mirror RHEL packages.   These are typically from 
> users who have small-mid size environments that cannot use Satellite 
> for various reasons.
>
> The problem with this is that Spacewalk/Satellite's yum_rhn_plugin can 
> only be used to mirror packages that match the arch (and distro) of 
> the requestor.  There is not a good solution for older RHEL or other 
> arches.
>
> Folks who get fed up with this generally turn to mrepo's rhnget, which 
> is a less than elegant solution for several reasons --more so, it does 
> not properly track entitlements, so it's a bit hard to audit what 
> systems are using what.   It's basically a script that uses part of 
> the up2date code.
>
> Now that Spacewalk is out, anyone care to use this list/thread to 
> jumpstart (err, kickstart?) some discussions about getting 
> https://fedorahosted.org/pulp moving again?   I am not so much 
> interested in the whole TurboGears UI idea, primarily I just want to 
> see command line tools and an API to faciliate easier mirroring.  If 
> done as a side-project, it could also be done in such a way as to not 
> require Oracle.
>
> Since cobbler already contains constructs for repo mirroring via yum, 
> and we are integrating this into Satellite, perhaps this is something 
> that can be done under cobbler's umbrella to save a bit of 
> infrastructure.    (There is already a completed web app, mirroring 
> code, an XMLPPC interface, and so forth).   Still, I have zero idea 
> how the entitlements connection would work.
>
> Comments?   Discussion?  Fire away.
>
> --Michael
>
>
>

One potential option is we borrow the relevant ideas from rhnget and 
combine that with Robin Norwood's yumgate 
(https://lists.dulug.duke.edu/pipermail/yum-devel/2006-November/002856.html) 
and use that to provide access to the newly mirrored repo.  Each repo 
can then keep a list of the individual machines that connnect to it and 
will make sure that systems the admin does not want to connect to the 
repo do not have access.

The admin could then also be able to run something to the effect of 
"$program repo usage" to see the list of all the systems who connected 
to that repo and the last time they connected.

This would require packaging the yumgate plugin but otherwise does not 
seem like it would require much code server side at all.

This could also be used to restrict access to repos containing 
(unfortunate, but they exist) closed source applications, which is an 
occasional use case for Linux apps in some universities, etc.  (Who can 
get access to FancyCADApplication3000, for instance).

--Michael