[et-mgmt-tools] Using cobbler to mirror repos like updates/extras -- further information

[Michael DeHaan]

Demetri Mouratis wrote:
> On 2/23/07, Michael DeHaan <mdehaan at redhat.com> wrote:
>>
>> What we have here is a failure to communicate :)
>>
>> Two kinds of mirrors, basically. Different concepts, used for different
>> things.
>>
>> "cobbler import" puts files into /var/www/cobbler/ks_mirror -- this is a
>> kickstart tree mirror. These don't need to be updated, and are essential
>> for doing full automated installations. However since Anaconda /does/
>> allow network installs, you don't /have/ to mirror them on your cobbler
>> server if you already have a good kickstart tree available over http on
>> your network. In this case, you'd just use "cobbler distro add", and
>> save yourself the import steps. However, most home users won't have an
>> fast kickstart tree available to them, and this is why cobbler import
>> helps you make one.
>>
>> cobbler repo add ... puts files into /var/www/cobbler/repo_mirror --
>> these are yum repositories for things like extras & updates. These
>> update quite frequently and are entirely optional for cobbler -- if you
>> don't use them, it will use external repos as configured by default 
>> in yum.
>>
> <snippage>
>
> Hi Michael,
>
> I have two requirements, one is a kickstart tree mirror for my base
> OS, CentOS 4.4.  The second requirement is for a repo mirror of a yum
> repository hosting my companies software setup to be fetched and
> installed by yum.  For the sake of simplicity, I'd like to use repo
> mirroring for both.
Sure...
>
> As you say above, and I had a surprisingly hard time seeing this, the
> kickstart tree does not strictly need to be updated.  However, is
> there any harm in doing so?  
Well what is imported with "cobbler import --mirror" is an install 
tree.    That tree usually has subdirectories called "os" and "tree".

Example:  http://download.fedora.redhat.com/pub/fedora/linux/core/6/i386/

Now, what you would mirror in terms of a "core" repo would be a subset 
of this ... for example, looking at a FC6 system, my fedora-core.repo
file references the following URL:

http://download.fedora.redhat.com/pub/fedora/linux/core/6/i386/os/

So yes, the repo that gets installed, is something you would have 
already mirrored with "cobbler import".

However, this tree won't change.   New packages will appear in the 
updates repo, and new things may be available in extras or a 3rd party repo,
but the repo is the way it was when it shipped without any changes.

> I haven't gone the extra step of changing
> the /etc/yum.repos.d/* configurations on my target hosts to use my
> kickstart server as the source for updates but I am considering it.
> In this case, does it make sense to just start with repo mirroring,
> treating a repo mirror as a superset of kickstart tree mirroring, and
> have both the OS and in-house code treated the same in cobbler?
If I were doing this, I would basically let cobbler manage your repos 
for updates and your companies repo using "cobbler repo add" and "reposync".

Then, also in post, I would configure the "core.repo" file to point to 
http://yourserver/cobbler/ks_mirror/yourdistro/youarch/os" just like the 
example above indicates.

When you run "cobbler reposync" only the updates repo and your company 
repo would be updated to the cobbler server, but all systems provisioned 
from it (including the core repo) could still use the cobbler server as 
an install mirror.

>
> Thanks.
Hope that helped ... if not, let me know.

This seems to indicate that it would be useful for cobbler, on systems 
that are being installed from something in /ks_mirror/ to autoconfigure 
the "core" repo to use the mirror.  Or at least, this should be 
switchable.   Since cobbler doesn't do this automagically now, you can 
do it in post yourself in the interim.

Cobbler knows how to configure the rest of the repos that are managed 
with "repo add" but not for the original import tree.

Eventual consolidation of the repo commands with import seems 
logical...but "import" is a bit wider grained because it can slurp in 
distros for multiple arches and so forth.   Effectively, cobbler import 
can slurp in multiple "core" repos at the same time.   Since those repos 
never change, I am hesistant to put them under the domain of "cobbler 
repo add" and "cobbler reposync".   They're really trees, which contain 
more than the repo.   But yeah, autoconfiguration on the client to use 
the cobbler mirror would be nice.

>
> _______________________________________________
> et-mgmt-tools mailing list
> et-mgmt-tools at redhat.com
> https://www.redhat.com/mailman/listinfo/et-mgmt-tools