[et-mgmt-tools] Using cobbler to mirror repos like updates/extras -- further information
mdehaan at redhat.com
Tue Mar 6 20:05:19 UTC 2007
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
>> "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.
> 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.
> 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".
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:
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.
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
More information about the et-mgmt-tools