Issue #7705 has been updated by Jeff McCune.

• Status changed from Accepted to Merged - Pending Release
• Branch set to https://github.com/puppetlabs/puppet/pull/991

Merged into 3.x¶

As: https://github.com/puppetlabs/puppet/commit/4b6db1c

Merged into master¶

As: https://github.com/puppetlabs/puppet/commit/7720851

Bug #7705: Overhauling authorization system internals and interface

• Author: Nick Fagerlund
• Status: Merged - Pending Release
• Priority: Normal
• Assignee: eric sorenson
• Category: security
• Target version: 3.x
• Affected Puppet version:
• Keywords: telly_deprecation
• Branch: https://github.com/puppetlabs/puppet/pull/991

When I’ve gone to document auth.conf, fileserver.conf, and now autosign.conf, I’ve run into the same pattern: I interview and get a consensus for how everyone thinks it works, I test it, and it turns out to work a: very differently, and b: non-optimally. (For example, autosign.conf is effectively useless if you’re using certnames that don’t look exactly like FQDNs.) I’m guessing I’d find something similar if I had any intention of ever documenting namespaceauth.conf.

Anyway, I now believe that the authorization code, especially the constellation of stuff surrounding and using Puppet::Network::AuthStore, is badly overcomplicated and at least partly misconceived. Issues stemming from this include the total lack of globbing or patterning in auth.conf (#5777 and #5966), auth.conf being useless for certain valid certnames (#7014, #7589) and otherwise basically assuming certname = DNS name, file parsing errors (#5010), behavior that appears based on misconceptions about how the system works (#7057), and more.

This issue is a little nebulous, but I believe we need to figure out where it’s necessary to specifically allow nodes to do things, design a flexible and simple underlying representation of these rights, and unify the way we express those rights in config files.

(Obviously this can’t happen until Telly, at the earliest.)

You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account

--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To post to this group, send email to puppet-bugs <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.

Issue #7442 has been updated by Ken Dreyer.

• Status changed from Accepted to In Topic Branch Pending Review

Proposed for master: https://github.com/puppetlabs/puppet/pull/979

Bug #7442: User provided password age bug on Solaris with 2.7.0.rc2

• Author: Gary Law
• Status: In Topic Branch Pending Review
• Priority: Normal
• Assignee:
• Category:
• Target version:
• Affected Puppet version:
• Keywords:
• Branch:

Hi

Applying the following:–

user { 'puppet': ensure => 'present', comment => 'Puppet', gid => '52', home => '/var/lib/puppet', password => '!!', password_max_age => '-1', password_min_age => '-1', shell => '/bin/true', uid => '52', }

(known good on Darwin and CentOS) fails on Solaris:

$ sudo puppet apply /etc/puppet/manifests/site.pp glaw <at> sv01:~ $ sudo puppet apply /etc/puppet/manifests/site.pp prtconf: devinfo facility not available err: /Stage[main]/Puppet/User[puppet]/password_min_age: change from to -1 failed: Could not set password_min_age on user[puppet]: Execution of '/usr/bin/passwd -n -1 puppet' returned 6: passwd: Invalid argument to option -n Invalid argument to option notice: /Stage[main]/Puppet/User[puppet]/password_max_age: password_max_age changed '' to '-1' notice: Class[Puppet]: Dependency User[puppet] has failures: true warning: Class[Puppet]: Skipping because of failed dependencies notice: Stage[main]: Dependency User[puppet] has failures: true warning: Stage[main]: Skipping because of failed dependencies notice: Finished catalog run in 0.13 seconds glaw <at> sv01:~ $

I think that the correct command for passwd in this case would be /usr/bin/passwd -x -1 puppet

But in any event the provider doesn’t seem to report on it, so even setting this correctly by hand doesn’t cause puppet to apply the config without error:

$ sudo puppet resource user puppet prtconf: devinfo facility not available user { 'puppet': ensure => 'present', comment => 'Puppet', gid => '52', home => '/var/lib/puppet', password => '!!', shell => '/bin/true', uid => '52', }

Gary

You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account

--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To post to this group, send email to puppet-bugs <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.

Issue #4388 has been updated by Nick Fagerlund.

• Assignee set to Patrick Carlisle

So removal of the relevant code paths is merged into 3.x as of commit 4b6db1c6f3bb383d8309c5d98cb6236862caf085, but I notice the setting is still present in defaults.rb at about line 172.

Assigning to Patrick, since he did the recent deed and I think he currently knows the most about the status here.

Feature #4388: Remove the namespaceauth.conf file

• Author: Matt Robinson
• Status: Accepted
• Priority: High
• Assignee: Patrick Carlisle
• Category: plumbing
• Target version: 3.x
• Affected Puppet version:
• Keywords: rest api
• Branch:

To start puppet agent with —listen you need both the auth.conf and namespaceauth.conf. I don’t think the namespaceauth.conf is necessary anymore since it seems to do the same thing but less as the auth.conf (both badly named security files), so if that’s true get rid of it. Otherwise document it.

You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account

--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To post to this group, send email to puppet-bugs <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.

Issue #11870 has been updated by Josh Cooper.

• Target version set to 3.x

This is a new feature, targeted for 3.x

Feature #11870: Support other types of windows packages

• Author: Josh Cooper
• Status: Accepted
• Priority: Normal
• Assignee: Josh Cooper
• Category: windows
• Target version: 3.x
• Affected Puppet version:
• Keywords: windows msi installshield nullsoft wise innosetup
• Branch:

Puppet only support MSI packages on Windows that can be installed via msiexec We should support other types of packages created from:

• InstallShield
• Wise
• MS Hotfixes
• NullSoft
• InnoSetup

One issue is that many of these are self-extracting executables. Another issue is that we would need to introspect the package to determine what set of command line options are required to perform a silent install and supress reboots. See http://unattended.sourceforge.net/installers.php

You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account

--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To post to this group, send email to puppet-bugs <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.

Issue #15560 has been updated by Josh Cooper.

• Assignee set to Josh Cooper
• Target version set to 2.7.x

I ran into the same issue on a work related project. Since we don’t create the user home directory, any subsequent resource that tries to write stuff, e.g. ssh keys, will fail. And forcing the creation of a directory is less than desirable because Windows sets up the DACL differently for user home directories (inherited ACEs are blocked, there’s no creator owner ACE, and builtin-users are not granted access)

Bug #15560: Puppet on Windows doesn't automatically create user home directories when managehome=>true

• Author: Adam Roben
• Status: Accepted
• Priority: Normal
• Assignee: Josh Cooper
• Category: windows
• Target version: 2.7.x
• Affected Puppet version:
• Keywords: windows user managehome
• Branch:

The user type provider on Windows claims to support the managehome property. But setting managehome=>true doesn’t actually create the user’s home directory. In fact, it seems to have no effect at all. The user’s home directory path gets set in the user itself, but no directory is created on disk.

You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account

--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To post to this group, send email to puppet-bugs <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.

Issue #15693 has been updated by Josh Cooper.

• Category set to windows
• Assignee set to Josh Cooper
• Target version set to 2.7.x

Bug #15693: windows service provider restart method cannot be overridden

• Author: Josh Cooper
• Status: Accepted
• Priority: Normal
• Assignee: Josh Cooper
• Category: windows
• Target version: 2.7.x
• Affected Puppet version: 2.7.18
• Keywords: windows service restart
• Branch:

Most service providers allow the restart command to be overridden, however, the windows service provider does not. We should at least document in the provider that the restart method cannot be overridden similar to what is done for the launchd. We should also consider allowing users to override the restart command as is done in base.rb

You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account

--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To post to this group, send email to puppet-bugs <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.

Issue #6352 has been updated by Luke Kanies.

Daniel and I discussed this in person and I never updated the ticket.

From what I remember, he and I disagreed on what it means for Facter not to be bound to Puppet. I think Puppet and Facter sharing fact names is not a binding, but Daniel seems to think it is, and thus there should be an abstraction between Puppet and Facter that does something like pick different names for every fact, or at least support different names for facts.

As to the addition of the ‘load’ method, I agree with him that it’s a change, but it’s not a dramatic change, and you have to choose between some extension to the API or painful slowness.

As to the value of the pull request, well, it’s already there, so if we were asking whether it was worth writing that would be one question, but because the code is already there it’s a question of comparing the cost of merging and ongoing maintenance to not doing it, rather than the cost of developing it. (I suppose there’s also the by-now non-trivial rebasing cost.) I wrote this in my spare time because I wanted to, not because it was specifically tied to a company priority, and while I think the code has its short-comings I am happy to find other solutions and I think overall it’s 99% of the way to making Facter no longer a hard dependency and also providing the opportunity for a much thinner API between Puppet and Facter, which are both good.

Bug #6352: Puppet should only use Facter through a plugin interface

• Author: Luke Kanies
• Status: Needs More Information
• Priority: Normal
• Assignee: Daniel Pittman
• Category: plumbing
• Target version:
• Affected Puppet version:
• Keywords: facter dependencies
• Branch: luke/ticket/master/6352-facter_should_not_be_hard_coded

Significant parts of Puppet (especially the client-side) use Facter directly. E.g., all of the provider subsystem is directly calling out to Facter.

This causes a few problems:

• Facter is hard-coded as a dependency for Puppet
• Facter is required even if none of its data is used
• Facter tends to be called more often than is necessary, because the data could just be cached in memory

This should be fixed so that Puppet provides its own internal interfaces for interacting with Facter data, such that there’s only one part of the system that actually talks to Facter.

You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account

--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To post to this group, send email to puppet-bugs <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.

Issue #11260 has been updated by Ken Barber.

• Project changed from Puppet Forge to Puppet

Refactor #11260: tool should generate code using the actual module name as the directory instead of username-modulename

• Author: Garrett Honeycutt
• Status: Needs Decision
• Priority: Normal
• Assignee: Pieter van de Bruggen
• Category:
• Target version:
• Affected Puppet version:
• Keywords: UX
• Branch:

This is what currently happens

[root <at> puppet modules]# puppet-module generate ghoneycutt-apache ===================================================================== Generating module at /etc/puppetlabs/puppet/modules/ghoneycutt-apache --------------------------------------------------------------------- ghoneycutt-apache ghoneycutt-apache/Modulefile ghoneycutt-apache/tests ghoneycutt-apache/tests/init.pp ghoneycutt-apache/README ghoneycutt-apache/manifests ghoneycutt-apache/manifests/init.pp ghoneycutt-apache/metadata.json ghoneycutt-apache/spec ghoneycutt-apache/spec/spec.opts ghoneycutt-apache/spec/spec_helper.rb

This is what should happen.

[root <at> puppet modules]# puppet-module generate ghoneycutt-apache ===================================================================== Generating module at /etc/puppetlabs/puppet/modules/apache --------------------------------------------------------------------- apache apache/Modulefile apache/tests apache/tests/init.pp apache/README apache/manifests apache/manifests/init.pp apache/metadata.json apache/spec apache/spec/spec.opts apache/spec/spec_helper.rb

People actually use the tool by doing the following, which one should not have to do.

# puppet-module generate ghoneycutt-apache && mv ghoneycutt-apache apache

You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account

--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To post to this group, send email to puppet-bugs <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.

Issue #11260 has been updated by Ken Barber.

• Category set to module tool
• Target version set to 3.x

Refactor #11260: tool should generate code using the actual module name as the directory instead of username-modulename

• Author: Garrett Honeycutt
• Status: Needs Decision
• Priority: Normal
• Assignee: Pieter van de Bruggen
• Category: module tool
• Target version: 3.x
• Affected Puppet version:
• Keywords: UX
• Branch:

This is what currently happens

[root <at> puppet modules]# puppet-module generate ghoneycutt-apache ===================================================================== Generating module at /etc/puppetlabs/puppet/modules/ghoneycutt-apache --------------------------------------------------------------------- ghoneycutt-apache ghoneycutt-apache/Modulefile ghoneycutt-apache/tests ghoneycutt-apache/tests/init.pp ghoneycutt-apache/README ghoneycutt-apache/manifests ghoneycutt-apache/manifests/init.pp ghoneycutt-apache/metadata.json ghoneycutt-apache/spec ghoneycutt-apache/spec/spec.opts ghoneycutt-apache/spec/spec_helper.rb

This is what should happen.

[root <at> puppet modules]# puppet-module generate ghoneycutt-apache ===================================================================== Generating module at /etc/puppetlabs/puppet/modules/apache --------------------------------------------------------------------- apache apache/Modulefile apache/tests apache/tests/init.pp apache/README apache/manifests apache/manifests/init.pp apache/metadata.json apache/spec apache/spec/spec.opts apache/spec/spec_helper.rb

People actually use the tool by doing the following, which one should not have to do.

# puppet-module generate ghoneycutt-apache && mv ghoneycutt-apache apache

You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account

--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To post to this group, send email to puppet-bugs <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.

Issue #15778 has been reported by Andrea M.

Bug #15778: ssh_authorized_key is not idempotent

• Author: Andrea M
• Status: Unreviewed
• Priority: Normal
• Assignee:
• Category: ssh
• Target version:
• Affected Puppet version:
• Keywords:
• Branch:

When an ssh_authorized_key resource type is applied multiple times, the authorized_keys grows with keys being repeated. Since operations should be idempotent, this procedure needs to include logic that checks for the existence of the key before adding it.

You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account

--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To post to this group, send email to puppet-bugs <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.