[Facter - Bug #2060] Inconsistent output in operatingsystemrelease between RedHat and CentOS
Issue #2060 has been updated by Stijn Hoop.
This has regressed:
[stijn@pclinvir020] ~ cat /etc/redhat-release
CentOS release 6.3 (Final)
[stijn@pclinvir020] ~ facter operatingsystemrelease
6.3
[stijn@pclinvir020] ~ rpm -q facter
facter-1.6.14-1.el6.x86_64
Bug #2060: Inconsistent output in operatingsystemrelease between RedHat and
CentOS
https://projects.puppetlabs.com/issues/2060#change-80100
Author: Oliver Hookins
Status: Closed
Priority: Normal
Assignee:
Category: library
Target version: 1.5.9
Keywords:
Branch:
Affected Facter version:
pre
[root@centos ~]# cat /etc/redhat-release
CentOS release 5.2 (Final)
[root@centos ~]# facter operatingsystemrelease
5.2
[root@rhel ~]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.3 (Tikanga)
[root@rhel ~]# facter operatingsystemrelease
5
/pre
It doesn't make sense that one reports the point release version and the other
doesn't, especially given they are more or less equivalent platforms. If I had
my way I would prefer without the point release.
You could patch it like this:
pre
--- operatingsystemrelease.rb.orig 2009-03-09 15:16:22.0 +1100
+++ operatingsystemrelease.rb 2009-03-09 15:16:46.0 +1100
@@ -55,7 +55,7 @@
setcode do
centos_release = Facter::Util::Resolution.exec(sed -r -e 's/CentOS
release //' -e 's/ \((Branch|Final)\)//' /etc/redhat-release)
if centos_release =~ /5/
-release = Facter::Util::Resolution.exec('rpm -q --qf
\'%{VERSION}.%{RELEASE}\' centos-release | cut -d. -f1,2')
+release = Facter::Util::Resolution.exec('rpm -q --qf
\'%{VERSION}.%{RELEASE}\' centos-release | cut -d. -f1')
else
release = centos_release
end
/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.
[Facter - Bug #2060] (Re-opened) Inconsistent output in operatingsystemrelease between RedHat and CentOS
Issue #2060 has been updated by Stijn Hoop.
Status changed from Closed to Re-opened
Target version changed from 1.5.9 to 1.6.x
Bug #2060: Inconsistent output in operatingsystemrelease between RedHat and
CentOS
https://projects.puppetlabs.com/issues/2060#change-80101
Author: Oliver Hookins
Status: Re-opened
Priority: Normal
Assignee:
Category: library
Target version: 1.6.x
Keywords:
Branch:
Affected Facter version:
pre
[root@centos ~]# cat /etc/redhat-release
CentOS release 5.2 (Final)
[root@centos ~]# facter operatingsystemrelease
5.2
[root@rhel ~]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.3 (Tikanga)
[root@rhel ~]# facter operatingsystemrelease
5
/pre
It doesn't make sense that one reports the point release version and the other
doesn't, especially given they are more or less equivalent platforms. If I had
my way I would prefer without the point release.
You could patch it like this:
pre
--- operatingsystemrelease.rb.orig 2009-03-09 15:16:22.0 +1100
+++ operatingsystemrelease.rb 2009-03-09 15:16:46.0 +1100
@@ -55,7 +55,7 @@
setcode do
centos_release = Facter::Util::Resolution.exec(sed -r -e 's/CentOS
release //' -e 's/ \((Branch|Final)\)//' /etc/redhat-release)
if centos_release =~ /5/
-release = Facter::Util::Resolution.exec('rpm -q --qf
\'%{VERSION}.%{RELEASE}\' centos-release | cut -d. -f1,2')
+release = Facter::Util::Resolution.exec('rpm -q --qf
\'%{VERSION}.%{RELEASE}\' centos-release | cut -d. -f1')
else
release = centos_release
end
/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 #11786] `puppet doc` is not compatible with newer RDoc - thus with Ruby 1.9
Issue #11786 has been updated by Daniele Sluijters. Actually, I just applied the gist and now I'm stuck with: ``` RDoc::RDocError is deprecated Could not generate documentation: uninitialized constant RDoc::RDoc::Generator ``` This is with rdoc 3.12 and Puppet 2.7. This should also be backported to 2.7 since 2.7 supports Ruby 1.9. Feature #11786: `puppet doc` is not compatible with newer RDoc - thus with Ruby 1.9 https://projects.puppetlabs.com/issues/11786#change-80104 Author: Justin Stoller Status: Accepted Priority: Normal Assignee: Daniel Pittman Category: ruby19 Target version: 3.x Affected Puppet version: development Keywords: ruby1.9.3 Branch: https://github.com/puppetlabs/puppet/pull/377 The `puppet doc` code depends heavily on RDoc to do the documentation generation. Unfortunately, while the Ruby 1.8 series exclusively used RDoc 1.*, the Ruby 1.9 uses 3.* and 4.* versions. These are solidly incompatible with the way we used and integrated with RDoc in the `puppet doc` application. We need to support the `puppet doc` features in a way that also works with newer Ruby. -- 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 #18370] (Unreviewed) err: Could not retrieve catalog from remote server: Error 400 on SERVER: header too long
Issue #18370 has been reported by Dean Gao. Bug #18370: err: Could not retrieve catalog from remote server: Error 400 on SERVER: header too long https://projects.puppetlabs.com/issues/18370 Author: Dean Gao Status: Unreviewed Priority: Normal Assignee: Category: Target version: Affected Puppet version: Keywords: header too long Branch: The issue happened when i was trying to connect to the puppet server by command 'puppetd --test --server server.puppet.com'. err: Could not retrieve catalog from remote server: Error 400 on SERVER: header too long warning: Not using cache on failed catalog err: Cloud not retrieve catalog: skipping run -- 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 #16856] puppet should support data in modules
Issue #16856 has been updated by R.I. Pienaar. I've pushed to my branch a commit that seems to fix it for me, thanks for reporting Feature #16856: puppet should support data in modules https://projects.puppetlabs.com/issues/16856#change-80105 Author: R.I. Pienaar Status: Needs More Information Priority: Normal Assignee: R.I. Pienaar Category: Target version: Affected Puppet version: Keywords: Branch: https://github.com/puppetlabs/puppet/pull/1217 At present there is a way to store data in modules using the puppet backend for hiera but it is optional and kind of broken. The site hierarchy impacts how the puppet backend behaves which makes it impossible for module authors to supply data in their modules they can rely on I propose a new hiera backend that loads a hierarchy of data from the 'data' directory in the module, this module must always be present in a puppet install. This ability is key to the ability to create configurable forge modules that do not have hard coded values thanks to the puppet 3 hiera integration reference the users list thread https://groups.google.com/d/topic/puppet-users/pvqzeyHkrY4/discussion -- 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 #7793] setting the $noop metaparameter as class parameter does not work
Issue #7793 has been updated by Stephen Johnson.
The issues is still present
class test ($string = hello)
{
file {'/tmp/test':
ensure = file,
content = $string,
}
file {'/tmp/test2':
ensure = file,
content = $string,
}
}
class{'test': noop = true}
I expected all the resource in the class to be noop but it is actually still
applying the resource.
Bug #7793: setting the $noop metaparameter as class parameter does not work
https://projects.puppetlabs.com/issues/7793#change-80110
Author: Michael Grüner
Status: Accepted
Priority: Normal
Assignee:
Category: metaparameters
Target version:
Affected Puppet version: 2.6.8
Keywords: noop
Branch:
As explained in https://projects.puppetlabs.com/issues/6526 I am trying to
set the $noop metaparameter as a class parameter to set a class and all
its resources to $noop. This does not seem to work:
pre
mgruener@lt-mgr:~$ cat test.pp
class foo($noop=true) {
file{ /tmp/test1:
content = I should not work in noop mode!,
}
}
node default {
include foo
}
mgruener@lt-mgr:~$ envpuppet puppet --version
2.6.8
mgruener@lt-mgr:~$ envpuppet puppet apply test.pp
warning: noop is a metaparam; this value will inherit to all contained resources
notice: /Stage[main]/Foo/File[/tmp/test1]/ensure: defined content as
'{md5}73878c2b0e1386f3127bb77f5a1c96e3'
notice: Finished catalog run in 0.01 seconds
mgruener@lt-mgr:~$ ls -la /tmp/test1
-rw-r--r-- 1 mgruener mgruener 31 2011-06-06 11:56 /tmp/test1
mgruener@lt-mgr:~$
/pre
I would expect it to work as if the noop parameter was set
directly for the resource.
--
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 #7793] setting the $noop metaparameter as class parameter does not work
Issue #7793 has been updated by Stephen Johnson.
Affected Puppet version changed from 2.6.8 to 3.0.2
Bug #7793: setting the $noop metaparameter as class parameter does not work
https://projects.puppetlabs.com/issues/7793#change-80111
Author: Michael Grüner
Status: Accepted
Priority: Normal
Assignee:
Category: metaparameters
Target version:
Affected Puppet version: 3.0.2
Keywords: noop
Branch:
As explained in https://projects.puppetlabs.com/issues/6526 I am trying to
set the $noop metaparameter as a class parameter to set a class and all
its resources to $noop. This does not seem to work:
pre
mgruener@lt-mgr:~$ cat test.pp
class foo($noop=true) {
file{ /tmp/test1:
content = I should not work in noop mode!,
}
}
node default {
include foo
}
mgruener@lt-mgr:~$ envpuppet puppet --version
2.6.8
mgruener@lt-mgr:~$ envpuppet puppet apply test.pp
warning: noop is a metaparam; this value will inherit to all contained resources
notice: /Stage[main]/Foo/File[/tmp/test1]/ensure: defined content as
'{md5}73878c2b0e1386f3127bb77f5a1c96e3'
notice: Finished catalog run in 0.01 seconds
mgruener@lt-mgr:~$ ls -la /tmp/test1
-rw-r--r-- 1 mgruener mgruener 31 2011-06-06 11:56 /tmp/test1
mgruener@lt-mgr:~$
/pre
I would expect it to work as if the noop parameter was set
directly for the resource.
--
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 #17613] puppet master ignores config and commandline parameters on SIGHUP
Issue #17613 has been updated by Andrew Parker. I think that Option 2 also has a problem if the vardir or confdir are set in the config file, then passing them through on the command line will override those values. That would mean that a change to those would not be picked up by a HUP and it re-reading the `puppet.conf` file. Bug #17613: puppet master ignores config and commandline parameters on SIGHUP https://projects.puppetlabs.com/issues/17613#change-80116 Author: Tom Fenri Status: Needs Decision Priority: Normal Assignee: eric sorenson Category: server Target version: 3.1.0 Affected Puppet version: 3.0.1 Keywords: Branch: We are using puppet version 3.0.1 on FreeBSD 8.1, installed from ports. $confdir is /home/share/puppet/, puppet master is running as user 'puppet'. rc.conf: puppetmaster_enable=YES puppetmaster_flags=--confdir=/home/share/puppet --rundir=/var/run/puppet When started via /usr/local/etc/rc.d/puppetmaster everything works fine, process looks like: puppet 58577 4.7 0.9 121420 71124 ?? Ss1:05PM 3:18.22 /usr/local/bin/ruby18 /usr/local/bin/puppet master --confdir=/home/share/puppet --rundir=/var/run/puppet When reloaded with kill -HUP $pid, which happens sometimes by newsyslog, it seems to forget all settings and tries to do things in /root/.puppet: Nov 14 13:38:22 isptsfits21 puppet-master[58577]: Caught HUP; calling restart Nov 14 13:38:22 isptsfits21 puppet-master[58577]: Restarting with '/usr/local/bin/puppet master --confdir=/home/share/puppet --rundir=/var/run/puppet' Nov 14 13:38:24 isptsfits21 puppet-master[58577]: Cannot create /root/.puppet/var; parent directory /root/.puppet does not exist Nov 14 13:38:24 isptsfits21 puppet-master[58577]: (/File[/root/.puppet/var]/ensure) change from absent to directory failed: Cannot create /root/.puppet/var; parent directory /root/.puppet does not exist Nov 14 13:38:24 isptsfits21 puppet-master[58577]: (/File[/root/.puppet/var/lib]) Dependency File[/root/.puppet/var] has failures: true Nov 14 13:38:24 isptsfits21 puppet-master[58577]: (/File[/root/.puppet/var/lib]) Skipping because of failed dependencies Nov 14 13:38:24 isptsfits21 puppet-master[58577]: (/File[/root/.puppet/var/server_data]) Dependency File[/root/.puppet/var] has failures: true Nov 14 13:38:24 isptsfits21 puppet-master[58577]: (/File[/root/.puppet/var/server_data]) Skipping because of failed dependencies Nov 14 13:38:24 isptsfits21 puppet-master[58577]: (/File[/root/.puppet/var/bucket]) Dependency File[/root/.puppet/var] has failures: true Nov 14 13:38:24 isptsfits21 puppet-master[58577]: (/File[/root/.puppet/var/bucket]) Skipping because of failed dependencies Nov 14 13:38:24 isptsfits21 puppet-master[58577]: (/File[/root/.puppet/var/reports]) Dependency File[/root/.puppet/var] has failures: true Nov 14 13:38:24 isptsfits21 puppet-master[58577]: (/File[/root/.puppet/var/reports]) Skipping because of failed dependencies Nov 14 13:38:24 isptsfits21 puppet-master[58577]: (/File[/root/.puppet/var/state]) Dependency File[/root/.puppet/var] has failures: true Nov 14 13:38:24 isptsfits21 puppet-master[58577]: (/File[/root/.puppet/var/state]) Skipping because of failed dependencies Nov 14 13:38:24 isptsfits21 puppet-master[58577]: (/File[/root/.puppet/var/yaml]) Dependency File[/root/.puppet/var] has failures: true Nov 14 13:38:24 isptsfits21 puppet-master[58577]: (/File[/root/.puppet/var/yaml]) Skipping because of failed dependencies Nov 14 13:38:24 isptsfits21 puppet-master[58577]: (/File[/root/.puppet/var/rrd]) Dependency File[/root/.puppet/var] has failures: true Nov 14 13:38:24 isptsfits21 puppet-master[58577]: (/File[/root/.puppet/var/rrd]) Skipping because of failed dependencies Nov 14 13:38:24 isptsfits21 puppet-master[58577]: (/File[/root/.puppet/var/log]) Dependency File[/root/.puppet/var] has failures: true Nov 14 13:38:24 isptsfits21 puppet-master[58577]: (/File[/root/.puppet/var/log]) Skipping because of failed dependencies Nov 14 13:38:24 isptsfits21 puppet-master[58577]: (/File[/root/.puppet/var/log/masterhttp.log]) Dependency File[/root/.puppet/var] has failures: true Nov 14 13:38:24 isptsfits21 puppet-master[58577]: (/File[/root/.puppet/var/log/masterhttp.log]) Skipping because of failed dependencies Nov 14 13:38:24 isptsfits21 puppet-master[58577]: Could not prepare for execution: Got 2 failure(s) while initializing: Cannot create /root/.puppet/var; parent directory /root/.puppet does not exist; change from absent to directory failed: Cannot create /root/.puppet/var; parent directory /root/.puppet does not exist After the last error the
[Puppet - Feature #11786] (Closed) `puppet doc` is not compatible with newer RDoc - thus with Ruby 1.9
Issue #11786 has been updated by Daniel Pittman. Status changed from Accepted to Closed Assignee deleted (Daniel Pittman) Hey. So, the decision was made by the platform team that they wouldn't take this change, or a change to simple disable `puppet doc`, in the 2.7 branch. It should be as close to correct as it will get with the 3.x releases. Sorry. Feature #11786: `puppet doc` is not compatible with newer RDoc - thus with Ruby 1.9 https://projects.puppetlabs.com/issues/11786#change-80125 Author: Justin Stoller Status: Closed Priority: Normal Assignee: Category: ruby19 Target version: 3.x Affected Puppet version: development Keywords: ruby1.9.3 Branch: https://github.com/puppetlabs/puppet/pull/377 The `puppet doc` code depends heavily on RDoc to do the documentation generation. Unfortunately, while the Ruby 1.8 series exclusively used RDoc 1.*, the Ruby 1.9 uses 3.* and 4.* versions. These are solidly incompatible with the way we used and integrated with RDoc in the `puppet doc` application. We need to support the `puppet doc` features in a way that also works with newer Ruby. -- 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 #17844] rename `my` in ruby dsl
Issue #17844 has been updated by eric sorenson. Priority changed from Normal to High Bumping priority to indicate it's in the current workload. Bug #17844: rename `my` in ruby dsl https://projects.puppetlabs.com/issues/17844#change-80126 Author: Patrick Carlisle Status: Merged - Pending Release Priority: High Assignee: Henrik Lindberg Category: language Target version: 3.1.0 Affected Puppet version: Keywords: ruby dsl backlog Branch: The `my` operator in the ruby dsl is misleading to sysadmins who probably have a perl backround. It should be renamed to something like `ruby_eval` (to be determined). -- 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 #17845] document stability of ruby dsl api
Issue #17845 has been updated by eric sorenson. Priority changed from Normal to High Target version changed from 3.x to 3.1.0 Bumping priority/target to indicate this is something in the current workload. Bug #17845: document stability of ruby dsl api https://projects.puppetlabs.com/issues/17845#change-80127 Author: Patrick Carlisle Status: In Topic Branch Pending Review Priority: High Assignee: Henrik Lindberg Category: documentation Target version: 3.1.0 Affected Puppet version: Keywords: backlog Branch: https://github.com/puppetlabs/puppet/pull/1298 Add YARD docs to Puppet::Parser::Scope and any other objects related to ruby dsl saying what can be considered api and generally marking it as experimental/unstable. -- 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 #18023] Puppet needs a public, clearly-defined Ruby API
Issue #18023 has been updated by eric sorenson. Priority changed from Normal to High Target version changed from 3.x to 3.1.0 This is underway as part of the Ruby DSL in #16937. Bumping priority/target to indicate it's in the current workload. Bug #18023: Puppet needs a public, clearly-defined Ruby API https://projects.puppetlabs.com/issues/18023#change-80128 Author: eric sorenson Status: Accepted Priority: High Assignee: eric sorenson Category: Target version: 3.1.0 Affected Puppet version: Keywords: backlog Branch: One of the problems people run into using Puppet as part of an infrastructure ecosystem is that there isn't a clearly defined Ruby API for it. There are REST endpoints that expose some functionality over the network, but they do not cover much of the total surface area of what Puppet can do, and things that are important for third parties aee probably never going to be exposed over the network. (A real-world use case: Foreman wants access to puppet master's configuration settings so it can integrate with the CA auth/issuance code). Today, people poke directly at internal methods, which both makes it difficult to change method signatures and control flow AND provides a crappy experience for tool authors. So Puppet should have a real, public, published (see #16426) API that the development team commits to and the outside world can trust. -- 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 #7316] puppet face applications (subcommands) delivered via modules should work
Issue #7316 has been updated by eric sorenson. Priority changed from High to Immediate Bug #7316: puppet face applications (subcommands) delivered via modules should work https://projects.puppetlabs.com/issues/7316#change-80131 Author: Dan Bode Status: Merged - Pending Release Priority: Immediate Assignee: Andrew Parker Category: Faces Target version: 3.1.0 Affected Puppet version: 3.0.0 Keywords: face faces subcommand application module plugin pluginsync backlog Branch: https://github.com/puppetlabs/puppet/pull/1319 If you deliver a new face that consists of: * application * face * action for face via pluginsync, then the application isn't actually found, and worse, it taunts you by showing it to you in the list of available subcommands. -- 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 #16753] Need the ability to list all nodes
Issue #16753 has been updated by eric sorenson. Priority changed from High to Immediate Bug #16753: Need the ability to list all nodes https://projects.puppetlabs.com/issues/16753#change-80132 Author: James Turnbull Status: Merged - Pending Release Priority: Immediate Assignee: Category: indirector Target version: 3.1.0 Affected Puppet version: 3.0.0 Keywords: backlog Branch: https://github.com/puppetlabs/puppet/pull/1317 In Puppet 3.0 we've disabled the default YAML node cache (see https://github.com/puppetlabs/puppet/commit/5a79d9abd96e73ff166527cdee69a30da8ab0f87). I use this code (and a number of others in the community use similar) to return a list of nodes: pre Puppet[:clientyamldir] = Puppet[:yamldir] if Puppet::Node.respond_to? :terminus_class Puppet::Node.terminus_class = :yaml nodes = Puppet::Node.search(*) else Puppet::Node.indirection.terminus_class = :yaml nodes = Puppet::Node.indirection.search(*) end /pre This now doesn't work. We need a method of returning the current list of nodes the master knows about. Currently available is: pre puppet node find 'hostname' /pre If we had: pre puppet node search '*' /pre That would meet my needs. -- 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 #16937] Improved Ruby DSL
Issue #16937 has been updated by eric sorenson. Priority changed from High to Immediate Feature #16937: Improved Ruby DSL https://projects.puppetlabs.com/issues/16937#change-80133 Author: Andrew Parker Status: Merged - Pending Release Priority: Immediate Assignee: Michael Hall Category: language Target version: 3.1.0 Affected Puppet version: Keywords: ruby, dsl, ruby dsl backlog Branch: This is a tracking ticket for the Ruby DSL rewrite that was done as a Google Summer of Code project. There original GSOC12 wording about this project was: # Feature Parity for the Ruby DSL ## Project Title Expand Features set for the Ruby DSL of Puppet ## Description/Benefits The Ruby DSL for Puppet is missing a few features when compared to the native DSL. This project would align the Ruby DSL with the native DSL. Examples of missing features in the ruby DSL as it stands today: * no defined types * issues are symbols vs strings * parameterized classes validation * Composite namevars * inheritance/overrides -- 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 #17844] rename `my` in ruby dsl
Issue #17844 has been updated by eric sorenson. Priority changed from High to Immediate Bug #17844: rename `my` in ruby dsl https://projects.puppetlabs.com/issues/17844#change-80134 Author: Patrick Carlisle Status: Merged - Pending Release Priority: Immediate Assignee: Henrik Lindberg Category: language Target version: 3.1.0 Affected Puppet version: Keywords: ruby dsl backlog Branch: The `my` operator in the ruby dsl is misleading to sysadmins who probably have a perl backround. It should be renamed to something like `ruby_eval` (to be determined). -- 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 #17845] document stability of ruby dsl api
Issue #17845 has been updated by eric sorenson. Priority changed from High to Immediate Bug #17845: document stability of ruby dsl api https://projects.puppetlabs.com/issues/17845#change-80135 Author: Patrick Carlisle Status: In Topic Branch Pending Review Priority: Immediate Assignee: Henrik Lindberg Category: documentation Target version: 3.1.0 Affected Puppet version: Keywords: backlog Branch: https://github.com/puppetlabs/puppet/pull/1298 Add YARD docs to Puppet::Parser::Scope and any other objects related to ruby dsl saying what can be considered api and generally marking it as experimental/unstable. -- 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 #18023] Puppet needs a public, clearly-defined Ruby API
Issue #18023 has been updated by eric sorenson. Priority changed from High to Immediate Bug #18023: Puppet needs a public, clearly-defined Ruby API https://projects.puppetlabs.com/issues/18023#change-80136 Author: eric sorenson Status: Accepted Priority: Immediate Assignee: eric sorenson Category: Target version: 3.1.0 Affected Puppet version: Keywords: backlog Branch: One of the problems people run into using Puppet as part of an infrastructure ecosystem is that there isn't a clearly defined Ruby API for it. There are REST endpoints that expose some functionality over the network, but they do not cover much of the total surface area of what Puppet can do, and things that are important for third parties aee probably never going to be exposed over the network. (A real-world use case: Foreman wants access to puppet master's configuration settings so it can integrate with the CA auth/issuance code). Today, people poke directly at internal methods, which both makes it difficult to change method signatures and control flow AND provides a crappy experience for tool authors. So Puppet should have a real, public, published (see #16426) API that the development team commits to and the outside world can trust. -- 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 #18023] Puppet needs a public, clearly-defined Ruby API
Issue #18023 has been updated by R.I. Pienaar. Which part of that ticket addresses this? I wasnt aware this was part of that, I am working on a new Puppet agent for mcollective so would be good to know whats up Bug #18023: Puppet needs a public, clearly-defined Ruby API https://projects.puppetlabs.com/issues/18023#change-80138 Author: eric sorenson Status: Accepted Priority: Immediate Assignee: eric sorenson Category: Target version: 3.1.0 Affected Puppet version: Keywords: backlog Branch: One of the problems people run into using Puppet as part of an infrastructure ecosystem is that there isn't a clearly defined Ruby API for it. There are REST endpoints that expose some functionality over the network, but they do not cover much of the total surface area of what Puppet can do, and things that are important for third parties aee probably never going to be exposed over the network. (A real-world use case: Foreman wants access to puppet master's configuration settings so it can integrate with the CA auth/issuance code). Today, people poke directly at internal methods, which both makes it difficult to change method signatures and control flow AND provides a crappy experience for tool authors. So Puppet should have a real, public, published (see #16426) API that the development team commits to and the outside world can trust. -- 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 #18023] Puppet needs a public, clearly-defined Ruby API
Issue #18023 has been updated by eric sorenson. RI - as part of the dsl, henrik and patrick added YARD docs throughout the codebase to declare public/private methods and document the method signatures https://github.com/puppetlabs/puppet/pull/1366 Bug #18023: Puppet needs a public, clearly-defined Ruby API https://projects.puppetlabs.com/issues/18023#change-80141 Author: eric sorenson Status: Accepted Priority: Immediate Assignee: eric sorenson Category: Target version: 3.1.0 Affected Puppet version: Keywords: backlog Branch: One of the problems people run into using Puppet as part of an infrastructure ecosystem is that there isn't a clearly defined Ruby API for it. There are REST endpoints that expose some functionality over the network, but they do not cover much of the total surface area of what Puppet can do, and things that are important for third parties aee probably never going to be exposed over the network. (A real-world use case: Foreman wants access to puppet master's configuration settings so it can integrate with the CA auth/issuance code). Today, people poke directly at internal methods, which both makes it difficult to change method signatures and control flow AND provides a crappy experience for tool authors. So Puppet should have a real, public, published (see #16426) API that the development team commits to and the outside world can trust. -- 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 #17449] (In Topic Branch Pending Review) auth.conf references path /file while referencing fileserver.conf
Issue #17449 has been updated by Nick Fagerlund. Status changed from Accepted to In Topic Branch Pending Review Branch changed from https://github.com/nfagerlund/puppet/tree/fileserver_conf to https://github.com/puppetlabs/puppet/pull/1369 Pull request sent. Bug #17449: auth.conf references path /file while referencing fileserver.conf https://projects.puppetlabs.com/issues/17449#change-80142 Author: Brian Harrington Status: In Topic Branch Pending Review Priority: Normal Assignee: Andrew Parker Category: server Target version: 3.1.0 Affected Puppet version: 3.0.1 Keywords: redhat linux Branch: https://github.com/puppetlabs/puppet/pull/1369 The default configuration of puppet 3.0.1-1 EL6 uses the stanza: # unconditionally allow access to all file services # which means in practice that fileserver.conf will # still be used path /file allow * while in fileserver.conf the default lists: # [files] # path [relative to distribution] # allow *.example.com # deny *.evil.example.com # allow 192.168.0.0/24 While the entry in fileserver.conf is an example, it conflicts with the defaults included in auth.conf. Either auth.conf should be changed or the sample in fileserver.conf. Additionally, if the sample in fileserver.conf is going to be changed, this becomes related to Bug ID 16686. -- 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 #17448] (In Topic Branch Pending Review) Sample fileserver.conf still contains references to allow statements by ip
Issue #17448 has been updated by Nick Fagerlund. Status changed from Accepted to In Topic Branch Pending Review Branch changed from https://github.com/nfagerlund/puppet/tree/fileserver_conf to https://github.com/puppetlabs/puppet/pull/1369 Pull request sent. Bug #17448: Sample fileserver.conf still contains references to allow statements by ip https://projects.puppetlabs.com/issues/17448#change-80143 Author: Brian Harrington Status: In Topic Branch Pending Review Priority: Low Assignee: Andrew Parker Category: server Target version: 3.1.0 Affected Puppet version: 3.0.1 Keywords: redhat linux Branch: https://github.com/puppetlabs/puppet/pull/1369 In version 3.0.1-1 EL6 of the RPMs the sample fileserver.conf contains references to using an allow statement by IP. As of this time this is still not implemented in this file (it's in auth.conf) as per Bug ID: 16686 and CVE-2012-3408. This should be removed (and possibly a comment mentioning auth.conf added). -- 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 #18023] Puppet needs a public, clearly-defined Ruby API
Issue #18023 has been updated by R.I. Pienaar. I totally commented on the wrong ticket, d'oh, ignore that :) Bug #18023: Puppet needs a public, clearly-defined Ruby API https://projects.puppetlabs.com/issues/18023#change-80145 Author: eric sorenson Status: Accepted Priority: Immediate Assignee: eric sorenson Category: Target version: 3.1.0 Affected Puppet version: Keywords: backlog Branch: One of the problems people run into using Puppet as part of an infrastructure ecosystem is that there isn't a clearly defined Ruby API for it. There are REST endpoints that expose some functionality over the network, but they do not cover much of the total surface area of what Puppet can do, and things that are important for third parties aee probably never going to be exposed over the network. (A real-world use case: Foreman wants access to puppet master's configuration settings so it can integrate with the CA auth/issuance code). Today, people poke directly at internal methods, which both makes it difficult to change method signatures and control flow AND provides a crappy experience for tool authors. So Puppet should have a real, public, published (see #16426) API that the development team commits to and the outside world can trust. -- 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 #17613] (Needs More Information) puppet master ignores config and commandline parameters on SIGHUP
Issue #17613 has been updated by eric sorenson. Status changed from Needs Decision to Needs More Information Assignee changed from eric sorenson to Tom Fenri Target version changed from 3.1.0 to 3.x Tom, can you confirm that adding your `vardir` explicitly works around the issue for you? This was under the radar because puppetlabs init scripts do a start/stop on webrick even when issuing a 'reload', and the issue only appears when running webrick because under passenger, Apache manages the process lifecycle so you don't have the changing euid. I’ve put this ticket’s status into “Needs more Information” and assigned it to you. Please either (a) update it with the information I’ve requested and re-assign it to me if you need more help, or (b) change the status to “Closed” if you were able to resolve the issue on your own. Bug #17613: puppet master ignores config and commandline parameters on SIGHUP https://projects.puppetlabs.com/issues/17613#change-80147 Author: Tom Fenri Status: Needs More Information Priority: Normal Assignee: Tom Fenri Category: server Target version: 3.x Affected Puppet version: 3.0.1 Keywords: Branch: We are using puppet version 3.0.1 on FreeBSD 8.1, installed from ports. $confdir is /home/share/puppet/, puppet master is running as user 'puppet'. rc.conf: puppetmaster_enable=YES puppetmaster_flags=--confdir=/home/share/puppet --rundir=/var/run/puppet When started via /usr/local/etc/rc.d/puppetmaster everything works fine, process looks like: puppet 58577 4.7 0.9 121420 71124 ?? Ss1:05PM 3:18.22 /usr/local/bin/ruby18 /usr/local/bin/puppet master --confdir=/home/share/puppet --rundir=/var/run/puppet When reloaded with kill -HUP $pid, which happens sometimes by newsyslog, it seems to forget all settings and tries to do things in /root/.puppet: Nov 14 13:38:22 isptsfits21 puppet-master[58577]: Caught HUP; calling restart Nov 14 13:38:22 isptsfits21 puppet-master[58577]: Restarting with '/usr/local/bin/puppet master --confdir=/home/share/puppet --rundir=/var/run/puppet' Nov 14 13:38:24 isptsfits21 puppet-master[58577]: Cannot create /root/.puppet/var; parent directory /root/.puppet does not exist Nov 14 13:38:24 isptsfits21 puppet-master[58577]: (/File[/root/.puppet/var]/ensure) change from absent to directory failed: Cannot create /root/.puppet/var; parent directory /root/.puppet does not exist Nov 14 13:38:24 isptsfits21 puppet-master[58577]: (/File[/root/.puppet/var/lib]) Dependency File[/root/.puppet/var] has failures: true Nov 14 13:38:24 isptsfits21 puppet-master[58577]: (/File[/root/.puppet/var/lib]) Skipping because of failed dependencies Nov 14 13:38:24 isptsfits21 puppet-master[58577]: (/File[/root/.puppet/var/server_data]) Dependency File[/root/.puppet/var] has failures: true Nov 14 13:38:24 isptsfits21 puppet-master[58577]: (/File[/root/.puppet/var/server_data]) Skipping because of failed dependencies Nov 14 13:38:24 isptsfits21 puppet-master[58577]: (/File[/root/.puppet/var/bucket]) Dependency File[/root/.puppet/var] has failures: true Nov 14 13:38:24 isptsfits21 puppet-master[58577]: (/File[/root/.puppet/var/bucket]) Skipping because of failed dependencies Nov 14 13:38:24 isptsfits21 puppet-master[58577]: (/File[/root/.puppet/var/reports]) Dependency File[/root/.puppet/var] has failures: true Nov 14 13:38:24 isptsfits21 puppet-master[58577]: (/File[/root/.puppet/var/reports]) Skipping because of failed dependencies Nov 14 13:38:24 isptsfits21 puppet-master[58577]: (/File[/root/.puppet/var/state]) Dependency File[/root/.puppet/var] has failures: true Nov 14 13:38:24 isptsfits21 puppet-master[58577]: (/File[/root/.puppet/var/state]) Skipping because of failed dependencies Nov 14 13:38:24 isptsfits21 puppet-master[58577]: (/File[/root/.puppet/var/yaml]) Dependency File[/root/.puppet/var] has failures: true Nov 14 13:38:24 isptsfits21 puppet-master[58577]: (/File[/root/.puppet/var/yaml]) Skipping because of failed dependencies Nov 14 13:38:24 isptsfits21 puppet-master[58577]: (/File[/root/.puppet/var/rrd]) Dependency File[/root/.puppet/var] has failures: true Nov 14 13:38:24 isptsfits21 puppet-master[58577]: (/File[/root/.puppet/var/rrd]) Skipping because of failed dependencies Nov 14 13:38:24 isptsfits21 puppet-master[58577]: (/File[/root/.puppet/var/log]) Dependency File[/root/.puppet/var] has failures: true Nov 14 13:38:24 isptsfits21 puppet-master[58577]: (/File[/root/.puppet/var/log]) Skipping because of failed dependencies Nov 14 13:38:24 isptsfits21 puppet-master[58577]: (/File[/root/.puppet/var/log/masterhttp.log]) Dependency File[/root/.puppet/var] has failures: true Nov 14 13:38:24 isptsfits21 puppet-master[58577]: (/File[/root/.puppet/var/log/masterhttp.log]) Skipping because of failed dependencies
[Puppet - Bug #18376] (Unreviewed) Clean up and unify default fileserver.conf files for packaging
Issue #18376 has been reported by Nick Fagerlund. Bug #18376: Clean up and unify default fileserver.conf files for packaging https://projects.puppetlabs.com/issues/18376 Author: Nick Fagerlund Status: Unreviewed Priority: Low Assignee: Matthaus Owens Category: Target version: Affected Puppet version: Keywords: Branch: nick@wren:~/Documents/puppet$ find . | grep fileserver.conf ./conf/fileserver.conf ./ext/debian/fileserver.conf ./ext/gentoo/puppet/fileserver.conf ./ext/redhat/fileserver.conf I just had to update all four of these files. They are identical. That's silly. We use a unified auth.conf file for all platforms, and we should unify this one too. Haus, could you look into this at some point? -- 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 - Refactor #3691] The Catalog should include both dependency and containment edges
Issue #3691 has been updated by eric sorenson. Priority changed from Normal to High Target version set to 3.x Keywords set to backlog Bumping into backlog to propose for Q1'13 engineering efforts. Refactor #3691: The Catalog should include both dependency and containment edges https://projects.puppetlabs.com/issues/3691#change-80148 Author: Luke Kanies Status: Accepted Priority: High Assignee: eric sorenson Category: transactions Target version: 3.x Affected Puppet version: 2.7.19 Keywords: backlog Branch: Right now, the catalogs sent from the server to the client include only containment edges, and the client has to go through some work internally to add dependency edges. In the course of doing so, it removes all of the containment edges. The current mechanism for removing them involves the infamous 'whit', which causes plenty of problems, including the need for the 'anchor' pattern. If we can refactor the catalog creation on the server, and graph sorting on the client, so that we can have both kinds of edges in the graph at the same time, we can get rid of all of the code around the relationship graph, along with the need for whits, and all of the complicated graph stuff involving them, plus the need for the anchor pattern. This will also make integration with other tools, like PuppetDB, easier. Note that the hard parts about doing this work are twofold: * Correctly descending dependencies in priority to containment edges. The edge types aren't equal and can't be treated as such. * Detecting dependency cycles. It's that last bit that blocked me last time I tried to do this. I have an attempt at this from a long time ago: https://github.com/lak/puppet/tree/refactor/master/3691-no_relationship_graph But I couldn't get cycle detection working, so I couldn't get it merged. -- 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 #15494] puppet parser validate returns zero on nonexistent file
Issue #15494 has been updated by Zack Smith. +1 Bug #15494: puppet parser validate returns zero on nonexistent file https://projects.puppetlabs.com/issues/15494#change-80155 Author: david boldt Status: Accepted Priority: Low Assignee: eric sorenson Category: executables Target version: Affected Puppet version: 2.7.17 Keywords: errors Branch: % ls -l /foo /foo: No such file or directory % puppet parser validate /foo ; echo $? 0 -- 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 #18378] (Accepted) puppet parser validate returns no output on nonexistent file
Issue #18378 has been reported by Zack Smith. Bug #18378: puppet parser validate returns no output on nonexistent file https://projects.puppetlabs.com/issues/18378 Author: Zack Smith Status: Accepted Priority: Normal Assignee: Category: executables Target version: Affected Puppet version: 2.7.19 Keywords: errors Branch: % ls -l /foo /foo: No such file or directory % puppet parser validate /foo This confusing to new users as the command also returns no output when the syntax check passes. New students in the puppet fundamentals course who don't use tab completion often have trouble with this ( almost every single class ). There should be a file not found error message. -- 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 #17449] (Merged - Pending Release) auth.conf references path /file while referencing fileserver.conf
Issue #17449 has been updated by Andrew Parker. Status changed from In Topic Branch Pending Review to Merged - Pending Release Merged in https://github.com/puppetlabs/puppet/commit/ba79c0d94c36aa3dc318de3e73cbce634b009d8e Bug #17449: auth.conf references path /file while referencing fileserver.conf https://projects.puppetlabs.com/issues/17449#change-80156 Author: Brian Harrington Status: Merged - Pending Release Priority: Normal Assignee: Andrew Parker Category: server Target version: 3.1.0 Affected Puppet version: 3.0.1 Keywords: redhat linux Branch: https://github.com/puppetlabs/puppet/pull/1369 The default configuration of puppet 3.0.1-1 EL6 uses the stanza: # unconditionally allow access to all file services # which means in practice that fileserver.conf will # still be used path /file allow * while in fileserver.conf the default lists: # [files] # path [relative to distribution] # allow *.example.com # deny *.evil.example.com # allow 192.168.0.0/24 While the entry in fileserver.conf is an example, it conflicts with the defaults included in auth.conf. Either auth.conf should be changed or the sample in fileserver.conf. Additionally, if the sample in fileserver.conf is going to be changed, this becomes related to Bug ID 16686. -- 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 #17448] (Merged - Pending Release) Sample fileserver.conf still contains references to allow statements by ip
Issue #17448 has been updated by Andrew Parker. Status changed from In Topic Branch Pending Review to Merged - Pending Release Merged in https://github.com/puppetlabs/puppet/commit/ba79c0d94c36aa3dc318de3e73cbce634b009d8e Bug #17448: Sample fileserver.conf still contains references to allow statements by ip https://projects.puppetlabs.com/issues/17448#change-80157 Author: Brian Harrington Status: Merged - Pending Release Priority: Low Assignee: Andrew Parker Category: server Target version: 3.1.0 Affected Puppet version: 3.0.1 Keywords: redhat linux Branch: https://github.com/puppetlabs/puppet/pull/1369 In version 3.0.1-1 EL6 of the RPMs the sample fileserver.conf contains references to using an allow statement by IP. As of this time this is still not implemented in this file (it's in auth.conf) as per Bug ID: 16686 and CVE-2012-3408. This should be removed (and possibly a comment mentioning auth.conf added). -- 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 #18026] SELinux warnings when using ensure = absent on file
Issue #18026 has been updated by Alex Cline.
These warnings also show up when a new node is provisioned. When the catalog
is compiled, File resources that have 'ensure = present' on them throw the
warning. Those resources are then created and the next puppet run doesn't have
the warnings.
Bug #18026: SELinux warnings when using ensure = absent on file
https://projects.puppetlabs.com/issues/18026#change-80160
Author: Malcolm Howe
Status: Unreviewed
Priority: Normal
Assignee:
Category: SELinux
Target version:
Affected Puppet version: 3.0.2
Keywords:
Branch:
When using, for example,
file {/etc/exclude.systemdump: ensure = absent }
If the file is already absent Puppet 3.0.2rc1 gives the following warnings not
seen in Puppet 3.0.1
Warning: /File[/etc/exclude.systemdump]/seluser: Could not stat; No such
file or directory - /etc/exclude.systemdump
Warning: /File[/etc/exclude.systemdump]/selrole: Could not stat; No such
file or directory - /etc/exclude.systemdump
Warning: /File[/etc/exclude.systemdump]/seltype: Could not stat; No such
file or directory - /etc/exclude.systemdump
Warning: /File[/etc/exclude.systemdump]/selrange: Could not stat; No such
file or directory - /etc/exclude.systemdump
System is running Centos 6 with SELinux in permissive mode.
--
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 #7622] Change confine :true to feature
Issue #7622 has been updated by Andrew Parker. Target version changed from 3.x to 3.1.0 Bug #7622: Change confine :true to feature https://projects.puppetlabs.com/issues/7622#change-80161 Author: James Turnbull Status: Merged - Pending Release Priority: Normal Assignee: Andrew Parker Category: plumbing Target version: 3.1.0 Affected Puppet version: 2.6.8 Keywords: Branch: https://github.com/puppetlabs/puppet/pull/1240 -- 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 #15214] Get rid of coupling between run_mode and confdir/vardir
Issue #15214 has been updated by Andrew Parker. Target version deleted (3.x) Bug #15214: Get rid of coupling between run_mode and confdir/vardir https://projects.puppetlabs.com/issues/15214#change-80162 Author: Chris Price Status: Duplicate Priority: Normal Assignee: Category: Target version: Affected Puppet version: Keywords: Branch: We have an ordering issue in the current code, because the default values for confdir and vardir are specified based on the run_mode setting, which is specified by individual applications. However, we need to know where our config dir and libdir are before we can even try to load an application. This introduces some very confusing and brittle ordering issues in bootstrapping puppet command line apps. A potential fix is here: https://github.com/cprice-puppet/puppet/commit/b064ee637b93d45483444274e15f5edf4ded3c75 Which is included in the pull request: https://github.com/puppetlabs/puppet/pull/882 -- 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 #16210] parenthesize argument(s) for future version warnings on RHEL 5 / Ruby 1.8.5
Issue #16210 has been updated by Andrew Parker. Target version deleted (3.x) Bug #16210: parenthesize argument(s) for future version warnings on RHEL 5 / Ruby 1.8.5 https://projects.puppetlabs.com/issues/16210#change-80163 Author: Dominic Cleal Status: Closed Priority: Low Assignee: Dominic Cleal Category: compatibility Target version: Affected Puppet version: Keywords: ruby Branch: With Ruby 1.8.5 on RHEL 5, the agent shows these warnings when starting: /usr/lib/ruby/site_ruby/1.8/puppet/provider/package/pacman.rb:17: warning: parenthesize argument(s) for future version /usr/lib/ruby/site_ruby/1.8/puppet/util/windows/registry.rb:23: warning: parenthesize argument(s) for future version -- 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 #17747] Inability to use gems as dependencies in custom providers types
Issue #17747 has been updated by Andrew Parker. Target version deleted (3.x) Bug #17747: Inability to use gems as dependencies in custom providers types https://projects.puppetlabs.com/issues/17747#change-80164 Author: Mohit Chawla Status: Duplicate Priority: Normal Assignee: eric sorenson Category: plug-ins Target version: Affected Puppet version: 2.7.19 Keywords: code_loading Branch: I am using a custom provider that uses an external gem, for eg., json. I am seeing this behavior: 1) In the first puppet run - errors would be thrown like : err: Could not load downloaded file /var/lib/puppet/lib/puppet/provider/custom_provider/json.rb: no such file to load -- json. However, the catalog compiles and gets executed successfully eventually in the same run, as I provide the json lib from my module. 2) If however, there was some other error in the first run, say a syntax error somewhere, and then you try a successive puppet run, it simply doesn't retrieve the catalog, with an error like: Could not autoload custom: Could not autoload /var/lib/puppet/lib/puppet/provider/custom_provider/json.rb: no such file to load -- json -- 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 #4388] Remove the namespaceauth.conf file
Issue #4388 has been updated by Andrew Parker. Target version changed from 3.x to 3.1.0 Feature #4388: Remove the namespaceauth.conf file https://projects.puppetlabs.com/issues/4388#change-80165 Author: Matt Robinson Status: Merged - Pending Release Priority: High Assignee: Henrik Lindberg Category: plumbing Target version: 3.1.0 Affected Puppet version: Keywords: rest api Branch: https://github.com/puppetlabs/puppet/pull/1204 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@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 #11786] `puppet doc` is not compatible with newer RDoc - thus with Ruby 1.9
Issue #11786 has been updated by Andrew Parker. Target version deleted (3.x) Feature #11786: `puppet doc` is not compatible with newer RDoc - thus with Ruby 1.9 https://projects.puppetlabs.com/issues/11786#change-80186 Author: Justin Stoller Status: Closed Priority: Normal Assignee: Category: ruby19 Target version: Affected Puppet version: development Keywords: ruby1.9.3 Branch: https://github.com/puppetlabs/puppet/pull/377 The `puppet doc` code depends heavily on RDoc to do the documentation generation. Unfortunately, while the Ruby 1.8 series exclusively used RDoc 1.*, the Ruby 1.9 uses 3.* and 4.* versions. These are solidly incompatible with the way we used and integrated with RDoc in the `puppet doc` application. We need to support the `puppet doc` features in a way that also works with newer Ruby. -- 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 #4915] scope.function_extlookup (in templates) takes an array parameter
Issue #4915 has been updated by Andrew Parker.
Target version deleted (2.7.x)
Removing the target version, since this was done as a documentation change.
Issue #15756 is the one about making puppet stricter about this.
Bug #4915: scope.function_extlookup (in templates) takes an array parameter
https://projects.puppetlabs.com/issues/4915#change-80187
Author: Jordan Sissel
Status: Closed
Priority: Normal
Assignee: Nick Fagerlund
Category: documentation
Target version:
Affected Puppet version: 2.6.1
Keywords:
Branch:
This does not work
pre
notice(
inline_template(%= Puppet::Parser::Functions.autoloader.loadall;
scope.function_extlookup('hello world') %)
)
Error:
Failed to parse inline template: extlookup(): wrong number of arguments (11;
must be = 3) at /home/jls/f.pp:2 on node snack.home
/pre
Volcane pointed out that extlookup() expects an array, which made the '11'
above pretty obvious as 'hello world'.size == 11.
This version works:
pre
notice(
inline_template(%= Puppet::Parser::Functions.autoloader.loadall;
scope.function_extlookup(['hello world']) %)
)
Output:
notice: Scope(Class[main]): Hello sir!
/pre
---
Possible fix: Make extlookup check if the type given is a string, and if so,
treat it normally.
--
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 #12540] puppet config print generates invalid log settings if puppet.conf doesn't exist
Issue #12540 has been updated by Andrew Parker. Target version deleted (2.7.x) Bug #12540: puppet config print generates invalid log settings if puppet.conf doesn't exist https://projects.puppetlabs.com/issues/12540#change-80188 Author: Josh Cooper Status: Closed Priority: Normal Assignee: Category: Target version: Affected Puppet version: Keywords: Branch: If ~/.puppet/puppet.conf does not exist, then `puppet config print` generates an invalid config for settings that are based on $vardir/log: pre $ rm ~/.puppet/puppet.conf $ puppet config print logdir $vardir/log The Puppet log directory. /pre Note the value of the logdir property is actually two lines with an embedded newline. Other log settings based on logdir have the same problem: pre $ puppet config print all | grep vardir/log httplog = $vardir/logThe Puppet log directory./http.log logdir = $vardir/logThe Puppet log directory. masterhttplog = $vardir/logThe Puppet log directory./masterhttp.log masterlog = $vardir/logThe Puppet log directory./puppetmaster.log puppetdlog = $vardir/logThe Puppet log directory./puppetd.log railslog = $vardir/logThe Puppet log directory./rails.log /pre Now create an empty puppet.conf and all of the logdir settings use the interpolated value of $vardir/log: pre $ touch ~/.puppet/puppet.conf $ puppet config print all | grep vardir/log $ puppet config print logdir /Users/josh/.puppet/var/log /pre This looks to be an issue with run_mode, see `Puppet::Util::RunMode.logopts` -- 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 #14073] puppet apply cannot find types in modules on Windows
Issue #14073 has been updated by Andrew Parker. Target version deleted (2.7.x) Bug #14073: puppet apply cannot find types in modules on Windows https://projects.puppetlabs.com/issues/14073#change-80189 Author: Jeff McCune Status: Duplicate Priority: Normal Assignee: Patrick Carlisle Category: modules Target version: Affected Puppet version: 2.7.4 Keywords: autoloader windows module load_path LOAD_PATH RUBYLIB autoload require bd Branch: # Overview # With Puppet 2.7.x (3a4ac604c85952511fd45c2f0699ce956eda3773) and master (b02aa930a03a282588e81f65e14f47a138a4b9f0) Puppet is not able to find custom types and providers located in a module. This appears to be a regression. # Actual Behaivor # With the [mount_providers](http://forge.puppetlabs.com/puppetlabs/mount_providers) module installed in the module path, there is an error because the type uses a require statement and the $LOAD_PATH is not correct: pre Z:\vagrant\modulespuppet describe --modulepath=Z:/vagrant/modules mounttab Could not run: Could not autoload \ Z:/vagrant/modules/mount_providers/lib/puppet/type/mountpoint.rb: Could not autoload Z:/vagrant/modules/mount_providers/lib/puppet/provider/mountpoint/linux.rb: \ no such file to load -- puppet/type/mountpoint /pre # Expected Behavior # The custom type in the mount providers module should be able to require additional files with the $LOAD_PATH modified to include the lib directory of the module from the module path. # Steps to reproduce # Install Puppet 2.7.13 from our MSI. Modify environment.bat to use PUPPET_DIR and FACTER_DIR pointing at your Git working copies. Install the mount_providers module somewhere. Use puppet describe --modulepath=Z:/path/to/modules mountpoint See the exception raised. This happens on both 2.7.x and master. -- 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 #16573] Gentoo package - resource is failing
Issue #16573 has been updated by Andrew Parker.
Target version deleted (2.7.x)
Bug #16573: Gentoo package - resource is failing
https://projects.puppetlabs.com/issues/16573#change-80191
Author: Marc Richter
Status: Duplicate
Priority: Normal
Assignee: eric sorenson
Category: Gentoo
Target version:
Affected Puppet version: 2.7.18
Keywords: eix
Branch:
Running Puppet on a Gentoo Linux, everytime, when a package - resource is
computed, the eix - command seems to give back a 1 exitcode, which makes the
Puppetrun fail.
When executing the eix commandline from the logs manually, this works, but on
the shell I have to surround a specific part with ' :
Let me give an example:
**The Manifest:**
`package { 'media-gfx/exif':
ensure = installed,
}`
**The result in Puppet-Report:**
`errCould not evaluate: Execution of '/usr/bin/eix --nocolor
--pure-packages --stable --format category name
[installedversions:LASTVERSION] [bestversion:LASTVERSION] homepage
description --exact --category-name media-gfx/exif' returned 1`
**The result when run manually, but sorroundet with ' between --format and
--exact:**
`vagrant-funtoo64 /boot # /usr/bin/eix --nocolor --pure-packages --stable
--format 'category name [installedversions:LASTVERSION]
[bestversion:LASTVERSION] homepage description' --exact --category-name
media-gfx/exif
media-gfx exif [] [] http://libexif.sourceforge.net/ Small CLI util to show
EXIF infos hidden in JPEG filesvagrant-funtoo64 /boot # echo $?
0
vagrant-funtoo64 /boot #`
--
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 #8311] file { mode = .. } -- investigation into strings, octal, etc --
Issue #8311 has been updated by Andrew Parker.
Target version deleted (2.7.x)
Removing the target version. We can retarget it if it gets reopened.
Bug #8311: file { mode = .. } -- investigation into strings, octal, etc --
https://projects.puppetlabs.com/issues/8311#change-80195
Author: tgeeky -
Status: Closed
Priority: Normal
Assignee: tgeeky -
Category: file
Target version:
Affected Puppet version: 2.7.1
Keywords: file, mode, octal
Branch:
This ticket is meant as an investigation into general problems with the
following syntax:
file { '/some/file/or/directory':
mode = _
}
In theory, any of the following could be entered where is:
* 0
* 1
* 0
* 0123
* 1365
* '0'
* ''
* '0777'
* 0
* 0123
* 644
* - - - - - - - - - -
* - r w S r w S r w -
* 8000
* 81ff
For instance, what should be valid here? How should puppet store (internally)
the information you supply? What should happen when invalid input is supplied?
Because Ruby is a dynamically typed language and because some joker
decided that prefixing a number with a zero specifies an octal number, Puppet
is left with some lingering bugs; and, even when a decision on syntax
is made, backwards compatibility is not an easy task.
This bug report was spurred on by (but is not identical to) my other
[[bug report#8255]](http://projects.puppetlabs.com/issues/8255). That bug is
just for the defaults (which is a puppet system also need of some TLC).
[[This pastie]](http://pastie.org/2181013) represents my first attack at
actually figuring out what's going on. It is nowhere near sufficient, and it's
not in test form (since I don't know how to write tests yet).
There are probably several bugs that are caused by this inconsistency. And
directories are not immune, either.
--
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 #1042] Trailing or extra slashes are not removed from file names when resolving relationships
Issue #1042 has been updated by Andrew Parker. Target version deleted (2.7.x) Bug #1042: Trailing or extra slashes are not removed from file names when resolving relationships https://projects.puppetlabs.com/issues/1042#change-80198 Author: Luke Kanies Status: Accepted Priority: Low Assignee: Category: RAL Target version: Affected Puppet version: 0.24.4 Keywords: Branch: This isn't a huge problem, since it has easy workarounds (remove the slashes from the relationship specification). It also has some difficult design aspects, because solving it requires that each resource type get some say in how related titles are handled -- i.e., in this case the file type needs to provide a method that trims extra slashes. -- 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 #709] crontab type seems to detect the current environment lines wrong
Issue #709 has been updated by Andrew Parker.
Target version deleted (2.7.x)
Bug #709: crontab type seems to detect the current environment lines wrong
https://projects.puppetlabs.com/issues/709#change-80197
Author: Karl Pietri
Status: Accepted
Priority: Normal
Assignee:
Category: cron
Target version:
Affected Puppet version: 0.24.7
Keywords: cronfixit
Branch:
pre
notice:
//node1/baseserverrole/webserverrole/webcron/rcron[ntpd_check]/Cron[ntpd_check]/environment:
environment changed
'MAILTO=em...@mydomain.com,MAILTO=em...@mydomain.com,MAILTO=em...@mydomain.com,MAILTO=em...@mydomain.com,MAILTO=em...@mydomain.com,MAILTO=em...@mydomain.com,MAILTO=em...@mydomain.com,MAILTO=em...@mydomain.com,MAILTO=em...@mydomain.com,MAILTO=em...@mydomain.com'
to 'MAILTO=em...@mydomain.com'
/pre
The cron provider seems to think there are more MAILTO's then actually are. As
listing the crontab shows:
pre
# Puppet Name: ntpd_check
MAILTO=em...@mydomain.com
*/5 * * * * /root/bin/ntpmon /dev/null 21
/pre
This happens everytime puppetd --test is run.
puppet config:
pre
rCron{ ntpd_check:
command=/root/bin/ntpmon /dev/null 21,
minute=*/5,
require=RFile[[rootbinntpmon]]
}
define
rCron($command,$minute=absent,$hour=absent,$monthday=absent,$month=absent,$weekday=absent,$environment=MAILTO=em...@mydomain.com){
cron{ $name:
command=$command,
minute=$minute,
hour=$hour,
month=$month,
monthday=$monthday,
weekday=$weekday,
environment=$environment,
user=root
}
}
/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 - Bug #1372] Class names that match the node name are not evaluated
Issue #1372 has been updated by Andrew Parker.
Target version deleted (2.7.x)
Bug #1372: Class names that match the node name are not evaluated
https://projects.puppetlabs.com/issues/1372#change-80199
Author: Digant Kasundra
Status: Investigating
Priority: Normal
Assignee: Lee Lowder
Category: language
Target version:
Affected Puppet version: 0.24.4
Keywords: devtriage
Branch:
If I setup:
class subversion {
warning(I am class subversion)
}
and in my nodes.pp I have
node subversion { include subversion }
When i run puppet in verbose mode on subversion, I never see that warning.
--
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 #1395] puppet memory usage
Issue #1395 has been updated by Andrew Parker. Target version deleted (2.7.x) Bug #1395: puppet memory usage https://projects.puppetlabs.com/issues/1395#change-80200 Author: Peter Meier Status: Needs More Information Priority: Normal Assignee: Daniel Pittman Category: plumbing Target version: Affected Puppet version: 0.25.1 Keywords: memory leaks Branch: In a recent discussion about using puppetd with xinetd (main thread:http://groups.google.com/group/puppet-users/browse_thread/thread/50c94008469fc395/11687cd0a633f8f4 ) it came out that there is some investigation needed on puppetd's memory usage. Different people noticed that running puppetd is using a lot of footprint (links follow), while other noticed that it uses nearly none (links follow) Notices about high memory usage: pre VIRT/RES 141m/61m:http://groups.google.com/group/puppet-users/msg/75a8bb3b6652bae6 127m/82m:http://groups.google.com/group/puppet-users/msg/a4a43d3edd585c03 64 bit 166m/83m:http://groups.google.com/group/puppet-users/msg/1825ed57ff84287f 183m/96m:http://groups.google.com/group/puppet-users/msg/ecf2cd36b6e1e3a6 version 0.24.4, 64 bit /pre Notices about low memory usage: pre nothing specific:http://groups.google.com/group/puppet-users/msg/aac9fade1b906bd9 version 0.24.4 57m/46m:http://groups.google.com/group/puppet-users/msg/680b2b2760aa8890 version 0.23.1 /pre Personally I can add another memory usage on a 32bit machine, which is rather low: 85m virt and 69m res, running 0.24.4 Luke then noticed:http://groups.google.com/group/puppet-users/msg/573a76e32fba3eb0 that we should investigate on memory usage in the near future. Besides the memory consumption of puppetd, also the memory consumption of puppetmaster was discussed. There Duncan Hill noticed that splitting the fileserver off the the main puppetmaster improved the situation heavily:http://groups.google.com/group/puppet-users/msg/a7083b931b5c4cda , however he noticed:http://groups.google.com/group/puppet-users/msg/f68347fdb69b8496 that the manifest puppetmaster still consumes a lot of memory. There have been also other reports about memory usage trashing the master and the client:http://groups.google.com/group/puppet-users/browse_thread/thread/26aa8025de704cc4/1c9608f58360cdbb, however this might not be related. Quick Summary: We have seen different environments reporting a lot of memory usage. Most of them seem to be 64bit machines using 0.24.4. One report about low memory usage was a 0.23.1 version. Personal additional assumption: And for a first glance it looks like that 64bit machines double the memory consumption. (Take care of this assumption) -- 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 #1453] removing a cron parameter does not change the object
Issue #1453 has been updated by Andrew Parker.
Target version deleted (2.7.x)
Bug #1453: removing a cron parameter does not change the object
https://projects.puppetlabs.com/issues/1453#change-80201
Author: Martha Greenberg
Status: Accepted
Priority: Normal
Assignee:
Category: cron
Target version:
Affected Puppet version: 0.24.5
Keywords: cron
Branch:
If you remove a parameter from a cron object, it should change the cron job to
have * in that field. However, puppet does not change it unless you specify
*.
pre
# cat /tmp/1.pp
cron { test:
command = /bin/echo test,
hour= 4,
minute = 3,
}
# puppet -v /tmp/1.pp
notice: //Cron[test]/ensure: created
# cat /var/spool/cron/crontabs/root
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (- installed on Sun Jul 27 23:45:24 2008)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
# HEADER: This file was autogenerated at Sun Jul 27 23:45:24 +0300 2008 by
puppet.
# HEADER: While it can still be managed manually, it is definitely not
recommended.
# HEADER: Note particularly that the comments starting with 'Puppet Name'
should# HEADER: not be deleted, as doing so could cause duplicate cron jobs.
# Puppet Name: test
3 4 * * * /bin/echo test
# cat /tmp/2.pp
cron { test:
command = /bin/echo test,
minute = 5,
}
# puppet -v /tmp/2.pp
notice: //Cron[test]/minute: minute changed '3' to '5'
# cat /var/spool/cron/crontabs/root
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (- installed on Sun Jul 27 23:51:11 2008)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
# HEADER: This file was autogenerated at Sun Jul 27 23:51:11 +0300 2008 by
puppet.
# HEADER: While it can still be managed manually, it is definitely not
recommended.
# HEADER: Note particularly that the comments starting with 'Puppet Name'
should# HEADER: not be deleted, as doing so could cause duplicate cron jobs.
# Puppet Name: test
5 4 * * * /bin/echo test
/pre
Notice that hour is still set to 4, not *!
--
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 #1531] ssh_authorized_keys should not use the key 'comment' as a unique identifier (name)
Issue #1531 has been updated by Andrew Parker. Target version deleted (2.7.x) Bug #1531: ssh_authorized_keys should not use the key 'comment' as a unique identifier (name) https://projects.puppetlabs.com/issues/1531#change-80202 Author: Paul Boven Status: Accepted Priority: Normal Assignee: Francois Deppierraz Category: Target version: Affected Puppet version: 0.24.4 Keywords: Branch: Currently the ssh authorized keys provider uses the 'comment' section from an SSH public key as the 'name'. However, this implies that these comment strings must be unique, while SSH itself imposes no such restriction: in fact, it often happens that users generate both an RSA and a DSA key, which by default will have the same comment. A better 'name' for a key would perhaps be its fingerprint. There is a very small chance of collisions, but using the comment as 'name' is certain to generate collisions (for me it already has). Otherwise, the key-string itself should perhaps be the 'name' as this is certainly unique. If a user just changes the 'name' of the key in the Puppet manifest, then the other problem is that Puppet (only looking at the 'name', not the contents of the key) fails to realize that a key is already in place so you end up with duplicates. The current implementation doesn't really manage authorized_keys, it only manages the comment section and has no knowledge of the actual key. Using the key fingerprint would require Puppet to be able to actually extract the fingerprint from the key and would be a non-trivial change. -- 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 #1720] The package resource type doesn't notice installed packages when more than one is installed
Issue #1720 has been updated by Andrew Parker.
Target version deleted (2.7.x)
Bug #1720: The package resource type doesn't notice installed packages when
more than one is installed
https://projects.puppetlabs.com/issues/1720#change-80203
Author: Trevor Hemsley
Status: Accepted
Priority: Normal
Assignee:
Category: package
Target version:
Affected Puppet version: 0.24.6
Keywords:
Branch:
On Redhat systems using yum as the package provider, we have a class that says
pre
class hpasm {
# This class is meant to keep dependancies for the correct build of the various
hp/compaq components
package {kernel-smp-devel:
ensure = 2.6.9-67.0.1.EL,
}
}
/pre
and rpm -q kernel-smp-devel reports
kernel-smp-devel-2.6.9-55.0.9.EL
kernel-smp-devel-2.6.9-55.0.2.EL
kernel-smp-devel-2.6.9-67.0.1.EL
kernel-smp-devel-2.6.9-67.0.7.EL
kernel-smp-devel-2.6.9-67.0.20.EL
kernel-smp-devel-2.6.9-78.0.1.EL
as installed. However puppetd --test --noop says
notice: //Node[basicnode]/hpasm/Package[kernel-smp-devel]/ensure: is
2.6.9-55.0.9.EL, should be 2.6.9-67.0.1.EL (noop)
I think this is probably a bug since puppet seems to stop looking after the
first rpm it finds
--
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 #2014] sshkey creates /etc/ssh/ssh_known_hosts with mode 600
Issue #2014 has been updated by Andrew Parker. Target version deleted (2.7.x) Bug #2014: sshkey creates /etc/ssh/ssh_known_hosts with mode 600 https://projects.puppetlabs.com/issues/2014#change-80204 Author: Todd Zullinger Status: Accepted Priority: Normal Assignee: Category: ssh Target version: Affected Puppet version: 0.24.7 Keywords: ssh known_hosts Branch: Using the sshkey type /etc/ssh/ssh_known_hosts is created with mode 600 by default. This seems undesirable in most situations. I think the default should be 644. I didn't see anything obvious in the sshkey code that set it strictly on purpose. Does puppet default to 600 somewhere? And is there a simple way to tweak a type to use a different mode? This seems like a similar issue to #1538. Of course, it's not an inifile, so the fix will be different. -- 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 #2043] up2date provider should split off architecture to --arch parameter
Issue #2043 has been updated by Andrew Parker.
Target version deleted (2.7.x)
Bug #2043: up2date provider should split off architecture to --arch parameter
https://projects.puppetlabs.com/issues/2043#change-80205
Author: Derek Whayman
Status: Tests Insufficient
Priority: Normal
Assignee: James Cammarata
Category: package
Target version:
Affected Puppet version: 0.24.7
Keywords: communitypatch
Branch: https://github.com/jamtur01/puppet/tree/ticket/master/2043
Re:
http://groups.google.com/group/puppet-dev/browse_thread/thread/5ce44b1541a1df8b
Just came across an issue where I had to install pam.i386 as well as
pam.x86_64 on a RHEL4 machine (via up2date). With the yum provider
you can simply
package { pam.i386: }
Because the underlying command is understood by yum
yum -y install pam.i386
With up to date this fails
up2date-nox -i pam.i386
You need to
up2date --arch=i386 pam
There has been a lot of discussion in the past (including myself)
about this, none of which came to a satisfactory conclusion. Packages
are inherently tricky as you have pam, pam.i386 and pam.x86_64
which doesn't sit comfortably with Puppet's concept of unique
resources.
So what I propose is something much simpler, rather than solve that
problem simply permit the same kludge within up2date as within yum,
i.e. this patch.
The provider will determine if the name end in an architecture by way of a long
regexp of known architectures. Splitting off via the dots is unreliable as
some package names do have a dot in them.
Regards,
Derek
--
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 - Refactor #2064] Checksums should be modeled explicitly in files
Issue #2064 has been updated by Andrew Parker. Target version deleted (2.7.x) Refactor #2064: Checksums should be modeled explicitly in files https://projects.puppetlabs.com/issues/2064#change-80206 Author: Luke Kanies Status: Accepted Priority: Normal Assignee: Category: file Target version: Affected Puppet version: 0.24.7 Keywords: Branch: Currently, checksums are used all over in files, but they're always passed around as strings. They should instead be passed around as instances of a Checksum class, which would greatly simplify the checksum handling. This should be relatively straightforward and would be a big win. -- 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 #2072] File content always prints as checksums
Issue #2072 has been updated by Andrew Parker. Target version deleted (2.7.x) Bug #2072: File content always prints as checksums https://projects.puppetlabs.com/issues/2072#change-80207 Author: Luke Kanies Status: Accepted Priority: Low Assignee: Category: file Target version: Affected Puppet version: 0.24.7 Keywords: Branch: This was done in commit:858480b04d84e56aa483c80642dd0512af4fd025 because it made the code drastically easier, but it means that, for instance, 'ralsh file /foo' prints the checksum instead of the file content, which in turn means files are no longer isomorphic with their puppet representation. This isn't a significant problem today, because only ralsh uses that functionality, but it should be fixed. -- 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 #2083] puppet cert errors and messages
Issue #2083 has been updated by Andrew Parker. Target version deleted (2.7.x) Bug #2083: puppet cert errors and messages https://projects.puppetlabs.com/issues/2083#change-80208 Author: Phil Schwartz Status: Accepted Priority: Normal Assignee: Category: usability Target version: Affected Puppet version: 0.24.7 Keywords: Branch: If the puppetmaster is reinstalled each puppetd client's certs will no longer work and there is nothing in the puppetmaster log that is useful for troubleshooting. Similarly, the puppetd client's output is less than sufficient and doesn't indicate that a potention solution is to remove the ssl files from the ssldir. -- 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 #2095] Changing the permissions of /etc/puppet/puppet.conf via puppet crashes puppetmaster
Issue #2095 has been updated by Andrew Parker.
Target version deleted (2.7.x)
Bug #2095: Changing the permissions of /etc/puppet/puppet.conf via puppet
crashes puppetmaster
https://projects.puppetlabs.com/issues/2095#change-80209
Author: Trevor Hemsley
Status: Accepted
Priority: Normal
Assignee:
Category: file
Target version:
Affected Puppet version: 0.24.7
Keywords:
Branch:
class puppetperms
{
file {/etc/puppet/puppet.conf:
owner = root,
group = root,
mode = 600
}
}
then invoke puppetd --test --tags puppetperms on the puppetmaster server
machine. The perms get changed, puppetmaster gets notified then crashes.
In syslog I see this
puppetd[6381]: (//Node[infra]/puppetperms/File[/etc/puppet/puppet.conf]/mode)
mode changed '644' to '600'
puppetd[6381]: Finished catalog run in 7.08 seconds
puppetmasterd[26866]: Reparsing /etc/puppet/puppet.conf
But puppetmaster is now dead.
Restart puppetmaster and all is OK again. Can happily run puppetd --test --tags
puppetperms while the perms are correct. Reset them via
chmod 700 /etc/puppet/puppet.conf
and puppetmaster immediately crashes without even running puppetd --test --tags
puppetperms.
BTW, puppetd does not run as a daemon on any of these machines, it's only run
manually.
--
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 #2118] Puppetmasterd should finish operations when restarting
Issue #2118 has been updated by Andrew Parker. Target version deleted (2.7.x) Bug #2118: Puppetmasterd should finish operations when restarting https://projects.puppetlabs.com/issues/2118#change-80210 Author: Luke Kanies Status: Accepted Priority: Normal Assignee: Category: plumbing Target version: Affected Puppet version: 0.24.7 Keywords: Branch: When the master gets a signal to restart, it will stop all open operations and restart immediately. It should instead finish any of those operations before restarting. I don't really know how this will work - I assume it will require some kind of registration process that keeps a counter of open connections, along with a lock that prevents new connections. Thus, a restart will enable this lock, and will not restart until the number of open connections has dropped to 0. -- 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 #2156] provider/service/freebsd.rb cannot handle service name containing 'dash'
Issue #2156 has been updated by Andrew Parker.
Target version deleted (2.7.x)
Bug #2156: provider/service/freebsd.rb cannot handle service name containing
'dash'
https://projects.puppetlabs.com/issues/2156#change-80211
Author: Tomoyuki Sakurai
Status: Needs More Information
Priority: Normal
Assignee:
Category: FreeBSD
Target version:
Affected Puppet version: 0.24.8
Keywords:
Branch:
the following service creates /etc/rc.conf.d/foo-bar, which is invalid.
service { foo-bar :
enable = true
}
- in the file name and variable name must be replaced with _.
pre
cat /etc/rc.conf.d/foo_bar
foo_bar_enable=YES
/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 - Bug #2158] Nagios files are created mode 600
Issue #2158 has been updated by Andrew Parker. Target version deleted (2.7.x) Bug #2158: Nagios files are created mode 600 https://projects.puppetlabs.com/issues/2158#change-80212 Author: Scott Briggs Status: Accepted Priority: Normal Assignee: Category: nagios Target version: Affected Puppet version: 0.24.6 Keywords: Branch: When puppet creates any nagios specific files, it creates them with mode 600 and owner and group both set to root. This renders the files unreadable by nagios which kind of defeats the purpose of having native nagios resources. Creating these files with mode 644 would be perfectly reasonable, however, it might be worthwhile to allow owner, group and mode to be set in the same way as a file resource if it's not too complicated. Thanks, Scott -- 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 #2159] Allowingunauthenticated client access to puppetca.getcert
Issue #2159 has been updated by Andrew Parker. Target version deleted (2.7.x) Bug #2159: Allowingunauthenticated client access to puppetca.getcert https://projects.puppetlabs.com/issues/2159#change-80213 Author: Scott Briggs Status: Accepted Priority: Normal Assignee: Category: usability Target version: Affected Puppet version: 0.24.8 Keywords: Branch: We started getting the following error messages on our puppetmaster after I changed the name of one of our servers: Apr 14 14:49:09 puppet-server puppetmasterd[32314]: Allowing unauthenticated client localhost(127.0.0.1) access to puppetca.getcert It turns out this was caused by the fact that I hadn't signed the cert for the server with the new name. The error message is not helpful at all, it should have the name of the server that's trying to authenticate, not localhost. Thanks, Scott -- 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 #2237] puppetd sometimes does not create $yamlclientdir automatically
Issue #2237 has been updated by Andrew Parker. Target version deleted (2.7.x) Bug #2237: puppetd sometimes does not create $yamlclientdir automatically https://projects.puppetlabs.com/issues/2237#change-80214 Author: Derek Whayman Status: Accepted Priority: Normal Assignee: Category: executables Target version: Affected Puppet version: 0.25.0 Keywords: Branch: Workaround's quite obvious :-) Cheers, Derek -- 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 #2251] cron provider doesn't correctly employ user property for resource existence checks.
Issue #2251 has been updated by Andrew Parker.
Target version deleted (2.7.x)
Bug #2251: cron provider doesn't correctly employ user property for resource
existence checks.
https://projects.puppetlabs.com/issues/2251#change-80215
Author: Marc Fournier
Status: Accepted
Priority: Normal
Assignee:
Category: cron
Target version:
Affected Puppet version: 0.24.8
Keywords: cron
Branch:
If I change the user parameter of a cron{} resource, the previous user will
still have the cron listed in his crontab.
Assuming the resource name stays the same, I would have expected changing the
user parameter to be as transparent as changing hour, minute, etc.
This is a possible workaround, but it may not be desirable in every case:
pre
resource { cron: purge = true }
/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 - Bug #2309] Defined resources are not evaluated immediately which can cause ordering problems
Issue #2309 has been updated by Andrew Parker.
Target version deleted (2.7.x)
Bug #2309: Defined resources are not evaluated immediately which can cause
ordering problems
https://projects.puppetlabs.com/issues/2309#change-80216
Author: Ohad Levy
Status: Accepted
Priority: Normal
Assignee:
Category: language
Target version:
Affected Puppet version: 0.24.8
Keywords:
Branch:
Because defined resources are queued as they're defined, and only evaluated
when all other work is done, we can see ordering issues. In the example below,
the two classes are evaluated to the level of the defined resource, and then
stopped. This results in the variable modification in the defined resource not
getting called until after the template is evaluated.
The correct behaviour should see the defined resource getting evaluated as soon
as it is added to the catalog, rather than queueing it for later.
original description:
it seems that templates ignore variable scopes, consider this code:
pre
node default {
include a
include b
}
class a {
$dirs =
dir{[/tmp,/tmp/a,/tmp/b]: before = File[/tmp/dirs]}
}
class b {
file{/tmp/dirs: content = $a::dirs}
#file{/tmp/dirs: content = template(/tmp/dirs.erb)}
}
define dir() {
$a::dirs += $name
file {$name: ensure = directory }
}
/pre
using template the output of the file is , but when dumping the variable
directly, the content is correct.
--
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 - Refactor #2326] Update or replace event-loop
Issue #2326 has been updated by Andrew Parker. Target version deleted (2.7.x) Refactor #2326: Update or replace event-loop https://projects.puppetlabs.com/issues/2326#change-80217 Author: James Turnbull Status: Accepted Priority: Normal Assignee: Category: plumbing Target version: Affected Puppet version: 0.24.8 Keywords: Branch: Puppet currently uses event-loop as an external library to provide the client wakeup loop (http://www.brockman.se/software/ruby-event-loop/event-loop-0.3/ChangeLog). The event-loop library has gone through three releases since we merged it. We should: a. Update the library to the current version b. Replace the external library with internal code. Preference is b. -- 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 #2350] Aptitude Provider installs newest version when it can't find the specified one, also doesn't detect several errors
Issue #2350 has been updated by Andrew Parker. Target version deleted (2.7.x) Bug #2350: Aptitude Provider installs newest version when it can't find the specified one, also doesn't detect several errors https://projects.puppetlabs.com/issues/2350#change-80218 Author: Clarence Tso Status: Accepted Priority: Normal Assignee: Category: package Target version: Affected Puppet version: 0.24.8 Keywords: aptitude provider package version Branch: While using the Aptitude provider, I found that if you specify a version that Aptitude can't find, it tells you this but then just goes ahead and installs the latest version. I fixed this by making a dry run to install the package and then checking whether it could find it or not, throwing a Puppet error if it can't find the version. The dry run is necessary, or else aptitude would install it before we can detect that the wrong version was installed. On a related note, I also added extra stdout checks to look for cases of unmet dependencies and 404's from the user's sources. These are all problems I ran into when using the Aptitude provider. With these fixes, the user is less likely to think that the package was installed when it wasn't (due to uncaught errors), and will also be assured of what package version they are using. I've submitted my git patch. I originally did this in subversion (just started using git, total nub in that respect) based on puppet-latest.tgz (got 0.24.8), but figured a git patch would be more appropriate, so I forked + cloned lak/puppet/, made the changes there, and created the patch. I don't have tests, but I've been using the puppet-latest.tgz-modified version on my production servers for the last month. -- 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 #2352] ssh_authorized_key can create files it can't parse
Issue #2352 has been updated by Andrew Parker. Target version deleted (2.7.x) Bug #2352: ssh_authorized_key can create files it can't parse https://projects.puppetlabs.com/issues/2352#change-80219 Author: Kjetil Torgrim Homme Status: Accepted Priority: Normal Assignee: Category: ssh Target version: Affected Puppet version: 0.24.8 Keywords: Branch: I have put all the keys in individual text files, and used template() to fetch the value and pass to ssh_authorized_key's key attribute. The problem with this is that my text files contains a trailing newline[1], and this newline was copied verbatim into the resulting file, so it became ssh-rsa B3NzaC1y...ojH2ZMvF+Efw== kjetilho@puppet That is, it was split across two lines. On the next run, ssh_authorized_key aborts since the file contains a syntax error...[2] In any case, Puppet should never generate files it can't handle, so there are two options IMHO: 1) strip whitespace from key before writing it to file. drop the resource processing if it's not valid base64. 2) drop the resource processing if it's not valid base64. I think my usecase of putting the keys in individual files is common enough that whitespace trimming should be done. It would also allow splitting inline values into multi-line strings. Workaround: use regsubst() to remove the newline from the templated value. [1] I really don't like text files with no terminating newline, it makes diff slightly unhappy etc. [2] The parser is very fickle in general, it bombs on empty lines, too. Please fix that when you're at it, not worth a separate issue I think :) -- 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 #2384] Provider features are validated at instantiation rather than run time
Issue #2384 has been updated by Andrew Parker.
Target version deleted (2.7.x)
Bug #2384: Provider features are validated at instantiation rather than run time
https://projects.puppetlabs.com/issues/2384#change-80220
Author: Oliver Hookins
Status: Accepted
Priority: High
Assignee: eric sorenson
Category: RAL
Target version:
Affected Puppet version: 0.24.8
Keywords: usability
Branch:
I'm attempting to do the following:
1. Install ruby-shadow
2. Create a user account (with a password)
Unfortunately puppet tends to screw up the order. Here's the test manifest:
pre
package { ruby-shadow: ensure = installed; }
user { testdude:
ensure = present,
gid = users,
password = '$1$loo03Rez$MfxLF/9uMeaeOPCtceYGc0',
require = Package[ruby-shadow],
comment = test account;
}
/pre
Puppet checks for the account's presence before anything, and complains about
ruby-shadow not being there. IMHO it shouldn't even care about checking
anything to do with the account, since I have specified a prerequisite. Anyway,
it installs ruby-shadow, then creates the account *without a password* despite
ruby-shadow now being on the system. It takes a second run of puppet to set the
password, which is really not ideal.
Here's the output with debugging and verbose:
pre
[root@test ~]# puppet -d -v test.pp
debug: Puppet::Type::Package::ProviderRpm: Executing '/bin/rpm --version'
debug: Puppet::Type::Package::ProviderUrpmi: Executing '/bin/rpm -ql rpm'
debug: Puppet::Type::Package::ProviderAptrpm: Executing '/bin/rpm -ql rpm'
debug: Puppet::Type::Package::ProviderYum: Executing '/bin/rpm --version'
debug: Failed to load library 'shadow' for feature 'libshadow'
debug: Puppet::Type::Package::ProviderAptitude: file /usr/bin/aptitude does not
exist
debug: Puppet::Type::Package::ProviderPkgdmg: file /Library/Receipts does not
exist
debug: Puppet::Type::Package::ProviderFreebsd: file /usr/sbin/pkg_delete does
not exist
debug: Puppet::Type::Package::ProviderSun: file /usr/sbin/pkgrm does not exist
debug: Puppet::Type::Package::ProviderEasy_install: file easy_install does not
exist
debug: Puppet::Type::Package::ProviderAppdmg: file /Library/Receipts does not
exist
debug: Puppet::Type::Package::ProviderHpux: file /usr/sbin/swinstall does not
exist
debug: Puppet::Type::Package::ProviderOpenbsd: file pkg_delete does not exist
debug: Puppet::Type::Package::ProviderPorts: file /usr/local/sbin/pkg_deinstall
does not exist
debug: Puppet::Type::Package::ProviderGem: file gem does not exist
debug: Puppet::Type::Package::ProviderSunfreeware: file pkg-get does not exist
debug: Puppet::Type::Package::ProviderDarwinport: file /opt/local/bin/port does
not exist
debug: Puppet::Type::Package::ProviderFink: file /sw/bin/fink does not exist
debug: Puppet::Type::Package::ProviderRug: file /usr/bin/rug does not exist
debug: Puppet::Type::Package::ProviderApple: file /Library/Receipts does not
exist
debug: Puppet::Type::Package::ProviderAptrpm: file apt-get does not exist
debug: Puppet::Type::Package::ProviderApt: file /usr/bin/apt-get does not exist
debug: Puppet::Type::Package::ProviderUrpmi: file urpmi does not exist
debug: Puppet::Type::Package::ProviderUp2date: file /usr/sbin/up2date-nox does
not exist
debug: Puppet::Type::Package::ProviderDpkg: file /usr/bin/dpkg does not exist
debug: Puppet::Type::Package::ProviderPortage: file /usr/bin/emerge does not
exist
debug: Puppet::Type::User::ProviderUser_role_add: file roleadd does not exist
debug: Puppet::Type::User::ProviderPw: file pw does not exist
debug: Puppet::Type::User::ProviderLdap: true value when expecting false
debug: Puppet::Type::User::ProviderNetinfo: file nireport does not exist
debug: Puppet::Type::User::ProviderDirectoryservice: file /usr/bin/dscl does
not exist
info: /User[testdude]: Provider useradd does not support features
manages_passwords; not managing attribute password
debug: Creating default schedules
debug: Prefetching yum resources for package
debug: Puppet::Type::Package::ProviderYum: Executing '/bin/rpm --version'
debug: Puppet::Type::Package::ProviderYum: Executing '/bin/rpm -qa
--nosignature --nodigest --qf '%{NAME} %|EPOCH?{%{EPOCH}}:{0}| %{VERSION}
%{RELEASE} %{ARCH}
''
debug: /User[testdude]/require: requires Package[ruby-shadow]
debug: Failed to load library 'ldap' for feature 'ldap'
debug: Puppet::Type::Package::ProviderYum: Executing '/bin/rpm -q ruby-shadow
--nosignature --nodigest --qf %{NAME} %|EPOCH?{%{EPOCH}}:{0}| %{VERSION}
%{RELEASE} %{ARCH}
'
debug: //Package[ruby-shadow]: Changing ensure
debug: //Package[ruby-shadow]: 1 change(s)
debug: Package[ruby-shadow](provider=yum): Ensuring = present
debug: Puppet::Type::Package::ProviderYum: Executing '/usr/bin/yum -d 0 -e 0 -y
install ruby-shadow'
debug: Puppet::Type::Package::ProviderYum: Executing '/bin/rpm -q ruby-shadow
--nosignature --nodigest --qf %{NAME} %|EPOCH?{%{EPOCH}}:{0}| %{VERSION}
%{RELEASE} %{ARCH}
'
[Puppet - Bug #2449] ralsh when used with the -e flag implements changes even when the file is not saved.
Issue #2449 has been updated by Andrew Parker. Target version deleted (2.7.x) Bug #2449: ralsh when used with the -e flag implements changes even when the file is not saved. https://projects.puppetlabs.com/issues/2449#change-80221 Author: Teyo Tyree Status: Accepted Priority: Normal Assignee: Category: executables Target version: Affected Puppet version: 0.24.8 Keywords: Branch: Executing ralsh with the -e flag allows the user to edit a resources' parameters using a text editor. Unfortunately, ralsh will implement changes even if the text file is not saved. This is counter intuitive and could cause users to unintentionally make changes on a live system. -- 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 #2471] Puppet.warning doesn't work with a hook in defaults.rb
Issue #2471 has been updated by Andrew Parker.
Target version deleted (2.7.x)
Bug #2471: Puppet.warning doesn't work with a hook in defaults.rb
https://projects.puppetlabs.com/issues/2471#change-80222
Author: Nigel Kersten
Status: Code Insufficient
Priority: Low
Assignee:
Category: plumbing
Target version:
Affected Puppet version: 0.25.0
Keywords:
Branch:
If you try to add a Puppet.warning to a hook in defaults.rb, like:
pre
:reportserver = {
:default = $server,
:desc = (Deprecated) The server to which to send transaction
reports.,
:call_on_define = true,
:hook = proc { |value|
if value
$stderr.puts This works
Puppet.warning This will not.
Puppet.settings[:report_server] = value
end
}
},
/pre
you get:
pre
/Library/Ruby/Site/1.8/puppet/util/log.rb:517:in `source=': uninitialized
constant Puppet::Type (NameError)
/pre
I notice :cacrl is using a Puppet.warning in a hook and is subject to the same
issue.
--
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 #2476] The --test option to puppetd is very confusing (and sometimes dangerous)
Issue #2476 has been updated by Andrew Parker. Target version deleted (2.7.x) Bug #2476: The --test option to puppetd is very confusing (and sometimes dangerous) https://projects.puppetlabs.com/issues/2476#change-80223 Author: Ben Hearsum Status: Investigating Priority: Normal Assignee: Nigel Kersten Category: executables Target version: Affected Puppet version: 0.24.8 Keywords: Branch: The --test option to puppetd is commonly and easily assumed to be show me what changes you WOULD make if run without --test. For people new to Puppet, it's very easy to make this mistake and sync up with the master before you intend to. I think it would be much better to call it something else. -- 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 #2500] puppetmaster should not load certs when not running under webrick
Issue #2500 has been updated by Andrew Parker. Target version deleted (2.7.x) Bug #2500: puppetmaster should not load certs when not running under webrick https://projects.puppetlabs.com/issues/2500#change-80224 Author: Ohad Levy Status: Accepted Priority: Normal Assignee: Category: SSL Target version: Affected Puppet version: 0.25.0rc1 Keywords: Branch: when running with puppetca false option, the following is observed on a client: pre err: Could not retrieve catalog from remote server: Error 500 on SERVER: Internal Server Error /pre and on the server: pre 1.2.3.4 - - [05/Aug/2009:13:44:02 +0800] GET /development/certificate_revocation_list/ca HTTP/1.1 500 9451 - - Aug 5 13:44:11 hostname puppetd[23354]: Could not retrieve catalog from remote server: Error 500 on SERVER: Internal Server Error /pre this happens when running the puppetmaster and puppetd on the same machine. -- 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 #2555] Problem when ignored files change timestamp of (recursively) copied directory
Issue #2555 has been updated by Andrew Parker.
Target version deleted (2.7.x)
Bug #2555: Problem when ignored files change timestamp of (recursively) copied
directory
https://projects.puppetlabs.com/issues/2555#change-80226
Author: Sven Mueller
Status: Accepted
Priority: Normal
Assignee:
Category: file
Target version:
Affected Puppet version: 0.24.8
Keywords:
Branch:
Opening a bug as requested.
Luke Kanies wrote:
On Aug 12, 2009, at 5:28 AM, Sven Mueller wrote:
Hi.
I'm wondering wether the following is expected behaviour (and if so,
wether it can be disabled):
I have
/etc/puppet/files/httpd/f.q.d.n/conf.d
which contains a few conf.d files per host that need to be copied to
the
server. The /etc/puppet/files (and all subdirectories of course) is
managed with subversion and thus (now) contains a .svn subdirectory.
Situation is that on the server, /etc/httpd/conf.d has been updated
and
after that, the respective conf.d directory has been added/committed
to
subversion. Now the situation looks like this:
On the server:
~ # ls -la /etc/httpd/conf.d
total 96
drwxr-xr-x 2 root root 4096 Aug 5 14:06 .
drwxr-xr-x 4 root root 4096 Jul 30 15:31 ..
-rw-r--r-- 1 root root 4090 Aug 5 11:58 risk.conf
-rw-r--r-- 1 root root 6933 Aug 5 10:33 risk.inc
On the puppet master:
# ls -la conf.d/
total 24
drwxr-xr-x 3 puppet root 4096 Aug 10 09:26 .
drwxr-xr-x 4 puppet root 4096 Aug 10 09:26 ..
-rw-r--r-- 1 puppet root 4090 Aug 5 11:50 risk.conf
-rw-r--r-- 1 puppet root 6933 Aug 5 10:22 risk.inc
drwxr-xr-x 6 puppet root 4096 Aug 10 09:27 .svn
As you can see, the .svn and . on the puppet master are newer than on
the puppet client.
File type is set up to use checksum=md5 and ignore=.svn (among
others).
There is a Service[httpd] (its a RHEL5 or CentOS5 server) subscribed
to File[/etc/httpd/conf.d]. Now each time puppetd is running on the
server (we don't let it run as a service, but run it manually with
--test), it shows something along the lines of:
notice: //Node[web_node]/httpd/File[/etc/httpd/conf.d]/checksum: is
{mtime}Wed Aug 05 14:06:12 +0200 2009, should be time (noop)
info: //Node[web_node]/httpd/File[/etc/httpd/conf.d]: Scheduling
refresh
of Service[httpd]
notice: //Node[sn_web_node]/httpd/Service[httpd]: Would have triggered
refresh from 1 dependencies
This can be avoided by touching /etc/httpd/conf.d on the server, but I
think that:
1) If puppet thinks the newer mtime of the directory on the puppet
server should cause the httpd service to be refreshed, that it
should
update the mtime of that directory on the server in the same run (as
to avoid repeatedly refreshing the service).
2) Alternatively (and in my humble opinion this should be preferred),
only actual changes while processing the File resource should
trigger
the Service resource to be refreshed.
Now: Is the stuff I described above expected behaviour of puppet? If
so:
Can I change it somehow? If not: Is there a workaround other than
manually touching the directory on the server? And: Is there a fix
that corrects the behaviour to act more along the lines of the two
alternatives listed above?
Hmm, this seems like a bug that would only be encountered when files
you're ignoring are causing the directory's timestamp to be modified.
Normally that newer file would get copied to the client, which would
update the local timestamp.
Can you file this as a bug?
--
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 #2556] rrdgraph only holds data for 6.25days in rrd dbs
Issue #2556 has been updated by Andrew Parker. Target version deleted (2.7.x) Bug #2556: rrdgraph only holds data for 6.25days in rrd dbs https://projects.puppetlabs.com/issues/2556#change-80227 Author: Michael Gebetsroither Status: Accepted Priority: Normal Assignee: Category: reports Target version: Affected Puppet version: 0.24.5 Keywords: Branch: hi, i've enabled rrdgraph a few weeks agoand it works great But the graphs created by puppet never show data beyond about one week. I've looked at the .rrd db files and they are set up to contain 300 samples, with the normal 30min interval. Whichs gives about 6.25days and seems to be correct. So it would be nice to not only create graphs for montly and beyond data, but also record the needed samples in the db. I'm really no ruby programmer, but it should be lib/puppet/util/metrics.rb line 40 and 42: def create(start = nil) ... args.push DS:%s:GAUGE:7200:U:U % [value[0]] and args.push RRA:AVERAGE:0.5:1:300 software versions: puppet 0.24.5-3 (debian lenny) RRDtool http://rubyrrdtool.rubyforge.org/ with own patch to get it working with librrd-dev 1.3 patch is at: http://github.com/gebi/rubyrrdtool/commit/dace968eee0c323076f1004f494b525176faac02 greets, michael -- 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 - Refactor #2586] Stacktrace printing should work on Passenger
Issue #2586 has been updated by Andrew Parker. Target version deleted (2.7.x) Refactor #2586: Stacktrace printing should work on Passenger https://projects.puppetlabs.com/issues/2586#change-80228 Author: Luke Kanies Status: Accepted Priority: Normal Assignee: Category: plumbing Target version: Affected Puppet version: 0.24.8 Keywords: Branch: Most likely, this means building a stack printing service that sends everything to the logs, rather than just printing on stdout as is done now. This also means going through all of the code and fixing the existing calls to print traces. It might make sense to, at the same time, refactor our error handling a bit - we currently don't create specific error classes for the various places we raise errors, and if we did, we could probably have the error creation automatically produce stack traces as appopriate. This would itself be a good bit of work so should probably be considered separately, but it's at least worth considering. -- 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 - Refactor #2623] authstore.rb needs to be refactored
Issue #2623 has been updated by Andrew Parker. Target version deleted (2.7.x) Refactor #2623: authstore.rb needs to be refactored https://projects.puppetlabs.com/issues/2623#change-80229 Author: Markus Roberts Status: Accepted Priority: Normal Assignee: Category: network Target version: Affected Puppet version: 0.24.8 Keywords: Branch: As noted in #2620, #2570, #2531 the authstore.rb system of storing patterns as a reversed array of munged segments is needlessly complex and leads to bulky code with error prone edge cases. It needs to be replaced with something simpler. -- 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 #2644] defaults.rb should set Puppet[:config] to /etc/puppet/puppet.conf if user is puppet
Issue #2644 has been updated by Andrew Parker. Target version deleted (2.7.x) Bug #2644: defaults.rb should set Puppet[:config] to /etc/puppet/puppet.conf if user is puppet https://projects.puppetlabs.com/issues/2644#change-80230 Author: defunt Bode Status: Accepted Priority: Normal Assignee: Category: package Target version: Affected Puppet version: 0.24.8 Keywords: Branch: The below code from defaults.rb always sets the puppet.conf location to be ~/.puppet/puppet.conf for the puppet user (who is also the calling user for external node classifiers). This makes it impossible to use the parse_config call to grab config information in the node classifier. as a work around, I had to do the following #ln -s /etc/puppet/puppet.conf /root/.puppet/puppet.conf pre if name != puppetmasterd and Puppet::Util::SUIDManager.uid != 0 conf = File.expand_path(~/.puppet) var = File.expand_path(~/.puppet/var) else conf = /etc/puppet var = /var/puppet end /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 - Bug #2701] Memory Leak in Puppet state
Issue #2701 has been updated by Andrew Parker.
Target version deleted (2.7.x)
Bug #2701: Memory Leak in Puppet state
https://projects.puppetlabs.com/issues/2701#change-80231
Author: Greg Boug
Status: Accepted
Priority: Normal
Assignee:
Category: plumbing
Target version:
Affected Puppet version: 0.24.8
Keywords:
Branch:
I have a puppet daemon running tidy to clean up a very busy directory (cleans
several thousand files each week). Using a tidy object:
tidy { /tps/reports:
age = 1d,
recurse = true,
rmdirs = true,
loglevel = info,
type = mtime,
}
The tidy works well, but every file gets recorded into state.yaml, even the
ones that were removed several months ago. When Puppet reads in this yaml file
it gets progressively bigger which consumes a significant chunk of memory on
the host (I just killed a Puppet daemon with approx 900Mb resident,
for example - this had been running approx. 2 weeks)
My workaround for now is that I wipe the state.yaml file and restart puppet
periodically - usually every couple of weeks or so... Another workaround I have
is to run the attached script periodically and restart puppet. The script culls
all references to Tidy objects from the database - preserving the rest of the
state database.
--
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 #3014] Make tmp directory location specifiable through the config file
Issue #3014 has been updated by Andrew Parker. Target version deleted (2.7.x) Feature #3014: Make tmp directory location specifiable through the config file https://projects.puppetlabs.com/issues/3014#change-80233 Author: Digant Kasundra Status: Accepted Priority: Low Assignee: Category: Target version: Affected Puppet version: 0.25.2 Keywords: Branch: We have a need to have puppet use a different tmp directory and wish for a way to specify that in the config file. -- 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 #3034] puppetdoc -r TYPE NAME would be useful
Issue #3034 has been updated by Andrew Parker. Target version deleted (2.7.x) Feature #3034: puppetdoc -r TYPE NAME would be useful https://projects.puppetlabs.com/issues/3034#change-80234 Author: Dan Bode Status: Accepted Priority: Normal Assignee: Category: documentation Target version: Affected Puppet version: 0.25.2 Keywords: Branch: being able to generate documents for specific types would be useful. pre #puppetdoc -r type file /pre should just output docs for the file resource pre #puppetdoc -r function template /pre should ouput the docs for this function currently these print everything, this is too much info to be useful. filtering it could actually make it useful. -- 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 #3047] Cron entries using special parameter lose their title when changed
Issue #3047 has been updated by Andrew Parker.
Target version deleted (2.7.x)
Bug #3047: Cron entries using special parameter lose their title when changed
https://projects.puppetlabs.com/issues/3047#change-80235
Author: James Turnbull
Status: Needs Decision
Priority: Normal
Assignee: Daniel Pittman
Category: cron
Target version:
Affected Puppet version: 0.25.2
Keywords: cron special
Branch: http://github.com/jes5199/puppet/tree/ticket/0.25.x/3047
When using a special parameter (e.g @reboot ...) to create a cron entry the
entry is added to with a title comment # Puppet Name: ... just like a regular
entry. However when the entry is modified the comment is dropped. Because there
is no longer a comment title if the entry is modified again, instead of
replacing the old line, it will add a new line complete with comment. The old
line is now left orphaned.
Example:
pre
cron{ test:
command = /bin/echo One /tmp/puppet.txt,
special = reboot,
}
/pre
gives:
pre
# Puppet Name: test
@reboot /bin/echo One /tmp/puppet.txt
/pre
changing to:
pre
cron{ test:
command = /bin/echo Two /tmp/puppet.txt,
special = reboot,
}
/pre
gives:
pre
@reboot /bin/echo Two /tmp/puppet.txt
/pre
changing again to:
pre
cron{ test:
command = /bin/echo Three /tmp/puppet.txt,
special = reboot,
}
/pre
gives:
pre
@reboot /bin/echo Two /tmp/puppet.txt
# Puppet Name: test
@reboot /bin/echo Three /tmp/puppet.txt
/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 #3119] puppet config file syntax errors
Issue #3119 has been updated by Andrew Parker. Target version deleted (2.7.x) Feature #3119: puppet config file syntax errors https://projects.puppetlabs.com/issues/3119#change-80236 Author: Lucas Suggs Status: Accepted Priority: Normal Assignee: Category: error reporting Target version: Affected Puppet version: 0.25.3 Keywords: Branch: Currently when puppet.conf has a syntax error (e.g. missing an = sign), it does not state that there is an error with the config file, it simply uses a default built-in config and it usually breaks (and causes a lot of head scratching and confusion). Can there please be a Your config file has an error on line: blah printed out when the config is wrong? I'm sure this would help save a lot of confusion. Thanks, Lucas -- 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 #3129] Problem using a number as as class name
Issue #3129 has been updated by Andrew Parker. Target version deleted (2.7.x) Bug #3129: Problem using a number as as class name https://projects.puppetlabs.com/issues/3129#change-80237 Author: Mike Culbertson Status: Accepted Priority: Normal Assignee: Category: RAL Target version: Affected Puppet version: 0.25.3 Keywords: Branch: I've run into what looks like a bug when using a number as a class name in a nested class. There are no errors while parsing the class itself, but when the manifest gets to the point where I actually include the class, this happens: pre err: Could not parse for environment development: Syntax error at ':'; expected '}' at /etc/puppet/development/modules/sol/manifests/init.pp:77 /pre The include line is: pre include sol::network::10 /pre If I double-quote the class name, the error does not occur. I've attached debug+trace logs from puppetd, puppetmasterd and a (slightly redacted) copy of the init.pp from the module in question. This is the only manifest in this particular module. However, I do have numeric class names elsewhere in other modules, and they all erorred out the same way until I quoted the class names, so it does not appear to be unique to this module or class. TIA -Mike -- 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 #3131] Cannot restrict access to single module in fileserver.conf
Issue #3131 has been updated by Andrew Parker. Target version deleted (2.7.x) Bug #3131: Cannot restrict access to single module in fileserver.conf https://projects.puppetlabs.com/issues/3131#change-80238 Author: Hari Sekhon Status: Accepted Priority: Normal Assignee: Category: modules Target version: Affected Puppet version: 0.24.8 Keywords: Branch: My fileserver.conf looks like: [modulename] /etc/puppet/modules/modulename allow x.x.x.x [modules] allow y.y.y.y/23 I want to restrict access to modulename to just the one server that needs it, x.x.x.x, such that all the other servers that do not require access to the module contents, especially the files, are prevented from fetching them. However, this currently does not work properly at all. A server on another ip still has full access to the module's contents. Possibly this is because it's still getting in through the [modules] section after failing the [modulename] section I don't know. If so it might be a very simple fix to simply stop at the first match. -- 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 #3140] Hostnames is puppetmaster logs
Issue #3140 has been updated by Andrew Parker. Target version deleted (2.7.x) Feature #3140: Hostnames is puppetmaster logs https://projects.puppetlabs.com/issues/3140#change-80240 Author: Daniel Kerwin Status: Accepted Priority: Normal Assignee: Category: Target version: Affected Puppet version: 0.25.4 Keywords: Branch: It would be great if the systems name shows up in the puppetmaster's log. I only use puppetrun and look at the puppetmaster's log to review the results. It's impossible to determine which node caused a specific message. I'd love something like this: pre puppetmasterd[8918]: (//mysql/Service[mysql]) Triggering 'refresh' from 1 dependencies /pre to pre puppetmasterd[8918]: (host123//mysql/Service[mysql]) Triggering 'refresh' from 1 dependencies /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 #3138] Improve procedure for enabling rspec tests in modules
Issue #3138 has been updated by Andrew Parker. Target version deleted (2.7.x) Feature #3138: Improve procedure for enabling rspec tests in modules https://projects.puppetlabs.com/issues/3138#change-80239 Author: Mike Pountney Status: Accepted Priority: Normal Assignee: Category: testing Target version: Affected Puppet version: 0.25.4 Keywords: rspec Branch: I'm logging this at the request of James Turnbull: I've recently started on my first puppet custom type/provider, and decided to try to do this a) in a module, and b) with rspec tests. I was able to get spec tests running, but with quite a bit of hackery, copying files from the main puppet repo: spec/spec_helper.rb test/lib test/lib/puppettest test/lib/puppettest/certificates.rb test/lib/puppettest/exetest.rb test/lib/puppettest/fakes.rb test/lib/puppettest/fileparsing.rb test/lib/puppettest/filetesting.rb test/lib/puppettest/parsertesting.rb test/lib/puppettest/railstesting.rb test/lib/puppettest/reporttesting.rb test/lib/puppettest/resourcetesting.rb test/lib/puppettest/runnable_test.rb test/lib/puppettest/servertest.rb test/lib/puppettest/support test/lib/puppettest/support/assertions.rb test/lib/puppettest/support/collection.rb test/lib/puppettest/support/helpers.rb test/lib/puppettest/support/resources.rb test/lib/puppettest/support/utils.rb test/lib/puppettest/support.rb test/lib/puppettest/testcase.rb test/lib/puppettest.rb Honestly, I haven't worked out which of these libs are totally required, but puppettest.rb is at a minimum. (puppettest/runnable_test.rb seems to be unrequired so far, except for being called in spec_helper.rb) Is there a way that this can be made easier? Developing types in modules seems to be a sensible way to go after all - it should allow folk on any client version to add a new type, rather than requiring they upgrade to puppet-latest. My vcsrepo module (based now on James' tutorial at http://www.kartar.net/2010/02/puppet-types-and-providers-are-easy/ btw) is located at: http://github.com/mikepea/puppet-git Naturally, i'm more than happy to help with this work, but my knowledge of the puppet codebase and Rspec framework is very limited. -- 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 #3362] splay drift occurs when passenger/mongrel get too much load.
Issue #3362 has been updated by Andrew Parker. Target version deleted (2.7.x) Bug #3362: splay drift occurs when passenger/mongrel get too much load. https://projects.puppetlabs.com/issues/3362#change-80241 Author: Dan Bode Status: Needs More Information Priority: Low Assignee: Nigel Kersten Category: plumbing Target version: Affected Puppet version: 0.25.4 Keywords: passenger load splay mongrel connection timeouts Branch: http://github.com/MarkusQ/puppet/tree/ticket/0.25.x/3362 not sure if this counts as a bug... I could not concretely prove the assumptions below. I did some investigation and this is my best guess as to the cause. Splay was drifting for hundreds of machines so that over time, most were checking in at the same time, while at other times none were checking in. here is my theory as to why. splay only runs the first time after puppet starts. Assumption: runinterval starts counting only after the client finishes its last run? Here is the chain of events that I think causes this: 1. passenger or mongrel is under heavy load. 2. processes get used up, they start queuing hosts. 3. Once a machine falls into the queue, it gets stuck with the group of machines that cause the queue to fill up, since it will now use runinterval and check in at the same time as the other machines that were running at that same time. 4. Over time, splay drifts so that most machines are checking in at the same time. Basically, once performance starts getting bad, the splaying falls apart so that it gets much worse. -- 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 #3371] FileBucket should not keep files in memory
Issue #3371 has been updated by Andrew Parker. Target version deleted (2.7.x) Feature #3371: FileBucket should not keep files in memory https://projects.puppetlabs.com/issues/3371#change-80242 Author: Jesse Wolfe Status: Accepted Priority: Normal Assignee: Category: plumbing Target version: Affected Puppet version: development Keywords: Branch: It should not be necessary to load entire files into memory to checksum them. -- 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 #3571] require function should be able to require more than just classes.
Issue #3571 has been updated by Andrew Parker.
Target version deleted (2.7.x)
Bug #3571: require function should be able to require more than just classes.
https://projects.puppetlabs.com/issues/3571#change-80243
Author: Nigel Kersten
Status: Accepted
Priority: Normal
Assignee:
Category: functions
Target version:
Affected Puppet version: 0.25.4
Keywords:
Branch:
The require function only works with classes.
It should be called require_class in that case.
This isn't at all transparent to read:
pre
class one {
require(two)
...
}
/pre
I naively expected the syntax to look like:
pre
class one {
require(Class[two])
...
}
/pre
and to be able to require any kind of object, but given this function can only
require classes, I suggest this would be a big improvement.
pre
class one {
require_class(two)
...
}
/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 #3764] Add fail parameter to notify resource
Issue #3764 has been updated by Andrew Parker.
Target version deleted (2.7.x)
Feature #3764: Add fail parameter to notify resource
https://projects.puppetlabs.com/issues/3764#change-80244
Author: Alan Barrett
Status: Requires CLA to be signed
Priority: Normal
Assignee: Alan Barrett
Category: functions
Target version:
Affected Puppet version: 0.25.4
Keywords:
Branch:
I often want a puppet manifest to result in an error on the client. This is
useful for marking to do items, where users should be reminded of
shortcomings in the manifest.
I have added a fail parameter to the notify resource. Usage is as follows:
pre
notify { Feature X is not yet implemented:
fail = true,
}
/pre
I attach a patch to implement this feature, but I have not added test cases.
It would be nice to have onlyif and unless parameters, but I have not
implemented those.
--
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 #3942] inadequate error messages for malformed host types
Issue #3942 has been updated by Andrew Parker.
Target version deleted (2.7.x)
Bug #3942: inadequate error messages for malformed host types
https://projects.puppetlabs.com/issues/3942#change-80245
Author: seph seph
Status: Accepted
Priority: Normal
Assignee:
Category: error reporting
Target version:
Affected Puppet version: 0.25.4
Keywords:
Branch:
When puppet encounters a malformed host type, say because the variable for the
ip address is unassigned, it produces a hard to debug error messages. Using
lucid, and the puppet packaged for it:
root@dell-r610-4v0hsl1:~# cat /tmp/host.pp
host{ test:
ip = ,
}
root@dell-r610-4v0hsl1:~# puppet --version
0.25.4
root@dell-r610-4v0hsl1:~# puppet -v /tmp/host.pp
info: Loading facts in acpi_available
info: Loading facts in interfaces
Parameter ip failed: Invalid IP address
I'd really like to see the name of the offending file, and the line. And
something me it was a host type.
This bug feels pretty much identical to #2633 (which I created awhile ago).
Which makes me think there's a meta issue around error messages, and not just
these ad hoc bugs. Judging from the diff in #2633, this ends up being related
to raising errors, and not calling self.fail? But I'm kinda grasping at straws.
I suspect someone with more ruby and puppet internals knowledge could grep for
cases of this.
--
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 #3950] Service notifies should be able to specify a type of restart/reload
Issue #3950 has been updated by Andrew Parker. Target version deleted (2.7.x) Feature #3950: Service notifies should be able to specify a type of restart/reload https://projects.puppetlabs.com/issues/3950#change-80246 Author: R.I. Pienaar Status: Accepted Priority: Normal Assignee: Category: service Target version: Affected Puppet version: 0.25.5 Keywords: Branch: At puppetcamp we discussed a scenario where you sometimes want to reload a service and sometimes want to restart it when sending a notify to a Service resource. An example would be reload bind just for adding new zones, but restart bind when changing major config options like what address to listen on. Or reload apache for new vhosts but restart it for changes to the main config. We didnt seem to come to conclusion if this should be a meta ability for all resources or just service - I am not sure where else it would make sense. But everyone did agree it would be an important feature to have. -- 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 #3982] please make config_version available as a variable
Issue #3982 has been updated by Andrew Parker. Target version deleted (2.7.x) Feature #3982: please make config_version available as a variable https://projects.puppetlabs.com/issues/3982#change-80247 Author: R.I. Pienaar Status: Accepted Priority: Normal Assignee: Category: plumbing Target version: Affected Puppet version: 0.25.5 Keywords: Branch: please make the value set by the config_version script available to manifests as a variable, would be useful to put this in motd's or something. -- 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 #4007] 'puppetca' needs feature to remove (/revoke) a pending certificate signing request
Issue #4007 has been updated by Andrew Parker. Target version deleted (2.7.x) Bug #4007: 'puppetca' needs feature to remove (/revoke) a pending certificate signing request https://projects.puppetlabs.com/issues/4007#change-80248 Author: Tore L. Status: Accepted Priority: Normal Assignee: Daniel Pittman Category: SSL Target version: Affected Puppet version: 0.25.5 Keywords: signing Branch: It is not possible to remove a pending certificate signing request with 'puppetca --revoke $fqdn': pre [root@X puppet]# puppetca --list rhel32bit.x.local [root@X puppet]# puppetca --revoke rhel32bit.x.local rhel32bit.x.local notice: Revoked certificate with serial # Inventory of signed certificates err: Could not call revoke: Cannot convert into OpenSSL::BN /pre You have to remove the certificate signing request manually. 'puppetca' should (IMO) do this. -- 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 #4068] Native Type for linux sysctl interface
Issue #4068 has been updated by Andrew Parker. Target version deleted (2.7.x) Feature #4068: Native Type for linux sysctl interface https://projects.puppetlabs.com/issues/4068#change-80249 Author: Thomas Hatch Status: In Topic Branch Pending Review Priority: Low Assignee: Thomas Hatch Category: Target version: Affected Puppet version: development Keywords: communitypatch Branch: http://groups.google.com/group/puppet-dev/browse_thread/thread/ba9b7b281a8e6c4d/94de927d1df6f5f3?hl=enlnk=gstq=4068#94de927d1df6f5f3 I have run into many deployments that manage sysctl using the file type, a native sysctl type will greatly add to deployment modularity. -- 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 #4072] Add remove/uninstall feature to zypper.rb
Issue #4072 has been updated by Andrew Parker. Target version deleted (2.7.x) Feature #4072: Add remove/uninstall feature to zypper.rb https://projects.puppetlabs.com/issues/4072#change-80250 Author: christian c Status: Accepted Priority: Normal Assignee: Category: provider Target version: Affected Puppet version: 0.25.4 Keywords: devtriage Branch: If the forthcomming zypper-provider only supports to install packages it may come to such situations: zypper install -y sendmail Loading repository data... Reading installed packages... Resolving package dependencies... Problem: exim-4.69-70.13.x86_64 conflicts with sendmail provided by sendmail-8.14.3-50.9.i586 Solution 1: deinstallation of exim-4.69-70.13.x86_64 Solution 2: do not ask to install a solvable providing sendmail Choose from above solutions by number or cancel [1/2/C]: c Puppet will always choose to cancel, so there is no chance to successfully install sendmail. But if you would remove exim with zypper, zypper would automatically install sendmail or postfix. So with some control mechnanism in the puppet manifest it should be possible to install sendmail. I went through some other package-providers to see how they solve the problem and came up with the following for zypper.rb: ### def uninstall zypper :remove, '-y', @resource[:name] end I tested it by executing some puppetruns and packages could be removed successfully - puppetd[ 2088 ]: (//allgemein::sendmail/Package[sendmail]/ensure) removed -- 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 #4138] Puppet needs to complain better about resources with blank names
Issue #4138 has been updated by Andrew Parker.
Target version deleted (2.7.x)
Bug #4138: Puppet needs to complain better about resources with blank names
https://projects.puppetlabs.com/issues/4138#change-80251
Author: Lee Whalen
Status: Accepted
Priority: Normal
Assignee: Daniel Pittman
Category: error reporting
Target version:
Affected Puppet version: 2.7.9
Keywords:
Branch:
I wrote a manifest that had this typo in it:
pre
class ldap_cfg {
File { owner = root,
group = root,
mode = 0644
}
$ldap_packages = [nss_ldap, openldap-clients]
include ldap_cfg::install
include ldap_cfg::config
}
class ldap_cfg::install {
package { $ldap_cfg_packages:
ensure = installed
}
}
/pre
(note how the variable is created as $ldap_packages and references as
$ldap_cfg_packages in the ldap_cfg::install class)
This threw the error err: Could not retrieve catalog from remote server:
Could not intern from pson: Could not convert from pson: Could not find
relationship target Package[], which was not particularly helpful in
tracking the rogue code snippet down. Any chance we could get that tweaked a
little bit?
Many thanks!
--Lee
--
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 #4151] defined function should not return true for unrealized virtual resources
Issue #4151 has been updated by Andrew Parker.
Target version deleted (2.7.x)
Bug #4151: defined function should not return true for unrealized virtual
resources
https://projects.puppetlabs.com/issues/4151#change-80252
Author: Jeff McCune
Status: Accepted
Priority: Normal
Assignee:
Category: functions
Target version:
Affected Puppet version: 0.25.5
Keywords: virtual resource defined realized realize function
Branch:
Description:
The defined() function currently returns true when given a reference to a
resource declared virtually even if the resource has not been realized.
Expected Behavior:
The defined() function should only return true if a resource has been realized.
Actual Behavior:
defined() returns true for unrealized virtual resources
Steps to reproduce:
Acceptance test git branch URI will be added to the ticket once an issue number
is available.
@notify { hello: }
if (defined(Notify[hello])) { $requires = [ Notify[hello] ] }
notify { goodbye: require = $requires }
The expected result of this puppet manifest snippet is that $requires is unset
and therefore Notify[goodbye] has no relationship.
--
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 #4192] Puppet changes permissions on /var/run, causing security spam every night from OpenBSD
Issue #4192 has been updated by Andrew Parker. Target version deleted (2.7.x) Bug #4192: Puppet changes permissions on /var/run, causing security spam every night from OpenBSD https://projects.puppetlabs.com/issues/4192#change-80253 Author: Joe McDonagh Status: Investigating Priority: Normal Assignee: Category: Target version: Affected Puppet version: 0.25.4 Keywords: Branch: Puppet wants /var/run to be mod 1777 on OpenBSD, but it's mod 755: pre debug: /File[/var/run]: Changing mode debug: /File[/var/run]: 1 change(s) debug: /File[/var/run]/mode: mode changed '755' to '1777' /pre I'm not really certain why puppet cares about that folder's permissions. Someone on IRC claimed this didn't happen on Linux, however on my Linux boxes my /var/run is mod 1777. The end result of this is that the security reports from OpenBSD come in every night, when they should only be coming in when there is a security 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 - Bug #4239] Function returning binary content trigger sql error with stored config
Issue #4239 has been updated by Andrew Parker.
Target version deleted (2.7.x)
Bug #4239: Function returning binary content trigger sql error with stored
config
https://projects.puppetlabs.com/issues/4239#change-80254
Author: Sylvain Avril
Status: Accepted
Priority: High
Assignee:
Category: stored configuration
Target version:
Affected Puppet version: 0.25.5
Keywords:
Branch:
To generate SSL certificates on the puppet server and distributing them to
puppet clients, I have created a small parser function.
Unfortunately, it trigger a SQL exception with stored config :
SQLite3::SQLException: unrecognized token: '7H^É9¸X509KEY: INSERT INTO
param_values (param_name_id, updated_at, line, resource_id, value,
created_at) VALUES(5, '2010-07-15 17:35:42', 81, 359, '7H^É9¸X509KEY
It appears that the binary content is not escaped before passing it to the SQL
database.
Here's a small piece of code which reproduce the problem:
module Puppet::Parser::Functions
nbsp;nbsp;nbsp;nbsp;newfunction(:getBinaryContent, :type = :rvalue) do
|args|
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;filename=/bin/echo
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;filesize = File.size(filename)
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;content = IO.read(filename,
filesize, 0)
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;return content
nbsp;nbsp;nbsp;nbsp;end
end
And the manifest :
file {/root/mybinary:
nbsp;nbsp;nbsp;nbsp;ensure = present,
nbsp;nbsp;nbsp;nbsp;content = getBinaryContent();
}
I don't know how exactly store config works but it seem a bad idea to have the
content param of the file stored in DB. Is the content of all file generated by
template stored in DB ?
--
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 #4248] Load library plugins that are used by multiple puppet functions and delivered via pluginsync
Issue #4248 has been updated by Andrew Parker. Target version deleted (2.7.x) Feature #4248: Load library plugins that are used by multiple puppet functions and delivered via pluginsync https://projects.puppetlabs.com/issues/4248#change-80255 Author: R.I. Pienaar Status: Accepted Priority: Normal Assignee: Category: plumbing Target version: Affected Puppet version: 0.25.5 Keywords: autoloader Branch: Because we do not add all module lib directories to Ruby's search path, ruby classes that exist only in the modules (because they have not yet been synced via pluginsync) cannot be found. The autoloader correctly loads files from the modules, but ruby itself can't load supporting classes. Old description: At present we can copy parser functions, types and providers out with plugins sync, this works fine. It seems though we cannot copy out Puppet::Util::* classes - useful for code accessed by various parser functions for example. I need to do something like: pre require File.dirname(__FILE__) + '/../../util/foo.rb' /pre from a parser function since: pre require 'puppet/util/foo' /pre doesnt work. I am also keen to be able to copy out new application classes that will tie into the puppet single executable thing, i guess these 2 features might be in the same realm. -- 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 #4253] puppetmaster started in a non accessible directory for the puppet user causing problems
Issue #4253 has been updated by Andrew Parker.
Target version deleted (2.7.x)
Bug #4253: puppetmaster started in a non accessible directory for the puppet
user causing problems
https://projects.puppetlabs.com/issues/4253#change-80256
Author: Peter Meier
Status: Accepted
Priority: Normal
Assignee:
Category: file
Target version:
Affected Puppet version: 0.25.5
Keywords:
Branch: http://github.com/nicklewis/puppet/tree/ticket/2.6.x/4253
running the following code:
pre
file{/etc/motd:
content = generate(/opt/bin/motd_gen.sh, ${hostname}, ${motd_message}),
owner = root, group = 0, mode = 0644;
}
/pre
Where @/opt/bin/motd_gen.sh@ has the follwing content:
pre
#!/bin/sh
/usr/bin/figlet $1
/bin/echo -e $2
/pre
causes the following problem if puppet is run from a directory (like /root),
that the puppet user (to which puppet master drops its privileges) doesn't have
access to:
pre
# pwd
/root
# puppet master --config /srv/puppet/etc/puppet.conf --no-daemonize
--masterport 8141 --verbose --debug --trace
[...]
/usr/lib/ruby/site_ruby/1.8/puppet/parser/compiler.rb:21:in `compile'
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/catalog/compiler.rb:77:in
`compile'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:175:in `benchmark'
/usr/lib/ruby/gems/1.8/gems/activesupport-2.2.2/lib/active_support/core_ext/benchmark.rb:8:in
`realtime'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:174:in `benchmark'
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/catalog/compiler.rb:75:in
`compile'
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/catalog/compiler.rb:34:in `find'
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:193:in `find'
/usr/lib/ruby/site_ruby/1.8/puppet/indirector.rb:50:in `find'
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/handler.rb:101:in `do_find'
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/handler.rb:68:in `send'
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/handler.rb:68:in `process'
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick/rest.rb:23:in `service'
/usr/lib/ruby/1.8/webrick/httpserver.rb:104:in `service'
/usr/lib/ruby/1.8/webrick/httpserver.rb:65:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:45:in `listen'
/usr/lib/ruby/1.8/webrick/server.rb:173:in `call'
/usr/lib/ruby/1.8/webrick/server.rb:173:in `start_thread'
/usr/lib/ruby/1.8/webrick/server.rb:162:in `start'
/usr/lib/ruby/1.8/webrick/server.rb:162:in `start_thread'
/usr/lib/ruby/1.8/webrick/server.rb:95:in `start'
/usr/lib/ruby/1.8/webrick/server.rb:92:in `each'
/usr/lib/ruby/1.8/webrick/server.rb:92:in `start'
/usr/lib/ruby/1.8/webrick/server.rb:23:in `start'
/usr/lib/ruby/1.8/webrick/server.rb:82:in `start'
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:42:in `listen'
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:41:in `initialize'
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:41:in `new'
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:41:in `listen'
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:38:in `synchronize'
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:38:in `listen'
/usr/lib/ruby/site_ruby/1.8/puppet/network/server.rb:127:in `listen'
/usr/lib/ruby/site_ruby/1.8/puppet/network/server.rb:142:in `start'
/usr/lib/ruby/site_ruby/1.8/puppet/daemon.rb:125:in `start'
/usr/lib/ruby/site_ruby/1.8/puppet/application/master.rb:114:in `main'
/usr/lib/ruby/site_ruby/1.8/puppet/application/master.rb:46:in `run_command'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:301:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:398:in `exit_on_fail'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:301:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/util/command_line.rb:55:in `execute'
/usr/bin/puppet:4
err: Permission denied - /root at
/srv/puppet/development/modules/public/motd/manifests/client.pp:4 on node
foo.bar.ch
/pre
running @puppet master@ from a directory like @/tmp@ works fine.
Imho puppet shouldn't leak the CWD to its subprocesses, especially if they're
not accessible to them.
--
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.
