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

[Michael DeHaan]

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