Jira (PUP-11538) Allow a Struct type to have a default key

2022-05-06 Thread James Ralston (Jira) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 James Ralston created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet /  PUP-11538  
 
 
  Allow a Struct type to have a default key   
 

  
 
 
 
 

 
Issue Type: 
  New Feature  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 Type System  
 
 
Created: 
 2022/05/06 12:06 AM  
 
 
Priority: 
  Normal  
 
 
Reporter: 
 James Ralston  
 

  
 
 
 
 

 
 PUP-5942 was a request to permit the Struct type to define keys using a pattern. This requiest was closed as Wontfix due to the complexity involved. I have a related but simpler (and hopefully thus viable) request: permit the Struct type to have a default key that will match any hash element, so long as the data type of the value of the key matches the specified data type. An example may be helpful in describing what I am proposing:  
 
 
 
 
 class openssh::server (  
 
 
   Struct[{  
 
 
 'Match'  => Hash[String, Hash[String, Scalar]],  
 
 
 'Subsystem'  => Hash[String, Scalar],

Jira (PUP-11538) Allow a Struct type to have a default key

2022-05-06 Thread James Ralston (Jira) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 James Ralston updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet /  PUP-11538  
 
 
  Allow a Struct type to have a default key   
 

  
 
 
 
 

 
Change By: 
 James Ralston  
 

  
 
 
 
 

 
 PUP-5942 was a request to permit the Struct type to define keys using a pattern. This requiest was closed as _Wontfix_ due to the complexity involved.I have a related but simpler (and hopefully thus viable) request: permit the Struct type to have a _default_ key that will match any hash element, so long as the data type of the value of the key matches the specified data type.An example may be helpful in describing what I am proposing:{code}class openssh::server (  Struct[{'Match'  => Hash[String, Hash[String, Scalar]],'Subsystem'  => Hash[String, Scalar],default  => Scalar,  }] $sshd_config,) inherits openssh {{code}For our in-house {{openssh::server}} module, the entire contents of the {{/etc/ssh/sshd_config}} file is passed to the module via a hash, where the key is the option name to set, and the value is the value for that option. For the vast majority of those options, the values are scalars (strings, booleans, or integers), and the ERB template code can generate the correct configuration lines in the {{/etc/ssh/sshd_config}} file without caring what each individual option is.But two sshd_config options are special and require specific data structures to pass their information to the ERB template code. The {{Match}} option takes a hash where the key is the criterion for the Match statement, and the value is a nested hash of options to set within that specific Match block. The {{Subsystem}} option takes a hash where the key is the name of the subsystem, and the value is the command for sshd to execute to invoke that subsystem.What I want to be able to enforce is that if the {{openssh::server::sshd_config}} parameter sets either the {{Match}} or {{Subsystem}} options, the values supplied conform to the data types that those options require. But I don't want to have to laboriously enumerate every one of the ~100 other sshd_config options in the Struct just in order to be able to ensure that the {{Match}} and {{Subsystem}} options conform.(Practically speaking, I _cannot_ enumerate all of the options, even if I wanted to: different distros ship with different versions of OpenSSH, and later OpenSSH versions not only support options that earlier versions do not, but have dropped support for options that earlier versions supported.)Just as it is useful for the Puppet case statement to support a _default_ case that matches if no other case _expression_ matches, it would be useful for Struct to support a _default_ schema key and data type that will match any supplied hash key not explicitly named in the Struct, so long as the data types match.Without this, the only way I can see to implement typedef checking for the {{Match}} and {{Subsystem}} options is to typedef _every_ valid sshd_config option (which as I explained two paragraphs above is impossible), or do something like this:{code}class openssh::server (  Hash[String,

Jira (FACT-2874) facter 4.0.46 should load external fact files in lexicographical order

2020-12-16 Thread James Ralston (Jira) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 James Ralston commented on  FACT-2874  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: facter 4.0.46 should load external fact files in lexicographical order   
 

  
 
 
 
 

 
 When testing Puppet Platform 7.1, this appears to be fixed: for duplicate facts, the one that appears in the file that sorts lexicographically last is the one that is used. Thank you!  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.379132.1606176297000.101290.160814621%40Atlassian.JIRA.

Jira (FACT-2874) facter 4.0.46 should load external fact files in lexicographical order

2020-11-23 Thread James Ralston (Jira) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 James Ralston created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Facter /  FACT-2874  
 
 
  facter 4.0.46 should load external fact files in lexicographical order   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Created: 
 2020/11/23 4:04 PM  
 
 
Priority: 
  Normal  
 
 
Reporter: 
 James Ralston  
 

  
 
 
 
 

 
 Up through facter 3.14.14 (Puppet 6.x), when facter loaded external facts from files in the /etc/facter/facts.d directory, if the same fact appeared in multiple files, the version of the fact that appeared in the file Puppet loaded last won. Starting in facter 4.0.46 (Puppet 7.x), if a fact is duplicated in multiple files, facter appears to use the first value it sees for the ultimate value of that fact, not the last. This is problematic in the case where events can dynamically add and remove files from the /etc/facter/facts.d directory. Here's an example. I have a NetworkManager dispatch script, /etc/NetworkManager/dispatcher.d/50-facter, that drops facter facts into /etc/facter/facts.d that contribute interface information. E.g.:  
 
 
 
 
 $ ls -lsa /etc/facter/facts.d  
 
 
 total 12  
 
 
 0 drwxr-xr-x. 1 root root  112 Nov 23 16:56 ./  
 
 
 0 drwxr-xr-x. 1 root root   14 Jul 13  2015 ../

Jira (FACT-2869) Puppet 7.0.0 facter changes is_virtual fact to string (from boolean)

2020-11-19 Thread James Ralston (Jira) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 James Ralston created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Facter /  FACT-2869  
 
 
  Puppet 7.0.0 facter changes is_virtual fact to string (from boolean)   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Created: 
 2020/11/19 9:56 PM  
 
 
Priority: 
  Normal  
 
 
Reporter: 
 James Ralston  
 

  
 
 
 
 

 
 In Puppet 6.x, facter reports the is_virtual fact as a boolean:  
 
 
 
 
 $ facter --version; facter --json is_virtual  
 
 
 3.14.14 (commit e36657bea27254f003c8fc71d8ef57454db643e2)  
 
 
 {  
 
 
   "is_virtual": false  
 
 
 }
  
 
 
 
  But in Puppet 7.0.0, facter reports the is_virtual fact as a string:

Jira (PUP-10161) Regresssion: puppet 6.11 can't manage selinux on centos/redhat 8

2020-01-08 Thread James Ralston (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 James Ralston commented on  PUP-10161  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Regresssion: puppet 6.11 can't manage selinux on centos/redhat 8   
 

  
 
 
 
 

 
 Red Hat responded to me. Red Hat asserts (and I have verified) that RHEL7 did build libselinux.so.1 with the rpm_execcon() function. The specific line in the RHEL7 libselinux.spec file (for every version of the RHEL7 libselinux package) is:  
 
 
 
 
 # FIXME: export DISABLE_RPM="y"
  
 
 
 
  This is trivial to verify on a RHEL7 system, using the stock Ruby and libselinux-ruby packages:  
 
 
 
 
 $ /usr/bin/irb   
 
 
 irb(main):001:0> require 'selinux'  
 
 
 => true  
 
 
 irb(main):002:0> Selinux.rpm_execcon(1, 2, 3, 4)  
 
 
 TypeError: Expected argument 1 of type char const *, but got Fixnum 2  
 
 
 in SWIG method 'rpm_execcon'  
 
 
 from (irb):2:in `rpm_execcon'  
 
 
 from (irb):2  
 
 
 from /usr/bin/irb:12:in `'  
 
 
 irb(main):003:0>

Jira (PUP-10161) Regresssion: puppet 6.11 can't manage selinux on centos/redhat 8

2019-12-14 Thread James Ralston (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 James Ralston commented on  PUP-10161  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Regresssion: puppet 6.11 can't manage selinux on centos/redhat 8   
 

  
 
 
 
 

 
 People who are attempting to use the RHEL8 Puppet packages on Fedora will also be burned by this, as every version of Fedora I have examined (including Rawhide) ships a libselinux package that was built with export DISABLE_RPM="y". (And yes, I know Puppet doesn't officially support running RHEL packages on Fedora. But I experiment with running puppetserver on Fedora, and Puppet doesn't build the puppetserver packages for the official Fedora repositories. Furthermore, because Fedora moves so rapidly, it's generally the case that by the time official Puppet packages appear for Fedora [n] are available, I've already migrated to Fedora [n+1]. For these reasons, I eschew Puppet's official Fedora repositories, and instead use the latest RHEL repository on my Fedora systems.) That notwithstanding, it is unusual for Red Hat to roll out a change for RHEL that hasn't hit Fedora already, as Fedora is essentially RHEL next. It's also somewhat unusual (but not without precedent) for Red Hat to break backwards shared library compatibility with RHEL minor point releases. As such, I think there is a possibility that this change wasn't intentional—that it was an oversight in the libselinux 2.8 → 2.9 rebase between RHEL 8.0 and RHEL 8.1 We are a RHEL shop and have a Red Hat support contract. I filed the following support case with Red Hat, gently questioning this change: 
 
why is libselinux now built with 'export DISABLE_RPM="n"'? 
What problem/issue/behavior are you having trouble with? What do you expect to see? 
Starting with libselinux-2.9-2.1.el8, the %build section of libselinux.spec file now contains: 
 
 
 
 
 
 export DISABLE_RPM="n"
  
 
 
 
 
 
This is a change from the previous (RHEL 8.0) version of libselinux, libselinux-2.8-6.el8, which contained: 
 
 
 
 
 
 export DISABLE_RPM="y"

Jira (FACT-2055) Facter fails if its working directory does not exist

2019-10-08 Thread James Ralston (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 James Ralston commented on  FACT-2055  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Facter fails if its working directory does not exist   
 

  
 
 
 
 

 
 The problem is that although facter does not call boost::filesystem::current_path directly (at least as far as I can tell), something else it calls does (most likely, another boost library call), and getcwd() fails with ENOENT if the cwd has been unlinked. I'll play devil's advocate here: is this a bug with Puppet, or a feature of Unix? Puppet is not the only program that will fail if its cwd is unlinked. A great many number of standard Unix utilities will throw errors (and potentially die / fail to function) if the cwd does not exist. If facter died or produced errors if the cwd were inaccessible, I would assert that is a bug with facter. (See PUP-9997 for the rationale there.) But facter bombing out if its cwd is unlinked? I'd argue the most reasonable response to that might simply be the punchline to the old "doctor, it hurts when I move my arm this way" joke: then don't do that.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.327976.1570129217000.134972.1570568160103%40Atlassian.JIRA.

Jira (PUP-10080) Exec resources fail if the working directory is inaccessible

2019-10-08 Thread James Ralston (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 James Ralston commented on  PUP-10080  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Exec resources fail if the working directory is inaccessible   
 

  
 
 
 
 

 
 John Bollinger, I propose that there are two separate issues here: 
 
Puppet misbehaves / fails if the cwd is inaccessible. 
Puppet misbehaves / fails if the cwd does not exist. 
 I reopend my ticket PUP-9997, which is solely about issue #1. Would you be willing to confine issue #1 to PUP-9997, and keep issue #2 confined to this ticket?  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.327890.1570115712000.134915.1570567080145%40Atlassian.JIRA.

Jira (PUP-5915) exec resources fail unless cwd is readable

2019-10-08 Thread James Ralston (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 James Ralston commented on  PUP-5915  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: exec resources fail unless cwd is readable   
 

  
 
 
 
 

 
 I was incorrect. This is not actually fixed. The problem is that the exec resource itself implicitly defaults the cwd parameter to the cwd if the cwd parameter was not provided for the exec resource in question. In the case where Puppet's cwd is inaccessible, this will cause all Puppet exec() resources to fail. I assert that defaulting the cwd parameter to the cwd of the Puppet process is wrong. If the user does not supply a cwd parameter to the exec resource in question, Puppet must assume that the user does not want Puppet to attempt to chdir() to any directory. Assuming that the user wants Puppet to chdir() to the cwd is an erroneous assumption, as 1) this is not what the user specified, and 2) it's nonsensical, as even if the chdir() call succeeds, Puppet has not actually changed the cwd. To fully fix this bug, I agree with John Bollinger in PUP-10080: the "implicitly default the cwd parameter to Puppet's cwd if it was not specified" behavior is wrong and should be removed. I think the only thing required is removing this line from lib/puppet/provider/exec.rb:  
 
 
 
 
   cwd ||= Dir.pwd
  
 
 
 
  This is because, from my read, Puppet::Util::Execution.execute() will do the correct thing if the cwd parameter is unspecified:  
 
 
 
 
 cwd = options[:cwd]  
 
 
 if cwd && ! Puppet::FileSystem.directory?(cwd)  
 
 
   raise ArgumentError, _("Working directory %{cwd} does not exist!") % { cwd: cwd }  
 
 
 end
  
 
 
 
  And:  
 
 
 
 
 cwd =

Jira (PUP-10080) Exec resources fail if the working directory is inaccessible

2019-10-08 Thread James Ralston (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 James Ralston commented on  PUP-10080  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Exec resources fail if the working directory is inaccessible   
 

  
 
 
 
 

 
 John Bollinger, I'll defer to Puppet folks who want to chime in, but as the reporter of PUP-9997, I would just submit a PR with the code fixes and no tests. From looking at the code for the Exec provider, I think the only thing that is required is removing the cwd ||= Dir.pwd line, as Puppet::Util::Execution.execute() only calls Dir.chdir if the cwd parameter was set. Did you come to a different conclusion?  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.327890.1570115712000.134538.1570559100152%40Atlassian.JIRA.

Jira (PUP-9997) Puppet must not call Dir.chdir() except in a child process

2019-09-04 Thread James Ralston (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 James Ralston updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet /  PUP-9997  
 
 
  Puppet must not call Dir.chdir() except in a child process   
 

  
 
 
 
 

 
Change By: 
 James Ralston  
 

  
 
 
 
 

 
 *Puppet Version:* 6.8.1*Puppet Server Version:* 6.5.0*OS Name/Version:* Red Hat Enterprise Linux 7In Ruby, Dir.chdir changes the current working directory (cwd) of the Ruby process. Under the hood, it calls the the chdir() system call.When Dir.chdir is passed a block, it notes the cwd, then calls chdir() and executes the block. When the block finishes, it calls chdir() again, supplying as the argument the previous cwd that it noted. (This is similar to the pushd/popd shell builtins.)However, in Unix, it is possible for the cwd to be a directory that is inaccessible to the current process. This means that once you chdir() out of the cwd, attempting to chdir() to the old cwd will fail.This is trivial to demonstrate for the non-root user:{noformat}$ cd /tmp$ mkdir foo$ chmod 0700 foo$ cd foo$ /usr/bin/pwd/tmp/foo$ cd /tmp/foo && echo noerrornoerror$ chmod  .$ /usr/bin/pwd/tmp/foo$ cd /tmp/foo && echo noerror-bash: cd: /tmp/foo: Permission denied{noformat}In most cases, the root user will never receive permission denied errors when attempting to chdir to a directory. But there are exceptions. One exception is a network filesystem where the local root user has no special privileges, such as Kerberized NFS. On Linux systems, removal of the {{CAP_DAC_OVERRIDE}} and {{CAP_DAC_READ_SEARCH}} capabilities will also prevent root from calling chdir() to an inaccessible directory.So, putting this all together, we reach the following conclusion: the only time where it is safe to call Dir.chdir() is in a child process. Because:# Calling Dir.chdir() without a block has a side-effect of changing the cwd for the execution of all subsequent code. This is undesirable, and dangerous.# Calling Dir.chdir() with a block can fail to restore the cwd when the block exits (as per above), which then reduces to #1.Previously, the _cwd_ parameter of the _exec_ resource was implemented using Dir.chdir() with a block argument. This caused failures for users who ran {{sudo puppet agent --test}} when sitting in a Kerberized NFS home directory that root could not execute, as the very first exec resource encountered would throw an exception when Dir.chdir() received EACCES when attempting to restore the old cwd when the block finished. This spawned at least two tickets: PUP-5808 and PUP-5915. At some point in the recent past In PUP-6919 (specifically ,  {{Puppet  [commit ebb57c3e|https : :Util::Execution //github . execute}} added the ability to specify the cwd of the command to be executed com/puppetlabs/puppet/commit/ebb57c3e60800bdc847cc1276b8a6d9d65c6208b]) ,  and  the exec resource was rewritten to simply pass the cwd to {{Puppet::Util::Execution.execute}} instead of calling Dir.chdir() itself. Since {{Puppet::Util::Execution.execute}} doesn't call Dir.chdir() until after it forks the child process and before it calls exec(), and since calling chdir() in a child

Jira (PUP-5808) puppet via sudo from nfs home is not working

2019-09-04 Thread James Ralston (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 James Ralston updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet /  PUP-5808  
 
 
  puppet via sudo from nfs home is not working   
 

  
 
 
 
 

 
 From digging, it was PUP-6919 (specifically, commit ebb57c3e) that rewrote the exec resource to have the child process call Dir.chdir(). Puppet 5.5.7 was the first version to contain the fix.  
 

  
 
 
 
 

 
Change By: 
 James Ralston  
 
 
Fix Version/s: 
 PUP 5.5.7  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.115050.1454515664000.86229.1567639260400%40Atlassian.JIRA.

Jira (PUP-5808) puppet via sudo from nfs home is not working

2019-09-04 Thread James Ralston (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 James Ralston commented on  PUP-5808  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: puppet via sudo from nfs home is not working   
 

  
 
 
 
 

 
 For posterity: the issue with the exec resource failing due to receiving EACCES when attempting to call chdir() to the cwd was resolved as a (perhaps intentional) side-effect of changes made to how the exec resource is implemented. (In essence, Puppet now calls chdir() in the child process it forks to perform the exec, not in the parent process.) But the root cause of this issue—that it is never safe to call chdir() except in a child process—is not completely resolved. See PUP-9997 for details.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.115050.1454515664000.86204.1567638661238%40Atlassian.JIRA.

Jira (PUP-9997) Puppet must not call Dir.chdir() except in a child process

2019-09-04 Thread James Ralston (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 James Ralston created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet /  PUP-9997  
 
 
  Puppet must not call Dir.chdir() except in a child process   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Created: 
 2019/09/04 4:00 PM  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 James Ralston  
 

  
 
 
 
 

 
 Puppet Version: 6.8.1 Puppet Server Version: 6.5.0 OS Name/Version: Red Hat Enterprise Linux 7 In Ruby, Dir.chdir changes the current working directory (cwd) of the Ruby process. Under the hood, it calls the the chdir() system call. When Dir.chdir is passed a block, it notes the cwd, then calls chdir() and executes the block. When the block finishes, it calls chdir() again, supplying as the argument the previous cwd that it noted. (This is similar to the pushd/popd shell builtins.) However, in Unix, it is possible for the cwd to be a directory that is inaccessible to the current process. This means that once you chdir() out of the cwd, attempting to chdir() to the old cwd will fail. This is trivial to demonstrate for the non-root user:  
 
 
 
 
 $ cd /tmp  
 
 
 $ mkdir foo  
 
 
 $ chmod 0700 foo  
 
 
 $ cd foo

Jira (PUP-9465) group resource type misunderstands/misuses libuser

2019-09-04 Thread James Ralston (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 James Ralston commented on  PUP-9465  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: group resource type misunderstands/misuses libuser   
 

  
 
 
 
 

 
 Gabriel Nagy, I agree that using binaries from 2 different packages in the same provider seems wrong. That's the primary reason why I think there should be two separate providers, even though there is a lot of overlap between the functionality of the providers. Upon reflection, I will walk back my "If both the libuser provider and the groupadd provider are available, prefer the libuser provider" assertion. But I'm not sure that the minor differences in functionality are appropriate selection criteria to prefer one provider over the other, either. As you noted, libuser doesn't support NIS (which shadow supports). But shadow doesn't support LDAP (which libuser supports). How about this: for any system where groupadd is currently the default provider, it should remain the default provider, even if the libuser provider is available. This will make the libuser provider available for those who specifically want it (most likely for the manages_members feature), but it will avoid potential disruption by exposing Puppet users to subtle differences between the groupadd and libuser providers. But I still think that once the libuser provider is available, the forcelocal parameter should be deprecated, and should emit a warning that 1) the forcelocal parameter will be removed in a future Puppet release, and 2) to use the libuser provider instead if the goal is have the manages_members feature.  Finally, I wouldn't put much stock in the 2013 comment 2 in Red Hat BZ#1028544 about libuser going away. A lot of what libuser was planned to do was subsumed by the sssd project, which is why development on libuser has slowed. But both the shadow project and the libuser project are active. As another metric, Red Hat Enterprise Linux 8 shipped with libuser. Since libuser was created by Red Hat developers and is maintained by Red Hat developers, that means libuser isn't going anywhere for the lifetime of RHEL8, which doesn't end until May 2029. And libuser is still in Fedora, which is (essentially) the upstream for RHEL.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by

Jira (PUP-9465) group resource type misunderstands/misuses libuser

2019-07-30 Thread James Ralston (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 James Ralston updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet /  PUP-9465  
 
 
  group resource type misunderstands/misuses libuser   
 

  
 
 
 
 

 
Change By: 
 James Ralston  
 
 
Affects Version/s: 
 PUP 6.1.0  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.293306.1548368109000.37199.1564525560475%40Atlassian.JIRA.

Jira (PUP-9465) group resource type misunderstands/misuses libuser

2019-07-30 Thread James Ralston (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 James Ralston updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet /  PUP-9465  
 
 
  group resource type misunderstands/misuses libuser   
 

  
 
 
 
 

 
Change By: 
 James Ralston  
 
 
Affects Version/s: 
 PUP 6.6.0  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.293306.1548368109000.37196.1564525560462%40Atlassian.JIRA.

Jira (PUP-9465) group resource type misunderstands/misuses libuser

2019-07-30 Thread James Ralston (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 James Ralston updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet /  PUP-9465  
 
 
  group resource type misunderstands/misuses libuser   
 

  
 
 
 
 

 
Change By: 
 James Ralston  
 
 
Labels: 
 group  libuser  linux user  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.293306.1548368109000.37202.1564525560485%40Atlassian.JIRA.

Jira (PUP-9465) group resource type misunderstands/misuses libuser

2019-07-30 Thread James Ralston (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 James Ralston updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet /  PUP-9465  
 
 
  group resource type misunderstands/misuses libuser   
 

  
 
 
 
 

 
Change By: 
 James Ralston  
 
 
Summary: 
 group resource type  should support lgroupadd provider on Linux  misunderstands/misuses libuser  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.293306.1548368109000.37106.1564524540140%40Atlassian.JIRA.

Jira (PUP-9465) group resource type should support lgroupadd provider on Linux

2019-07-30 Thread James Ralston (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 James Ralston commented on  PUP-9465  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: group resource type should support lgroupadd provider on Linux   
 

  
 
 
 
 

 
 Hi Melissa Stone, Branan Riley, I apologize for taking so long to get back to this. I've reopened this ticket, because I believe there is a fundamental mis-engineering here that should be addressed. Both the Puppet code and the responses to this ticket imply that the Puppet devs believe that lgroupmod is the "local" version of groupmod. But this is not the case. The (groupadd, groupmod, groupdel) programs belong to the shadow project. These utilities explicitly operate on local files (/etc/passwd, /etc/shadow, /etc/group, /etc/gshadow) only. The (lgroupadd, lgroupmod, lgroupdel) programs belong to the libuser project. Per its documentation, libuser is a library that implements a standardized interface for manipulating and administering user and group accounts, using pluggable back-ends to interface to data sources. Currently, local files and LDAP backends are supported. In essence, it's a more capable replacement for shadow-utils, designed to easier to maintain (because it's not carrying around 20+ years of warts). It is not the case that the "l" in lgroupmod et. al. means local; it means libuser. The model that Puppet resource types use is that when there are multiple methods that can accomplish a backend task, each method is enumerated as a separate provider, and Puppet chooses the best provider on a per-platform basis. That is a clean, beautiful, easy-to-understand model; it's one of the clear design wins of Puppet. It is what Puppet administrators and developers are used to. This is why the forcelocal parameter is so egregiously wrong and offensive. If Puppet understood how to use the (lgroupadd, lgroupmod, lgroupdel) programs, I fully expected to see Puppet's usage of those programs encapsulated by a separate libuser provider. Seeing no such provider, and searching the documentation in vain for any explicit mention of the (lgroupadd, lgroupmod, lgroupdel) programs, I concluded Puppet did not understand how to use the (lgroupadd, lgroupmod, lgroupdel) programs. (Yes, the documentation does mention libuser. But it does so in a way that has no relation to what libuser actually is and what it actually does.) Fortunately, there is an easy path out of this mess for the group resource: 
 
Turn the libuser provider feature into a provider proper, which uses the (lgroupadd, lgroupmod, lgroupdel) programs. The libuser provider should have the manages_members and system_groups features. 
If both the libuser provider and the groupadd provider are available, prefer the libuser provider. 
Deprecate the forcelocal parameter, and emit a warning if it is set to true. 
As a special case, for backwards compatibility, if the groupadd provider was specified and the forcelocal parameter was true, use the libuser provider instead of the groupadd provider. 
 Taking the above steps will correct the long-standing mis-engineering of the group resource, aligning it with the proper Puppet provider model.

Jira (PUP-9811) incoherent Puppet Platform 6.5.0 announcement versus release notes

2019-06-27 Thread James Ralston (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 James Ralston created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet /  PUP-9811  
 
 
  incoherent Puppet Platform 6.5.0 announcement versus release notes   
 

  
 
 
 
 

 
Issue Type: 
  Task  
 
 
Affects Versions: 
 PUP 6.5.0  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 Docs  
 
 
Created: 
 2019/06/27 1:47 PM  
 
 
Environment: 
 The email announcement for Puppet Platform 6.5.0 consisted of this text: 
 
This release contain bug fixes and enhancement, notably: 
 
Support added for Fedora 30 (amd64) 
New v4 catalog endpoint 
 
You can see the full list of changes in the release notes https://puppet.com/docs/puppet/6.5/release_notes_puppet.html
 However, the 6.5.0 release notes make no mention of the new v4 catalog endpoint. I'm guessing that both the release announcement and the release notes went through multiple iterations of reviews/edits, and the final versions were supposed to be coherent, but this discrepancy was accidentally missed. Please update the release notes to include the information about the new v4 catalog endpoint that the release announcement references.  
 
 
Priority: 
  Normal  
 
 
Reporter: 
 James Ralston

Jira (PUP-9811) incoherent Puppet Platform 6.5.0 announcement versus release notes

2019-06-27 Thread James Ralston (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 James Ralston updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet /  PUP-9811  
 
 
  incoherent Puppet Platform 6.5.0 announcement versus release notes   
 

  
 
 
 
 

 
Change By: 
 James Ralston  
 
 
Environment: 
 The email announcement for Puppet Platform 6.5.0 consisted of this text:{quote}This release contain bug fixes and enhancement, notably:* Support added for Fedora 30 (amd64)* New v4 catalog endpoint You can see the full list of changes in the release notes https://puppet.com/docs/puppet/6.5/release_notes_puppet.html{quote}However, the 6.5.0 release notes make no mention of the new v4 catalog endpoint.I'm guessing that both the release announcement and the release notes went through multiple iterations of reviews/edits, and the final versions were supposed to be coherent, but this discrepancy was accidentally missed.Please update the release notes to include the information about the new v4 catalog endpoint that the release announcement references.  
 

  
 
 
 
 

 
 The email announcement for Puppet Platform 6.5.0 consisted of this text:{quote}This release contain bug fixes and enhancement, notably:* Support added for Fedora 30 (amd64)* New v4 catalog endpoint You can see the full list of changes in the release notes https://puppet.com/docs/puppet/6.5/release_notes_puppet.html{quote}However, the 6.5.0 release notes make no mention of the new v4 catalog endpoint.I'm guessing that both the release announcement and the release notes went through multiple iterations of reviews/edits, and the final versions were supposed to be coherent, but this discrepancy was accidentally missed.Please update the release notes to include the information about the new v4 catalog endpoint that the release announcement references.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

Jira (PUP-9465) group resource type should support lgroupadd provider on Linux

2019-01-24 Thread James Ralston (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 James Ralston created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet /  PUP-9465  
 
 
  group resource type should support lgroupadd provider on Linux   
 

  
 
 
 
 

 
Issue Type: 
  New Feature  
 
 
Affects Versions: 
 PUP 6.1.0  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 Types and Providers  
 
 
Created: 
 2019/01/24 2:15 PM  
 
 
Priority: 
  Normal  
 
 
Reporter: 
 James Ralston  
 

  
 
 
 
 

 
 Puppet Version: 6.1.0 Puppet Server Version: 6.1.0 OS Name/Version: Red Hat Enterprise Linux 7 The group resource type supports the groupadd provider, but not the lgroupadd provider. lgroupadd (and lgroupmod and lgroupdel) are part of the libuser library/package. While libuser is essentially a rewrite of the groupadd, groupmod, and groupdel programs from the shadow-utils package (because Red Hat tends toward NIH syndrome), lgroupmod has one important advantage over groupmod: lgroupmod can manipulate group members directly. E.g., you can do this:  
 
 
 
 
 $ lgroupmod --member-add user1,user2,user3 somegroup
  
 
 
 
  In contrast, groupmod cannot do this. Instead, you have to do this:

Jira (PUP-8947) Automatically cast ACPL results to Sensitive for Sensitive-typed class parameters

2018-07-18 Thread James Ralston (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 James Ralston commented on  PUP-8947  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Automatically cast ACPL results to Sensitive for Sensitive-typed class parameters   
 

  
 
 
 
 

 
 The problem I have with using covert_to in lookup_options is that is completely falls down in a case like this:  
 
 
 
 
 class duo (  
 
 
   Struct[{  
 
 
 Optional['duo'] => Struct[{  
 
 
   Optional['host']  => Optional[String],  
 
 
   Optional['ikey']  => Optional[Sensitive[String]],  
 
 
   Optional['skey']  => Optional[Sensitive[String]],  
 
 
   Optional['groups']=> Optional[Variant[String, Array[String]]],  
 
 
   Optional['failmode']  => Optional[Enum['safe', 'secure']],  
 
 
   Optional['pushinfo']  => Optional[Variant[Boolean, Enum['yes', 'no']]],  
 
 
   Optional['http_proxy']=> Optional[String],  
 
 
   Optional['autopush']  => Optional[Variant[Boolean, Enum['yes', 'no']]],  
 
 
   Optional['prompts']   => Optional[Integer[1,default]],

Jira (PUP-8639) need seamless way to replace expiring CA certificate

2018-04-06 Thread James Ralston (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 James Ralston commented on  PUP-8639  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: need seamless way to replace expiring CA certificate   
 

  
 
 
 
 

 
 Correction: someone asserted that puppet certregen is a face that the puppetlabs-certregen modules adds. But per the module dependencies, the module doesn't work with Puppet 5, and doesn't seem to be under active development.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.

Jira (PUP-8639) need seamless way to replace expiring CA certificate

2018-04-06 Thread James Ralston (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 James Ralston created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet /  PUP-8639  
 
 
  need seamless way to replace expiring CA certificate   
 

  
 
 
 
 

 
Issue Type: 
  New Feature  
 
 
Assignee: 
 Unassigned  
 
 
Created: 
 2018/04/06 1:30 PM  
 
 
Priority: 
  Normal  
 
 
Reporter: 
 James Ralston  
 

  
 
 
 
 

 
 What realistic option does a Puppet open source site have if the expiration on the CA master certificate is approaching, and one wants to smoothly transition to a new CA master certificate? The only official documentation I can find that comes close to this is the following: https://puppet.com/docs/puppet/5.5/ssl_regenerate_certificates.html But that procedure is describing an apocalypse-level security event where all certificates must be treated as untrustworthy and discarded. There is this: https://forge.puppet.com/puppetlabs/certregen …but that module hasn't been updated in almost a year, and is incompatible with Puppet 5, because Puppet 5 removed puppet certregen and replaced it with… nothing, as far as I can tell. The only potential solution I can see is this: https://blog.flyingcircus.io/2017/09/01/how-to-renew-puppet-ca-and-server-certificates-in-place/ Perhaps PE already has a smooth way to do this, but there needs to be a smooth way to do this for Puppet open source as well, without sending sites running open source scurrying to random third-party blog posts. I realize this is both a very unsexy and very challenging issue to solve, but for the sites that need to solve it… it's a DEFCON 1 event.

Jira (PUP-8566) "puppet config print" should only emit diagnostic info when run with verbose or higher

2018-04-03 Thread James Ralston (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 James Ralston commented on  PUP-8566  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: "puppet config print" should only emit diagnostic info when run with verbose or higher   
 

  
 
 
 
 

 
 R.I.Pienaar wrote: 
 
Master, apply etc all have --configprint and all does the right thing.
 Ummm… ok, I'll ask it: why? Why have the exact same functionality duplicated across different command families? But back to the issue at hand: the original goal of PUP-2868 was to prevent novice users from running puppet config print without --section and then getting confused over which settings applied to which role. Issuing a big fat warning when --section is not used satisfies that goal. Therefore, I agree that the behavior of puppet config print should be reverted to only print the section if --verbose (or perhaps --debug) is passed. (I have no strong opinion as to whether the threshold is --verbose or --debug.) I originally suggested using --quiet to suppress printing the section, but I think this behavior change makes more sense than what I suggested, so I'm all for it.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit

Jira (PUP-8566) "puppet config print" needs --quiet option to disable new (default) verbosity

2018-03-21 Thread James Ralston (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 James Ralston commented on  PUP-8566  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: "puppet config print" needs --quiet option to disable new (default) verbosity   
 

  
 
 
 
 

 
 R.I.Pienaar advice appreciated, but alas, in this case, I must use puppet config print, because I'm specifically looking for reportdir, which is defined in the [master] section. So using puppet agent --configprint will give me incorrect results:  
 
 
 
 
 $ puppet agent --configprint reportdir  
 
 
 /opt/puppetlabs/puppet/cache/reports  
 
 
    
 
 
 $ puppet config print --color=false --section master reportdir 2>/dev/null  
 
 
 /opt/puppetlabs/server/data/puppetserver/reports
  
 
 
 
  For now, I've updated my scripts to redirect stderr to /dev/null, but this is just hiding the problem.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by

Jira (PUP-8566) "puppet config print" needs --quiet option to disable new (default) verbosity

2018-03-21 Thread James Ralston (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 James Ralston created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet /  PUP-8566  
 
 
  "puppet config print" needs --quiet option to disable new (default) verbosity   
 

  
 
 
 
 

 
Issue Type: 
  New Feature  
 
 
Affects Versions: 
 PUP 5.5.0  
 
 
Assignee: 
 Unassigned  
 
 
Created: 
 2018/03/21 10:47 AM  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 James Ralston  
 

  
 
 
 
 

 
 While the enhancements implemented in PUP-2868 are arguably good, because they make puppet config print less confusing for novice users, making puppet config print unconditionally emit messages to stderr is undesirable, as the extraneous stderr messages can confuse programs which are using puppet config print non-interactively and are parsing the output. Case in point: I have multiple cron jobs that use puppet config print to obtain Puppet configuration information. After upgrading to 5.5.0, I am now receiving messages like this on an hourly basis:  
 
 
 
 
 From: "(Cron Daemon)"   
 
 
 To: r...@example.org  
 
 
 Subject: Cron  run-parts /etc/cron.hourly  
 
 
 Date: Wed, 21 Mar 2018 13:01:01 -0400

Jira (PUP-2172) Add exceptions to http_proxy_{port,host}

2018-03-13 Thread James Ralston (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 James Ralston commented on  PUP-2172  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Add exceptions to http_proxy_{port,host}   
 

  
 
 
 
 

 
 I'm re-opening this ticket, because I believe the severity of the problem hasn't been fully appreciated. Any security-competent site that requires outbound HTTP[S] traffic to use a network proxy will have configured the proxy to deny all requests for internal resources. (Otherwise, internal users can bypass internal network ACLs by routing requests through the proxy.) This means that any application that is proxy-aware must implement an exception list for the proxy. Without this exception list, the application is essentially offering its users two choices: 
 
You can access foreign resources, but not local resources. 
You can access local resources, but not foreign resources. 
 We see this in the applications that rely on the curl-style (http_proxy, https_proxy, and no_proxy) environment variables. E.g.:  
 
 
 
 
 $ set | grep proxy  
 
 
 http_proxy=http://proxy.example.org:8080  
 
 
 https_proxy=http://proxy.example.org:8080  
 
 
 no_proxy=localhost,.example.org
  
 
 
 
  The no_proxy setting is not optional: without this, applications will not be able to access local resources. As a real-world example of just how critical the no_proxy list is, consider this example:  
 
 
 
 
 package { 'r10k':  
 
 
   ensure   => present,  
 
 
   provider => puppet_gem,

Jira (PUP-2172) Add exceptions to http_proxy_{port,host}

2018-03-13 Thread James Ralston (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 James Ralston updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet /  PUP-2172  
 
 
  Add exceptions to http_proxy_{port,host}   
 

  
 
 
 
 

 
Change By: 
 James Ralston  
 
 
Affects Version/s: 
 PUP 5.4.0  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.

Jira (PUP-5915) exec resources fail unless cwd is readable

2018-03-02 Thread James Ralston (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 James Ralston commented on  PUP-5915  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: exec resources fail unless cwd is readable   
 

  
 
 
 
 

 
 My first attempt at solving the problem was incorrect, which is why I never submitted a PR. But this is still biting us, so I'll take another crack at it.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.

Jira (PUP-5868) yumrepo does not remove repo file

2018-03-02 Thread James Ralston (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 James Ralston commented on  PUP-5868  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: yumrepo does not remove repo file   
 

  
 
 
 
 

 
 Lucas Yamanishi said: 
 
Most, if not all repo-release.rpm spec files mark the repo files as %config(noreplace) which will prevent them from being recreated if deleted.
 This is incorrect. All the %config and %config(noreplace) flags do is to tell rpm that local changes to the file in question must not be lost. (The %config flag retains local changes by moving the current file to .rpmorig; the %config(noreplace) flag retains local changes by installing the new file as .rpmnew. and keeping the current file in place.) But if the file doesn't exist, there are no potential changes to lose, so rpm will always create the file on package install/upgrade.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.

Jira (PUP-6589) Resource Type sshkey doesn't allow the declaration of multiple SSH host keys for one host

2017-12-14 Thread James Ralston (JIRA) 
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 James Ralston commented on  PUP-6589 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Resource Type sshkey doesn't allow the declaration of multiple SSH host keys for one host  
 
 
 
 
 
 
 
 
 
 
Bump. This bug makes the sshkey resource type utterly unusable. 
For any modern ssh implementation, a host may have rsa keys, ecdsa keys, and ed25519 keys. If we're going to publish a host's ssh public keys, we have to publish all of them. The fact that it is impossible to do this using the sshkey resource (unless you want to publish a bunch of fake host names, as per the description) means that there's no point in even attempting to use sshkey resources to manage ssh public keys. 
(We tried using the sshkey resource years ago, but when we realized that it was broken by design, we abandoned it.) 
I agree with Peter Meier: what makes a ssh public key unique is the combination of its name and its key type. Neither the name nor the key type by itself is unique. The sshkey resource should use the same uniqueness test. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v7.0.2#70111-sha1:88534db) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.

Jira (PUP-868) Deprecate Unusable Certificate Faces

2017-03-12 Thread James Ralston (JIRA) 
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 James Ralston commented on  PUP-868 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Deprecate Unusable Certificate Faces  
 
 
 
 
 
 
 
 
 
 
Moses Mendoza: thanks; I commented on SERVER-1747 as well. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.

Jira (PUP-868) Deprecate Unusable Certificate Faces

2017-03-07 Thread James Ralston (JIRA) 
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 James Ralston commented on  PUP-868 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Deprecate Unusable Certificate Faces  
 
 
 
 
 
 
 
 
 
 
Andrew Parker, we use the certificate_revocation_list face to distribute our CA master's crl to our [non-CA] Puppet master pool, by having the non-CA masters regularly poll the CA master for the latest crl: 
 
 
 
 
 
 
$ puppet certificate_revocation_list find ca --terminus rest
 
 
 
 
 
 
 
I do not see a way to do this using puppet cert. The only way I see to do it is to call the Puppet HTTP API directly. E.g.: 
 
 
 
 
 
 
$ CA_SERVER=$(puppet config print --section master ca_server) 
 
 
 
 
$ LOCAL_CA_CERT=$(puppet config print --section master localcacert) 
 
 
 
 
$ curl --cacert ${LOCAL_CA_CERT} https://${CA_SERVER}:8140/puppet-ca/v1/certificate_revocation_list/ca\?environment\=ignored
 
 
 
 
 
 
 
Am I missing how to perform the same action using puppet cert? 
Or are you deprecating a face that provides needed functionality (for sites running Puppet Open Source with multiple Puppet servers) without providing a functional replacement? 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment

Jira (PUP-5868) yumrepo does not remove repo file

2017-03-02 Thread James Ralston (JIRA) 
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 James Ralston commented on  PUP-5868 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: yumrepo does not remove repo file  
 
 
 
 
 
 
 
 
 
 
Leaving the zero-length *.repo files is the correct thing to do, because removing them could create unintended side-effects. 
For example, say that /etc/yum.repos.d/foo.repo is contributed by the foo-release package. It defines a single repository, foo. You create a yumrepo resource to remove that repository via ensure => absent. This leaves a zero-length foo.repo file, which doesn't perturb yum in the slightest. 
But if the yumrepo resource were to remove that zero-length foo.repo file, then if the foo-release package is upgraded to a more recent package, the foo.repo file will be recreated, with the foo repository definition that you told Puppet to remove, and will persist until the next Puppet agent run. 
In contrast, if the yumrepo resource keeps the zero-length foo.repo file, then upgrading the foo-release package won't magically recreate the foo repository definition. (Worst case, you'll get a foo.repo.rpmnew file, which yum will ignore.) 
Of course, in this example, removing the foo-release package from the system would be a more optimal solution to get rid of the foo repository definition. But yumrepo can't assume that it's always going to be employed in the most optimal way. 
I suspect yumrepo's behavior of keeping zero-length *.repo files wasn't specifically intentional, but is a side-effect of the fact that the yumrepo resource uses the Ruby inifile gem to do all the reading/writing behind the scenes, and the inifile gem will cheerfully write out a configuration file that has nothing in it if you have removed all of the sections/settings. This is because it cannot assume that you want the configuration file to be removed entirely just because you aren't setting anything in it—in most cases, that assumption would be wrong, and would potentially break things (e.g., a daemon that will run just fine if its configuration file is empty, but will refuse to start if its configuration file is missing entirely). 
Regardless, whether intentional or not, yumrepo's behavior of leaving zero-length *.repo files is the correct behavior. 
If those files really task you, then script (via an exec resource that you trigger from your yumrepo resources, a cron job, et. al.) something like this to try to remove them safely: 
 
 
 
 
 
 
$ find /etc/yum.repos.d -name '*.repo' -type f -size 0 -print | 
 
 
 
 
  xargs -r rpm -qf | 
 
 
 
 
  grep 'not owned by any package' |

Jira (PUP-6865) puppet 4.8.0 breaks code that uses strftime()

2016-11-29 Thread James Ralston (JIRA) 
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 James Ralston commented on  PUP-6865 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: puppet 4.8.0 breaks code that uses strftime()  
 
 
 
 
 
 
 
 
 
 
Just to confirm: Thomas Hallgren's hunch was correct: I had updated puppet-agent on the master, but hadn't restarted the master. Restarting the master resolved the problems. 
The real issue here is that the puppetserver package is broken, because the server needs to be restarted if the puppet-agent package changes, but the puppetserver spec file lacks a %triggerpostun trigger on the puppet-agent package. (See PA-681 for more information and a suggested fix.) 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.

Jira (PUP-6943) control ordering of classic Hiera versus environment data searching

2016-11-29 Thread James Ralston (JIRA) 
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 James Ralston commented on  PUP-6943 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: control ordering of classic Hiera versus environment data searching  
 
 
 
 
 
 
 
 
 
 
It feels hackish, but I believe your suggestion would work. 
For example, right now, in our global (version 3) hiera.yaml file, we have: 
 
 
 
 
 
 
:yaml: 
 
 
 
 
  :datadir: /etc/puppetlabs/code/hiera 
 
 
 
 
:hierarchy: 
 
 
 
 
  - nodes/%{fqdn}/config 
 
 
 
 
  - ./%{hiera_area_0}/config 
 
 
 
 
  - ./%{hiera_area_1}/config 
 
 
 
 
  - ./%{hiera_area_2}/config 
 
 
 
 
  - ./%{hiera_area_3}/config 
 
 
 
 
  - ./%{hiera_area_4}/config 
 
 
 
 
  - ./%{hiera_area_5}/config

Jira (PUP-6943) control ordering of classic Hiera versus environment data searching

2016-11-28 Thread James Ralston (JIRA) 
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 James Ralston created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Puppet /  PUP-6943 
 
 
 
  control ordering of classic Hiera versus environment data searching  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  New Feature 
 
 
 

Affects Versions:
 

 PUP 4.8.1 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Created:
 

 2016/11/28 7:38 PM 
 
 
 

Priority:
 
  Normal 
 
 
 

Reporter:
 
 James Ralston 
 
 
 
 
 
 
 
 
 
 
From Puppet Lookup: Quick reference for Hiera users: 
 
Every time you request data through Puppet lookup, Puppet will search three tiers of data, in this order: 
 

Classic Hiera.
 

Environment data.
 

Module data.
 
 
… 
 

Environment data is the core of Puppet lookup. It’s where most of your data should live.
 

Classic Hiera is for global overrides, when you need to fix

Jira (PUP-6865) puppet 4.8.0 breaks code that uses strftime()

2016-11-02 Thread James Ralston (JIRA) 
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 James Ralston created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Puppet /  PUP-6865 
 
 
 
  puppet 4.8.0 breaks code that uses strftime()  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Affects Versions:
 

 PUP 4.8.0 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Components:
 

 AIO 
 
 
 

Created:
 

 2016/11/02 7:15 PM 
 
 
 

Priority:
 
  Normal 
 
 
 

Reporter:
 
 James Ralston 
 
 
 
 
 
 
 
 
 
 
After upgrading to puppet-agent-1.8.0, my catalogs fail to compile with the following error: 
 
 
 
 
 
 
Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Resource Statement, Evaluation Error: Error while evaluating a Function Call, uninitialized constant Puppet::Pops::Time at /etc/puppetlabs/code/modules/bind/manifests/master_zone.pp:27:12 at /etc/puppetlabs/code/modules/bind/manifests/init.pp:286 on node shieldbreaker.l33tskillz.local

Jira (PUP-5915) exec resources fail unless cwd is readable

2016-02-17 Thread James Ralston (JIRA) 
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 James Ralston commented on  PUP-5915 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: exec resources fail unless cwd is readable  
 
 
 
 
 
 
 
 
 
 
Also, unless I'm missing something, the fix is pretty simple. Here's a quick diff (ignoring whitespace changes, so that it's easier to read): 
 
 
 
 
 
 
--- /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/provider/exec.rb.ORIG   2016-02-02 14:10:21.0 -0500 
 
 
 
 
+++ /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/provider/exec.rb 2016-02-17 14:05:12.750781461 -0500 
 
 
 
 
@@ -12,7 +12,9 @@ 
 
 
 
 
 checkexe(command) 
 
 
 
 
  
 
 
 
 
 if dir = resource[:cwd] 
 
 
 
 
-  unless File.directory?(dir) 
 
 
 
 
+  if File.directory?(dir) 
 
 
 
 
+Dir.chdir(dir) 
 
 
 
 
+  else

Jira (PUP-5915) exec resources fail unless cwd is readable

2016-02-17 Thread James Ralston (JIRA) 
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 James Ralston created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Puppet /  PUP-5915 
 
 
 
  exec resources fail unless cwd is readable  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Affects Versions:
 

 PUP 4.3.2 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Created:
 

 2016/02/17 10:44 AM 
 
 
 

Priority:
 
  Normal 
 
 
 

Reporter:
 
 James Ralston 
 
 
 
 
 
 
 
 
 
 
The exec() resource always attempts to perform a chdir() to the current working directory (cwd). This is true regardless of the value of the cwd parameter. 
If the cwd isn't accessible by the user running Puppet, Puppet will fail to apply the exec() resource. This is true regardless of whether the command being executed actually requires the cwd to be readable. 
An example: 
 
 
 
 
 
 
$ cd /tmp 
 
 
 
 
$ mkdir test

Jira (PUP-5256) some puppet-agent package builds lack selinux.so Ruby module

2015-09-16 Thread James Ralston (JIRA) 
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 James Ralston created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Puppet /  PUP-5256 
 
 
 
  some puppet-agent package builds lack selinux.so Ruby module  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Affects Versions:
 

 puppet-agent 1.2.4 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Created:
 

 2015/09/16 9:29 AM 
 
 
 

Priority:
 
  Normal 
 
 
 

Reporter:
 
 James Ralston 
 
 
 
 
 
 
 
 
 
 
Some builds of puppet-agent available at http://yum.puppetlabs.com/ are missing the selinux.so module. This means that when the Puppet agent applies a catalog, it does not ensure correct SELinux file contexts on the files it updates. 
For example, the Fedora 21 packages lack the selinux.so module: 
 
 
 
 
 
 
$ rpm -q puppet-agent 
 
 
 
 
puppet-agent-1.2.4-1.fedoraf21.x86_64 
 
 
 
 
 

Jira (PUP-5259) puppet-agent SRPM packages missing from http://yum.puppetlabs.com

2015-09-16 Thread James Ralston (JIRA) 
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 James Ralston created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Puppet /  PUP-5259 
 
 
 
  puppet-agent SRPM packages missing from http://yum.puppetlabs.com  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Created:
 

 2015/09/16 1:25 PM 
 
 
 

Priority:
 
  Normal 
 
 
 

Reporter:
 
 James Ralston 
 
 
 
 
 
 
 
 
 
 
I am attempting to roll a patch to address CPR-222. Since the Puppet Agent Git repository is not public on Github (as far as I can tell), my only option for obtaining the puppet-agent.spec file for Red Hat is to pull it out of the latest available SRPM package. 
However, all puppet-agent SRPM packages are currently missing from http://yum.puppetlabs.com/, even though the binary packages are present. 
I heavily doubt this intentional. Could someone please go find and correct whatever is going wrong with the RPM publishing process that is dropping the puppet-agent SRPM packages on the floor? 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 

Jira (PUP-4785) External facts not working with cfacter

2015-06-25 Thread James Ralston (JIRA) 
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 James Ralston commented on  PUP-4785 
 
 
 
 
 
 
 
 
 
 


 
 
 
 
 
 
  Re: External facts not working with cfacter  
 
 
 
 
 
 
 
 
 
 
We're seeing the exact same issue. This might be related to the fact (no pun intended) that facter in Puppet 4.2.0 appears to have silently become cfacter, even though there's no mention of that in the release notes. Regardless, it simply ignores external facts; they aren't outputted, and they aren't sent to the master. 
THIS IS A SHOWSTOPPER BUG. Our site relies on external facts extensively to customize our host configuration. When Puppet 4.2.0 hit a dozen or so of our test boxes, it essentially rendered them unusable, and I'm going to have to spend the rest of the day peeling puppet-agent-1.2.0 off of them and repairing them. We can't be the only site where important functionality is determined by external facts. 
Seriously. This is a critical bug, and it needs to be fixed immediately. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 


 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   





-- 
You received this message because you are subscribed to the Google Groups Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.

Jira (PUP-4661) Puppet agent fights with RPM package over owner/group of certain directories

2015-05-27 Thread James Ralston (JIRA) 
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 James Ralston commented on  PUP-4661 
 
 
 
 
 
 
 
 
 
 


 
 
 
 
 
 
  Re: Puppet agent fights with RPM package over owner/group of certain directories  
 
 
 
 
 
 
 
 
 
 
And yes, this might seem like a trivial issue. 
But some people operate Linux hosts that must conform to the United States Government Defense Information Systems Agency (DISA) Security Technical Implementation Guides (STIGs). And the RHEL6 STIG contains this rule (among many others): 
 
Group ID (Vulid): V-38454 Group Title: SRG-OS-99 Rule ID: SV-50254r1_rule Severity: CAT III Rule Version (STIG-ID): RHEL-06-000516 Rule Title: The system package management tool must verify ownership on all files and directories associated with packages. 
Vulnerability Discussion: Ownership of system binaries and configuration files that is incorrect could allow an unauthorized user to gain privileges that they should not have. The ownership set by the vendor should be maintained. Any deviations from this baseline should be investigated. 
Check Content: The following command will list which files on the system have ownership different from what is expected by the RPM database: 
 
 
 
 
 
 
# rpm -Va | grep '^.U'
 
 
 
 
 
 
 
If there is output, this is a finding. 
Fix Text: The RPM package management system can restore ownership of package files and directories. The following command will update files and directories with ownership different from what is expected by the RPM database: 
 
 
 
 
 
 
# rpm -qf \[file or directory name\] 
 
 
 
 
# rpm --setugids \[package\]
 
 
 
 
 
 

 
Whether one agrees with this rule is irrelevant: if you are required to comply with the STIG, you will be regularly audited on your compliance. And the behavior of the Puppet

Jira (PUP-4661) Puppet agent fights with RPM package over owner/group of certain directories

2015-05-27 Thread James Ralston (JIRA) 
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 James Ralston created an issue 
 
 
 
 
 
 
 
 
 
 


 
 
 
 
 
 
 Puppet /  PUP-4661 
 
 
 
  Puppet agent fights with RPM package over owner/group of certain directories  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Affects Versions:
 

 PUP 4.1.0 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Created:
 

 2015/05/27 3:33 PM 
 
 
 

Environment:
 
 
Red Hat Enterprise Linux 
 
 
 

Priority:
 
  Normal 
 
 
 

Reporter:
 
 James Ralston 
 
 
 
 
 
 
 
 
 
 
For Red Hat Enterprise Linux systems, the puppet-agent RPM packages the following directories as user root, group root: 
 
 
 
 
 
 
$ rpm --verify puppet-agent 
 
 
 
 
S.5T.  c /etc/puppetlabs/puppet/puppet.conf

Jira (PUP-3377) Puppet fails to manage file resources containing invalid UTF-8

2015-04-07 Thread James Ralston (JIRA) 
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 James Ralston commented on  PUP-3377 
 
 
 
 
 
 
 
 
 
 


 
 
 
 
 
 
  Re: Puppet fails to manage file resources containing invalid UTF-8  
 
 
 
 
 
 
 
 
 
 
Guys, any progress on this? 
What makes this bug so horribly egregious is that Puppet will fail to apply a file resource if the file's current content isn't encoded in UTF-8, even though that content is going to be cheerfully obliterated by Puppet. 
Michal Ruzicka already made this point, but just to pound on it some more, let's say that the foo package drops the config file /etc/foo.conf, which contains non-ASCII characters and is encoded in ISO-8859-1. We want to override the package-provided /etc/foo.conf file with our own version, which contains only US-ASCII. So we create a file resource to manage it: 
 
 
 
 
 
 
  file { '/etc/foo.conf': 
 
 
 
 
ensure  = file, 
 
 
 
 
require = Package['foo'], 
 
 
 
 
owner   = root, 
 
 
 
 
group   = root, 
 
 
 
 
mode= '0644', 
 
 
 
 
source  = 'puppet:///modules/foo/foo.conf', 
 
 
 
 
  }