Demetri Mouratis wrote:
On 3/6/07, Michael DeHaan <mdehaan@xxxxxxxxxx> wrote:
<snip>
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.
Hi Michael,
Thanks.
It makes perfect sense to me. I'm trying to make sure it makes sense
to my customers. The finer points about repositories were not
something I had given much thought to prior to today's excercise. To
be safe, I think I will widen up the scope of what I am syncing and
fall back to the mirror command for this purpose. In reality, it
seems as though the repository mirroring solution you have put
together really shines with the latest Anaconda features as configured
at install time. Given that I'm still on 4.4, I believe I may have
jumped the gun a bit with repository mirroring.
If I were you, I would still use the repo mirroring commands.
As long as your kickstart does not contain "$yum_repo_stanza", Anaconda
will not try to use the repositories, but you are still free to add
"$yum_config_stanza" (which is only valid in FC6+/RHEL5+) to
automagically configure the contents of /etc/yum.repos.d. Using the
repo mirror commands will keep cobbler from being confused, because
"cobbler import --mirror" hasn't been designed to import things like
"updates". "repo add" has, for instance, it knows to run createrepo to
rebuild the repository indexes for files that have been excluded by
/etc/cobbler/rsync.exclude. That's pretty important in order to keep
your repos in good shape.
Once you start installing RHEL5, you can add the "$yum_repo_stanza" bit
back in. To see an example of this, diff
"/etc/cobbler/kickstart_fc5.ks" with "/etc/cobbler/kickstart_fc6.ks".
Not too many differences, just that Anaconda will install packages from
updates and make 3rd party repos available in the fc6 one, and in the
others, you'll have to do things in post or after the system reboots to
get that behavior that ordinarily Anaconda would do for you.
We're managing a bit of this ourselves these days in terms of hacking
up entries in /etc/yum.repos.d. Internally, I'd like to see less
hacking and more of a finished process around:
a, initial installation of the OS
b, provisioning the correct repository or repositories for additonal
software (we call this bootstrap)
c, deployment of addtional software from either initial provisioning
server, alternate third party mirror, or internal software mirrors as
required.
Several folks here have raised concerns about the control issue when
production systems are pointing to third party repositories. Doing so
potentially removes our ability to stage changes onto our systems in a
controlled fashion. This fact leads me to believe that while currently
I don't need internal mirrors for all OS/third party software, it may
be a good idea to build them in.
Well, if anything, it makes the installs faster. Probably the right
thing to do is to sign your packages and leave the GPGcheck stuff
enabled for the repo, but yes, that's true on the staging front.
Thanks for the quick clarification. I think I'm back on track now.
Good deal, hopefully I have not thrown you further off track :)
-D
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
