Demetri Mouratis wrote:
On 2/23/07, Michael DeHaan <mdehaan@xxxxxxxxxx> 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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
