Has the component/type defaults syntax changed for 0.22.x?
I have a component:
<snip>
define remotefile($owner=root, $group=root, $mode, $source,
$backup=false, $recurse=false, $groupname="default") {
file {
$name:
mode => $mode,
owner => $owner,
group => $group,
backup => $backup,
recurse => $recurse,
source => [
"puppet://$puppetserver/hosts/$source",
"puppet://$puppetserver/groups/$groupname/
$operatingsystem/$hardwaremodel/$source",
"puppet://$puppetserver/groups/$groupname/
$operatingsystem/any/$source",
"puppet://$puppetserver/groups/$groupname/any/any/
$source",
# These are used when a groupname is specified, but
no files are found
"puppet://$puppetserver/groups/default/
$operatingsystem/$hardwaremodel/$source",
"puppet://$puppetserver/groups/default/
$operatingsystem/any/$source",
"puppet://$puppetserver/groups/default/any/any/$source"
]
}
}
</snip>
And then a class like:
<snip>
class gadmin
{
File {
owner => "gadmin",
group => "gadmin"
}
Remotefile {
owner => "gadmin",
group => "gadmin"
}
remotefile {
"/home/gadmin/.ssh/authorized_keys":
mode => 444,
source => "users/gadmin/ssh/authorized_keys";
"/home/gadmin/.ssh/config":
mode => 444,
source => "users/gadmin/ssh/config"
}
}
</snip>
But for some reason the owner/group does not get picked up on the
first pass... I have to run puppetd -o -v twice for each host to once
to get the new content, and then another time to get the perms updated.
Any idea why this might be happening?
--jason
On Feb 14, 2007, at 6:23 PM, Jason Dillon wrote:> [...] > But for some reason the owner/group does not get picked up on the > first pass... I have to run puppetd -o -v twice for each host to once > to get the new content, and then another time to get the perms > updated. > > Any idea why this might be happening?This definitely sounds like a bug. I know there''s at least one defaults-related bug currently open, but this makes it look like defaults are broken. I just verified that it works in simple isolated cases: define yay($arg) { exec { "/bin/echo $name $arg": } } Yay { arg => yep } yay { foo: } prints: notice: //yay[foo]/Exec[/bin/echo foo yep]/returns: executed successfully Can you produce an isolated test case, preferably involving ''exec'' rather than file (since it won''t need any extra setup)? -- Love is a snowmobile racing across the tundra and then suddenly it flips over, pinning you underneath. At night, the ice weasels come. --Matt Groening --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jason Dillon wrote:> But for some reason the owner/group does not get picked up on the > first pass... I have to run puppetd -o -v twice for each host to once > to get the new content, and then another time to get the perms updated. > > Any idea why this might be happening?I am seeing very much the same behavior, but only when a file is _replaced_, if the file does not exist on the client it will be created with the correct ownership and group. A remote file is pulled over on the first pass if the content changes, but it''s ownership and group seem to be what they were in the filestore, not as specified in the config. This is all corrected by the second run of the puppet service, but in the meantime I had various services die for a half-hour. Sorry I can''t provide a fix, but I do commiserate with you. My definitions are quite a bit simpler: define remotefile($source, $owner = root, $group = root, $mode = 440, $recurse = true, $backup = main, $replace = true ) { file { $name: source => "$puppetserver/files/$source", backup => $backup, owner => $owner, group => $group, mode => $mode, recurse => $recurse, replace => $replace } } [...snip...] remotefile { "/etc/nagios/nrpe.cfg" : source => "modules/nagios-nrpe/nrpe.cfg", mode => 640, owner => root, group => nagios, require => Package["nagios-nrpe"] } [...snip...] puppeteer manifests # ls -l ./files/modules/nagios-nrpe/nrpe.cfg - -rw-r----- 1 root puppet 6479 Feb 14 16:15 ./files/modules/nagios-nrpe/nrpe.cfg puppeteer manifests # ls -l /etc/nagios/nrpe.cfg - -rw-r----- 1 root nagios 6479 Feb 16 09:18 /etc/nagios/nrpe.cfg puppeteer manifests # echo "junk" >> /etc/nagios/nrpe.cfg puppeteer manifests # ls -l /etc/nagios/nrpe.cfg - -rw-r----- 1 root nagios 6484 Feb 16 09:18 /etc/nagios/nrpe.cfg puppeteer manifests # puppetd --server puppeteer.goshen.edu --test --tags nagios-nrpe --verbose notice: Ignoring --listen on onetime run info: Config is up to date notice: Starting configuration run notice: //base-menno/puppeteer/nagios-nrpe/remotefile[/etc/nagios/nrpe.cfg]/File[/etc/nagios/nrpe.cfg]/checksum: checksum changed ''{md5}88796d0b27f1496696fbc20732b4ced2'' to ''{md5}88be36ec13ae5270cee3cfc029d3d4f9'' info: //base-menno/puppeteer/nagios-nrpe/remotefile[/etc/nagios/nrpe.cfg]/File[/etc/nagios/nrpe.cfg]: Filebucketed to main with sum 88be36ec13ae5270cee3cfc029d3d4f9 notice: //base-menno/puppeteer/nagios-nrpe/remotefile[/etc/nagios/nrpe.cfg]/File[/etc/nagios/nrpe.cfg]/source: replacing from source puppet://puppeteer.goshen.edu/files/modules/nagios-nrpe/nrpe.cfg info: //base-menno/puppeteer/nagios-nrpe/remotefile[/etc/nagios/nrpe.cfg]/File[/etc/nagios/nrpe.cfg]: Scheduling refresh of Service[nrpe] info: //base-menno/puppeteer/nagios-nrpe/remotefile[/etc/nagios/nrpe.cfg]/File[/etc/nagios/nrpe.cfg]: Scheduling refresh of Service[nrpe] notice: //base-menno/puppeteer/nagios-nrpe/Service[nrpe]: Triggering ''refresh'' from 2 dependencies err: //base-menno/puppeteer/nagios-nrpe/Service[nrpe]: Failed to call refresh on Service[nrpe]: Could not restart Service[nrpe] puppeteer manifests # ls -l /etc/nagios/nrpe.cfg - -rw-r----- 1 root puppet 6479 Feb 16 09:19 /etc/nagios/nrpe.cfg Note the group change. It is corrected on the next run of puppet. Again, this does not happen with files that are new on the client in my experience, but it does happen with files that have changed on the client. I''ve filed a ticket: http://reductivelabs.com/cgi-bin/puppet.cgi/ticket/508 - -- Paul Ortman PGP Key: 55602C81 - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFF1cMLfw8KGlVgLIERAggAAJ9jiSX3GWQYMD7ncaLkpUllxUk1VwCfeY6w 2iQi41b5dShxJWN0n0M4+gA=pQW8 -----END PGP SIGNATURE-----
On Feb 16, 2007, at 8:43 AM, Paul Ortman wrote:> [...] > Again, this does not happen with files that are new on the client in > my experience, but it does happen with files that have changed on > the client. > > I''ve filed a ticket: http://reductivelabs.com/cgi-bin/puppet.cgi/ > ticket/508Hi Paul, Thank you very much for this thorough researching of the problem. Jon Nangle and I had just now tracked down this bug, but if you had sent this email a week ago it would have saved us a lot of back and forth. :) I know the source of the bug, and it should be straightforward to fix, fortunately. And if anyone is looking for an example of great bug reports, Pauls #508 is one. -- Real freedom lies in wildness, not in civilization. -- Charles Lindbergh --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Luke Kanies wrote:> Thank you very much for this thorough researching of the problem. > Jon Nangle and I had just now tracked down this bug, but if you had > sent this email a week ago it would have saved us a lot of back and > forth. :)I knew about it about 2 days ago, but I didn''t have time to file it then, so sadly it had to wait until today when I read Jason''s email and was inspired to try to isolate the problem.> I know the source of the bug, and it should be straightforward to > fix, fortunately.Great. You guys rock.> And if anyone is looking for an example of great bug reports, Pauls > #508 is one.You''re too kind. Thanks though, its nice to read that once in awhile to keep motivated to report issues -- that shows good project leadership IMHO. - -- Paul Ortman PGP Key: 55602C81 - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFF1eD2fw8KGlVgLIERAqcGAJsEofWQ2advP30QMPqFJh7HpDo7ggCfQqPH z9/VrKysRUb2gdur84w/cSw=K7Iu -----END PGP SIGNATURE-----