That works inversely proportionally to the number of "special" boxes you
have for a particular resource and since we have a handful or resources
that work this way, we'd definitely prefer something similar to the
approach we're currently using in 0.22.4.
If we have to though, we do already have a node entry for each of our
boxes, so having a special class for these resources to be included as
appropriate wouldn't be a total paradigm shift of everything...
korymatu wrote:
> Could you put the affected systems in their own node?
>
> Node 'special1' inherits default ...
>
> You could apply the class for your .conf only to the systems that need
> while ensuring that they still receive the default barrage of
> management.
>
> On Jul 20, 4:41 pm, David Sowder <davidrsow...@gmail.com> wrote:
>
>> We're in the process of testing a very long overdue upgrade of our
>> puppetmaster from 0.22.4 to 0.24.8 to facilitate upgrading our Puppet
>> clients later. Because the system where puppetmasterd is installed must
>> also have it's puppetd upgraded, we've run into an issue with a pattern
>> commonly used in our Puppet manifests such as the following: file {
>> "/etc/sysctl.conf": owner => "root", group => "root", mode => 444,
>> source => [ "puppet://$server/kernel/sysctl.conf.$hostname" ] } where we
>> needed to manage the contents of /etc/sysctl.conf on a few of our
>> systems but were not ready to declare that file to be "pristine" (and
>> thus ready for a generic copy of the file) on all other hosts. This was
>> achieved by not creating sysctl.conf.alpha or sysctl.conf.beta files and
>> leaving out an "ensure" parameter, thus having no source for the
>> resource is not considered an error. On a test system with an upgraded
>> puppetmasterd and upgraded puppetd, we are getting errors such as the
>> following: Jul 20 20:36:42 beta puppetd[30414]:
>> (//Node[genericunixserver]/kernel/File[/etc/sysctl.conf]) Failed to
>> retrieve current state of resource: No specified source was found from
>> puppet:///kernel/sysctl.conf.beta and we'd like to restore the previous
>> behavior of /etc/sysctl.conf only being managed on systems we provide a
>> matching entry for in the "source" parameter. A admittedly brief check
>> of the type reference didn't seem to reveal any obvious leads. Is anyone
>> else using this kind of pattern and if so, how are you implementing it?
>> -- David R. Sowder, Linux Systems Admin (Software Systems Specialist II)
>> Office of Information Technology, University of Texas at Arlington Work:
>> 817-272-1081 dav...@uta.eduhttp://www.uta.edu/
>>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@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
-~----------~----~----~----~------~----~------~--~---
