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 davids@uta.edu http://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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---