Puppet users - Mar 2009 - file, recurse and managing subdirectories

Hi

let''s assume we have the following source dir:

cd /tmp
mkdir src src/a/b -p
echo "blub1" > src/file1
echo "blub2" > src/a/file2
echo "blub3" > src/a/b/file3
echo "blub4" > src/a/b/file4

and we have the following manifest:

file{''/tmp/target'':
    source => ''/tmp/src'',
    recurse => true,
    purge => true,
    owner => root, group => 0, mode => 644;
}

file{''/tmp/target/a/b'':
   mode => 0666;
}

So we''d like to recursively copy a directory to a target. However one
subdirectory should have special permissions as we need to write into it.

So what puppet does is that it manages manages the target and its
subdirectories, copies file1 and file2. But it doesn''t copy file3 and
file4. If I leave first the second file definition out, then everything
gets copied. Later I readd it, everything still seems to work fine,
until I change for example file4. file4 then will never get updated.
Or also if I manually add a file5 in /tmp/target/a/b this won''t get
purged by puppet as it should as it isn''t in the source and not managed
by puppet.

Is this the expected behavior, is there a workaround or is it simply a bug?

My problem is that I have some files which will be copied by scp into
/tmp/target/a/b, which aren''t present in the source.
I manage these file-path as well by puppet (simply ensure => file and
setting the username of the scp user) to ensure that they don''t get
purged. However it looked like sometimes scp removes the files and try
to readd them, while updating. However readding the file failed as the
scp-user didn''t have write permission on the folder containing these
files. So I thought it might be fine to make the folder group-writeable
so the scp-user could write into it.
However this then lead to the described problem.

If it is a bug, would this information be enough to file an issue?

cheers pete

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

On Mar 17, 2009, at 3:25 PM, Peter Meier wrote:
>
> Hi
>
> let''s assume we have the following source dir:
>
> cd /tmp
> mkdir src src/a/b -p
> echo "blub1" > src/file1
> echo "blub2" > src/a/file2
> echo "blub3" > src/a/b/file3
> echo "blub4" > src/a/b/file4
>
> and we have the following manifest:
>
> file{''/tmp/target'':
>    source => ''/tmp/src'',
>    recurse => true,
>    purge => true,
>    owner => root, group => 0, mode => 644;
> }
>
> file{''/tmp/target/a/b'':
>   mode => 0666;
> }
>
> So we''d like to recursively copy a directory to a target. However
one
> subdirectory should have special permissions as we need to write  
> into it.
>
> So what puppet does is that it manages manages the target and its
> subdirectories, copies file1 and file2. But it doesn''t copy file3
and
> file4. If I leave first the second file definition out, then  
> everything
> gets copied. Later I readd it, everything still seems to work fine,
> until I change for example file4. file4 then will never get updated.
> Or also if I manually add a file5 in /tmp/target/a/b this won''t
get
> purged by puppet as it should as it isn''t in the source and not  
> managed
> by puppet.
>
> Is this the expected behavior, is there a workaround or is it simply  
> a bug?
I don''t think I completely understood your examples, but it''s
expected
behaviour that Puppet will not manage through recursion any files  
you''re explicitly managing.

To Puppet, there are implicit and explicit resources; anything that  
shows up directly in your catalog is an explicit resource, anything  
managed through recursion is implicit.  Implicit resources that  
conflict with explicit resources always just get ignored.  Crucially  
for you, when doing recusion, explicit resources cause the recursion  
to stop at the explicit point.

Imagine if you wanted to do recursive management on that second file  
statement - what behaviour woould you expect to see, if the top-level  
recursion still managed the other directory, especially if purging  
were enabled?  You''d have the two file statements fighting, it seems.

So yeah, this is expected behaviour, and I don''t think it''s a
bug, but
maybe others disagree.

-- 
If you make people think they''re thinking, they''ll love you;
But if
you really make them think, they''ll hate you. -- Don Marquis
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Hi
>> Is this the expected behavior, is there a workaround or is it simply
>> a bug?
>
> I don''t think I completely understood your examples, but
it''s expected
> behaviour that Puppet will not manage through recursion any files
> you''re explicitly managing.
I think you got it. :)
> To Puppet, there are implicit and explicit resources; anything that
> shows up directly in your catalog is an explicit resource, anything
> managed through recursion is implicit.  Implicit resources that
> conflict with explicit resources always just get ignored.  Crucially
> for you, when doing recusion, explicit resources cause the recursion
> to stop at the explicit point.
>
> Imagine if you wanted to do recursive management on that second file
> statement - what behaviour woould you expect to see, if the top-level
> recursion still managed the other directory, especially if purging
> were enabled?  You''d have the two file statements fighting, it
seems.
I was also thinking that, but wasn''t sure if it really might be the
problem.
> So yeah, this is expected behaviour, and I don''t think
it''s a bug, but
> maybe others disagree.
So expected behavior. And I now also see the solution for my use case.  
I just have to readd, the subsource part. :/

thanks for looking at it and cheers pete.

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---