Puppet users - Jan 2013 - Windows Puppet File Resource Getting Puppet Server's UNIX File Permissions

I am noticing some very odd behavior with my puppet server and a windows 
client.

For my puppet server I have a module setup similar to this below... Please 
note, I am not setting any permission on this file.
file { "C:\\directory\\file.dll":
                ensure => ''present'',
                source => "puppet:///modules/aaa/file.dll",
}

The actual permissions in the unix filesystem is set to 644

When I apply this to my Windows client, the puppet agent will change the 
mode of the file *already on the server* to 0644, which is not what I would 
expect puppet to do.  I would expect since it is already there, it would 
not even care about the permissions.

I know this is taking the UNIX filesystem permissions because I chmod''d
the
file on the filesystem to 0777 and when running puppet on Windows, it took 
the new permissions.

This becomes problematic because I am using puppet environments with an SVN 
checkout system.  Every time I update svn checkouts, it defaults to 0644. 
 Does anyone know if this is expected behavior or ways around this?

-- 
_____________________________________________________
This email and any files transmitted with it are confidential and intended 
solely for the addressee.  If you received this email in error, please do 
not disclose the contents to anyone; kindly notify the sender by return 
email and delete this email and any attachments from your system.

© 2011 Currensee Inc. is a member of the National Futures Association (NFA) 
Member ID 0403251 | Over the counter retail foreign currency (Forex) 
trading may involve significant risk of loss. It is not suitable for all 
investors and you should make sure you understand the risks involved before 
trading and seek independent advice if necessary. Performance, strategies 
and charts shown are not necessarily predictive of any particular result 
and past performance is no indication of future results. Investor returns 
may vary from Trade Leader returns based on slippage, fees, broker spreads, 
volatility or other market conditions.

Currensee Inc | 54 Canal St 4th Floor | Boston, MA 02114 | +1.617.624.3824

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/joCwso4AsIoJ.
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 Alex,

On Wed, Jan 16, 2013 at 12:49 PM, phundisk <alex.farhadi@currensee.com>
wrote:
> I am noticing some very odd behavior with my puppet server and a windows
> client.
>
> For my puppet server I have a module setup similar to this below... Please
> note, I am not setting any permission on this file.
> file { "C:\\directory\\file.dll":
>                 ensure => ''present'',
>                 source => "puppet:///modules/aaa/file.dll",
> }
>
> The actual permissions in the unix filesystem is set to 644
>
> When I apply this to my Windows client, the puppet agent will change the
> mode of the file already on the server to 0644, which is not what I would
> expect puppet to do.  I would expect since it is already there, it would
not
> even care about the permissions.
>
> I know this is taking the UNIX filesystem permissions because I
chmod''d the
> file on the filesystem to 0777 and when running puppet on Windows, it took
> the new permissions.
>
> This becomes problematic because I am using puppet environments with an SVN
> checkout system.  Every time I update svn checkouts, it defaults to 0644.
> Does anyone know if this is expected behavior or ways around this?
This is "expected" in that windows agents emulate current *nix agent
behavior. With that said there are issues with the current behavior in
general. Currently, *nix agents will attempt to apply the remote
uid/gid to the local system, which may not be what you would expect.
See http://projects.puppetlabs.com/issues/5240.

You could either set the executable bit on these files in svn[1] or
define a default mode for file resources[2]. I''d probably go with the
former.

Josh

[1] http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.propset.html
[2] http://docs.puppetlabs.com/guides/style_guide.html#resource-defaults
--
Josh Cooper
Developer, Puppet Labs

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

I see.  That is very interesting to know, it was causing me much stress as 
to where the permissions were coming from originally.  I appreciate the 
help again Josh!

On Wednesday, January 16, 2013 4:35:46 PM UTC-5, Josh Cooper
wrote:
>
> Hi Alex, 
>
> On Wed, Jan 16, 2013 at 12:49 PM, phundisk
<alex.f...@currensee.com<javascript:>>
> wrote: 
> > I am noticing some very odd behavior with my puppet server and a
windows
> > client. 
> > 
> > For my puppet server I have a module setup similar to this below... 
> Please 
> > note, I am not setting any permission on this file. 
> > file { "C:\\directory\\file.dll": 
> >                 ensure => ''present'', 
> >                 source =>
"puppet:///modules/aaa/file.dll",
> > } 
> > 
> > The actual permissions in the unix filesystem is set to 644 
> > 
> > When I apply this to my Windows client, the puppet agent will change
the
> > mode of the file already on the server to 0644, which is not what I 
> would 
> > expect puppet to do.  I would expect since it is already there, it
would
> not 
> > even care about the permissions. 
> > 
> > I know this is taking the UNIX filesystem permissions because I
chmod''d
> the 
> > file on the filesystem to 0777 and when running puppet on Windows, it 
> took 
> > the new permissions. 
> > 
> > This becomes problematic because I am using puppet environments with
an
> SVN 
> > checkout system.  Every time I update svn checkouts, it defaults to 
> 0644. 
> > Does anyone know if this is expected behavior or ways around this? 
>
> This is "expected" in that windows agents emulate current *nix
agent
> behavior. With that said there are issues with the current behavior in 
> general. Currently, *nix agents will attempt to apply the remote 
> uid/gid to the local system, which may not be what you would expect. 
> See http://projects.puppetlabs.com/issues/5240. 
>
> You could either set the executable bit on these files in svn[1] or 
> define a default mode for file resources[2]. I''d probably go with
the
> former. 
>
> Josh 
>
> [1] http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.propset.html 
> [2] http://docs.puppetlabs.com/guides/style_guide.html#resource-defaults 
> -- 
> Josh Cooper 
> Developer, Puppet Labs 
>
-- 
_____________________________________________________
This email and any files transmitted with it are confidential and intended 
solely for the addressee.  If you received this email in error, please do 
not disclose the contents to anyone; kindly notify the sender by return 
email and delete this email and any attachments from your system.

© 2011 Currensee Inc. is a member of the National Futures Association (NFA) 
Member ID 0403251 | Over the counter retail foreign currency (Forex) 
trading may involve significant risk of loss. It is not suitable for all 
investors and you should make sure you understand the risks involved before 
trading and seek independent advice if necessary. Performance, strategies 
and charts shown are not necessarily predictive of any particular result 
and past performance is no indication of future results. Investor returns 
may vary from Trade Leader returns based on slippage, fees, broker spreads, 
volatility or other market conditions.

Currensee Inc | 54 Canal St 4th Floor | Boston, MA 02114 | +1.617.624.3824

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/6I3LEHFoNTkJ.
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 Wednesday, January 16, 2013 3:35:46 PM UTC-6, Josh Cooper
wrote:
>
> Hi Alex, 
>
> On Wed, Jan 16, 2013 at 12:49 PM, phundisk
<alex.f...@currensee.com<javascript:>>
> wrote: 
> > I am noticing some very odd behavior with my puppet server and a
windows
> > client. 
> > 
> > For my puppet server I have a module setup similar to this below... 
> Please 
> > note, I am not setting any permission on this file. 
> > file { "C:\\directory\\file.dll": 
> >                 ensure => ''present'', 
> >                 source =>
"puppet:///modules/aaa/file.dll",
> > } 
> > 
> > The actual permissions in the unix filesystem is set to 644 
> > 
> > When I apply this to my Windows client, the puppet agent will change
the
> > mode of the file already on the server to 0644, which is not what I 
> would 
> > expect puppet to do.  I would expect since it is already there, it
would
> not 
> > even care about the permissions. 
> > 
> > I know this is taking the UNIX filesystem permissions because I
chmod''d
> the 
> > file on the filesystem to 0777 and when running puppet on Windows, it 
> took 
> > the new permissions. 
> > 
> > This becomes problematic because I am using puppet environments with
an
> SVN 
> > checkout system.  Every time I update svn checkouts, it defaults to 
> 0644. 
> > Does anyone know if this is expected behavior or ways around this? 
>
> This is "expected" in that windows agents emulate current *nix
agent
> behavior. With that said there are issues with the current behavior in 
> general. Currently, *nix agents will attempt to apply the remote 
> uid/gid to the local system, which may not be what you would expect. 
> See http://projects.puppetlabs.com/issues/5240. 
>

What I would expect on both Unix and Windows is that if the target file 
already exists and the resource declaration does not specify a mode, then 
the current mode will not be changed.  It is not a managed property.  The 
same applies to uid/gid.  This is distinguished from the case of issue 
5240, which is about the uid/gid to apply to a File resource if the target 
file is initially absent.

Is the Windows client indeed emulating the Unix one here?  In other words, 
are they *both* buggy, or is it just the Windows client?


John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/b3WN5RZXVWwJ.
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.

Yes the Windows client is updating the mode based on what the file
permission is in the puppet master''s unix''s file system, I did
not see any
change messages about the uid or gid being changed.  Let me know if you
need any more information or screen shots.  I will be more than happy to
provide whatever is needed.


On Thu, Jan 17, 2013 at 9:56 AM, jcbollinger
<John.Bollinger@stjude.org>wrote:
>
>
> On Wednesday, January 16, 2013 3:35:46 PM UTC-6, Josh Cooper wrote:
>
>> Hi Alex,
>>
>> On Wed, Jan 16, 2013 at 12:49 PM, phundisk
<alex.f...@currensee.com>
>> wrote:
>> > I am noticing some very odd behavior with my puppet server and a
>> windows
>> > client.
>> >
>> > For my puppet server I have a module setup similar to this
below...
>> Please
>> > note, I am not setting any permission on this file.
>> > file { "C:\\directory\\file.dll":
>> >                 ensure => ''present'',
>> >                 source =>
"puppet:///modules/aaa/file.**dll",
>> > }
>> >
>> > The actual permissions in the unix filesystem is set to 644
>> >
>> > When I apply this to my Windows client, the puppet agent will
change
>> the
>> > mode of the file already on the server to 0644, which is not what
I
>> would
>> > expect puppet to do.  I would expect since it is already there, it
>> would not
>> > even care about the permissions.
>> >
>> > I know this is taking the UNIX filesystem permissions because I
chmod''d
>> the
>> > file on the filesystem to 0777 and when running puppet on Windows,
it
>> took
>> > the new permissions.
>> >
>> > This becomes problematic because I am using puppet environments
with an
>> SVN
>> > checkout system.  Every time I update svn checkouts, it defaults
to
>> 0644.
>> > Does anyone know if this is expected behavior or ways around this?
>>
>> This is "expected" in that windows agents emulate current
*nix agent
>> behavior. With that said there are issues with the current behavior in
>> general. Currently, *nix agents will attempt to apply the remote
>> uid/gid to the local system, which may not be what you would expect.
>> See
http://projects.puppetlabs.**com/issues/5240<http://projects.puppetlabs.com/issues/5240>.
>>
>>
>
>
> What I would expect on both Unix and Windows is that if the target file
> already exists and the resource declaration does not specify a mode, then
> the current mode will not be changed.  It is not a managed property.  The
> same applies to uid/gid.  This is distinguished from the case of issue
> 5240, which is about the uid/gid to apply to a File resource if the target
> file is initially absent.
>
> Is the Windows client indeed emulating the Unix one here?  In other words,
> are they *both* buggy, or is it just the Windows client?
>
>
> John
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/b3WN5RZXVWwJ.
>
> 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.
>
-- 
_____________________________________________________
This email and any files transmitted with it are confidential and intended 
solely for the addressee.  If you received this email in error, please do 
not disclose the contents to anyone; kindly notify the sender by return 
email and delete this email and any attachments from your system.

(c) 2011 Currensee Inc. is a member of the National Futures Association (NFA) 
Member ID 0403251 | Over the counter retail foreign currency (Forex) 
trading may involve significant risk of loss. It is not suitable for all 
investors and you should make sure you understand the risks involved before 
trading and seek independent advice if necessary. Performance, strategies 
and charts shown are not necessarily predictive of any particular result 
and past performance is no indication of future results. Investor returns 
may vary from Trade Leader returns based on slippage, fees, broker spreads, 
volatility or other market conditions.

Currensee Inc | 54 Canal St 4th Floor | Boston, MA 02114 | +1.617.624.3824

-- 
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 John,

On Thu, Jan 17, 2013 at 6:56 AM, jcbollinger <John.Bollinger@stjude.org>
wrote:
>
>
> On Wednesday, January 16, 2013 3:35:46 PM UTC-6, Josh Cooper wrote:
>>
>> Hi Alex,
>>
>> On Wed, Jan 16, 2013 at 12:49 PM, phundisk
<alex.f...@currensee.com>
>> wrote:
>> > I am noticing some very odd behavior with my puppet server and a
windows
>> > client.
>> >
>> > For my puppet server I have a module setup similar to this
below...
>> > Please
>> > note, I am not setting any permission on this file.
>> > file { "C:\\directory\\file.dll":
>> >                 ensure => ''present'',
>> >                 source =>
"puppet:///modules/aaa/file.dll",
>> > }
>> >
>> > The actual permissions in the unix filesystem is set to 644
>> >
>> > When I apply this to my Windows client, the puppet agent will
change the
>> > mode of the file already on the server to 0644, which is not what
I
>> > would
>> > expect puppet to do.  I would expect since it is already there, it
would
>> > not
>> > even care about the permissions.
>> >
>> > I know this is taking the UNIX filesystem permissions because I
chmod''d
>> > the
>> > file on the filesystem to 0777 and when running puppet on Windows,
it
>> > took
>> > the new permissions.
>> >
>> > This becomes problematic because I am using puppet environments
with an
>> > SVN
>> > checkout system.  Every time I update svn checkouts, it defaults
to
>> > 0644.
>> > Does anyone know if this is expected behavior or ways around this?
>>
>> This is "expected" in that windows agents emulate current
*nix agent
>> behavior. With that said there are issues with the current behavior in
>> general. Currently, *nix agents will attempt to apply the remote
>> uid/gid to the local system, which may not be what you would expect.
>> See http://projects.puppetlabs.com/issues/5240.
>
>
>
> What I would expect on both Unix and Windows is that if the target file
> already exists and the resource declaration does not specify a mode, then
> the current mode will not be changed.  It is not a managed property.
Good point. I would expect the behavior you describe, but that''s not
what I''m seeing.

Here''s my module''s init.pp:

class dism {
  file { "${systemdrive}/tmp/file.dll":
    ensure => ''present'',
    source => "puppet:///modules/dism/file.dll",
  }
}

On the master:

# ls -la file.dll
-rwxr--r-- 1 root root 15 Jan 17 10:17 file.dll

When using a Mac agent, the mode is indeed changed, but not the owner
or group. This seems to consistent as far back as 0.25.4:

$ puppetd --version
0.25.4
$ puppetd --test --debug
debug: /Stage[main]/Dism/File[/tmp/file.dll]/checksum: Initializing
checksum hash
debug: /Stage[main]/Dism/File[/tmp/file.dll]: Creating checksum
{md5}0c7169d609a64c22bd07e1e3a3b38a9f
debug: /Stage[main]/Dism/File[/tmp/file.dll]: Changing mode
debug: /Stage[main]/Dism/File[/tmp/file.dll]: 1 change(s)
notice: /Stage[main]/Dism/File[/tmp/file.dll]/mode: mode changed
''644'' to ''744''
> The
> same applies to uid/gid.  This is distinguished from the case of issue
5240,
> which is about the uid/gid to apply to a File resource if the target file
is
> initially absent.
>
> Is the Windows client indeed emulating the Unix one here?  In other words,
> are they both buggy, or is it just the Windows client?
So it seems they are consistent. Did puppet used to behave differently
in earlier versions?

Josh

--
Josh Cooper
Developer, Puppet Labs

-- 
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 Thursday, January 17, 2013 12:56:30 PM UTC-6, Josh Cooper
wrote:
>
> Hi John, 
>
> On Thu, Jan 17, 2013 at 6:56 AM, jcbollinger
<John.Bo...@stjude.org<javascript:>>
> wrote: 
>
[...] 
> > What I would expect on both Unix and Windows is that if the target
file
> > already exists and the resource declaration does not specify a mode, 
> then 
> > the current mode will not be changed.  It is not a managed property. 
>
> Good point. I would expect the behavior you describe, but that''s
not
> what I''m seeing. 
> [...] Did puppet used to behave differently 
> in earlier versions [than 0.25.4]? 
>
>
I was able to verify that the same behavior is exhibited by Puppet 0.24.8.  
That behavior goes against basic Puppet principles, however: unmanaged 
resources and resource properties should not be modified by Puppet.   It 
looks like that''s the consensus opinion of those commenting on issue
5240,
too.  Basically, then, this is a longstanding, cross-platform bug.  I have 
added a comment about this to issue 5240, as it probably makes sense to 
expand that issue to cover this matter, too.


John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/VtCl9YmeIS0J.
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 01/18/2013 06:27 PM, jcbollinger wrote:
> I was able to verify that the same behavior is exhibited by Puppet
> 0.24.8.  That behavior goes against basic Puppet principles, however:
> unmanaged resources and resource properties should not be modified by
> Puppet.   It looks like that''s the consensus opinion of those
commenting
> on issue 5240, too.  Basically, then, this is a longstanding,
> cross-platform bug.  I have added a comment about this to issue 5240, as
> it probably makes sense to expand that issue to cover this matter, too.
But if you push the directory with recurse => true, what permissions 
would files get in that case? Permissions of the file on the master, or 
default permission for that scope?

I think the first one is far better.



-- 
Jakov Sosic
www.srce.unizg.hr

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

Permissions on the source should be irrelevant imho.
Windows should always respect the destination inheritance, particularly if no
mode is specified.  Source perms are irrelevant imho.

We need a proper permissions type and provider which can handle the ntfs acl
style.  Mode interpretation is just that - and not the way this should work.   I
looked at security.rb and just think this is just kludgey.  I need to specify
multiple users (ad sid lookup?), their perm, and their options.   Not sure if it
should be a part of file resource or a more generic security thing,  since maybe
it can apply to more than files...


-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/x-hCGJn6Ms8J.
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 Saturday, January 19, 2013 7:04:47 AM UTC-6, Jakov Sosic
wrote:
>
> On 01/18/2013 06:27 PM, jcbollinger wrote: 
>
> > I was able to verify that the same behavior is exhibited by Puppet 
> > 0.24.8.  That behavior goes against basic Puppet principles, however: 
> > unmanaged resources and resource properties should not be modified by 
> > Puppet.   It looks like that''s the consensus opinion of those
commenting
> > on issue 5240, too.  Basically, then, this is a longstanding, 
> > cross-platform bug.  I have added a comment about this to issue 5240,
as
> > it probably makes sense to expand that issue to cover this matter,
too.
>
> But if you push the directory with recurse => true, what permissions 
> would files get in that case? Permissions of the file on the master, or 
> default permission for that scope? 
>
>
I think you''re confusing two unrelated dimensions.  Whether the
resource is
recursive or not, if no mode (uid/gid) is declared for it then Puppet 
should not modify the mode (uid/gid) of *existing files* as part of 
managing that resource.  This is standard Puppet behavior, and users should 
be able to rely on it.  There are functional reasons to want it, too.

There is a completely separate question of what Puppet should do when it
*creates
a new file*: if the resource declaration does not specify a mode (uid/gid) 
then Puppet either must choose one by some other means.  Its current 
behavior is to use the properties of the source file, which I actually 
think is fine, though issue 5240 raises questions about that behavior.

Recursive File resources have long been a problematic area for Puppet.  
That''s not a flaw in Puppet (unless you consider recursive Files
themselves
to be a misfeature); rather, it''s inherent in the problem.  The whole
point
of recursive File resources is to manage a bunch of files without declaring 
all the properties of each one individually.  But then, you''re not 
declaring the properties of each one individually.  If you want fine 
control then you need something that carries all the needed data.  The best 
alternative in most cases is either to manage Files separately or to 
package them up and manage them via the Package.


John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/dz6Q5qGVG9EJ.
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,

On CentOS, I perform some tests with package resource, for example to define
that a package has to be present but no yum server is defined on the agent.

In the dashboard, it is clearly displayed that the manifest failed, but yum
output is not displayed.

Is there a way to get the yum output displayed in dashboard ?

Cordialement,

Bernard Granier
CE Plateforme Système
bernard.granier@morpho.com<mailto:bernard.granier@morpho.com>
01 58 11 32 51


#
" This e-mail and any attached documents may contain confidential or
proprietary information. If you are not the intended recipient, you are notified
that any dissemination, copying of this e-mail and any attachments thereto or
use of their contents by any means whatsoever is strictly prohibited. If you
have received this e-mail in error, please advise the sender immediately and
delete this e-mail and all attached documents from your computer system."
#

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

I am only speaking for windows permissions:
>
>>
>> But if you push the directory with recurse => true, what permissions
>> would files get in that case? Permissions of the file on the master, or
>> default permission for that scope? 
>>
>  
On Windows the answer is the permissions on the endpoint (no 
modification).  Permissions are never copied from src to dest.
Particularly sourcing from *nix, I would end up with a box of chocolateys I 
don''t want to eat.  
 
 
>
>
> I think you''re confusing two unrelated dimensions.  Whether the
resource
> is recursive or not, if no mode (uid/gid) is declared for it then Puppet 
> should not modify the mode (uid/gid) of *existing files* as part of 
> managing that resource.  This is standard Puppet behavior, and users should
> be able to rely on it.  There are functional reasons to want it, too.
>
 
No - don''t want it. no mode, no perm change.  Standard windows
inheritance
model.
 
>
> There is a completely separate question of what Puppet should do when it
*creates
> a new file*: if the resource declaration does not specify a mode 
> (uid/gid) then Puppet either must choose one by some other means.  Its 
> current behavior is to use the properties of the source file, which I 
> actually think is fine, though issue 5240 raises questions about that 
> behavior.
>
> Negative - not fine for windows.  Never want the source mode to end up on 
the target.  Bad settings = takeown = bad.
 
 
> Recursive File resources have long been a problematic area for Puppet.  
> That''s not a flaw in Puppet (unless you consider recursive Files
themselves
> to be a misfeature); rather, it''s inherent in the problem.  The
whole point
> of recursive File resources is to manage a bunch of files without declaring
> all the properties of each one individually.  But then, you''re not
> declaring the properties of each one individually.  If you want fine 
> control then you need something that carries all the needed data.  The best
> alternative in most cases is either to manage Files separately or to 
> package them up and manage them via the Package.
>
> On windows inheritance model works nicely.  The security.rb and mode 
interpretation should not be applicable on windows.  We need to rewrite 
perms to respect ntfs. 
 
>
> John
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/jnCsosOdCsAJ.
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.