Jira (PUP-5921) Deprecate source_permissions

36 views
Skip to first unread message

Kylo Ginsberg (JIRA)

unread,
Feb 17, 2016, 8:17:04 PM2/17/16
to puppe...@googlegroups.com
Kylo Ginsberg created an issue
 
Puppet / Bug PUP-5921
Deprecate source_permissions
Issue Type: Bug Bug
Assignee: Unassigned
Created: 2016/02/17 5:16 PM
Fix Versions: PUP 4.x
Priority: Normal Normal
Reporter: Kylo Ginsberg

We are steering people away from source_permissions for two reasons:

  1. it doesn't make sense for environments (including PE) that use git for the backend (user/group aren't managed by git)
  2. it is not fully supported/supportable by static_catalogs

It is still used by pluginsync for external facts however, and we will need to find a replacement mechanism for that, see linked PUP-5920.

Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc)
Atlassian logo

Michael Smith (JIRA)

unread,
Feb 22, 2016, 5:19:03 PM2/22/16
to puppe...@googlegroups.com
Michael Smith updated an issue
Change By: Michael Smith
We are steering people away from {{source_permissions}} for two reasons:
# it doesn't make sense for environments (including PE) that use git for the backend (user/group aren't managed by git)
#
 -  it is not fully supported/supportable by static_catalogs - no longer true

It is still used by pluginsync for external facts however, and we will need to find a replacement mechanism for that, see linked PUP-5920.

Michael Smith (JIRA)

unread,
Feb 22, 2016, 5:19:11 PM2/22/16
to puppe...@googlegroups.com
Michael Smith updated an issue
We are steering people away from {{source_permissions}} for two reasons:
# it doesn't make sense for environments (including PE) that use git for the backend (user/group aren't managed by git)
# -it is not fully supported/supportable by static_catalogs- no longer true , it will now be fully supported in static_catalogs

It is still used by pluginsync for external facts however, and we will need to find a replacement mechanism for that, see linked PUP-5920.

Kylo Ginsberg (JIRA)

unread,
Mar 2, 2016, 6:53:04 PM3/2/16
to puppe...@googlegroups.com
Kylo Ginsberg updated an issue
Change By: Kylo Ginsberg
Sprint: Client Triage

Andrew Henroid (JIRA)

unread,
Jun 30, 2016, 12:49:03 PM6/30/16
to puppe...@googlegroups.com
Andrew Henroid updated an issue
Change By: Andrew Henroid
Scope Change Category: Adopted
Scope Change Reason: onboarding
Sprint: Client 2016-07-13 (HA, 1.5.3)
This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9)
Atlassian logo

Andrew Henroid (JIRA)

unread,
Jun 30, 2016, 12:53:06 PM6/30/16
to puppe...@googlegroups.com
Andrew Henroid assigned an issue to Andrew Henroid
Change By: Andrew Henroid
Assignee: Andrew Henroid

William Hopper (JIRA)

unread,
Jun 30, 2016, 2:36:02 PM6/30/16
to puppe...@googlegroups.com
William Hopper updated an issue
Change By: William Hopper
Scope Change Reason: brought on for onboarding , but we realized it was blocked on another ticket so we took it back out
Sprint: Client 2016-07-13 (HA, 1.5.3)

Andrew Henroid (JIRA)

unread,
Jul 1, 2016, 5:22:06 PM7/1/16
to puppe...@googlegroups.com
Andrew Henroid assigned an issue to Unassigned
Change By: Andrew Henroid
Assignee: Andrew Henroid

Geoff Nichols (JIRA)

unread,
Apr 5, 2017, 1:35:02 AM4/5/17
to puppe...@googlegroups.com
Geoff Nichols updated an issue
Change By: Geoff Nichols
Team: Agent
This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe)
Atlassian logo

Geoff Nichols (JIRA)

unread,
Apr 5, 2017, 1:35:02 AM4/5/17
to puppe...@googlegroups.com
Geoff Nichols commented on Bug PUP-5921
 
Re: Deprecate source_permissions

Josh Cooper and Moses Mendoza - should we try to get this in for 4.10.x or move to 5.y?

Geoff Nichols (JIRA)

unread,
Apr 5, 2017, 1:35:02 AM4/5/17
to puppe...@googlegroups.com
Geoff Nichols updated an issue
Change By: Geoff Nichols
Sprint: Agent Needs Information

Josh Cooper (JIRA)

unread,
Apr 5, 2017, 12:11:02 PM4/5/17
to puppe...@googlegroups.com
Josh Cooper commented on Bug PUP-5921
 
Re: Deprecate source_permissions

I'd say move to 5.y. It would be good to solve the general problem of how users pluginsync external executable facts without relying on executable mode bits on the server.

Moses Mendoza (JIRA)

unread,
Apr 6, 2017, 12:34:02 PM4/6/17
to puppe...@googlegroups.com
Moses Mendoza updated an issue
Change By: Moses Mendoza
Fix Version/s: PUP 4.y
Fix Version/s: PUP 5.y

Geoff Nichols (JIRA)

unread,
Apr 7, 2017, 1:24:02 AM4/7/17
to puppe...@googlegroups.com
Geoff Nichols updated an issue
Change By: Geoff Nichols
Sprint: Agent Needs Information

Henrik Lindberg (JIRA)

unread,
May 15, 2017, 2:54:04 PM5/15/17
to puppe...@googlegroups.com
Henrik Lindberg updated an issue
Change By: Henrik Lindberg
Labels: triaged

Josh Cooper (JIRA)

unread,
Mar 15, 2018, 8:12:03 PM3/15/18
to puppe...@googlegroups.com
Josh Cooper updated an issue
Change By: Josh Cooper
Sub-team: Coremunity
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Atlassian logo

Josh Cooper (JIRA)

unread,
Mar 19, 2018, 5:22:03 PM3/19/18
to puppe...@googlegroups.com
Josh Cooper updated an issue
Change By: Josh Cooper
Acceptance Criteria: We should emit a deprecation warning if anyone puts "source_permissions" in their manifests. We should not emit a deprecation warning during pluginsync (when we programmatically create a catalog with a file resource).

Craig Gomes (JIRA)

unread,
Apr 13, 2018, 9:53:03 AM4/13/18
to puppe...@googlegroups.com
Craig Gomes updated an issue
Change By: Craig Gomes
Sprint: Platform Core Hopper

Josh Cooper (JIRA)

unread,
Jul 17, 2018, 2:45:02 PM7/17/18
to puppe...@googlegroups.com
Josh Cooper commented on Bug PUP-5921
 
Re: Deprecate source_permissions

The following will generate a deprecation warning on the agent when applying a catalog with source_permissions set. However, I think ideally we want the deprecation warning emitted during compilation. Henrik Lindberg does the pops validator support issuing deprecation warnings for specific properties/parameters?

diff --git a/lib/puppet/type/file/source.rb b/lib/puppet/type/file/source.rb
index 905406c069..5989980b2b 100644
--- a/lib/puppet/type/file/source.rb
+++ b/lib/puppet/type/file/source.rb
@@ -352,5 +352,11 @@ module Puppet
 
     defaultto :ignore
     newvalues(:use, :use_when_creating, :ignore)
+    munge do |value|
+      if @resource.file && @resource.line
+        Puppet.puppet_deprecation_warning("The `source_permissions` parameter is deprecated. Explicitly set `owner`, `group`, and `mode`.", file: @resource.file, line: @resource.line)
+      end
+      value
+    end
   end
 end

Josh Cooper (JIRA)

unread,
Jul 17, 2018, 2:48:03 PM7/17/18
to puppe...@googlegroups.com
Josh Cooper commented on Bug PUP-5921
 
Re: Deprecate source_permissions

If there is a way to validate during compilation, then we may want to make the same change to PUP-7534, when using the content property to specify a checksum.

Kris Bosland (JIRA)

unread,
Jul 23, 2018, 6:20:03 PM7/23/18
to puppe...@googlegroups.com
Kris Bosland assigned an issue to Kris Bosland
Change By: Kris Bosland
Assignee: Kris Bosland

Kris Bosland (JIRA)

unread,
Jul 24, 2018, 3:11:04 PM7/24/18
to puppe...@googlegroups.com
Kris Bosland updated an issue
Change By: Kris Bosland
Sprint: Platform Core Hopper KANBAN

Kris Bosland (JIRA)

unread,
Jul 25, 2018, 8:33:04 PM7/25/18
to puppe...@googlegroups.com
Kris Bosland commented on Bug PUP-5921
 
Re: Deprecate source_permissions

 

Because this will be set by set_default inside Type.set_parameters, we will need to detect setting default inside this code.

If we don't, this message will be given during any use of the file resource, even if the user does not specify source_permissions in their puppet code.

We can use a marker similar to the one used in 'puppet config --section'.

 

Garrett Guillotte (JIRA)

unread,
Jul 30, 2018, 4:38:02 PM7/30/18
to puppe...@googlegroups.com
Garrett Guillotte updated an issue
Change By: Garrett Guillotte
Component/s: DOCS

Jorie Tappa (JIRA)

unread,
Jul 30, 2018, 4:40:08 PM7/30/18
to puppe...@googlegroups.com
Jorie Tappa updated an issue
Change By: Jorie Tappa
Acceptance Criteria:
We should emit a deprecation warning if anyone puts "source_permissions" in their manifests. We should not emit a deprecation warning during pluginsync (when we programmatically create a catalog with a file resource).


We should be communicating via docs or some other method for migration implications from 3.x

Josh Cooper (JIRA)

unread,
Aug 2, 2018, 2:08:03 PM8/2/18
to puppe...@googlegroups.com
Josh Cooper updated an issue
Change By: Josh Cooper
Fix Version/s: PUP 5.y
Fix Version/s: PUP 5.5.5

Josh Cooper (JIRA)

unread,
Aug 10, 2018, 12:37:04 PM8/10/18
to puppe...@googlegroups.com
Josh Cooper assigned an issue to Josh Cooper
Change By: Josh Cooper
Assignee: Kris Bosland Josh Cooper

Josh Cooper (JIRA)

unread,
Aug 13, 2018, 7:36:02 PM8/13/18
to puppe...@googlegroups.com
Josh Cooper updated an issue
Change By: Josh Cooper
Release Notes Summary: Setting source_permissions to use or use_when_creating is deprecated. If permissions should be managed, set them explicitly using owner, group, mode.
Release Notes: Deprecation

Josh Cooper (JIRA)

unread,
Aug 13, 2018, 7:37:02 PM8/13/18
to puppe...@googlegroups.com
Josh Cooper assigned an issue to Kris Bosland
Change By: Josh Cooper
Assignee: Josh Cooper Kris Bosland

Josh Cooper (JIRA)

unread,
Aug 13, 2018, 7:37:02 PM8/13/18
to puppe...@googlegroups.com

Michelle Fredette (JIRA)

unread,
Aug 20, 2018, 5:25:03 PM8/20/18
to puppe...@googlegroups.com
Michelle Fredette updated an issue
Change By: Michelle Fredette
Labels: docs_reviewed

Jim Richardson (JIRA)

unread,
Aug 26, 2018, 9:54:04 AM8/26/18
to puppe...@googlegroups.com
Jim Richardson commented on Bug PUP-5921
 
Re: Deprecate source_permissions

I understand why this was done regarding owner / group. I never even knew those attributes used the sources_permissions parameter. But removing "mode" support from source_permissions makes the recursive parameter absolutely useless, without having dual directory/file mode parameters. There is no way to have non executable files in an recursive file definition since directories must have execute permissions.

I realized this issue has been closed, but somehow I think those that approved in were never *nix admims.

Now, I have added my .02. Ya'll be careful out there, ya hear?

 

Josh Cooper (JIRA)

unread,
Aug 29, 2018, 1:05:05 PM8/29/18
to puppe...@googlegroups.com
Josh Cooper commented on Bug PUP-5921
 
Re: Deprecate source_permissions

There is no way to have non executable files in a recursive file definition since directories must have execute permissions.

That's not quite true. If you set the mode to 0640 for the initial directory, then puppet will make sure all directories are also executable. For example given:

class recurse {
  file { '/tmp/recurse':
    ensure  => directory,
    mode    => '640',
    recurse => true,
    source  => 'puppet:///modules/recurse',
  }
}

Where the module contains:

# tree -p /etc/puppetlabs/code/environments/production/modules/recurse/files
/etc/puppetlabs/code/environments/production/modules/recurse/files
└── [drwxr-xr-x]  dir
    └── [drwxr-xr-x]  dir
        └── [-rw-r-----]  file

Will produce:

# puppet agent -t
Info: Using configured environment 'production'
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Retrieving locales
Info: Loading facts
Info: Caching catalog for localhost
Info: Applying configuration version '1535560649'
Notice: /Stage[main]/Recurse/File[/tmp/recurse]/ensure: created
Notice: /Stage[main]/Recurse/File[/tmp/recurse/dir]/ensure: created
Notice: /Stage[main]/Recurse/File[/tmp/recurse/dir/file]/ensure: defined content as '{md5}d41d8cd98f00b204e9800998ecf8427e'
Notice: Applied catalog in 0.09 seconds

and the resulting file is read-only, but the directories are executable:

# tree -p /tmp
/tmp
└── [drwxr-x---]  recurse
    └── [drwxr-x---]  dir
        └── [drwxr-x---]  dir
            └── [-rw-r-----]  file

You can also declare an explicit resource whose mode will be merged with the generated resource:

class recurse {
  file { '/tmp/recurse':
    ensure  => directory,
    mode    => '640',
    recurse => true,
    source  => 'puppet:///modules/recurse',
  }
  file { '/tmp/recurse/dir/dir':
    ensure => directory,
    mode   => '777',
  }
}

Will set the permission of the recursively generated directory to 777:

# puppet agent -t
Info: Using configured environment 'production'
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Retrieving locales
Info: Loading facts
Info: Caching catalog for localhost
Info: Applying configuration version '1535562162'
Notice: /Stage[main]/Recurse/File[/tmp/recurse/dir/dir]/mode: mode changed '0750' to '0777'

# tree -p /tmp
/tmp
└── [drwxr-x---]  recurse
    └── [drwxr-x---]  dir
        └── [drwxrwxrwx]  dir
            └── [-rw-r-----]  file

Jim Richardson (JIRA)

unread,
Aug 29, 2018, 6:23:03 PM8/29/18
to puppe...@googlegroups.com
Jim Richardson commented on Bug PUP-5921
 
Re: Deprecate source_permissions

Yes I agree with you now I matter of fact I learned that in puppet class
yesterday.

On Wed, Aug 29, 2018, 12:05 PM Josh Cooper (JIRA) <

Bill Sirinek (JIRA)

unread,
Sep 7, 2018, 4:52:01 PM9/7/18
to puppe...@googlegroups.com
Bill Sirinek commented on Bug PUP-5921
 
Re: Deprecate source_permissions

The puppet-supported puppet_agent module flags this deprecation warning. The offending code is in manifests/prepare.pp on line 28.

Nate McCurdy (JIRA)

unread,
Jul 19, 2019, 4:20:03 PM7/19/19
to puppe...@googlegroups.com
Nate McCurdy commented on Bug PUP-5921
 
Re: Deprecate source_permissions

When is source_permissions being removed from Puppet?
I see tickets about deprecating it, but no mention of when it will be removed. It's still available in Puppet 6.6.

Also, I'd just like to throw my 2 cents in here and state that source_permissions is very handy for copying over the mode of a file. Really that's all I use it for, and I use it quite a bit. Removing the option to copy over the mode of a file from the source will cause a lot of busy work on our end and will mean that we need to find another solution to the workflow used by a few of the organizations i work with.

We use it primarily to allow teams to check-in a directory of arbitrary files and scripts to be deployed by Puppet to their nodes. The teams have limited permissions to edit the Puppet manifests that control this behavior but have full rights to modify the files/ directory of a module. If source_permissions goes away, those teams would then need to edit the Puppet manifests to create on-off file resources to fix the mode of their scripts.

Raul Tambre (JIRA)

unread,
Oct 23, 2019, 3:36:04 AM10/23/19
to puppe...@googlegroups.com
Raul Tambre commented on Bug PUP-5921
 
Re: Deprecate source_permissions

What is the intended replacement for keeping the mode when copying files?

I can't seem to find one. Fixing the mode for each one manually isn't an option if I'm recursively copying a directory with hundreds of files.

Maximilian Philipps (JIRA)

unread,
Jan 7, 2020, 7:16:03 AM1/7/20
to puppe...@googlegroups.com
Maximilian Philipps commented on Bug PUP-5921
 
Re: Deprecate source_permissions

I don't understand why source_permissions is deprecated. "it doesn't make sense for environments (including PE) that use git for the backend (user/group aren't managed by git)" and if the backend isn't git? Also source_permissions is really useful for mode sensitive files, even if the backend is git.

I am not aware that source may only point to git repositories.

Julian (JIRA)

unread,
Jan 25, 2020, 3:58:04 PM1/25/20
to puppe...@googlegroups.com

Peter Krauspe (Jira)

unread,
Sep 23, 2020, 9:24:04 AM9/23/20
to puppe...@googlegroups.com
Peter Krauspe commented on Bug PUP-5921
 
Re: Deprecate source_permissions

Yes I aggree, PLEASE undeprecate this option ! In my application case it would be horrible to loose it !!
The same arguments as given from other users: We have a lot of files to deploy through  file resource using recurse = true.
I dont want to go to something like an exec { "/usr/bin/tar zxpf files.tgz":} When people continue doing similiar workarounds you get to a point where you have to ask yourself why do I use puppet when thoose options get removed. 

This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Atlassian logo
Reply all
Reply to author
Forward
0 new messages