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

Search Discussions

  • Josh Cooper at Jan 16, 2013 at 9:35 pm
    Hi Alex,
    On Wed, Jan 16, 2013 at 12:49 PM, phundisk 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.
  • Phundisk at Jan 16, 2013 at 9:58 pm
    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 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.
  • Jcbollinger at Jan 17, 2013 at 7:05 pm

    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 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.
  • Alex Farhadi at Jan 17, 2013 at 7:22 pm
    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 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.
  • Josh Cooper at Jan 17, 2013 at 7:59 pm
    Hi John,
    On Thu, Jan 17, 2013 at 6:56 AM, jcbollinger 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.
  • Jcbollinger at Jan 18, 2013 at 5:27 pm

    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 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.
  • Jakov Sosic at Jan 19, 2013 at 1:04 pm

    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.
  • Rich Siegel at Jan 20, 2013 at 6:51 pm
    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.
  • Jcbollinger at Jan 22, 2013 at 3:57 pm

    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.
  • GRANIER Bernard (MORPHO) at Jan 22, 2013 at 4:12 pm
    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
    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.
  • Rich Siegel at Jan 23, 2013 at 7:39 pm
    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedJan 16, '13 at 8:49p
activeJan 23, '13 at 7:39p
posts12
users6
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase