Windows Puppet File Resource Getting Puppet Server's UNIX File Permissions

[phundisk]

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?

[Josh Cooper]

Hi Alex,

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

[phundisk]

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!

[jcbollinger]

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

[Alex Farhadi]

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.

--
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...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@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.

© 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

[Josh Cooper]

Hi John,

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

[jcbollinger]

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

[Jakov Sosic]

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

[Rich Siegel]

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

[jcbollinger]

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

[GRANIER Bernard (MORPHO)]

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...@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."
#

[Rich Siegel]

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