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. 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. Thanks for the quick clarification. I think I'm back on track now. -D
