Hi, You can use stuff like cobbler with puppet. The cobbler server has all the repositories configured via its Web interface and the client nodes will have the repositories that is present on the cobbler server. You then only one system (cobbler server) that manages the repository. The client machine just gets the updated file once cobbler does the reposync from the External Repo. I have tested it and it works fine for me.
Regards, Kevin On Sep 24, 8:46 am, Stefan Schlesinger <s...@ono.at> wrote: > On Sep 22, 2010, at 14:06 , Leslie Giles wrote: > > > I'm working on rolling out Puppet, but I'm stuck and I know somebody has > > solved this problem... > > > We have an engineering environment of around 200 Centos servers, plus a > > production environment of roughly the same size. Currently, when we roll > > out a new server, we do a 'yum update' so the new server has the latest > > packages; however this means that just about every server has a different > > set of package versions - a system rolled out today will have different > > versions from one rolled out last month, and that will have different > > versions from one rolled out last year. > > This might be a bit OT on this list but.... > > Usually operating system vendors do stable releases for that purpose. They > invest a lot of effort to provide a stable version of a certain set of > packages. Once released, they tend to not update software versions, except for > updates which will fix security patches. > > So really, if you need a stable environment, use the stable version of your > distribution and DO make security updates. Doing so never caused any harm to > my > systems. > > The next thing is that you have to somehow migrate your systems from stable > release to stable release. Thats where puppet comes into play. You simply > apply your manifests on the distribution's new release, and test the major > service provided by the server. > > > This has bitten me in the past, where a feature developed on a recent > > system failed to run on an older server, so I'm looking for a solution. I > > am in the middle of rolling out Puppet, and we have private mirrors of the > > yum repos, so a solution could build on these. > > I can see several possible solutions: > > - manage changes to the yum repos, and use puppet to make sure that every > > server is up to date w.r.t. the yum repo. However this makes it difficult > > to roll out changes in a controlled way,or to rollback changes. > > Same here, there shouldn't be any issues with updates as long as you don't > upgrade a system from one major distribution release to the next. If a > security update causes any harm to your application, you should fix it too. > > > - use puppet to list all package versions, and manage the versions > > explicitly in puppet, however this means that puppet is going to have > > hundreds of entries, and I can imagine a situation where I upgrade one > > package in puppet without realizing that it depends on a newer version of > > another package, thus puppet and yum start fighting about which version of > > the other package should be installed. > > Specifying each installed package's version manually in your puppet > manifest doesn't sound like a wise idea to me. > > > - always make sure that all systems are updated to the latest, which means > > a slightly less stable environment, but avoids incompatibilities between > > systems, and particularly the possibility that a feature developed on a > > newer system will be asked to run on an older system. > > I think you should invest some work to provide an environment to your > developers which better fits your production environment. If they use > applications or libraries provided by your operating system, they need to make > sure, that as soon as you upgrade your system, their code is still in a > workable state. > > If they don't want to do that, either you or them needs to ship their > application bundled with the appropriate set of libraries, so you decouple > your > application release cycles from your distribution's one. > > Regards, Stefan. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
