[Puppet - Bug #7970] (Unreviewed) naginator not parsing blank parameters
Issue #7970 has been reported by Chris Phillips.
Bug #7970: naginator not parsing blank parameters
https://projects.puppetlabs.com/issues/7970
Author: Chris Phillips
Status: Unreviewed
Priority: Normal
Assignee:
Category:
Target version:
Affected Puppet version:
Keywords:
Branch:
Even though it wrote it, and is valid nagios syntax, The Naginator can not
parse this:
define host {
host_name gib-proxytest
parents
hostgroups gib
uselinux-server
address10.3.100.72
alias proxytest
}
Where the parents value is blank. It borks with:
err: Could not prefetch nagios_host provider 'naginator': Could not parse
configuration for nagios_host: line 62: syntax error at '
' in /etc/nagios/nagios_host.cfg
And then rebuilds the file from scratch every time.
--
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@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #7970] naginator not parsing blank parameters
Issue #7970 has been updated by Chris Phillips.
Category set to nagios
Affected Puppet version set to 2.6.7
Bug #7970: naginator not parsing blank parameters
https://projects.puppetlabs.com/issues/7970
Author: Chris Phillips
Status: Unreviewed
Priority: Normal
Assignee:
Category: nagios
Target version:
Affected Puppet version: 2.6.7
Keywords:
Branch:
Even though it wrote it, and is valid nagios syntax, The Naginator can not
parse this:
define host {
host_name gib-proxytest
parents
hostgroups gib
uselinux-server
address10.3.100.72
alias proxytest
}
Where the parents value is blank. It borks with:
err: Could not prefetch nagios_host provider 'naginator': Could not parse
configuration for nagios_host: line 62: syntax error at '
' in /etc/nagios/nagios_host.cfg
And then rebuilds the file from scratch every time.
--
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@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #7959] augeas type_check RAM usage
Issue #7959 has been updated by Markus Falb.
CentOS release 5.6 (Final)
hardwareisa = x86_64
facter-1.5.8-1.el5
puppet-0.25.5-1.el5
ruby-augeas-0.4.1-1.el5
augeas-libs-0.8.1-2.el5
(all from EPEL with CentOS's ruby-1.8.5-5.el5_4.8)
Bug #7959: augeas type_check RAM usage
https://projects.puppetlabs.com/issues/7959
Author: Markus Falb
Status: Unreviewed
Priority: Normal
Assignee:
Category: agent
Target version:
Affected Puppet version:
Keywords:
Branch:
augeas { ram fresser:
type_check = true,
context = /files/etc/sysctl.conf,
changes = set net.ipv4.ip_forward 1,
}
and puppet needs 1GB RAM ? This looks wrong to me. I only see this behaviour if
type_check is true.
--
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@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Facter - Bug #1346] Using 'ip addr' over ifconfig
Issue #1346 has been updated by Spencer Rinehart. Arch Linux recently deprecated net-tools in favor of iproute2 and yp-tools. [1] I give a big +1 for ip addr. [1] http://www.archlinux.org/news/deprecation-of-net-tools/ Bug #1346: Using 'ip addr' over ifconfig https://projects.puppetlabs.com/issues/1346 Author: Ian Christian Status: Accepted Priority: Normal Assignee: martin krafft Category: library Target version: 2.0.0 Patch: None Keywords: Branch: Affected Facter version: pre # facter /usr/lib/ruby/site_ruby/1.8/facter/ipmess.rb:85: command not found: /sbin/ifconfig -a /usr/bin/facter:54: command not found: /sbin/ifconfig -a /usr/bin/facter:54: command not found: dnsdomainname /usr/bin/facter:54: command not found: domainname /usr/bin/facter:54: command not found: /sbin/ifconfig architecture = i386 domain = internal.HIDDEN facterversion = 1.3.8 fqdn = ruby-test.internal.HIDDEN hardwareisa = unknown hardwaremodel = i686 hostname = ruby-test id = root ipaddress = 10.200.201.73 /pre It would be nice if when ifconfig can't be found, it falls back to using 'ip addr' - also, notice that domainname and dnsdomainname are not present on this system - however facter does appear to get them correct regardless. -- 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@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet Documentation - Feature #7972] (Unreviewed) Feature request: provide examples of entire classes including entire classes in the documentation
Issue #7972 has been reported by Justin Honold. Feature #7972: Feature request: provide examples of entire classes including entire classes in the documentation https://projects.puppetlabs.com/issues/7972 Author: Justin Honold Status: Unreviewed Priority: Normal Assignee: Category: Target version: Keywords: Branch: Affected URL: There are many examples of resource-to-class requirements, but I haven't found any which show class-to-class requirements. I don't think it is necessarily clear that this functionality exists, so I would like to see a line or two with, you can even have classes require classes, and here's how: [example]. -- 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@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet Documentation - Feature #7972] Feature request: provide examples of entire classes including entire classes in the documentation
Issue #7972 has been updated by Justin Honold. Urg, subject should say, requiring, not including :-) Please edit. Feature #7972: Feature request: provide examples of entire classes including entire classes in the documentation https://projects.puppetlabs.com/issues/7972 Author: Justin Honold Status: Unreviewed Priority: Normal Assignee: Category: Target version: Keywords: Branch: Affected URL: There are many examples of resource-to-class requirements, but I haven't found any which show class-to-class requirements. I don't think it is necessarily clear that this functionality exists, so I would like to see a line or two with, you can even have classes require classes, and here's how: [example]. -- 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@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet Dashboard - Bug #7973] (Accepted) Refactor colors for changed/unchanged
Issue #7973 has been reported by Randall Hansen. Bug #7973: Refactor colors for changed/unchanged https://projects.puppetlabs.com/issues/7973 Author: Randall Hansen Status: Accepted Priority: Normal Assignee: Randall Hansen Category: Target version: 1.2 Keywords: Branch: Affected URL: Affected Dashboard version: Blue for unchanged and green for changed is suboptimal. -- 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@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #7974] (Unreviewed) Stages should reload facts between runs
Issue #7974 has been reported by Jamison Fryman.
Feature #7974: Stages should reload facts between runs
https://projects.puppetlabs.com/issues/7974
Author: Jamison Fryman
Status: Unreviewed
Priority: Normal
Assignee:
Category:
Target version:
Affected Puppet version:
Keywords:
Branch:
During a stage run, I might have some data in the form of a fact that will not
be populated until future runs of puppet. Consider the below example. In this
case, the logic in `class bar` will not be evaluated during the initial run of
puppet until `/etc/ROLE` has been defined and populated on the machine.
Custom Fact:
precode class='ruby'
Facter.add(role) do
setcode do
%x{/etc/ROLE -i}.chomp
end
end
/code/pre
Puppet Code:
precode class='puppet'
class stage {
stage { ['pre', 'post']: }
Stage['pre'] - Stage['main'] - Stage['post']
}
class foo {
file { '/etc/ROLE':
ensure = file,
content = 'FS',
}
}
class bar {
if $role == 'FS' { (do something ) }
}
/code/pre
Node Definition
precode
node 'test' {
class { 'foo':
stage = 'pre',
}
include bar
}
/code/pre
--
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@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #2198] Install multiple package within a single call to the package manager
Issue #2198 has been updated by Nigel Kersten. erk. This is completely my fault. I was incorrectly filtering and failed to chase it up. Feature #2198: Install multiple package within a single call to the package manager https://projects.puppetlabs.com/issues/2198 Author: Stéphan Gorget Status: In Topic Branch Pending Merge Priority: Normal Assignee: Stéphan Gorget Category: transactions Target version: 2.7.x Affected Puppet version: 0.25.0 Keywords: communitypatch Branch: http://github.com/phantez/puppet/commit/51ff88c950c172e6060ae63c1c71968e7898b462 During the configuration applying process the package manager is called for each package installation. It is possible to reduce the number of calls to the package manager by gathering package installation and delayed some package installation. Naturally, this modification should not break the dependency graph. -- 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@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #7974] Stages should reload facts between runs
Issue #7974 has been updated by Daniel Pittman.
Feature #7974: Stages should reload facts between runs
During a stage run, I might have some data in the form of a fact that will
not be populated until future runs of puppet. Consider the below example. In
this case, the logic in class bar will not be evaluated during the initial
run of puppet until /etc/ROLE has been defined and populated on the machine.
You are actually asking for a similar feature, stages should be
entirely separate catalog runs in Puppet. :)
The catalog is static; stages are just a shorthand for ordering that
you could otherwise express entirely by hand, by putting the right
dependencies in place between the contained items in the relevant
classes. (Which, indeed, is more or less what people did before
stages came about. :)
Reloading facts between runs would actually be this:
1. Puppet agent uploads facts, get the first stage catalog
2. Puppet agent applies the first stage catalog
3. Puppet agent uploads facts, gets the second stage catalog
4. ...repeat until you are done.
Part of this is because we interpolate the facts on the master, during
compilation, before the catalog ever gets to the agent.
I don't believe we want to support this multi-catalog model, and I
don't believe there is a mechanism for otherwise getting this right
without fundamental architectural shifts – that, IMO, will render this
request obsolete by doing the same thing a different way. :)
Feature #7974: Stages should reload facts between runs
https://projects.puppetlabs.com/issues/7974
Author: Jamison Fryman
Status: Unreviewed
Priority: Normal
Assignee:
Category:
Target version:
Affected Puppet version:
Keywords:
Branch:
During a stage run, I might have some data in the form of a fact that will not
be populated until future runs of puppet. Consider the below example. In this
case, the logic in `class bar` will not be evaluated during the initial run of
puppet until `/etc/ROLE` has been defined and populated on the machine.
Custom Fact:
precode class='ruby'
Facter.add(role) do
setcode do
%x{/etc/ROLE -i}.chomp
end
end
/code/pre
Puppet Code:
precode class='puppet'
class stage {
stage { ['pre', 'post']: }
Stage['pre'] - Stage['main'] - Stage['post']
}
class foo {
file { '/etc/ROLE':
ensure = file,
content = 'FS',
}
}
class bar {
if $role == 'FS' { (do something ) }
}
/code/pre
Node Definition
precode
node 'test' {
class { 'foo':
stage = 'pre',
}
include bar
}
/code/pre
--
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@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #7974] (Rejected) Stages should reload facts between runs
Issue #7974 has been updated by Daniel Pittman.
Status changed from Unreviewed to Rejected
Feature #7974: Stages should reload facts between runs
https://projects.puppetlabs.com/issues/7974
Author: Jamison Fryman
Status: Rejected
Priority: Normal
Assignee:
Category:
Target version:
Affected Puppet version:
Keywords:
Branch:
During a stage run, I might have some data in the form of a fact that will not
be populated until future runs of puppet. Consider the below example. In this
case, the logic in `class bar` will not be evaluated during the initial run of
puppet until `/etc/ROLE` has been defined and populated on the machine.
Custom Fact:
precode class='ruby'
Facter.add(role) do
setcode do
%x{/etc/ROLE -i}.chomp
end
end
/code/pre
Puppet Code:
precode class='puppet'
class stage {
stage { ['pre', 'post']: }
Stage['pre'] - Stage['main'] - Stage['post']
}
class foo {
file { '/etc/ROLE':
ensure = file,
content = 'FS',
}
}
class bar {
if $role == 'FS' { (do something ) }
}
/code/pre
Node Definition
precode
node 'test' {
class { 'foo':
stage = 'pre',
}
include bar
}
/code/pre
--
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@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet Dashboard - Bug #7973] (In Topic Branch Pending Merge) Refactor colors for changed/unchanged
Issue #7973 has been updated by Randall Hansen. Status changed from Accepted to In Topic Branch Pending Merge Bug #7973: Refactor colors for changed/unchanged https://projects.puppetlabs.com/issues/7973 Author: Randall Hansen Status: In Topic Branch Pending Merge Priority: Normal Assignee: Randall Hansen Category: Target version: 1.2 Keywords: Branch: Affected URL: Affected Dashboard version: Blue for unchanged and green for changed is suboptimal. -- 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@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet Dashboard - Bug #7976] (Accepted) Node filter links in sidebar broken when active
Issue #7976 has been reported by Randall Hansen. Bug #7976: Node filter links in sidebar broken when active https://projects.puppetlabs.com/issues/7976 Author: Randall Hansen Status: Accepted Priority: Normal Assignee: Randall Hansen Category: Target version: 1.2 Keywords: Branch: Affected URL: Affected Dashboard version: This is a JavaScript problem. -- 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@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet Enterprise - Feature #7455] (Rejected) optionally install VCS components as part of the installer
Issue #7455 has been updated by Nigel Kersten. Status changed from Needs Decision to Rejected This is out of scope of the installer. If we're going to start adding tools that aren't required for actual installation, we'll be delivering them as modules. Feature #7455: optionally install VCS components as part of the installer https://projects.puppetlabs.com/issues/7455 Author: Garrett Honeycutt Status: Rejected Priority: Normal Assignee: Nigel Kersten Category: Target version: Keywords: Branch: Affected PE version: Since we are bootstrapping Puppet Enterprise with the installer script, it would be nice to optionally install specific VCS tools so that you can bootstrap your modules and manifests from your VCS. pre To install version control system tools enter a name from the list or leave empty to skip. [git|svn|bzr|hg]: /pre The list would only display what is normally available upon a given system. For instance, RHEL 6 appears to ship with git/subversion/mercurial but not Bazaar (bzr). -- 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@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #7243] (Accepted) Additional data in Puppet CSRs (certdnsnames, and custom data)
Issue #7243 has been updated by Nigel Kersten. Status changed from Needs Decision to Accepted Assignee deleted (Nigel Kersten) Feature #7243: Additional data in Puppet CSRs (certdnsnames, and custom data) https://projects.puppetlabs.com/issues/7243 Author: Matt Wise Status: Accepted Priority: Normal Assignee: Category: Target version: 2.7.x Affected Puppet version: Keywords: Branch: Puppet Clients currently do not support filling in 'certdnsnames' in their CSR. That is only done on the signing-server side of things. This should be updated so that either the client, or server can set the certdnsnames (or both). In addition to this, the Puppet CSR generation code should allow for the addition of arbitrary data in the form of keypairs (foo=xyz) that is embedded into the CSR. That data should then be accessible in some way to the Puppet master process itself during catalog compilation. This allows for companies to build in their own security models around the SSL certs. -- 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@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet Dashboard - Bug #7976] Node filter links in sidebar broken when active
Issue #7976 has been updated by Randall Hansen. And also a problem of poor markup to represent the graph. Bug #7976: Node filter links in sidebar broken when active https://projects.puppetlabs.com/issues/7976 Author: Randall Hansen Status: Accepted Priority: Normal Assignee: Randall Hansen Category: Target version: 1.2 Keywords: Branch: Affected URL: Affected Dashboard version: This is a JavaScript problem. -- 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@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet Documentation - Feature #7972] Feature request: provide examples of entire classes requiring entire classes in the documentation
Issue #7972 has been updated by Nick Lewis. Subject changed from Feature request: provide examples of entire classes including entire classes in the documentation to Feature request: provide examples of entire classes requiring entire classes in the documentation Feature #7972: Feature request: provide examples of entire classes requiring entire classes in the documentation https://projects.puppetlabs.com/issues/7972 Author: Justin Honold Status: Unreviewed Priority: Normal Assignee: Category: Target version: Keywords: Branch: Affected URL: There are many examples of resource-to-class requirements, but I haven't found any which show class-to-class requirements. I don't think it is necessarily clear that this functionality exists, so I would like to see a line or two with, you can even have classes require classes, and here's how: [example]. -- 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@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #7241] Group membership should be a type of its own.
Issue #7241 has been updated by Stefan Schulte.
Nigel Kersten wrote:
I don't think we need to be hung up on namevars at all. Sure, we could use
something multi-var like that, but I also really like:
pre
groupmembership { 'ensure_testuser_in_testgroup':
ensure = present,
member = testuser,
group = testgroup,
}
/pre
ok, but if testuser is not in testgroup, what exactly is out of sync here? Is
member out of sync (it is from the group's point of view) or is group out of
sync (it is from the user's point of view)?
I just fear that the number of resources I have to specify will explode when I
want to specify a user which is in a lot of groups. I also prefer one message
`User[foo]/groups changed group1,group2,group3 to group4,group5,group6)` over
six messages about absent/present groupmembership resources but that is of
course just my opinion.
You may also have problems when another resource requires your user because
this resource cannot be sure that the user is completly set (or you have to
manually require all the groupmembership resources as well)
As a sidenode: How do you ensure that you dont specify two conflicting
memberships (if you prefer arbitrary titles)?
Feature #7241: Group membership should be a type of its own.
https://projects.puppetlabs.com/issues/7241
Author: Nigel Kersten
Status: Accepted
Priority: Normal
Assignee:
Category:
Target version: Telly
Affected Puppet version:
Keywords:
Branch:
It's very difficult right now to express declarative statements like:
* Ensure this user is not in this group, leave it alone otherwise
* Ensure this user is in this group without defining the user, leave it alone
otherwise.
I propose that we move group membership to a type of its own. That would also
allow us to abstract away the differences between different platforms, some of
which consider membership to be an attribute of the group, some of which
consider it to be an attribute of the user.
It would allow us to remove all the authoritative settings for user/group
membership, as they would move to this type instead.
--
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@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #7272] Puppet should allow for *automatic resigning* of SSL certs
Issue #7272 has been updated by Nigel Kersten. Category set to SSL Target version set to Telly Feature #7272: Puppet should allow for *automatic resigning* of SSL certs https://projects.puppetlabs.com/issues/7272 Author: Matt Wise Status: Accepted Priority: Normal Assignee: Category: SSL Target version: Telly Affected Puppet version: Keywords: Branch: Since Puppet acts as an SSL 'factory' anyways, it should be a bit more full featured and offer a resigning capability to existing validated clients. In our environment we've cobbled together a system where the clients check regularly that their SSL cert is still valid. If its going to be not-valid within X days, they start checking in with a CGI script on the puppet ca master. When they connect, they supply their original CSR (found in /var/lib/puppet) and the CGI script handles some validation of that CSR, and then signs a new certificate with that data. This is a kludge that should be built into Puppet. I propose the following workflow.. 1) Puppet Agent runs... before even connecting to the server, it determines whether or not its SSL certificate is going to expire within XX days. If it is ... 2) Puppet agent supplies original CSR (thats still in /var/lib/puppet) to puppet ca server, and requests a resigning. If resigning is enabled on the puppet server ... 3) Puppet server resigns the cert, deletes the old cert and immediately invalidates its serial #. Server then passes the new Cert back to the client... 4) Client re-starts essentially with the new cert and begins its real puppet run. This functionality allows for Puppet certs to be extremely short-lived... you could actually let certs expire after as little as a day or two if you wanted, and Puppet would handle all of the resigning. Any client that 'doesnt check in' would simply have its cert expire, and would have to be fixed manually. (ps, i think its critical that the client resupplies the CSR to the server.. rather than the ca server looking for the original CSR. this allows for multiple puppet ca servers, which is pretty critical in large environments) (pps, the only reason we havnt finished our migration to a multi-ca-master environment is the CRL... ideally if i could tell each of my puppet masters about the others, they could all keep their CRLs in-sync with eachother) -- 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@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #7244] Autosign should allow for an external approver
Issue #7244 has been updated by Nigel Kersten. Assignee changed from Nigel Kersten to Matt Wise Matt, does it look like #7243 will solve your problem? (Assigned to one of the two Matt Wise accounts) Feature #7244: Autosign should allow for an external approver https://projects.puppetlabs.com/issues/7244 Author: Matt Wise Status: Needs More Information Priority: Normal Assignee: Matt Wise Category: SSL Target version: 2.7.x Affected Puppet version: Keywords: Branch: Puppet should allow for the autosign code to point to an external script, instead of the autosign.conf file itself for approval in signing a end-clients cert. This method should allow the client to supply a unique bit of auth data that is passed to the exec script on the master, and validated. If return 0, sign the code. If not, do not sign. In this way, I can pass an arbitrary token (say its 12345) through the puppet agent to the puppet ca master. The puppet ca master can then run myauthscript.sh -arg 12345. if that script returns 0, puppet c an then sign the certificate. If not, puppet fails to sign the certificate. -- 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@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet Dashboard - Bug #7976] (In Topic Branch Pending Merge) Node filter links in sidebar broken when active
Issue #7976 has been updated by Randall Hansen. Status changed from Accepted to In Topic Branch Pending Merge Bug #7976: Node filter links in sidebar broken when active https://projects.puppetlabs.com/issues/7976 Author: Randall Hansen Status: In Topic Branch Pending Merge Priority: Normal Assignee: Randall Hansen Category: Target version: 1.2 Keywords: Branch: Affected URL: Affected Dashboard version: This is a JavaScript problem. -- 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@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #7244] Autosign should allow for an external approver
Issue #7244 has been updated by Matt Wise. I see these as two very different requests... Bug #7243 will let me implement security around what classes a host can request once it has a cert. This request allows me to create my own 'authorization' system for autosigning. They're both very important, but this one is actually more important for me right now. Feature #7244: Autosign should allow for an external approver https://projects.puppetlabs.com/issues/7244 Author: Matt Wise Status: Needs More Information Priority: Normal Assignee: Matt Wise Category: SSL Target version: 2.7.x Affected Puppet version: Keywords: Branch: Puppet should allow for the autosign code to point to an external script, instead of the autosign.conf file itself for approval in signing a end-clients cert. This method should allow the client to supply a unique bit of auth data that is passed to the exec script on the master, and validated. If return 0, sign the code. If not, do not sign. In this way, I can pass an arbitrary token (say its 12345) through the puppet agent to the puppet ca master. The puppet ca master can then run myauthscript.sh -arg 12345. if that script returns 0, puppet c an then sign the certificate. If not, puppet fails to sign the certificate. -- 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@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet Dashboard - Refactor #5947] (Merged - Pending Release) Rename the Destroy button to Delete
Issue #5947 has been updated by Josh Cooper. Status changed from Accepted to Merged - Pending Release Merged into puppet-dashboard master as commit:af11c91222a5b89361d5cd86dff3345b90300563 Refactor #5947: Rename the Destroy button to Delete https://projects.puppetlabs.com/issues/5947 Author: James Turnbull Status: Merged - Pending Release Priority: Normal Assignee: Nigel Kersten Category: Target version: Keywords: Branch: Affected URL: Affected Dashboard version: The Destroy button no only doesn't destroy things but it's faintly disconcerting to a lot of people. Can we please rename it to Delete. -- 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@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet Dashboard - Bug #7981] (Needs Decision) Make delete confirmation messages consistent
Issue #7981 has been reported by Josh Cooper. Bug #7981: Make delete confirmation messages consistent https://projects.puppetlabs.com/issues/7981 Author: Josh Cooper Status: Needs Decision Priority: Normal Assignee: Randall Hansen Category: Target version: Keywords: Branch: Affected URL: Affected Dashboard version: The confirmation dialog says, are you sure you wish to delete this node? when deleting nodes, but it just says are you sure? when deleting reports, classes, and groups. The messages should be made consistent. -- 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@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet Dashboard - Bug #7973] (Merged - Pending Release) Refactor colors for changed/unchanged
Issue #7973 has been updated by Randall Hansen. Status changed from In Topic Branch Pending Merge to Merged - Pending Release Merged into master at commit:9c468f9b86e5d093f5026b0bcc5d7655f2c37547 Bug #7973: Refactor colors for changed/unchanged https://projects.puppetlabs.com/issues/7973 Author: Randall Hansen Status: Merged - Pending Release Priority: Normal Assignee: Randall Hansen Category: Target version: 1.2 Keywords: Branch: Affected URL: Affected Dashboard version: Blue for unchanged and green for changed is suboptimal. -- 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@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet Dashboard - Bug #7976] (Merged - Pending Release) Node filter links in sidebar broken when active
Issue #7976 has been updated by Randall Hansen. Status changed from In Topic Branch Pending Merge to Merged - Pending Release Merged into master at commit:b24b0a4e78d42e5d8d0d6a741a35259f86d8506e Bug #7976: Node filter links in sidebar broken when active https://projects.puppetlabs.com/issues/7976 Author: Randall Hansen Status: Merged - Pending Release Priority: Normal Assignee: Randall Hansen Category: Target version: 1.2 Keywords: Branch: Affected URL: Affected Dashboard version: This is a JavaScript problem. -- 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@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet Dashboard - Feature #7938] (Merged - Pending Release) Accept 4K reports in one hour to dashboard
Issue #7938 has been updated by Daniel Pittman. Status changed from Accepted to Merged - Pending Release https://github.com/puppetlabs/puppet-dashboard/commit/b99e4d6ed5f575655d6345bf4dffb9a20f8148fd merges this into master. Feature #7938: Accept 4K reports in one hour to dashboard https://projects.puppetlabs.com/issues/7938 Author: Daniel Pittman Status: Merged - Pending Release Priority: Normal Assignee: Daniel Pittman Category: Target version: Keywords: Branch: https://github.com/daniel-pittman/puppet-dashboard/commits/feature/master/7938-background-tasks-for-dashboard Affected URL: Affected Dashboard version: To meet the performance goals we have set, we need to be able to deliver either 2K or 4K reports to dashboard in a single hour. That is potentially more than one report per second, although we can reasonably spend up to 16 cores on this problem. (Less would be nice.) Given the performance of ActiveRecord, it doesn't seem achievable that we can hit that during the current round of work. We only need the reports *delivered* during that window, however. So, if we accept at line-rate, buffer behind, and import the reports into the server more slowly we should be able to get the performance required. The most promising model for this is to build a report spooler that sits beside the regular report import tool. This can accept the report data, then spool it for later processing in a buffer that can accept the data. We then import that data as fast as possible – we have ~ 2 hours for 2K nodes – while still being able to deliver the accept performance required. -- 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@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
