[Puppet - Bug #14343] undefined method twoscope_lookupvar while looking for top scope or facter variables
Issue #14343 has been updated by konrad rzentarzewski.
do you have any comments on specific context that may cause lookupvar to fail?
we're using quite big manifests and nearly every module uses variables in pp's
and erb's, so i can't really say why is it failing in those specific snippets.
in isolated environment i can't reproduce it either, with dist or REE ruby, so
i don't think this is REE fault...
1root@punch(18)~$ /usr/local/bin/ruby /usr/bin/puppet apply t.pp
notice: command[check_ibm_ds35xx]=/usr/local/bin/check_ds35xx.pl -n
asdkhfdfdffg
notice:
/Stage[main]//Notify[command[check_ibm_ds35xx]=/usr/local/bin/check_ds35xx.pl
-n asdkhfdfdffg]/message: defined 'message' as
'command[check_ibm_ds35xx]=/usr/local/bin/check_ds35xx.pl -n asdkhfdfdffg'
notice: /Stage[main]//Exec[test]/returns: 1
notice: /Stage[main]//Exec[test]/returns: executed successfully
notice: Finished catalog run in 0.41 seconds
1root@punch(19)~$ /usr/bin/ruby /usr/bin/puppet apply t.pp
notice: command[check_ibm_ds35xx]=/usr/local/bin/check_ds35xx.pl -n
asdkhfdfdffg
notice:
/Stage[main]//Notify[command[check_ibm_ds35xx]=/usr/local/bin/check_ds35xx.pl
-n asdkhfdfdffg]/message: defined 'message' as
'command[check_ibm_ds35xx]=/usr/local/bin/check_ds35xx.pl -n asdkhfdfdffg'
notice: /Stage[main]//Exec[test]/returns: 1
notice: /Stage[main]//Exec[test]/returns: executed successfully
notice: Finished catalog run in 0.50 seconds
2root@punch(20)~$ cat t.pp
$clusterversion = 1
exec { test: command = /bin/echo $clusterversion, logoutput = true }
$ibm_ds_storagesubsystem_name = 'asdkhfdfdffg'
$x =
inline_template('command[check_ibm_ds35xx]=/usr/local/bin/check_ds35xx.pl -n
%= ibm_ds_storagesubsystem_name %')
notify { $x: }
Bug #14343: undefined method twoscope_lookupvar while looking for top scope or
facter variables
https://projects.puppetlabs.com/issues/14343#change-62534
Author: konrad rzentarzewski
Status: Needs More Information
Priority: Normal
Assignee: Andrew Parker
Category: compiler
Target version:
Affected Puppet version: 2.7.14
Keywords:
Branch:
with upgrade to 2.7.14 comes the following error from puppetmasters:
err: Could not retrieve catalog from remote server: Error 400 on SERVER:
Puppet::Parser::AST::Variable failed with error NoMethodError: undefined method
`twoscope_lookupvar' for nil:NilClass at
/etc/puppet/site/modules/[...]/init.pp:2863 on node [...]
referenced module code is just a top scope or facter variable lookup, ie.
exec { load-cluster-conf: command = cman_tool version -r
$clusterversion }
it seems that twoscope_lookupvar is not visible in puppet classes.
the following patch fixes this behaviour.
--
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 #14343] undefined method twoscope_lookupvar while looking for top scope or facter variables
Issue #14343 has been updated by konrad rzentarzewski.
i've found something interesting. resources that fail belong to the classes
which are inherited. those are the only inherited classes in our env (it was
commited by a programmer which is no longer here, and the rest of the team use
require something::common instead of class specific inherits common).
when i changed:
class primary inherits secondary {
exec { load-cluster-conf:
# ...
to:
class primary {
include cluster::secondary
exec { load-cluster-conf:
# ...
and:
class ibm_ds35xx ($subsystem) inherits ibm_ds_sm_monitoring {
file { nrpe_ibm_ds35xx:
content = template(nagios/nrpe-ibm-ds35xx.erb),
to:
class ibm_ds35xx ($subsystem) {
include ibm_ds_sm_monitoring
file { nrpe_ibm_ds35xx:
content = template(nagios/nrpe-ibm-ds35xx.erb),
it's no longer failing (good!).
tested with both distribution and enterprise ruby.
yet, you should investigate if you can replicate this problem with class
inheritance.
Bug #14343: undefined method twoscope_lookupvar while looking for top scope or
facter variables
https://projects.puppetlabs.com/issues/14343#change-62535
Author: konrad rzentarzewski
Status: Needs More Information
Priority: Normal
Assignee: Andrew Parker
Category: compiler
Target version:
Affected Puppet version: 2.7.14
Keywords:
Branch:
with upgrade to 2.7.14 comes the following error from puppetmasters:
err: Could not retrieve catalog from remote server: Error 400 on SERVER:
Puppet::Parser::AST::Variable failed with error NoMethodError: undefined method
`twoscope_lookupvar' for nil:NilClass at
/etc/puppet/site/modules/[...]/init.pp:2863 on node [...]
referenced module code is just a top scope or facter variable lookup, ie.
exec { load-cluster-conf: command = cman_tool version -r
$clusterversion }
it seems that twoscope_lookupvar is not visible in puppet classes.
the following patch fixes this behaviour.
--
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 #5860] arrays do not work in selectors
Issue #5860 has been updated by Dominic Cleal.
The same goes for returning hashes from a selector:
$foo = test
$real_foo = $foo ? {
default = { test = foo },
}
notice($foo[test])
throws this:
err: Could not parse for environment production: Syntax error at '{';
expected '}' at /home/dcleal/tmp/5860.pp:3 ...
Bug #5860: arrays do not work in selectors
https://projects.puppetlabs.com/issues/5860#change-62537
Author: Adam Crews
Status: Accepted
Priority: Normal
Assignee:
Category:
Target version: 2.7.x
Affected Puppet version:
Keywords:
Branch:
Using an array in a selector does not work:
$info = [ acrews, Adam, /bin/bash ]
$shell = $info[2] ? {
/bin/ = $info[2],
default = /sbin/nologin,
}
I get: Syntax error at '?'; expected '}
If I do this it works:
$info = [ acrews, Adam, /bin/bash ]
$AA = $info[2]
$shell = $AA ? {
/bin/ = $info[2],
default = /sbin/nologin,
}
An array element should be able to be used exactly like any normal variable.
I see this on 2.6.4.
--
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 #14397] win32console 1.3.1 bug causing acceptance tests to fail
Issue #14397 has been updated by Ken Barber. The patch has been accepted, and the ticket is closed on the win32console end: https://github.com/luislavena/win32console/pull/16 https://github.com/luislavena/win32console/issues/14 I'm just waiting for a new release of the gem from the author. In the meantime I have a branch prepped to fix the acceptance tests: https://github.com/kbarber/puppet-acceptance/tree/ticket/master/14397-win32console_v1.3.2 Once I get confirmation we have a new win32console 1.3.2 gem, I'll raise a pull request. (I'm just adding both Jeff + Justin as they may care about the status of this work.) Bug #14397: win32console 1.3.1 bug causing acceptance tests to fail https://projects.puppetlabs.com/issues/14397#change-62538 Author: Ken Barber Status: Accepted Priority: Urgent Assignee: Ken Barber Category: windows Target version: 3.0.0 Affected Puppet version: Keywords: win32console ansi color Branch: We are seeing failures with win32console 1.3.1: https://jenkins.puppetlabs.com/job/Puppet%20Acceptance%20Windows%20(master)/platform=windows2003-32a,slave-tb=slave-tb.puppetlabs.lan/21/console This is due to a bug I've introduced in win32console: https://github.com/luislavena/win32console/issues/14 For now we are recommending that win32console 1.3.0 be used until this problem is solved. -- 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 #14423] (Unreviewed) syntax error when , is incuded
Issue #14423 has been reported by Anand Kumria.
Bug #14423: syntax error when , is incuded
https://projects.puppetlabs.com/issues/14423
Author: Anand Kumria
Status: Unreviewed
Priority: Normal
Assignee:
Category:
Target version:
Affected Puppet version: 2.7.14
Keywords: DSL
Branch:
The general syntax of the puppet DSL allows for trailing commas (,) to appear
at the end of each line.
**except**, it seems as an overridable parameter to a class.
This inconsistency just bit me on my first module, where I had it working
locally and did a final cleanup prior to upload.
Could not parse for environment production: Syntax error at ')' at
/tmp/vagrant-puppet/modules-0/nullmailer/manifests/init.pp:9 on node
web1.example.net
To fix, I did:
% git diff
diff --git a/manifests/init.pp b/manifests/init.pp
index ab5cd41..7237184 100644
--- a/manifests/init.pp
+++ b/manifests/init.pp
@@ -4,7 +4,7 @@ class nullmailer (
$service = $nullmailer::params::service,
$manage_etc_mailname = $nullmailer::params::manage_etc_mailname,
$adminaddr = root@$::domain,
- $remoterelay = smtp.$::domain,
+ $remoterelay = smtp.$::domain
) inherits nullmailer::params {
This is from akumria/nullmailer on the puppetforge, where I uploaded v1.0.1
with the workaround.
But it seems odd and inconsistent that I had to.
--
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 #14402] variable interpolation and scope
Issue #14402 has been updated by Gary Wilson (@earthgecko).
And `$zpf-controller::ec2_cert` works as well :)
There are topscope and non-namespaced variables in the erb templates and these
still work dynamically and puppet-master is **not warning** about them.
Is it to be assumed that the namespacing and scope of variables in the erb
templating context are affected in the same manner by the changes to variable
scoping and make many existing variables in pre 2.7 templates Out of scope
variables in 2.8?
So the best fix for templates using dynamic lookup would be to use the
`scope.lookupvar` methodology with namespaced variables on all affected vars
and templates, e.g. `%= scope.lookupvar('zpf-controller::ec2_cert') %` or is
the `scope.lookupvar` function not affected by the variable and scoping changes?
Bug #14402: variable interpolation and scope
https://projects.puppetlabs.com/issues/14402#change-62540
Author: Gary Wilson (@earthgecko)
Status: Unreviewed
Priority: Normal
Assignee:
Category:
Target version:
Affected Puppet version: 2.7.14
Keywords:
Branch:
I am somewhat lost in the changes in variable interpolation, the deprecation of
dynamic lookup and the styling guide documentation vs Scope and Puppet
documentation (http://docs.puppetlabs.com/guides/scope_and_puppet.html) and Bug
#10146: Puppet interpolates variables differently in 2.7.x
(https://projects.puppetlabs.com/issues/10146)
So with 2.7.x variables should be declared as `/root/.ssh/${var}` according
to #10146 (to be safe).
The following variable worked with dynamic lookup.
pre
file { /root/.ssh/${ec2_cert}:
source = /opt/keys/controller_keys/${ec2_cert},
/pre
Variables were reworked so not just `$var` but to `${var}` to be safe as #10146.
However changing the variables to namespace variables due to dynamic lookup
deprecation on 2.7.14 the following does not work.
pre
file { /root/.ssh/${zpf-controller:ec2_cert}:
source = /opt/keys/controller_keys/${zpf-controller:ec2_cert},
/pre
Errors with the following:
pre
May 10 16:19:51 zpf-controller-dev-1-10g-ruk puppet-master[20240]: Syntax error
at ':'; expected '}' at /etc/puppet/modules/zpf/manifests/init.pp:264 on node
zpf-controller-dev-2-512m-c4l
/pre
So the variables are not being interpolated in the curly brackets.
However this does work.
pre
file { /root/.ssh/$zpf-controller:ec2_cert:
source = /opt/keys/controller_keys/$zpf-controller:ec2_cert,
/pre
Does this mean that you cannot curly bracket namespace variables? Is this a
bug or another **significant** change in the variable interpolation changes
that come with 2.7.x?
--
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 #14424] (Unreviewed) installation of a module fails
Issue #14424 has been reported by Anand Kumria. Bug #14424: installation of a module fails https://projects.puppetlabs.com/issues/14424 Author: Anand Kumria Status: Unreviewed Priority: Normal Assignee: Category: Target version: Affected Puppet version: 2.7.14 Keywords: Branch: I use vagrant to test out my puppet manifests, so I want to specify a directory where I'd like things to be installed. % puppet module install -i mtest akumria-nullmailer Preparing to install into mtest ... Downloading from http://forge.puppetlabs.com ... Error: undefined method `each' for nil:NilClass Error: Try 'puppet help module install' for usage -- 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 #14425] (Unreviewed) Access to multidimensional hash in manifest results in syntax error
Issue #14425 has been reported by Florian Zavatzki.
Bug #14425: Access to multidimensional hash in manifest results in syntax error
https://projects.puppetlabs.com/issues/14425
Author: Florian Zavatzki
Status: Unreviewed
Priority: Normal
Assignee:
Category:
Target version:
Affected Puppet version: 2.6.2
Keywords:
Branch:
Accessing a multidimensional hash with more then two levels results in a syntax
error.
class value {
$hash = {'l1' = {'l2' = {'l3' = 'foo'}}}
}
class access {
include value
$bar = $value::hash['l1']['l2']['l3']
}
This result in a syntax error:
Syntax error at '['; expected ']'
Using the example above with a step between, everything works:
class access {
include value
$bar1 = $value::hash['l1']
$bar2 = $bar1['l2']['l3']
}
Tested in version 2.6.2-5+squeeze5 on Debian squeeze.
--
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 #14426] (Unreviewed) upgrading a module is not possible
Issue #14426 has been reported by Anand Kumria. Bug #14426: upgrading a module is not possible https://projects.puppetlabs.com/issues/14426 Author: Anand Kumria Status: Unreviewed Priority: Normal Assignee: Category: Target version: Affected Puppet version: 2.7.14 Keywords: Branch: I use vagrant to test my manifests before publishing, so I specify the location where modules should be installed. When attempting to upgrade a module, already installed. % puppet module install -i modules akumria-nullmailer Preparing to install into modules ... Error: Could not install module 'akumria-nullmailer' (latest) Module 'akumria-nullmailer' (v1.0.0) is already installed Use `puppet module upgrade` to install a different version Use `puppet module install --force` to re-install only this module Installation itself fails (see #14424), but I used the puppet-module gem to install this module. So, let's try an upgrade: % puppet module upgrade -i modules akumria-nullmailer Could not parse options: ambiguous option: -i Hmm, what about the longform version of this option? % puppet module upgrade --target-dir modules akumria-nullmailer Could not parse options: invalid option: --target-dir OK - perhaps it'll just figure things out magically: % puppet module upgrade akumria-nullmailer Preparing to upgrade 'akumria-nullmailer' ... Error: Could not upgrade module 'akumria-nullmailer' Module 'akumria-nullmailer' is not installed Use `puppet module install` to install this module -- 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 #8346] services falsely presumed running on redhat
Issue #8346 has been updated by Sven T.
Is there a real solution, something without the workaround? I happen to need
the lsb package... :/
Bug #8346: services falsely presumed running on redhat
https://projects.puppetlabs.com/issues/8346#change-62541
Author: Chris Phillips
Status: Accepted
Priority: Normal
Assignee:
Category: service
Target version:
Affected Puppet version: 2.6.7
Keywords: service status stopped restart
Branch:
I have a number of systems which are frequently having problems centering
around various services being believed to be running by puppet when they are
actually stopped. I have not seen any examples of the opposite being true
however.
Two examples:
I use a nagios check to run puppet, so want to ensure the puppet client service
is NOT running. the manifest I use to do this is:
service { puppet:
ensure = stopped,
enable = false,
subscribe = File[/etc/puppet/puppet.conf],
hasrestart = true,
hasstatus = true,
}
And this is normally working just fine, however sometimes a client starts to
believe that the service IS running, despite there being NO puppet processes
running other than the current one-shot one executing the manifests. This
happens if running from a cron job, a nagios check or puppetd -tv from
command line directly. /etc/init.d/puppet status returns that the service is
not running, with the right exit code (3). Puppet output on continual manual
runs:
notice: /Stage[first]/Puppet/Service[puppet]/ensure: ensure changed 'running'
to 'stopped'
notice: Finished catalog run in 13.93 seconds
again and again forever until the manifest is changed, to, for example, say it
should be running, let that apply, and then revert back to stopped.
Similarly I need func running on all boxes, sometimes it will stop during a
logrotate for unknown reasons, and puppet will refuse to start it despite
everything saying it is stopped.
service { funcd:
ensure = running,
enable = true,
subscribe = File[/etc/func/minion.conf],
require = Package[func],
hasrestart = true,
hasstatus = false
}
Again this generally works, but over this weekend 9 boxes has func fail on
them, there are NO func processes running, and /etc/init.d/funcd status
confirms this (textually and exist code 3), and this manifest generally works
fine.
This may possibly be related to the use of the hasstatus parameter, it *seemed*
to improve the func service check, but doesn't influence the puppet service
being falsely believed to be running. Or the repetitive nature suggests
something is possibly cached on the client?
This is on 2.6.7 on rhel5 6, i386 and x86_64.
--
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 #2179] IP support calls 'ip' and 'ifconfig' ridiculous numbers of times
Issue #2179 has been updated by Ken Barber. Assignee deleted (Ken Barber) Bug #2179: IP support calls 'ip' and 'ifconfig' ridiculous numbers of times https://projects.puppetlabs.com/issues/2179#change-62544 Author: Luke Kanies Status: Accepted Priority: High Assignee: Category: library Target version: 2.0.0 Keywords: caching, ifconfig, interfaces Branch: Affected Facter version: I've got a client who says that they're each being called something like 1500 times, and Facter is taking 25% of the total run time. I am going to try to get a quick caching system in place for 1.5.5, but we can bump it if we have to. -- 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 - Feature #4519] Facter should provide a convenient way to cache values
Issue #4519 has been updated by Ken Barber. Assignee deleted (Ken Barber) Feature #4519: Facter should provide a convenient way to cache values https://projects.puppetlabs.com/issues/4519#change-62545 Author: Peter Meier Status: Accepted Priority: Normal Assignee: Category: library Target version: 2.0.0 Keywords: Branch: https://github.com/kbarber/facter/tree/ticket/4519-cache Affected Facter version: I think this have discussed already various times and it is even planned?!. But I couldn't find a logged ticket and as I stumpled over that problem once again I thought I might want to file a feature request: Facter should provide a way to: 1. cache facts with a certain timeout, so that the fact value gets cache for the defined time 1. provide a way to cache any kind of data for a certain amount of time Why? We might want to have facts that take some time to calculate, however that don't change much. Or there might be data required to calucate a certain fact which high resource intensive, but doesn't change often. So what I like to have is similar to the @confine@ a way to set @timeout@, so that if this is set to some seconds/minutes (?) the fact isn't calculated again until the timeout expired. For the second point I'd like to have a simple key value store with timeout capability built into facter, so I can cache output of commands, which can then be used amongst different facts. Example: xen management tools are getting slower the more VMs you start. Hence @xm list@ can get slower and slower and if you have various facts that are depending on the output of that command and you take the naive approach and call @xm list@ a couple of times, you slowdown facter and hence puppet runs enormously. If I have only one fact using the output it would be nice to let facter cache that fact. However, if I have multiple facts depending on the output of @xm list@ I might want to cache also the output of @xm list@ so that @xm list@ is called really only once per facter run. Currently you can do that with your own cache implementation hacked into facts, but I think it would be nicer if facter would provide a convenient way to cache things. -- 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 - Feature #7559] Fact for identifying Amazon VPC instances.
Issue #7559 has been updated by Ken Barber.
Assignee deleted (Ken Barber)
Feature #7559: Fact for identifying Amazon VPC instances.
https://projects.puppetlabs.com/issues/7559#change-62547
Author: Nigel Kersten
Status: Needs Decision
Priority: Normal
Assignee:
Category: library
Target version:
Keywords:
Branch:
Affected Facter version:
(From the list)
I ran into a buglet in facter 1.5.9rc6 (from tmz repo). In normal AWS
instances it works great. In VPC instances if doesn't work. This seems
to be because VPC instances don't use the fe:ff:ff:... MAC addresses.
pre
/sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 02:67:4E:E1:26:30
inet addr:172.17.129.24 ...
/sbin/arp
Address HWtype HWaddress Flags Mask Iface
169.254.169.253 ether 02:67:4E:C0:00:01 C eth0
172.17.128.1 ether 02:67:4E:C0:00:01 C eth0
/sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 02:67:4E:DA:58:16
inet addr:172.17.128.126
/sbin/arp
Address HWtype HWaddress Flags Mask Iface
169.254.169.253 ether 02:67:4E:C0:00:01 C eth0
172.17.128.1 ether 02:67:4E:C0:00:01 C eth0
/pre
Of the two VPC EC2 instances I've seen, the MAC address always start
with 02:67:4E. I have only seen two instances, both in the same VPC, so
I don't know if this holds for every VPC instance, YMMV.
in ec2.rb , the following seemed to work:
pre
def has_euca_mac?
!!(Facter.value(:macaddress) =~ %r{^02:67:4[eE]:})
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 - Feature #4561] Structured data should be supported
Issue #4561 has been updated by Ken Barber.
Assignee deleted (Ken Barber)
Feature #4561: Structured data should be supported
https://projects.puppetlabs.com/issues/4561#change-62546
Author: Luke Kanies
Status: Accepted
Priority: High
Assignee:
Category: library
Target version:
Keywords:
Branch:
https://github.com/kbarber/facter/tree/ticket/master/4561-add_structured_data
Affected Facter version:
Facter currently only supports a flat result list, and it should instead
support structured data - basically, a hash of hashes and arrays.
This should probably be able to be represented in two ways - either a hash of
hashes/arrays, or namespaces. That is, this:
pre
{:top = {:middle = {:bottom = value}}}
/pre
Could also be represented as:
pre
top::middle::bottom = value
/pre
We could optionally have a converter that s/::/_/g for backward compatibility,
which should be both trivial and unnecessary, but there should definitely be
some kind of backward compatibility mode for callers who can't deal with
structured data.
--
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 #8104] Facter 1.6.0 outputs
Issue #8104 has been updated by Ken Barber. Assignee deleted (Ken Barber) Bug #8104: Facter 1.6.0 outputs https://projects.puppetlabs.com/issues/8104#change-62548 Author: James Turnbull Status: Accepted Priority: Urgent Assignee: Category: binary Target version: Keywords: security Branch: Affected Facter version: 1.6.0 $ facter --version 1.6.0 pre $ facter Error loading fact ./facter/autotest/discover.rb no such file to load -- autotest Error loading fact ./facter/autotest/facter_rspec.rb no such file to load -- autotest Error loading fact ./facter/autotest/rspec.rb no such file to load -- autotest /usr/local/lib/site_ruby/1.8/puppet/external/dot.rb:57: warning: already initialized constant NODE_OPTS /usr/local/lib/site_ruby/1.8/puppet/external/dot.rb:97: warning: already initialized constant EDGE_OPTS /usr/local/lib/site_ruby/1.8/puppet/external/dot.rb:112: warning: already initialized constant GRAPH_OPTS ... /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 #8963] facter-1.6.0 fails to run in some OpenSolaris|Indiana releases if no swap devices present.
Issue #8963 has been updated by Ken Barber. Assignee deleted (Ken Barber) Bug #8963: facter-1.6.0 fails to run in some OpenSolaris|Indiana releases if no swap devices present. https://projects.puppetlabs.com/issues/8963#change-62550 Author: Lucas Van Tol Status: In Topic Branch Pending Review Priority: Normal Assignee: Category: library Target version: 1.6.x Keywords: Branch: Affected Facter version: 1.6.0 pre :~$ swap -l No swap devices configured :~$ facter ... facterversion = 1.5.7 ... rubyversion = 1.8.7 ... kernel = SunOS kernelmajversion = snv_128a kernelrelease = 5.11 kernelversion = snv_128a :-$ gem install facter Successfully installed facter-1.6.0 1 gem installed :~$ facter No swap devices configured Error: undefined method `each' for nil:NilClass --- Editing 'lib/facter/memory.rb' and adding an 'if !swap.nil?'...'end' around lines 170..175 seems to work with or without swap. Still displays the error from :~$ facter No swap devices configured ... facterversion = 1.6.0 ... kernel = SunOS kernelmajversion = snv_128a kernelrelease = 5.11 kernelversion = snv_128a ... memoryfree = 5.83 GB memorysize = 32.00 GB ... swapfree = 0.00 kB swapsize = 0.00 kB ... /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 #10508] EC2 facts not available if endpoint timesout or is unavailable
Issue #10508 has been updated by Ken Barber. Assignee deleted (Ken Barber) Bug #10508: EC2 facts not available if endpoint timesout or is unavailable https://projects.puppetlabs.com/issues/10508#change-62551 Author: Matt Moran Status: Code Insufficient Priority: Normal Assignee: Category: library Target version: Keywords: Branch: https://github.com/puppetlabs/facter/pull/95 Affected Facter version: 1.5.9 Using EC2 facts in templates or putting conditionals around them can be surprising, due to if the EC2 facts are unavailable your puppet runs may produce unexpected behaviour. It would be good if variables from the EC2 metadata endpoint were cached in a file. This can be used to fulfil the facts if the endpoint is unavailable or timesout. -- 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 #12879] undefined method `has_openstack_mac?' for Facter::Util::EC2:Module
Issue #12879 has been updated by Ken Barber. Assignee deleted (Ken Barber) Bug #12879: undefined method `has_openstack_mac?' for Facter::Util::EC2:Module https://projects.puppetlabs.com/issues/12879#change-62553 Author: Chip Schweiss Status: Investigating Priority: High Assignee: Category: library Target version: Keywords: Branch: Affected Facter version: 1.6.6 This is on CentOS 6.2 w/ Puppet 2.6.14-1.el6 both from the Puppet yum repository. The problem is only occurring in daemon mode of puppet. This is in the syslog repeatedly: pre Feb 29 08:14:55 hostname puppet-agent[21815]: Could not run Puppet configuration client: Could not retrieve local facts: undefined method `has_openstack_mac?' for Facter::Util::EC2:Module /pre I've checked on several systems and it appears to be a bug introduced in 1.6.6-1. The last successful run in the logs contains: pre Feb 28 14:55:18 hostname puppet-agent[21815]: (/Stage[puppet]/Facter/Package[facter]/ensure) ensure changed '1.6.5-1.el6' to '1.6.6-1.el6' /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 - Feature #12766] Get working for travis-ci
Issue #12766 has been updated by Ken Barber. Assignee deleted (Ken Barber) Feature #12766: Get working for travis-ci https://projects.puppetlabs.com/issues/12766#change-62552 Author: Ken Barber Status: Needs Decision Priority: Normal Assignee: Category: testing Target version: 1.6.x Keywords: travis Branch: Affected Facter version: This ticket is to cover getting facter working for Travis-CI as a trial. This was brought up recently by another submitter, and since then we have decided to try it out. -- 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 #8128] Some facts take a LOOONNGGG time to run
Issue #8128 has been updated by Ken Barber. Assignee deleted (Ken Barber) Bug #8128: Some facts take a LOOONNGGG time to run https://projects.puppetlabs.com/issues/8128#change-62549 Author: James Turnbull Status: Accepted Priority: High Assignee: Category: library Target version: Keywords: Branch: Affected Facter version: FOr example puppetversion - it can take 600-800 ms per run: puppetversion: 825.72ms This is because it requires 'puppet' and loads it before returning the version. It should be rewritten to not do this. Other heavy facts: pre lsbdistid: 136.45ms operatingsystem: 137.29ms lsbdistdescription: 131.18ms lsbdistrelease: 135.20ms lsbmajdistrelease: 135.72ms puppetversion: 137.39ms lsbrelease: 132.03ms lsbdistcodename: 134.41ms /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 #13199] (Accepted) md5lite, mtime not honoured for file type/provider
Issue #13199 has been updated by Ken Barber.
Status changed from Investigating to Accepted
Assignee deleted (Ken Barber)
Affected Puppet version set to 2.7.14
I think I've pretty much established this is true, but alas - its not a quick
fix.
Bug #13199: md5lite, mtime not honoured for file type/provider
https://projects.puppetlabs.com/issues/13199#change-62554
Author: Ken Barber
Status: Accepted
Priority: Normal
Assignee:
Category: file
Target version:
Affected Puppet version: 2.7.14
Keywords:
Branch:
It seems I can't get the puppetmaster to honour the checksum = mtime setting,
or the md5lite setting. So the following example has no performance improvement
over just using md5:
file { /testtransfer:
ensure = directory,
recurse = remote,
purge = true,
checksum = mtime,
source = puppet:///modules/${module_name}/bigfileshere,
}
The problem seems to be in multiple places. The first place, I can't get the
file_server/metadata to respond with mtime, md5lite checksums:
# curl -k --cert /etc/puppetlabs/pupem --key
/etc/puppetlabs/puppet/ssl/private_keys/puppetclient2.vm.pem --cacert
/etc/puppetlabs/puppet/ssl/certs/ca.pem -H 'Accept: yaml'
'https://puppet:8140/production/file_metadatas/modules/filetransfer/sles/SLES-11-SP1-DVD-x86_64-GM-DVD1.iso
checksum_type=md5lite'
---
- !ruby/object:Puppet::FileServing::Metadata
checksum: {md5}d2e10420f3689faa49a004b60fb396b7
checksum_type: md5
destination:
expiration: 2012-03-16 17:49:23.600743 -07:00
ftype: file
group: 0
links: !ruby/sym manage
mode: 420
owner: 0
path:
/etc/puppetlabs/puppet/modules/filetransfer/files/sles/SLES-11-SP1-DVD-x86_64-GM-DVD1.iso
relative_path: .
stat_method: !ruby/sym lstat
This is fixed with this patch:
diff --git a/lib/puppet/indirector/file_server.rb
b/lib/puppet/indirector/file_server.rb
index 9516a40..9fbd57e 100644
--- a/lib/puppet/indirector/file_server.rb
+++ b/lib/puppet/indirector/file_server.rb
@@ -51,6 +51,7 @@ class Puppet::Indirector::FileServer
Puppet::Indirector::Terminus
Puppet::FileServing::Fileset.merge(*filesets).collect do |file,
base_path|
inst = model.new(base_path, :relative_path = file)
inst.links = request.options[:links] if request.options[:links]
+ inst.checksum_type = request.options[:checksum_type] if
request.options[:checksum_type]
inst.collect
inst
end
Which does the correct thing:
# curl -k --cert /etc/puppetlabs/puppet/ssl/certs/puppetclient2.vm.pem
--key /etc/puppetlabs/puppet/ssl/private_keys/puppetclient2.vm.pem --cacert
/etc/puppetlabs/puppet/ssl/certs/ca.pem -H 'Accept: yaml'
'https://puppet:8140/production/file_metadatas/modules/filetransfer/sles/SLES-11-SP1-DVD-x86_64-GM-DVD1.iso?checksum_type=md5lite'
---
- !ruby/object:Puppet::FileServing::Metadata
checksum: {md5lite}bf619eac0cdf3f68d496ea9344137e8b
checksum_type: md5lite
destination:
expiration: 2012-03-16 17:51:43.033651 -07:00
ftype: file
group: 0
links: !ruby/sym manage
mode: 420
owner: 0
path:
/etc/puppetlabs/puppet/modules/filetransfer/files/sles/SLES-11-SP1-DVD-x86_64-GM-DVD1.iso
relative_path: .
stat_method: !ruby/sym lstat
The second problem seems to be in the provider itself, it seems to me as if its
still trying to do an md5 scan on the local filesystem - but I'll have to dig
deeper to find the root cause for 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 #14311] Expose catalog version
Issue #14311 has been updated by Haw Loeung. Hi Kelsey, Kelsey Hightower wrote: Haw, In order to help us make a better decision on accepting this, it would help if you provided a use case. What are you trying to accomplish in your postrun script? Why would a custom [report processor](http://docs.puppetlabs.com/guides/reporting.html#processing-reports) not work for you? First of all, thank you for replying. Our current set up is that we have a live/production environment and multiple environments for each user to play and test with (e.g. hloeung, user2, user3, ...). Developers are able to apply changes on certain nodes, test, make sure it all works before these changes are then merged into the live/production environment and rolled out across the board. We also have directories such as /etc which are bazaar repositories to track changes. When the puppet run completes and adds new configuration files and such in these directories, the postrun script automatically commits them with a generic message such as puppet auto-commit. What I would like, is to add more information to the generic auto-commit messages including the environment and the actual catalog number as provided by the puppet master (which is running on different nodes). For example, it would look like this: r100 - puppet auto-commit hloeung r5001 r101 - puppet auto-commit live r4980 r102 - puppet auto-commit hloeung r5002 r103 - puppet auto-commit user2 r4981 ... Currently, the environment is made available in the special variable $environment, but I would also like to see the $catalog.version (provided by the puppet master) made available somehow so I could pass this as an argument to the postrun script. I've tried passing last_run_summary.yaml which has the catalog.version as config_version but that is updated _after_ the postrun script is executed so therefore providing the catalog.version from the last run... which is incorrect. Feature #14311: Expose catalog version https://projects.puppetlabs.com/issues/14311#change-62555 Author: Haw Loeung Status: Needs More Information Priority: Normal Assignee: Haw Loeung Category: Target version: Affected Puppet version: Keywords: Branch: Hi, Would it be possible to expose the catalog version so that something like the following in the puppet.conf would work? postrun_command=/usr/local/sbin/postrun.sh $environment $catalog.version I've tried parsing the last_run_summary.yaml file but that is only updated *after* postrun is executed. -- 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 #9007] (Needs Decision) Construct for specifying parameter validity in paramterized classes in puppet language
Issue #9007 has been updated by Ken Barber.
Status changed from Needs More Information to Needs Decision
Assignee deleted (Ken Barber)
So the current methodology kicking around is kwalify:
http://forge.puppetlabs.com/puppetlabs/kwalify
Or validate_* functions in stdlib:
http://forge.puppetlabs.com/puppetlabs/stdlib
Either of these are good choices. Kwalify is my preferred 'declarative'
methodology, but it was discussed in that thread Nigel mentioned that such
methodology belongs in incubation. Try either of these two methods and maybe
let us know on the puppet-users or puppet-dev how you go. I think until we get
enough push for this outside of core, there is little point adding anything in
core to handle it atm.
But happy to leave this ticket open if everyone else is, to discuss the
possible future of such features in core.
Feature #9007: Construct for specifying parameter validity in paramterized
classes in puppet language
https://projects.puppetlabs.com/issues/9007#change-62556
Author: Joe McDonagh
Status: Needs Decision
Priority: Low
Assignee:
Category: parameterized classes
Target version:
Affected Puppet version:
Keywords: parameters classes parameterized
Branch:
Currently, I'm doing this inside my parameterized classes:
pre
class mysql (
$ensure = present,
$server_type= stock
) {
if ($ensure != present and $ensure != absent) {
fail The mysql class only supports 'present' and 'absent' for ensure
values.
}
if ($server_type != stock and $server_type != puppet and $server_type
!= atlassian) {
fail The mysql class only supports 'stock', 'puppet', and 'atlassian'
as server types as of now.
}
/pre
It would be nice if there some construct to specify valid parameters. I assume
this is pretty easy to do in the Ruby DSL, but I think it'd be valuable to be
able to do this and look nice in pure puppet.
--
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 #9007] (Duplicate) Construct for specifying parameter validity in paramterized classes in puppet language
Issue #9007 has been updated by Ken Barber.
Status changed from Needs Decision to Duplicate
Actually, this is a duplicate of #7218 - so I'll mark it as such.
Feature #9007: Construct for specifying parameter validity in paramterized
classes in puppet language
https://projects.puppetlabs.com/issues/9007#change-62557
Author: Joe McDonagh
Status: Duplicate
Priority: Low
Assignee:
Category: parameterized classes
Target version:
Affected Puppet version:
Keywords: parameters classes parameterized
Branch:
Currently, I'm doing this inside my parameterized classes:
pre
class mysql (
$ensure = present,
$server_type= stock
) {
if ($ensure != present and $ensure != absent) {
fail The mysql class only supports 'present' and 'absent' for ensure
values.
}
if ($server_type != stock and $server_type != puppet and $server_type
!= atlassian) {
fail The mysql class only supports 'stock', 'puppet', and 'atlassian'
as server types as of now.
}
/pre
It would be nice if there some construct to specify valid parameters. I assume
this is pretty easy to do in the Ruby DSL, but I think it'd be valuable to be
able to do this and look nice in pure puppet.
--
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 #7218] (Needs Decision) Integrated variable checking for defines and parameterized classes.
Issue #7218 has been updated by Ken Barber.
Status changed from Needs More Information to Needs Decision
Assignee deleted (Ken Barber)
Forge module is here:
http://forge.puppetlabs.com/puppetlabs/forge
The plan originally with this work was to leave it in incubation and see if it
gets adopted before even thinking about putting such a thing in core. I've had
very little noise about it though.
Feature #7218: Integrated variable checking for defines and parameterized
classes.
https://projects.puppetlabs.com/issues/7218#change-62558
Author: Trevor Vaughan
Status: Needs Decision
Priority: Low
Assignee:
Category: language
Target version:
Affected Puppet version:
Keywords:
Branch:
I would like the ability to, in the puppet language, check variables being
passed to a class or define for validity.
This can currently be done by throwing a ParseError from a template, but that
is quite syntactically heavy.
Current Case:
pre
define foo ( $bar ) {
inline_template(% if not ['true','false'].include?(bar) then raise
Puppet::ParseError.new(\$bar must be one of 'true', 'false'\)%)
}
/pre
Desired Case:
pre
define foo ( $bar, $baz ) {
validate {
bar = ['true','false'],
baz = '/fancy regex'
}
}
/pre
Not critical, just would add some awesomeness.
--
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 #14424] (Accepted) installation of a module fails
Issue #14424 has been updated by Kelsey Hightower. Status changed from Unreviewed to Accepted Assignee set to Kelsey Hightower Bug #14424: installation of a module fails https://projects.puppetlabs.com/issues/14424#change-62562 Author: Anand Kumria Status: Accepted Priority: Normal Assignee: Kelsey Hightower Category: Target version: Affected Puppet version: 2.7.14 Keywords: Branch: I use vagrant to test out my puppet manifests, so I want to specify a directory where I'd like things to be installed. % puppet module install -i mtest akumria-nullmailer Preparing to install into mtest ... Downloading from http://forge.puppetlabs.com ... Error: undefined method `each' for nil:NilClass Error: Try 'puppet help module install' for usage -- 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 #14306] puppet module tool version comparison issues.
Issue #14306 has been updated by Nan Liu. Which version of puppet was clean added to puppet module? pre $ puppet module clean err: 'module' has no 'clean' action. See `puppet help module`. $ puppet --version 2.7.14 $ puppet help module USAGE: puppet module action This subcommand can find, install, and manage modules from the Puppet Forge, a repository of user-contributed Puppet code. It can also generate empty modules, and prepare locally developed modules for release on the Forge. OPTIONS: --mode MODE- The run mode to use (user, agent, or master). --render-as FORMAT - The rendering format to use. --verbose - Whether to log verbosely. --debug- Whether to log debug information. ACTIONS: buildBuild a module release package. changes Show modified files of an installed module. generate Generate boilerplate for a new module. install Install a module from a repository or release archive. list List installed modules search Search a repository for a module. uninstallUninstall a puppet module. upgrade Upgrade a puppet module. See 'puppet man module' or 'man puppet-module' for full help. /pre Bug #14306: puppet module tool version comparison issues. https://projects.puppetlabs.com/issues/14306#change-62563 Author: Nan Liu Status: Investigating Priority: Normal Assignee: Kelsey Hightower Category: modules Target version: Affected Puppet version: 2.7.14 Keywords: Branch: Manually installation from tar.gz of module prerelease to forge shows it's having odd problems with version comparison. 0.0.3 is not greater than 0.0.2. pre $ puppet module install puppetlabs-apt-0.0.3.tar.gz --verbose Preparing to install into /Users/nan/.puppet/modules ... Downloading from http://forge.puppetlabs.com ... Error: Could not install module 'puppetlabs-apt' (v0.0.3) No version of 'puppetlabs-apt' will satisfy dependencies You specified 'puppetlabs-apt' (v0.0.3) 'puppetlabs-mongrodb' (v0.0.1) requires 'puppetlabs-apt' (= 0.0.2) Use `puppet module install --force` to install this module anyway /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 #14424] (In Topic Branch Pending Review) installation of a module fails
Issue #14424 has been updated by Kelsey Hightower. Status changed from Accepted to In Topic Branch Pending Review So I have a patch ready to go for this, the work-around for now would be to use the full path of the target directory. Bug #14424: installation of a module fails https://projects.puppetlabs.com/issues/14424#change-62564 Author: Anand Kumria Status: In Topic Branch Pending Review Priority: Normal Assignee: Kelsey Hightower Category: Target version: Affected Puppet version: 2.7.14 Keywords: Branch: I use vagrant to test out my puppet manifests, so I want to specify a directory where I'd like things to be installed. % puppet module install -i mtest akumria-nullmailer Preparing to install into mtest ... Downloading from http://forge.puppetlabs.com ... Error: undefined method `each' for nil:NilClass Error: Try 'puppet help module install' for usage -- 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 #14428] (Unreviewed) inconsistent options for module install / list
Issue #14428 has been reported by Anand Kumria. Bug #14428: inconsistent options for module install / list https://projects.puppetlabs.com/issues/14428 Author: Anand Kumria Status: Unreviewed Priority: Low Assignee: Category: Target version: Affected Puppet version: 2.7.14 Keywords: Branch: Whilst looking at the work-around mentiond in #14424, I became aware of an inconsistency with puppet module. % puppet module install -i `pwd`/mtest akumria-nullmailer Preparing to install into /home/anand/Work/linuxpeak/puppet27/mtest ... Downloading from http://forge.puppetlabs.com ... Installing -- do not interrupt ... /home/anand/Work/linuxpeak/puppet27/mtest └─┬ akumria-nullmailer (v1.0.1) └── puppetlabs-stdlib (v2.3.2) % puppet module list --tree --modulepath mtest /home/anand/Work/linuxpeak/puppet27/mtest └─┬ akumria-nullmailer (v1.0.1) └── puppetlabs-stdlib (v2.3.2) It would be nice if the same option to specify the location was used for all commands (note that the upgrade command does not even seem to take an option to specify the location of the modules). -- 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 #14428] inconsistent options for module install / list
Issue #14428 has been updated by Anand Kumria. Oh, see #14426 for the upgrade problem. Bug #14428: inconsistent options for module install / list https://projects.puppetlabs.com/issues/14428#change-62565 Author: Anand Kumria Status: Unreviewed Priority: Low Assignee: Category: Target version: Affected Puppet version: 2.7.14 Keywords: Branch: Whilst looking at the work-around mentiond in #14424, I became aware of an inconsistency with puppet module. % puppet module install -i `pwd`/mtest akumria-nullmailer Preparing to install into /home/anand/Work/linuxpeak/puppet27/mtest ... Downloading from http://forge.puppetlabs.com ... Installing -- do not interrupt ... /home/anand/Work/linuxpeak/puppet27/mtest └─┬ akumria-nullmailer (v1.0.1) └── puppetlabs-stdlib (v2.3.2) % puppet module list --tree --modulepath mtest /home/anand/Work/linuxpeak/puppet27/mtest └─┬ akumria-nullmailer (v1.0.1) └── puppetlabs-stdlib (v2.3.2) It would be nice if the same option to specify the location was used for all commands (note that the upgrade command does not even seem to take an option to specify the location of the modules). -- 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 #14429] (Unreviewed) Naginator should provide a way to change mode, owner and group for files it writtes.
Issue #14429 has been reported by Romain Vrignaud. Feature #14429: Naginator should provide a way to change mode, owner and group for files it writtes. https://projects.puppetlabs.com/issues/14429 Author: Romain Vrignaud Status: Unreviewed Priority: Normal Assignee: Category: Target version: Affected Puppet version: Keywords: Branch: Naginator write files with 600 mode. Nagios is run with user nagios and can't read its configuration file. I suggest that mode, owner and group be added during Naginator ressource definition. Regards, -- 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 #14424] installation of a module fails
Issue #14424 has been updated by Kelsey Hightower. Branch set to https://github.com/puppetlabs/puppet/pull/756 Bug #14424: installation of a module fails https://projects.puppetlabs.com/issues/14424#change-62566 Author: Anand Kumria Status: In Topic Branch Pending Review Priority: Normal Assignee: Kelsey Hightower Category: Target version: Affected Puppet version: 2.7.14 Keywords: Branch: https://github.com/puppetlabs/puppet/pull/756 I use vagrant to test out my puppet manifests, so I want to specify a directory where I'd like things to be installed. % puppet module install -i mtest akumria-nullmailer Preparing to install into mtest ... Downloading from http://forge.puppetlabs.com ... Error: undefined method `each' for nil:NilClass Error: Try 'puppet help module install' for usage -- 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 #14426] (Needs Decision) upgrading a module is not possible
Issue #14426 has been updated by Kelsey Hightower. Status changed from Unreviewed to Needs Decision Assignee set to Pieter van de Bruggen The the upgrade action only supports the `--environment` flag for setting the target directories to search for modules to upgrade. In order to use this you would have to use environments as described here: [http://docs.puppetlabs.com/guides/environment.html#configuring-environments-on-the-puppet-master](http://docs.puppetlabs.com/guides/environment.html#configuring-environments-on-the-puppet-master). But based on your use case, it seems you would like this to work with master-less setups. We may need to add the ability to set the target directory or module path for the upgrade command. It's seems environment alone is not sufficient. Pieter, I have the following questions for UX: * Should we attempt to normailize the options between commands? * Should we add a `--target-dir` or `--modulepath` flag to the upgrade command? Bug #14426: upgrading a module is not possible https://projects.puppetlabs.com/issues/14426#change-62567 Author: Anand Kumria Status: Needs Decision Priority: Normal Assignee: Pieter van de Bruggen Category: Target version: Affected Puppet version: 2.7.14 Keywords: Branch: I use vagrant to test my manifests before publishing, so I specify the location where modules should be installed. When attempting to upgrade a module, already installed. % puppet module install -i modules akumria-nullmailer Preparing to install into modules ... Error: Could not install module 'akumria-nullmailer' (latest) Module 'akumria-nullmailer' (v1.0.0) is already installed Use `puppet module upgrade` to install a different version Use `puppet module install --force` to re-install only this module Installation itself fails (see #14424), but I used the puppet-module gem to install this module. So, let's try an upgrade: % puppet module upgrade -i modules akumria-nullmailer Could not parse options: ambiguous option: -i Hmm, what about the longform version of this option? % puppet module upgrade --target-dir modules akumria-nullmailer Could not parse options: invalid option: --target-dir OK - perhaps it'll just figure things out magically: % puppet module upgrade akumria-nullmailer Preparing to upgrade 'akumria-nullmailer' ... Error: Could not upgrade module 'akumria-nullmailer' Module 'akumria-nullmailer' is not installed Use `puppet module install` to install this module -- 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 #14428] (Investigating) inconsistent options for module install / list
Issue #14428 has been updated by Kelsey Hightower. Description updated Status changed from Unreviewed to Investigating Assignee set to Pieter van de Bruggen I've added comments to #14426 related to the possible need to review and normalize the options between the commands. Bug #14428: inconsistent options for module install / list https://projects.puppetlabs.com/issues/14428#change-62568 Author: Anand Kumria Status: Investigating Priority: Low Assignee: Pieter van de Bruggen Category: Target version: Affected Puppet version: 2.7.14 Keywords: Branch: Whilst looking at the work-around mentiond in #14424, I became aware of an inconsistency with puppet module. % puppet module install -i `pwd`/mtest akumria-nullmailer Preparing to install into /home/anand/Work/linuxpeak/puppet27/mtest ... Downloading from http://forge.puppetlabs.com ... Installing -- do not interrupt ... /home/anand/Work/linuxpeak/puppet27/mtest └─┬ akumria-nullmailer (v1.0.1) └── puppetlabs-stdlib (v2.3.2) % puppet module list --tree --modulepath mtest /home/anand/Work/linuxpeak/puppet27/mtest └─┬ akumria-nullmailer (v1.0.1) └── puppetlabs-stdlib (v2.3.2) It would be nice if the same option to specify the location was used for all commands (note that the upgrade command does not even seem to take an option to specify the location of the modules). -- 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 #7731] install.rb doesn't honor --destdir with respect to /etc/puppet/auth.conf
Issue #7731 has been updated by Nigel Kersten. Assignee changed from Jonathan Grochowski to Matthaus Litteken Note the upstream Macports bug: http://trac.macports.org/ticket/29676 (It's set to open maintainer so anyone can submit patches, not just that lazy bastard who is the primary maintainer) Bug #7731: install.rb doesn't honor --destdir with respect to /etc/puppet/auth.conf https://projects.puppetlabs.com/issues/7731#change-62569 Author: Nigel Kersten Status: Accepted Priority: High Assignee: Matthaus Litteken Category: installation Target version: 2.7.x Affected Puppet version: Keywords: Branch: When you pass --destdir into install.rb, it still installs the config files in /etc/puppet, no matter what destdir is set to. -- 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 #11658] Noticed operatingsystemrelease isn't trying to use lsbdistrelease on Linux boxes
Issue #11658 has been updated by Hailee Kenney. Doing `lsbdistrelease` first for all Linuxes seems like a reversal of the `confine` logic, where it starts at most specific and then generalizes. Are we sure that's what we want? Bug #11658: Noticed operatingsystemrelease isn't trying to use lsbdistrelease on Linux boxes https://projects.puppetlabs.com/issues/11658#change-62571 Author: Joe McDonagh Status: Accepted Priority: Normal Assignee: Hailee Kenney Category: library Target version: Keywords: Branch: Affected Facter version: 1.6.4 Causing some of my code to fail on the upcoming Ubuntu LTS 12.04. Basically it's got a ton of conditionals in this file, which I can see the utility of having in case LSB isn't available. However, I think the more clever, and proper way to handle this, is on Facter.value(:kernel) == Linux, first try to use lsbdistrelease to fill in operatingsystemrelease if it's there, then fall back to these sort of rough around the edges determination methods if it's not available. This is what the fact operatingsystemrelease shows on my 12.04 test box: operatingsystemrelease = 3.2.0-2-generic This is cause it can't glean the info from /etc/issue (which is a pretty unreliable place to look for OS info) so it uses kernelrelease... I am kind of depending on a version here which is the other problem. Should this fact contain strings? I'd have a patch ready for you guys but I think this is a design question really... -- 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 #14428] inconsistent options for module install / list
Issue #14428 has been updated by Pieter van de Bruggen. `install`, `list`, `uninstall`, and `upgrade` all respect the `--modulepath` option for specifying module locations (and this *should* be documented), and this is the preferred way to specify a standalone installation directory. `--target-dir` (`-i`) is meant for when you want to install into a specific directory, but resolve dependencies against the modulepath. Bug #14428: inconsistent options for module install / list https://projects.puppetlabs.com/issues/14428#change-62573 Author: Anand Kumria Status: Investigating Priority: Low Assignee: Pieter van de Bruggen Category: Target version: Affected Puppet version: 2.7.14 Keywords: Branch: Whilst looking at the work-around mentiond in #14424, I became aware of an inconsistency with puppet module. % puppet module install -i `pwd`/mtest akumria-nullmailer Preparing to install into /home/anand/Work/linuxpeak/puppet27/mtest ... Downloading from http://forge.puppetlabs.com ... Installing -- do not interrupt ... /home/anand/Work/linuxpeak/puppet27/mtest └─┬ akumria-nullmailer (v1.0.1) └── puppetlabs-stdlib (v2.3.2) % puppet module list --tree --modulepath mtest /home/anand/Work/linuxpeak/puppet27/mtest └─┬ akumria-nullmailer (v1.0.1) └── puppetlabs-stdlib (v2.3.2) It would be nice if the same option to specify the location was used for all commands (note that the upgrade command does not even seem to take an option to specify the location of the modules). -- 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 #14426] upgrading a module is not possible
Issue #14426 has been updated by Pieter van de Bruggen. As mentioned in #14428: `install`, `list`, `uninstall`, and `upgrade` all respect the `--modulepath` option for specifying module locations (and this *should* be documented), and this is the preferred way to specify a standalone installation directory. `--target-dir` (`-i`) is meant for when you want to install into a specific directory, but resolve dependencies against the modulepath. It doesn't apply to anything except install. Bug #14426: upgrading a module is not possible https://projects.puppetlabs.com/issues/14426#change-62574 Author: Anand Kumria Status: Needs Decision Priority: Normal Assignee: Pieter van de Bruggen Category: Target version: Affected Puppet version: 2.7.14 Keywords: Branch: I use vagrant to test my manifests before publishing, so I specify the location where modules should be installed. When attempting to upgrade a module, already installed. % puppet module install -i modules akumria-nullmailer Preparing to install into modules ... Error: Could not install module 'akumria-nullmailer' (latest) Module 'akumria-nullmailer' (v1.0.0) is already installed Use `puppet module upgrade` to install a different version Use `puppet module install --force` to re-install only this module Installation itself fails (see #14424), but I used the puppet-module gem to install this module. So, let's try an upgrade: % puppet module upgrade -i modules akumria-nullmailer Could not parse options: ambiguous option: -i Hmm, what about the longform version of this option? % puppet module upgrade --target-dir modules akumria-nullmailer Could not parse options: invalid option: --target-dir OK - perhaps it'll just figure things out magically: % puppet module upgrade akumria-nullmailer Preparing to upgrade 'akumria-nullmailer' ... Error: Could not upgrade module 'akumria-nullmailer' Module 'akumria-nullmailer' is not installed Use `puppet module install` to install this module -- 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 #14426] upgrading a module is not possible
Issue #14426 has been updated by Anand Kumria. Confirmed that: puppet module upgrade --modulepath=mtest akumria-nullmailer works as expected. So this is more of a documentation / usage problem. Bug #14426: upgrading a module is not possible https://projects.puppetlabs.com/issues/14426#change-62575 Author: Anand Kumria Status: Needs Decision Priority: Normal Assignee: Pieter van de Bruggen Category: Target version: Affected Puppet version: 2.7.14 Keywords: Branch: I use vagrant to test my manifests before publishing, so I specify the location where modules should be installed. When attempting to upgrade a module, already installed. % puppet module install -i modules akumria-nullmailer Preparing to install into modules ... Error: Could not install module 'akumria-nullmailer' (latest) Module 'akumria-nullmailer' (v1.0.0) is already installed Use `puppet module upgrade` to install a different version Use `puppet module install --force` to re-install only this module Installation itself fails (see #14424), but I used the puppet-module gem to install this module. So, let's try an upgrade: % puppet module upgrade -i modules akumria-nullmailer Could not parse options: ambiguous option: -i Hmm, what about the longform version of this option? % puppet module upgrade --target-dir modules akumria-nullmailer Could not parse options: invalid option: --target-dir OK - perhaps it'll just figure things out magically: % puppet module upgrade akumria-nullmailer Preparing to upgrade 'akumria-nullmailer' ... Error: Could not upgrade module 'akumria-nullmailer' Module 'akumria-nullmailer' is not installed Use `puppet module install` to install this module -- 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 #12504] operatingsystemrelease doesn't work for Ubuntu LTS 12.04
Issue #12504 has been updated by Hailee Kenney. Reproduced this with the development version of precise. Bug #12504: operatingsystemrelease doesn't work for Ubuntu LTS 12.04 https://projects.puppetlabs.com/issues/12504#change-62580 Author: Ken Barber Status: Investigating Priority: Normal Assignee: Hailee Kenney Category: library Target version: 1.6.x Keywords: Branch: Affected Facter version: 1.6.5 As mentioned in #11658, /etc/issue seems to have changed so now operatingsystemrelease doesn't seem to work any more on Ubuntu LTS 12.04. We'll need to confirm the details, but it looks like this is real. -- 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 #12504] operatingsystemrelease doesn't work for Ubuntu LTS 12.04
Issue #12504 has been updated by Hailee Kenney. On the release version of precise: code prepuppet@ubuntu-12-04: /etc/apt$ facter operatingsystemrelease 12.04 /pre /code Do we really need to fix this since it's fine on the release version? Bug #12504: operatingsystemrelease doesn't work for Ubuntu LTS 12.04 https://projects.puppetlabs.com/issues/12504#change-62582 Author: Ken Barber Status: Investigating Priority: Normal Assignee: Hailee Kenney Category: library Target version: 1.6.x Keywords: Branch: Affected Facter version: 1.6.5 As mentioned in #11658, /etc/issue seems to have changed so now operatingsystemrelease doesn't seem to work any more on Ubuntu LTS 12.04. We'll need to confirm the details, but it looks like this is real. -- 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 #11658] Noticed operatingsystemrelease isn't trying to use lsbdistrelease on Linux boxes
Issue #11658 has been updated by Hailee Kenney. Facter works the way it should on the release version of Ubuntu 12.04: code prepuppet@ubuntu-12-04: /etc/apt$ facter operatingsystemrelease 12.04 /pre /code We still have the question about `lsbdistrelease`, but at least it's returning the right thing Ubuntu 12.04. Bug #11658: Noticed operatingsystemrelease isn't trying to use lsbdistrelease on Linux boxes https://projects.puppetlabs.com/issues/11658#change-62583 Author: Joe McDonagh Status: Accepted Priority: Normal Assignee: Hailee Kenney Category: library Target version: Keywords: Branch: Affected Facter version: 1.6.4 Causing some of my code to fail on the upcoming Ubuntu LTS 12.04. Basically it's got a ton of conditionals in this file, which I can see the utility of having in case LSB isn't available. However, I think the more clever, and proper way to handle this, is on Facter.value(:kernel) == Linux, first try to use lsbdistrelease to fill in operatingsystemrelease if it's there, then fall back to these sort of rough around the edges determination methods if it's not available. This is what the fact operatingsystemrelease shows on my 12.04 test box: operatingsystemrelease = 3.2.0-2-generic This is cause it can't glean the info from /etc/issue (which is a pretty unreliable place to look for OS info) so it uses kernelrelease... I am kind of depending on a version here which is the other problem. Should this fact contain strings? I'd have a patch ready for you guys but I think this is a design question really... -- 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 #14438] (Accepted) old puppet commands need to be removed from puppet packaging
Issue #14438 has been reported by Patrick Carlisle. Refactor #14438: old puppet commands need to be removed from puppet packaging https://projects.puppetlabs.com/issues/14438 Author: Patrick Carlisle Status: Accepted Priority: Normal Assignee: Matthaus Litteken Category: package Target version: Affected Puppet version: development Keywords: Branch: The following commands have been removed in Telly: filebucket pi puppetdoc ralsh puppetca puppetd puppetmasterd puppetqd puppetrun -- 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 #14440] (Accepted) Can't get help or man text for instrumentation_* faces via the API
Issue #14440 has been reported by Nick Fagerlund. Bug #14440: Can't get help or man text for instrumentation_* faces via the API https://projects.puppetlabs.com/issues/14440 Author: Nick Fagerlund Status: Accepted Priority: Normal Assignee: Chris Price Category: Target version: Affected Puppet version: Keywords: Branch: $ irb require 'puppet/face' = true manface=Puppet::Face[:man, '0.0.1'] helpface=Puppet::Face[:help, '0.0.1'] manface.man(facts) (whole man page for facts face) manface.man(instrumentation_data) RuntimeError: Could not find terminus for instrumentation_data from /Users/nick/src/puppet/lib/puppet/indirector/face.rb:125:in `indirection' from /Users/nick/src/puppet/lib/puppet/face/help/man.erb:123:in `man implementation, required on Ruby 1.8' from /Users/nick/src/puppet/lib/puppet/face/man.rb:54:in `man implementation, required on Ruby 1.8' from /Users/nick/src/puppet/lib/puppet/interface/action.rb+eval[wrapper]:207:in `__send__' from /Users/nick/src/puppet/lib/puppet/interface/action.rb+eval[wrapper]:207:in `man' from (irb):5 helpface.help(instrumentation_data) RuntimeError: Could not find terminus for instrumentation_data from /Users/nick/src/puppet/lib/puppet/indirector/face.rb:125:in `indirection' from /Users/nick/src/puppet/lib/puppet/face/help/face.erb:76:in `help implementation, required on Ruby 1.8' from /Users/nick/src/puppet/lib/puppet/face/help.rb:92:in `help implementation, required on Ruby 1.8' from /Users/nick/src/puppet/lib/puppet/interface/action.rb+eval[wrapper]:207:in `__send__' from /Users/nick/src/puppet/lib/puppet/interface/action.rb+eval[wrapper]:207:in `help' from (irb):7 Note that getting man text from the command line works fine; it's just from the API, and it's just for the `instrumentation_data, instrumentation_probe,` and `instrumentation_listener` faces. -- 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 #14440] Can't get help or man text for instrumentation_* faces via the API
Issue #14440 has been updated by Chris Price. This is also triggered by: rake gen_manpages Haven't dug into that yet but I presume that it ends up just executed the exact code that Nick included above. Bug #14440: Can't get help or man text for instrumentation_* faces via the API https://projects.puppetlabs.com/issues/14440#change-62590 Author: Nick Fagerlund Status: Accepted Priority: Normal Assignee: Chris Price Category: Target version: Affected Puppet version: Keywords: Branch: $ irb require 'puppet/face' = true manface=Puppet::Face[:man, '0.0.1'] helpface=Puppet::Face[:help, '0.0.1'] manface.man(facts) (whole man page for facts face) manface.man(instrumentation_data) RuntimeError: Could not find terminus for instrumentation_data from /Users/nick/src/puppet/lib/puppet/indirector/face.rb:125:in `indirection' from /Users/nick/src/puppet/lib/puppet/face/help/man.erb:123:in `man implementation, required on Ruby 1.8' from /Users/nick/src/puppet/lib/puppet/face/man.rb:54:in `man implementation, required on Ruby 1.8' from /Users/nick/src/puppet/lib/puppet/interface/action.rb+eval[wrapper]:207:in `__send__' from /Users/nick/src/puppet/lib/puppet/interface/action.rb+eval[wrapper]:207:in `man' from (irb):5 helpface.help(instrumentation_data) RuntimeError: Could not find terminus for instrumentation_data from /Users/nick/src/puppet/lib/puppet/indirector/face.rb:125:in `indirection' from /Users/nick/src/puppet/lib/puppet/face/help/face.erb:76:in `help implementation, required on Ruby 1.8' from /Users/nick/src/puppet/lib/puppet/face/help.rb:92:in `help implementation, required on Ruby 1.8' from /Users/nick/src/puppet/lib/puppet/interface/action.rb+eval[wrapper]:207:in `__send__' from /Users/nick/src/puppet/lib/puppet/interface/action.rb+eval[wrapper]:207:in `help' from (irb):7 Note that getting man text from the command line works fine; it's just from the API, and it's just for the `instrumentation_data, instrumentation_probe,` and `instrumentation_listener` faces. -- 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 #14440] Can't get help or man text for instrumentation_* faces via the API
Issue #14440 has been updated by Nick Fagerlund. Yeah, same code. Bug #14440: Can't get help or man text for instrumentation_* faces via the API https://projects.puppetlabs.com/issues/14440#change-62592 Author: Nick Fagerlund Status: Accepted Priority: Normal Assignee: Chris Price Category: Target version: Affected Puppet version: Keywords: Branch: $ irb require 'puppet/face' = true manface=Puppet::Face[:man, '0.0.1'] helpface=Puppet::Face[:help, '0.0.1'] manface.man(facts) (whole man page for facts face) manface.man(instrumentation_data) RuntimeError: Could not find terminus for instrumentation_data from /Users/nick/src/puppet/lib/puppet/indirector/face.rb:125:in `indirection' from /Users/nick/src/puppet/lib/puppet/face/help/man.erb:123:in `man implementation, required on Ruby 1.8' from /Users/nick/src/puppet/lib/puppet/face/man.rb:54:in `man implementation, required on Ruby 1.8' from /Users/nick/src/puppet/lib/puppet/interface/action.rb+eval[wrapper]:207:in `__send__' from /Users/nick/src/puppet/lib/puppet/interface/action.rb+eval[wrapper]:207:in `man' from (irb):5 helpface.help(instrumentation_data) RuntimeError: Could not find terminus for instrumentation_data from /Users/nick/src/puppet/lib/puppet/indirector/face.rb:125:in `indirection' from /Users/nick/src/puppet/lib/puppet/face/help/face.erb:76:in `help implementation, required on Ruby 1.8' from /Users/nick/src/puppet/lib/puppet/face/help.rb:92:in `help implementation, required on Ruby 1.8' from /Users/nick/src/puppet/lib/puppet/interface/action.rb+eval[wrapper]:207:in `__send__' from /Users/nick/src/puppet/lib/puppet/interface/action.rb+eval[wrapper]:207:in `help' from (irb):7 Note that getting man text from the command line works fine; it's just from the API, and it's just for the `instrumentation_data, instrumentation_probe,` and `instrumentation_listener` faces. -- 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 #14440] Can't get help or man text for instrumentation_* faces via the API
Issue #14440 has been updated by Chris Price.
Yup. puppet/tasks/rake/manpages.rake:52:
faces.each do |face|
File.open(./man/man8/puppet-#{face}.8.ronn, 'w') do |fh|
fh.write manface.man(#{face})
end
%x{#{ronn} #{ronn_args} ./man/man8/puppet-#{face}.8.ronn}
FileUtils.rm(./man/man8/puppet-#{face}.8.ronn)
end
Bug #14440: Can't get help or man text for instrumentation_* faces via the API
https://projects.puppetlabs.com/issues/14440#change-62593
Author: Nick Fagerlund
Status: Accepted
Priority: Normal
Assignee: Chris Price
Category:
Target version:
Affected Puppet version:
Keywords:
Branch:
$ irb
require 'puppet/face'
= true
manface=Puppet::Face[:man, '0.0.1']
helpface=Puppet::Face[:help, '0.0.1']
manface.man(facts)
(whole man page for facts face)
manface.man(instrumentation_data)
RuntimeError: Could not find terminus for instrumentation_data
from /Users/nick/src/puppet/lib/puppet/indirector/face.rb:125:in
`indirection'
from /Users/nick/src/puppet/lib/puppet/face/help/man.erb:123:in `man
implementation, required on Ruby 1.8'
from /Users/nick/src/puppet/lib/puppet/face/man.rb:54:in `man
implementation, required on Ruby 1.8'
from
/Users/nick/src/puppet/lib/puppet/interface/action.rb+eval[wrapper]:207:in
`__send__'
from
/Users/nick/src/puppet/lib/puppet/interface/action.rb+eval[wrapper]:207:in `man'
from (irb):5
helpface.help(instrumentation_data)
RuntimeError: Could not find terminus for instrumentation_data
from /Users/nick/src/puppet/lib/puppet/indirector/face.rb:125:in
`indirection'
from /Users/nick/src/puppet/lib/puppet/face/help/face.erb:76:in `help
implementation, required on Ruby 1.8'
from /Users/nick/src/puppet/lib/puppet/face/help.rb:92:in `help
implementation, required on Ruby 1.8'
from
/Users/nick/src/puppet/lib/puppet/interface/action.rb+eval[wrapper]:207:in
`__send__'
from
/Users/nick/src/puppet/lib/puppet/interface/action.rb+eval[wrapper]:207:in
`help'
from (irb):7
Note that getting man text from the command line works fine; it's just from the
API, and it's just for the `instrumentation_data, instrumentation_probe,` and
`instrumentation_listener` faces.
--
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 #14322] (In Topic Branch Pending Review) `puppet --version` does not return the current version
Issue #14322 has been updated by Daniel Pittman. Status changed from Accepted to In Topic Branch Pending Review Target version changed from 3.X to 3.0.0 Branch set to https://github.com/puppetlabs/puppet/pull/759 https://github.com/puppetlabs/puppet/pull/759 has a fix for this. Bug #14322: `puppet --version` does not return the current version https://projects.puppetlabs.com/issues/14322#change-62594 Author: Matthaus Litteken Status: In Topic Branch Pending Review Priority: Normal Assignee: Category: Target version: 3.0.0 Affected Puppet version: development Keywords: Branch: https://github.com/puppetlabs/puppet/pull/759 [root@localhost ~]# /usr/bin/puppet --version See 'puppet help' for help on available puppet subcommands `puppet agent --version` behaves as expected. This behavior was surprising. -- 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 #14440] Can't get help or man text for instrumentation_* faces via the API
Issue #14440 has been updated by Chris Price. The problem here is that Puppet::Util::Instrumentation.init() doesn't get called for the code path that the rake task is executing. The *real* problem is that we don't have an API, and the rake task is trying to use faces as an API even though we haven't really defined the allowable entry points and initialization steps. I am investigating to find the least evil spot(s) to call this initialization. Bug #14440: Can't get help or man text for instrumentation_* faces via the API https://projects.puppetlabs.com/issues/14440#change-62596 Author: Nick Fagerlund Status: Accepted Priority: Normal Assignee: Chris Price Category: Target version: Affected Puppet version: Keywords: Branch: $ irb require 'puppet/face' = true manface=Puppet::Face[:man, '0.0.1'] helpface=Puppet::Face[:help, '0.0.1'] manface.man(facts) (whole man page for facts face) manface.man(instrumentation_data) RuntimeError: Could not find terminus for instrumentation_data from /Users/nick/src/puppet/lib/puppet/indirector/face.rb:125:in `indirection' from /Users/nick/src/puppet/lib/puppet/face/help/man.erb:123:in `man implementation, required on Ruby 1.8' from /Users/nick/src/puppet/lib/puppet/face/man.rb:54:in `man implementation, required on Ruby 1.8' from /Users/nick/src/puppet/lib/puppet/interface/action.rb+eval[wrapper]:207:in `__send__' from /Users/nick/src/puppet/lib/puppet/interface/action.rb+eval[wrapper]:207:in `man' from (irb):5 helpface.help(instrumentation_data) RuntimeError: Could not find terminus for instrumentation_data from /Users/nick/src/puppet/lib/puppet/indirector/face.rb:125:in `indirection' from /Users/nick/src/puppet/lib/puppet/face/help/face.erb:76:in `help implementation, required on Ruby 1.8' from /Users/nick/src/puppet/lib/puppet/face/help.rb:92:in `help implementation, required on Ruby 1.8' from /Users/nick/src/puppet/lib/puppet/interface/action.rb+eval[wrapper]:207:in `__send__' from /Users/nick/src/puppet/lib/puppet/interface/action.rb+eval[wrapper]:207:in `help' from (irb):7 Note that getting man text from the command line works fine; it's just from the API, and it's just for the `instrumentation_data, instrumentation_probe,` and `instrumentation_listener` faces. -- 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 #14440] Can't get help or man text for instrumentation_* faces via the API
Issue #14440 has been updated by Chris Price. I have a fix for this, but it is stupid and it is a hack. I need to create another ticket explaining the larger problem before I am willing to push this up to github. Bug #14440: Can't get help or man text for instrumentation_* faces via the API https://projects.puppetlabs.com/issues/14440#change-62598 Author: Nick Fagerlund Status: Accepted Priority: Normal Assignee: Chris Price Category: Target version: Affected Puppet version: Keywords: Branch: $ irb require 'puppet/face' = true manface=Puppet::Face[:man, '0.0.1'] helpface=Puppet::Face[:help, '0.0.1'] manface.man(facts) (whole man page for facts face) manface.man(instrumentation_data) RuntimeError: Could not find terminus for instrumentation_data from /Users/nick/src/puppet/lib/puppet/indirector/face.rb:125:in `indirection' from /Users/nick/src/puppet/lib/puppet/face/help/man.erb:123:in `man implementation, required on Ruby 1.8' from /Users/nick/src/puppet/lib/puppet/face/man.rb:54:in `man implementation, required on Ruby 1.8' from /Users/nick/src/puppet/lib/puppet/interface/action.rb+eval[wrapper]:207:in `__send__' from /Users/nick/src/puppet/lib/puppet/interface/action.rb+eval[wrapper]:207:in `man' from (irb):5 helpface.help(instrumentation_data) RuntimeError: Could not find terminus for instrumentation_data from /Users/nick/src/puppet/lib/puppet/indirector/face.rb:125:in `indirection' from /Users/nick/src/puppet/lib/puppet/face/help/face.erb:76:in `help implementation, required on Ruby 1.8' from /Users/nick/src/puppet/lib/puppet/face/help.rb:92:in `help implementation, required on Ruby 1.8' from /Users/nick/src/puppet/lib/puppet/interface/action.rb+eval[wrapper]:207:in `__send__' from /Users/nick/src/puppet/lib/puppet/interface/action.rb+eval[wrapper]:207:in `help' from (irb):7 Note that getting man text from the command line works fine; it's just from the API, and it's just for the `instrumentation_data, instrumentation_probe,` and `instrumentation_listener` faces. -- 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 #14441] (Accepted) Clean up terrible hack in rake manpages task
Issue #14441 has been reported by Chris Price. Refactor #14441: Clean up terrible hack in rake manpages task https://projects.puppetlabs.com/issues/14441 Author: Chris Price Status: Accepted Priority: Urgent Assignee: Daniel Pittman Category: API Target version: Waldorf Affected Puppet version: Keywords: Branch: I had to add the following line to the manpages.rake file: Puppet::Util::Instrumentation.init() This is part of a broader problem that really may deserve its own ticket(s). The reason it is necessary is because there is state initialization that happens when you run code via puppet's application class (from the command line), but that same state initialization does *not* happen when you try to use a Face as API (library code). We need to put some real thought into what our official stance is on using puppet classes (faces or anything else) as API, and come up with a finite list of well-defined, contained, entry points. Once that is done we can make sure that state initialization is always triggered via those code paths, and that all initialization is consistent with what would happen if you ran via the command line. Then we should remove the hack from the rake task. -- 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 #14440] (In Topic Branch Pending Review) Can't get help or man text for instrumentation_* faces via the API
Issue #14440 has been updated by Chris Price. Status changed from Accepted to In Topic Branch Pending Review Branch set to https://github.com/puppetlabs/puppet/pull/763 Bug #14440: Can't get help or man text for instrumentation_* faces via the API https://projects.puppetlabs.com/issues/14440#change-62602 Author: Nick Fagerlund Status: In Topic Branch Pending Review Priority: Normal Assignee: Chris Price Category: Target version: Affected Puppet version: Keywords: Branch: https://github.com/puppetlabs/puppet/pull/763 $ irb require 'puppet/face' = true manface=Puppet::Face[:man, '0.0.1'] helpface=Puppet::Face[:help, '0.0.1'] manface.man(facts) (whole man page for facts face) manface.man(instrumentation_data) RuntimeError: Could not find terminus for instrumentation_data from /Users/nick/src/puppet/lib/puppet/indirector/face.rb:125:in `indirection' from /Users/nick/src/puppet/lib/puppet/face/help/man.erb:123:in `man implementation, required on Ruby 1.8' from /Users/nick/src/puppet/lib/puppet/face/man.rb:54:in `man implementation, required on Ruby 1.8' from /Users/nick/src/puppet/lib/puppet/interface/action.rb+eval[wrapper]:207:in `__send__' from /Users/nick/src/puppet/lib/puppet/interface/action.rb+eval[wrapper]:207:in `man' from (irb):5 helpface.help(instrumentation_data) RuntimeError: Could not find terminus for instrumentation_data from /Users/nick/src/puppet/lib/puppet/indirector/face.rb:125:in `indirection' from /Users/nick/src/puppet/lib/puppet/face/help/face.erb:76:in `help implementation, required on Ruby 1.8' from /Users/nick/src/puppet/lib/puppet/face/help.rb:92:in `help implementation, required on Ruby 1.8' from /Users/nick/src/puppet/lib/puppet/interface/action.rb+eval[wrapper]:207:in `__send__' from /Users/nick/src/puppet/lib/puppet/interface/action.rb+eval[wrapper]:207:in `help' from (irb):7 Note that getting man text from the command line works fine; it's just from the API, and it's just for the `instrumentation_data, instrumentation_probe,` and `instrumentation_listener` faces. -- 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 #14387] (In Topic Branch Pending Review) Puppet's Module face should send along an appropriate UA string
Issue #14387 has been updated by Andrew Parker. Status changed from Accepted to In Topic Branch Pending Review Branch set to https://github.com/puppetlabs/puppet/pull/762 https://github.com/puppetlabs/puppet/pull/762 Bug #14387: Puppet's Module face should send along an appropriate UA string https://projects.puppetlabs.com/issues/14387#change-62606 Author: Pieter van de Bruggen Status: In Topic Branch Pending Review Priority: Normal Assignee: Andrew Parker Category: Target version: 3.0.0 Affected Puppet version: Keywords: Branch: https://github.com/puppetlabs/puppet/pull/762 At present, the Module face makes its HTTP requests anonymously, which makes it somewhat more difficult to do analysis on adoption stats. Ideally, I'd like to see a user agent string like: PMT/1.0.2 (core) Puppet/3.0.0 (Ubuntu 10.04) PMT/1.0.2 (module) Puppet/3.0.0 (Ubuntu 10.04; PE 3.5.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 #14387] Puppet's Module face should send along an appropriate UA string
Issue #14387 has been updated by Andrew Parker. The version string will be `PMT/$face_version Puppet/$puppet_version ($os_name; $os_version) Ruby/$ruby_version ($ruby_release_date; $ruby_platform)` Bug #14387: Puppet's Module face should send along an appropriate UA string https://projects.puppetlabs.com/issues/14387#change-62604 Author: Pieter van de Bruggen Status: Accepted Priority: Normal Assignee: Andrew Parker Category: Target version: 3.0.0 Affected Puppet version: Keywords: Branch: At present, the Module face makes its HTTP requests anonymously, which makes it somewhat more difficult to do analysis on adoption stats. Ideally, I'd like to see a user agent string like: PMT/1.0.2 (core) Puppet/3.0.0 (Ubuntu 10.04) PMT/1.0.2 (module) Puppet/3.0.0 (Ubuntu 10.04; PE 3.5.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 #14442] (Unreviewed) `puppet help module install` shouldn't reference 'a private Forge-like repository'
Issue #14442 has been reported by Justin Stoller. Bug #14442: `puppet help module install` shouldn't reference 'a private Forge-like repository' https://projects.puppetlabs.com/issues/14442 Author: Justin Stoller Status: Unreviewed Priority: Normal Assignee: Category: documentation Target version: 2.7.x Affected Puppet version: 2.7.14 Keywords: module, help, doc Branch: When running: pre # puppet help module install /pre I see: pre Installs a module from the Puppet Forge, from a release archive file on-disk, or from a private Forge-like repository. /pre Yet we don't provide or support software or an external API for others to use or build off of to create a 'private Forge-like' repository. See https://groups.google.com/forum/#!msg/puppet-users/xvX5KkiHHr8/nMXLUbPYvfgJ -- 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 #14442] `puppet help module install` shouldn't reference 'a private Forge-like repository'
Issue #14442 has been updated by Justin Stoller. Assignee set to Justin Stoller Bug #14442: `puppet help module install` shouldn't reference 'a private Forge-like repository' https://projects.puppetlabs.com/issues/14442#change-62608 Author: Justin Stoller Status: Unreviewed Priority: Normal Assignee: Justin Stoller Category: documentation Target version: 2.7.x Affected Puppet version: 2.7.14 Keywords: module, help, doc Branch: When running: pre # puppet help module install /pre I see: pre Installs a module from the Puppet Forge, from a release archive file on-disk, or from a private Forge-like repository. /pre Yet we don't provide or support software or an external API for others to use or build off of to create a 'private Forge-like' repository. See https://groups.google.com/forum/#!msg/puppet-users/xvX5KkiHHr8/nMXLUbPYvfgJ -- 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 #14322] (Merged - Pending Release) `puppet --version` does not return the current version
Issue #14322 has been updated by Patrick Carlisle. Status changed from In Topic Branch Pending Review to Merged - Pending Release Bug #14322: `puppet --version` does not return the current version https://projects.puppetlabs.com/issues/14322#change-62609 Author: Matthaus Litteken Status: Merged - Pending Release Priority: Normal Assignee: Category: Target version: 3.0.0 Affected Puppet version: development Keywords: Branch: https://github.com/puppetlabs/puppet/pull/759 [root@localhost ~]# /usr/bin/puppet --version See 'puppet help' for help on available puppet subcommands `puppet agent --version` behaves as expected. This behavior was surprising. -- 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 #14442] `puppet help module install` shouldn't reference 'a private Forge-like repository'
Issue #14442 has been updated by Justin Stoller. Branch set to https://github.com/justinstoller/puppet/tree/bug/2.7.x/14442-dont_refer_to_features_that_dont_exist Reworded the help info, pull request here: https://github.com/puppetlabs/puppet/pull/764 Bug #14442: `puppet help module install` shouldn't reference 'a private Forge-like repository' https://projects.puppetlabs.com/issues/14442#change-62610 Author: Justin Stoller Status: Unreviewed Priority: Normal Assignee: Justin Stoller Category: documentation Target version: 2.7.x Affected Puppet version: 2.7.14 Keywords: module, help, doc Branch: https://github.com/justinstoller/puppet/tree/bug/2.7.x/14442-dont_refer_to_features_that_dont_exist When running: pre # puppet help module install /pre I see: pre Installs a module from the Puppet Forge, from a release archive file on-disk, or from a private Forge-like repository. /pre Yet we don't provide or support software or an external API for others to use or build off of to create a 'private Forge-like' repository. See https://groups.google.com/forum/#!msg/puppet-users/xvX5KkiHHr8/nMXLUbPYvfgJ -- 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 #14442] `puppet help module install` shouldn't reference 'a private Forge-like repository'
Issue #14442 has been updated by Nick Fagerlund. Haha, I did this at the same time. I found some extra references to a generic swap-out-able repo, so merge https://github.com/puppetlabs/puppet/pull/765 instead. Bug #14442: `puppet help module install` shouldn't reference 'a private Forge-like repository' https://projects.puppetlabs.com/issues/14442#change-62612 Author: Justin Stoller Status: Unreviewed Priority: Normal Assignee: Justin Stoller Category: documentation Target version: 2.7.x Affected Puppet version: 2.7.14 Keywords: module, help, doc Branch: https://github.com/justinstoller/puppet/tree/bug/2.7.x/14442-dont_refer_to_features_that_dont_exist When running: pre # puppet help module install /pre I see: pre Installs a module from the Puppet Forge, from a release archive file on-disk, or from a private Forge-like repository. /pre Yet we don't provide or support software or an external API for others to use or build off of to create a 'private Forge-like' repository. See https://groups.google.com/forum/#!msg/puppet-users/xvX5KkiHHr8/nMXLUbPYvfgJ -- 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 #12147] iphostnumber fact, on Darwin, is redundant to other cross-platform facts.
Issue #12147 has been updated by Jeff Weiss. Assignee set to Hailee Kenney Target version set to 2.0.0 Bug #12147: iphostnumber fact, on Darwin, is redundant to other cross-platform facts. https://projects.puppetlabs.com/issues/12147#change-62614 Author: Daniel Pittman Status: Accepted Priority: Normal Assignee: Hailee Kenney Category: Target version: 2.0.0 Keywords: Branch: Affected Facter version: `lib/facter/iphostnumber.rb` defines the primary IP address and primary mac of a Darwin system, and is redundant to other facts that extract the same thing. It should go away in favour of the other implementation, and be just a thin alias until we can kill the fact entirely. -- 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 #11466] Remove duplicated memorytotal fact
Issue #11466 has been updated by Jeff Weiss. Assignee set to Hailee Kenney Target version set to 2.0.0 Bug #11466: Remove duplicated memorytotal fact https://projects.puppetlabs.com/issues/11466#change-62615 Author: Adrien Thebo Status: Accepted Priority: Normal Assignee: Hailee Kenney Category: library Target version: 2.0.0 Keywords: Branch: Affected Facter version: 1.6.4 Two different facts, memorysize and memorytotal, were added for the amount of RAM in a box, which introduced some nasty breakages. To ensure backwards compatibility all facts were switched to memorysize, and memorytotal was created as a stub that referenced memorysize. This should be removed in the next major release. -- 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 #10225] virtual fact does not detect linux vserver host/guest correctly
Issue #10225 has been updated by Adrien Thebo.
Assignee deleted (Adrien Thebo)
Bug #10225: virtual fact does not detect linux vserver host/guest correctly
https://projects.puppetlabs.com/issues/10225#change-62616
Author: ghislain -
Status: Investigating
Priority: Normal
Assignee:
Category: library
Target version: 1.6.x
Keywords: vserver
Branch:
Affected Facter version: 1.6.2
the virtual fact does not work on vserver 2.3.1 because /proc/virtual is hidden
but still detected by facter:
The only REAL way to tell is to test /proc/self/status and look for the vxid,
if zero = host, if 1 = special spectator context facter will nerver see this
one, if more = guest
i wrote this one for me:
pre
if File.exists?(/proc/self/status)
File.open('/proc/self/status').each_line{ |s|
procstatus = s.split(': ');
if procstatus[0] == 'VxID'
if procstatus[1].strip! == '0'
# this is the host
Facter.add(vps) do
setcode{ vserverhost }
end
else
# this is the guest
Facter.add(vps) do
setcode{ vserverguest }
end
end
else
# pas un vserver
end
}
end
/pre
This does not relly on file xx or yy to be there it just test if the current
process has a virtual ID.
pre
GUEST:/%(root) facter virtual
vserver_host
GUEST:/%(root) grep -i VXid /proc/self/status
VxID: 40410
(root) vserver-info
Versions:
Kernel: 3.0.7-vs2.3.1aq
VS-API: 0x00020308
VCI: 0x13001f11
util-vserver: 0.30.216-pre2994; Oct 21 2011, 17:32:30
/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 - Feature #2157] External fact support
Issue #2157 has been updated by Adrien Thebo. Branch changed from https://github.com/kbarber/facter/tree/ticket/2157-external_fact_support to https://github.com/adrienthebo/facter/tree/ticket/master/2157-external_fact_support I've done a lot of work to split up Ken's work into a lot of small commits, but I don't have the bandwidth to finish this off. The code is at https://github.com/adrienthebo/facter/tree/ticket/master/2157-external_fact_support and while it could use some rebasing and squashing, the code looks solid (to me) and just needs a little gardening. Feature #2157: External fact support https://projects.puppetlabs.com/issues/2157#change-62617 Author: Paul Nasrat Status: Code Insufficient Priority: Normal Assignee: Adrien Thebo Category: interface Target version: 2.0.0 Keywords: Branch: https://github.com/adrienthebo/facter/tree/ticket/master/2157-external_fact_support Affected Facter version: Facter should support non-ruby facts, preferably in /etc/facter.d. It should support these facts being either executable, in which case the result is the value of the named fact, or in a data format such as yaml, in which case the data file is read in and interpreted as the fact value. It probably makes sense to initially stick to yaml for data formats, since json doesn't ship with ruby, and to also allow executable facts to return either a plain string or yaml. Note that we can do this without supporting any kind of overriding, but it'd be much better if we supported multiple (configurable?) fact directories, with a search path. Thus, if Facter shipped with /etc/facter.d/myfactname and you wanted to override it, you could do so by creating a new file and putting it in a higher-priority location rather than editing a file distributed with the core. Given we're adding structured data support, namespaced facts would be supported with directory structures; e.g., /etc/facter.d/my/fact/name would resolve to my::fact::name. Ideally, the long-term direction here would be not to require any pure-ruby facts, such that the Facter library could be rewritten in any other language and it would function the same, because all of its actual data is outside of 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.
[Facter - Feature #2157] External fact support
Issue #2157 has been updated by Adrien Thebo. Assignee deleted (Adrien Thebo) Feature #2157: External fact support https://projects.puppetlabs.com/issues/2157#change-62618 Author: Paul Nasrat Status: Code Insufficient Priority: Normal Assignee: Category: interface Target version: 2.0.0 Keywords: Branch: https://github.com/adrienthebo/facter/tree/ticket/master/2157-external_fact_support Affected Facter version: Facter should support non-ruby facts, preferably in /etc/facter.d. It should support these facts being either executable, in which case the result is the value of the named fact, or in a data format such as yaml, in which case the data file is read in and interpreted as the fact value. It probably makes sense to initially stick to yaml for data formats, since json doesn't ship with ruby, and to also allow executable facts to return either a plain string or yaml. Note that we can do this without supporting any kind of overriding, but it'd be much better if we supported multiple (configurable?) fact directories, with a search path. Thus, if Facter shipped with /etc/facter.d/myfactname and you wanted to override it, you could do so by creating a new file and putting it in a higher-priority location rather than editing a file distributed with the core. Given we're adding structured data support, namespaced facts would be supported with directory structures; e.g., /etc/facter.d/my/fact/name would resolve to my::fact::name. Ideally, the long-term direction here would be not to require any pure-ruby facts, such that the Facter library could be rewritten in any other language and it would function the same, because all of its actual data is outside of 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.
[Facter - Bug #11031] capturing ec2 userdata as a fact may be a security risk
Issue #11031 has been updated by Adrien Thebo. Assignee deleted (Adrien Thebo) Bug #11031: capturing ec2 userdata as a fact may be a security risk https://projects.puppetlabs.com/issues/11031#change-62619 Author: Dan Bode Status: Investigating Priority: Normal Assignee: Category: Target version: 1.6.x Keywords: Branch: Affected Facter version: When cloud-init is used for bootstrapping nodes, a script contained in the userdata is often passed to the node to perform bootstrapping. In the case of cloud formation, this script often contains IAM credentials (access code/secret code) that are used to call cfn-init. In my integration of PE with cloudformation, I can see the AWS credentials in the inventory service when running b/c they are captured as a part of the ec2 metadata. This is not that big of a deal for my use case b/c the credentials only refer to a temporary account that only has the permissions to read metadata from cloudformation instances. In general, I have concerns over rather capturing userdata with facter may potentially (and unexpectedly) expose a user's credentials in some cases. -- 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 #2211] Facter timeouts reap all subprocesses thus confusing Puppet
Issue #2211 has been updated by Adrien Thebo. Assignee deleted (Adrien Thebo) Bug #2211: Facter timeouts reap all subprocesses thus confusing Puppet https://projects.puppetlabs.com/issues/2211#change-62620 Author: John Florian Status: Accepted Priority: High Assignee: Category: library Target version: 1.6.x Keywords: Branch: Affected Facter version: It is no longer possible to have puppet install packages via yum/rpm if the network interface is not bound to an IP address. Our use case requires using puppet in the non-daemon mode and this is possible for us because the system will have all necessary manifests and other necessary files locally. This worked just fine with 0.24.6 on Fedora 10, but began failing upon the upgrade to 0.24.8. See the attachments for failure messages and a code diff that seems to have introduced the regression. If I revert this one change, things work nicely once again. Looks like a very simple fix if it weren't for the ominous looking comment in the code. :-) -- 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 #6955] Risk of malicious code execution
Issue #6955 has been updated by Jeff Weiss. Assignee set to Hailee Kenney Target version changed from 1.6.x to 2.0.0 Bug #6955: Risk of malicious code execution https://projects.puppetlabs.com/issues/6955#change-62621 Author: Jacek Masiulaniec Status: Accepted Priority: Urgent Assignee: Hailee Kenney Category: library Target version: 2.0.0 Keywords: Branch: Affected Facter version: Fact search path includes current working directory: [jacekm@localhost ~]$ ls facter ls: facter: No such file or directory [jacekm@localhost ~]$ facter /dev/null [jacekm@localhost ~]$ mkdir facter [jacekm@localhost ~]$ echo 'STDERR.puts evil code' facter/evil.rb [jacekm@localhost ~]$ facter /dev/null evil code [jacekm@localhost ~]$ This is harmful in multi-user environments: starting facter in specially crafted directory can result in malicious code execution. -- 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 - Feature #2157] External fact support
Issue #2157 has been updated by Jeff Weiss. Assignee set to Jeff Weiss Needs - rebase (off current tree?) - review - move addl functionality to atomic tickets pull reqs (eg powershell) - squashed ? We have docs already of what these external facts should look like with custom facts Feature #2157: External fact support https://projects.puppetlabs.com/issues/2157#change-62622 Author: Paul Nasrat Status: Code Insufficient Priority: Normal Assignee: Jeff Weiss Category: interface Target version: 2.0.0 Keywords: Branch: https://github.com/adrienthebo/facter/tree/ticket/master/2157-external_fact_support Affected Facter version: Facter should support non-ruby facts, preferably in /etc/facter.d. It should support these facts being either executable, in which case the result is the value of the named fact, or in a data format such as yaml, in which case the data file is read in and interpreted as the fact value. It probably makes sense to initially stick to yaml for data formats, since json doesn't ship with ruby, and to also allow executable facts to return either a plain string or yaml. Note that we can do this without supporting any kind of overriding, but it'd be much better if we supported multiple (configurable?) fact directories, with a search path. Thus, if Facter shipped with /etc/facter.d/myfactname and you wanted to override it, you could do so by creating a new file and putting it in a higher-priority location rather than editing a file distributed with the core. Given we're adding structured data support, namespaced facts would be supported with directory structures; e.g., /etc/facter.d/my/fact/name would resolve to my::fact::name. Ideally, the long-term direction here would be not to require any pure-ruby facts, such that the Facter library could be rewritten in any other language and it would function the same, because all of its actual data is outside of 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.
[Facter - Feature #2157] External fact support
Issue #2157 has been updated by Jeff Weiss. Target version changed from 2.0.0 to 2.X Feature #2157: External fact support https://projects.puppetlabs.com/issues/2157#change-62623 Author: Paul Nasrat Status: Code Insufficient Priority: Normal Assignee: Jeff Weiss Category: interface Target version: 2.X Keywords: Branch: https://github.com/adrienthebo/facter/tree/ticket/master/2157-external_fact_support Affected Facter version: Facter should support non-ruby facts, preferably in /etc/facter.d. It should support these facts being either executable, in which case the result is the value of the named fact, or in a data format such as yaml, in which case the data file is read in and interpreted as the fact value. It probably makes sense to initially stick to yaml for data formats, since json doesn't ship with ruby, and to also allow executable facts to return either a plain string or yaml. Note that we can do this without supporting any kind of overriding, but it'd be much better if we supported multiple (configurable?) fact directories, with a search path. Thus, if Facter shipped with /etc/facter.d/myfactname and you wanted to override it, you could do so by creating a new file and putting it in a higher-priority location rather than editing a file distributed with the core. Given we're adding structured data support, namespaced facts would be supported with directory structures; e.g., /etc/facter.d/my/fact/name would resolve to my::fact::name. Ideally, the long-term direction here would be not to require any pure-ruby facts, such that the Facter library could be rewritten in any other language and it would function the same, because all of its actual data is outside of 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.
[Facter - Bug #3357] fact fqdn doesn't get set if domain fact isn't set
Issue #3357 has been updated by Jeff Weiss. Target version changed from 1.6.x to 2.0.0 Bug #3357: fact fqdn doesn't get set if domain fact isn't set https://projects.puppetlabs.com/issues/3357#change-62624 Author: Simon Hürlimann Status: Requires CLA to be signed Priority: Normal Assignee: Category: library Target version: 2.0.0 Keywords: domain, fqdn Branch: Affected Facter version: 1.6.3 If the domain fact doesn't get a value (see #3356) the fqdn isn't set either. But it should probably be just the hostname in this case. Think may break in very interesting ways when using fqdn in your pupper recipes, but it won't be set. See https://bugs.launchpad.net/bugs/534773 as an example;-) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Facter - Feature #4519] Facter should provide a convenient way to cache values
Issue #4519 has been updated by Jeff Weiss. Target version changed from 2.0.0 to 2.X Feature #4519: Facter should provide a convenient way to cache values https://projects.puppetlabs.com/issues/4519#change-62626 Author: Peter Meier Status: Accepted Priority: Normal Assignee: Category: library Target version: 2.X Keywords: Branch: https://github.com/kbarber/facter/tree/ticket/4519-cache Affected Facter version: I think this have discussed already various times and it is even planned?!. But I couldn't find a logged ticket and as I stumpled over that problem once again I thought I might want to file a feature request: Facter should provide a way to: 1. cache facts with a certain timeout, so that the fact value gets cache for the defined time 1. provide a way to cache any kind of data for a certain amount of time Why? We might want to have facts that take some time to calculate, however that don't change much. Or there might be data required to calucate a certain fact which high resource intensive, but doesn't change often. So what I like to have is similar to the @confine@ a way to set @timeout@, so that if this is set to some seconds/minutes (?) the fact isn't calculated again until the timeout expired. For the second point I'd like to have a simple key value store with timeout capability built into facter, so I can cache output of commands, which can then be used amongst different facts. Example: xen management tools are getting slower the more VMs you start. Hence @xm list@ can get slower and slower and if you have various facts that are depending on the output of that command and you take the naive approach and call @xm list@ a couple of times, you slowdown facter and hence puppet runs enormously. If I have only one fact using the output it would be nice to let facter cache that fact. However, if I have multiple facts depending on the output of @xm list@ I might want to cache also the output of @xm list@ so that @xm list@ is called really only once per facter run. Currently you can do that with your own cache implementation hacked into facts, but I think it would be nicer if facter would provide a convenient way to cache things. -- 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 #2179] IP support calls 'ip' and 'ifconfig' ridiculous numbers of times
Issue #2179 has been updated by Jeff Weiss. Target version changed from 2.0.0 to 2.X Bug #2179: IP support calls 'ip' and 'ifconfig' ridiculous numbers of times https://projects.puppetlabs.com/issues/2179#change-62627 Author: Luke Kanies Status: Accepted Priority: High Assignee: Category: library Target version: 2.X Keywords: caching, ifconfig, interfaces Branch: Affected Facter version: I've got a client who says that they're each being called something like 1500 times, and Facter is taking 25% of the total run time. I am going to try to get a quick caching system in place for 1.5.5, but we can bump it if we have to. -- 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 #12723] (In Topic Branch Pending Review) Puppet apply freezes occasionally
Issue #12723 has been updated by James Turnbull. Status changed from Investigating to In Topic Branch Pending Review Branch set to https://github.com/puppetlabs/facter/pull/174 Bug #12723: Puppet apply freezes occasionally https://projects.puppetlabs.com/issues/12723#change-62629 Author: Timur Batyrshin Status: In Topic Branch Pending Review Priority: Normal Assignee: Category: library Target version: 2.X Keywords: Branch: https://github.com/puppetlabs/facter/pull/174 Affected Facter version: I've stumbled recently on puppet hanging occasionally in Ubuntu 10.04 run on t1.micro x64 EC2 instace. Say, 1 out of 3 complex and long puppet apply runs got frozen with process zombified aside. While hanging it was impossible to terminate puppet through usual Ctrl-C however it honored SIGTERM. Tracing back the freeze have lead to Facter using Thread::exclusive in couple of places. Here is my pull request for the fix: https://github.com/puppetlabs/facter/pull/174 After removing Thread::exclusive section the freezes disappeared. These lines were introduced through a series of commits: https://github.com/puppetlabs/facter/commit/c2aa5086ab55da9c708d962b84a1b85404fc6329 (for processor.rb) https://github.com/puppetlabs/facter/commit/a633aebab4dc4d07119a619c21cad6a719552083 (for memory.rb) I see no reason for running the code here in exclusive threads as it only does simple file read and calculation using local variables and does not address anything outside its own block. The original commits neither do clarify the reason for using exclusive threads here. -- 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 #14443] (Unreviewed) Always produce a backtrace on unhandled errors
Issue #14443 has been reported by Andrew Parker. Feature #14443: Always produce a backtrace on unhandled errors https://projects.puppetlabs.com/issues/14443 Author: Andrew Parker Status: Unreviewed Priority: Normal Assignee: Category: Target version: Affected Puppet version: Keywords: Branch: Right now puppet will write errors to the log file such as err: Could not retrieve catalog from remote server: Error 400 on SERVER: Puppet::Parser::AST::Variable failed with error NoMethodError: undefined method `twoscope_lookupvar' for nil:NilClass at /etc/puppet/site/modules/[...]/init.pp:2863 on node [...] In any case like this we need to make sure that there is always a backtrace available with the unhandled error. Quite often it is difficult to get a reproduction of the error from a user that might produce the backtrace and so debugging the issue can become nearly impossible. We should also consider producing some other information what would be useful for a bug report in this case. -- 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 #14343] undefined method twoscope_lookupvar while looking for top scope or facter variables
Issue #14343 has been updated by Andrew Parker.
Does your example in `t.pp` cause the error for you if you serve it from a
puppet master? I tried using it and still did not get your error.
Bug #14343: undefined method twoscope_lookupvar while looking for top scope or
facter variables
https://projects.puppetlabs.com/issues/14343#change-62630
Author: konrad rzentarzewski
Status: Needs More Information
Priority: Normal
Assignee: Andrew Parker
Category: compiler
Target version:
Affected Puppet version: 2.7.14
Keywords:
Branch:
with upgrade to 2.7.14 comes the following error from puppetmasters:
err: Could not retrieve catalog from remote server: Error 400 on SERVER:
Puppet::Parser::AST::Variable failed with error NoMethodError: undefined method
`twoscope_lookupvar' for nil:NilClass at
/etc/puppet/site/modules/[...]/init.pp:2863 on node [...]
referenced module code is just a top scope or facter variable lookup, ie.
exec { load-cluster-conf: command = cman_tool version -r
$clusterversion }
it seems that twoscope_lookupvar is not visible in puppet classes.
the following patch fixes this behaviour.
--
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 #14200] (Merged - Pending Release) puppet 'help' docs show invalid description of 'resource'
Issue #14200 has been updated by Daniel Pittman. Status changed from In Topic Branch Pending Review to Merged - Pending Release Bug #14200: puppet 'help' docs show invalid description of 'resource' https://projects.puppetlabs.com/issues/14200#change-62631 Author: Chris Price Status: Merged - Pending Release Priority: Urgent Assignee: Chris Price Category: Faces Target version: 3.0.0 Affected Puppet version: Keywords: Branch: https://github.com/puppetlabs/puppet/pull/754 Current state of the world: run 'puppet help', and you will get the following description for 'resource': resource API only: interact directly with resources via the RAL. This is the help for the resource *Face*. However, when you actually run 'puppet resource' on the command line, you end up running the resource *Application*. So the help docs are completely incorrect. This is an artifact of the fact that when generating help we scan the Faces first, and assume that they all must have a corresponding application. Most of them do, but at least the resource one does not. Then, when we scan the Applications, we throw out any of the ones for which we already found a face by the same name. Proposed changes: 1. Change the 'help' face to only scan the applications directory. For each application, if it inherits from FaceBase, then we'll go grab the docs from the Face. If not we'll grab the docs from the application. 2. While I'm in here, I'd like to change the ERB template so that our 'help' screen doesn't differentiate between faces and apps. Users running this command are just looking for docs for command line tools. They aren't going to care about the implementation details of a particular tool, and I don't see any reason to force that information on them. Also while I'm in here, I will explore puppet help resource and make sure it's not skipping over the application and going to the face, because that is not useful for a command-line user. -- 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 #14424] (Merged - Pending Release) installation of a module fails
Issue #14424 has been updated by Daniel Pittman. Status changed from In Topic Branch Pending Review to Merged - Pending Release Target version set to 2.7.15 Bug #14424: installation of a module fails https://projects.puppetlabs.com/issues/14424#change-62632 Author: Anand Kumria Status: Merged - Pending Release Priority: Normal Assignee: Kelsey Hightower Category: Target version: 2.7.15 Affected Puppet version: 2.7.14 Keywords: Branch: https://github.com/puppetlabs/puppet/pull/756 I use vagrant to test out my puppet manifests, so I want to specify a directory where I'd like things to be installed. % puppet module install -i mtest akumria-nullmailer Preparing to install into mtest ... Downloading from http://forge.puppetlabs.com ... Error: undefined method `each' for nil:NilClass Error: Try 'puppet help module install' for usage -- 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 #14387] (Merged - Pending Release) Puppet's Module face should send along an appropriate UA string
Issue #14387 has been updated by Daniel Pittman. Status changed from In Topic Branch Pending Review to Merged - Pending Release Bug #14387: Puppet's Module face should send along an appropriate UA string https://projects.puppetlabs.com/issues/14387#change-62633 Author: Pieter van de Bruggen Status: Merged - Pending Release Priority: Normal Assignee: Andrew Parker Category: Target version: 3.0.0 Affected Puppet version: Keywords: Branch: https://github.com/puppetlabs/puppet/pull/762 At present, the Module face makes its HTTP requests anonymously, which makes it somewhat more difficult to do analysis on adoption stats. Ideally, I'd like to see a user agent string like: PMT/1.0.2 (core) Puppet/3.0.0 (Ubuntu 10.04) PMT/1.0.2 (module) Puppet/3.0.0 (Ubuntu 10.04; PE 3.5.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 #14440] Can't get help or man text for instrumentation_* faces via the API
Issue #14440 has been updated by Daniel Pittman. Awesome. Thanks for the work-around; happy to merge that for now. Bug #14440: Can't get help or man text for instrumentation_* faces via the API https://projects.puppetlabs.com/issues/14440#change-62634 Author: Nick Fagerlund Status: In Topic Branch Pending Review Priority: Normal Assignee: Chris Price Category: Target version: Affected Puppet version: Keywords: Branch: https://github.com/puppetlabs/puppet/pull/763 $ irb require 'puppet/face' = true manface=Puppet::Face[:man, '0.0.1'] helpface=Puppet::Face[:help, '0.0.1'] manface.man(facts) (whole man page for facts face) manface.man(instrumentation_data) RuntimeError: Could not find terminus for instrumentation_data from /Users/nick/src/puppet/lib/puppet/indirector/face.rb:125:in `indirection' from /Users/nick/src/puppet/lib/puppet/face/help/man.erb:123:in `man implementation, required on Ruby 1.8' from /Users/nick/src/puppet/lib/puppet/face/man.rb:54:in `man implementation, required on Ruby 1.8' from /Users/nick/src/puppet/lib/puppet/interface/action.rb+eval[wrapper]:207:in `__send__' from /Users/nick/src/puppet/lib/puppet/interface/action.rb+eval[wrapper]:207:in `man' from (irb):5 helpface.help(instrumentation_data) RuntimeError: Could not find terminus for instrumentation_data from /Users/nick/src/puppet/lib/puppet/indirector/face.rb:125:in `indirection' from /Users/nick/src/puppet/lib/puppet/face/help/face.erb:76:in `help implementation, required on Ruby 1.8' from /Users/nick/src/puppet/lib/puppet/face/help.rb:92:in `help implementation, required on Ruby 1.8' from /Users/nick/src/puppet/lib/puppet/interface/action.rb+eval[wrapper]:207:in `__send__' from /Users/nick/src/puppet/lib/puppet/interface/action.rb+eval[wrapper]:207:in `help' from (irb):7 Note that getting man text from the command line works fine; it's just from the API, and it's just for the `instrumentation_data, instrumentation_probe,` and `instrumentation_listener` faces. -- 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 #13559] (Merged - Pending Release) Telly requires a single console log output mechanism, but will have two after PMT merges up.
Issue #13559 has been updated by Daniel Pittman. Status changed from Code Insufficient to Merged - Pending Release Bug #13559: Telly requires a single console log output mechanism, but will have two after PMT merges up. https://projects.puppetlabs.com/issues/13559#change-62635 Author: Daniel Pittman Status: Merged - Pending Release Priority: Urgent Assignee: Chris Price Category: logging Target version: 3.0.0 Affected Puppet version: Keywords: Branch: https://github.com/puppetlabs/puppet/pull/692 While the PMT work was underway, a new console output mechanism was needed. This was added in 2.7.x, the stable series, as an addition used only in the PMT code itself. Now that has merged to the main tree, and we are starting to look at Telly, we need to have this fixed. We can't ship Telly with two log output mechanisms. -- 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 #6955] Risk of malicious code execution
Issue #6955 has been updated by Jeff Weiss. Looking at this and thinking that perhaps instead of excluding `.` and anything beginning with `..` (my first thought), but rather excluding anything that isn't explicitly an absolute directory. We'll need to make certain that we don't screw up windows when we do that. Bug #6955: Risk of malicious code execution https://projects.puppetlabs.com/issues/6955#change-62636 Author: Jacek Masiulaniec Status: Accepted Priority: Urgent Assignee: Hailee Kenney Category: library Target version: 2.0.0 Keywords: Branch: Affected Facter version: Fact search path includes current working directory: [jacekm@localhost ~]$ ls facter ls: facter: No such file or directory [jacekm@localhost ~]$ facter /dev/null [jacekm@localhost ~]$ mkdir facter [jacekm@localhost ~]$ echo 'STDERR.puts evil code' facter/evil.rb [jacekm@localhost ~]$ facter /dev/null evil code [jacekm@localhost ~]$ This is harmful in multi-user environments: starting facter in specially crafted directory can result in malicious code execution. -- 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 #6955] (In Topic Branch Pending Review) Risk of malicious code execution
Issue #6955 has been updated by Jeff Weiss. Status changed from Accepted to In Topic Branch Pending Review Assignee changed from Hailee Kenney to Jeff Weiss Branch set to https://github.com/puppetlabs/facter/pull/203 Bug #6955: Risk of malicious code execution https://projects.puppetlabs.com/issues/6955#change-62640 Author: Jacek Masiulaniec Status: In Topic Branch Pending Review Priority: Urgent Assignee: Jeff Weiss Category: library Target version: 2.0.0 Keywords: Branch: https://github.com/puppetlabs/facter/pull/203 Affected Facter version: Fact search path includes current working directory: [jacekm@localhost ~]$ ls facter ls: facter: No such file or directory [jacekm@localhost ~]$ facter /dev/null [jacekm@localhost ~]$ mkdir facter [jacekm@localhost ~]$ echo 'STDERR.puts evil code' facter/evil.rb [jacekm@localhost ~]$ facter /dev/null evil code [jacekm@localhost ~]$ This is harmful in multi-user environments: starting facter in specially crafted directory can result in malicious code execution. -- 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 #11466] (In Topic Branch Pending Review) Remove duplicated memorytotal fact
Issue #11466 has been updated by Jeff Weiss. Status changed from Accepted to In Topic Branch Pending Review Assignee changed from Hailee Kenney to Jeff Weiss Branch set to https://github.com/puppetlabs/facter/pull/204 Bug #11466: Remove duplicated memorytotal fact https://projects.puppetlabs.com/issues/11466#change-62641 Author: Adrien Thebo Status: In Topic Branch Pending Review Priority: Normal Assignee: Jeff Weiss Category: library Target version: 2.0.0 Keywords: Branch: https://github.com/puppetlabs/facter/pull/204 Affected Facter version: 1.6.4 Two different facts, memorysize and memorytotal, were added for the amount of RAM in a box, which introduced some nasty breakages. To ensure backwards compatibility all facts were switched to memorysize, and memorytotal was created as a stub that referenced memorysize. This should be removed in the next major release. -- 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 - Feature #12790] (Merged - Pending Release) Facter should fail if a recursion is detected
Issue #12790 has been updated by Daniel Pittman. Status changed from In Topic Branch Pending Review to Merged - Pending Release Target version set to 2.0.0 Thanks so much for that submission. Sorry it took so long to merge. Feature #12790: Facter should fail if a recursion is detected https://projects.puppetlabs.com/issues/12790#change-62642 Author: Stefan Schulte Status: Merged - Pending Release Priority: Normal Assignee: Category: Target version: 2.0.0 Keywords: Branch: https://github.com/puppetlabs/facter/pull/179 Affected Facter version: Facter already detects recursions (`fact a queries fact b queries fact a`) but instead of raising an exception or at least print a warning it will just return nil as the fact value and print a debug message (`Facter::Util::Fact#searching`) As seen in #11511 recursions can be hard to detect and can lead to unexpected results. In my opinion a recursion is never `expected behaviour`. -- 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 #7484] (Merged - Pending Release) facter fqdn is empty when domainnames aren't containing any dot (ie tld)
Issue #7484 has been updated by Daniel Pittman.
Status changed from In Topic Branch Pending Review to Merged - Pending Release
We believe that this has been fixed, and should be resolved in the release of
Facter 2.0.0
Bug #7484: facter fqdn is empty when domainnames aren't containing any dot (ie
tld)
https://projects.puppetlabs.com/issues/7484#change-62643
Author: Edouard Bourguignon
Status: Merged - Pending Release
Priority: Normal
Assignee: Hailee Kenney
Category: library
Target version: 2.0.0
Keywords: tld fqdn hostname dot intern
Branch: https://github.com/puppetlabs/facter/pull/199
Affected Facter version:
As far as I understand the following regexp used in domain.rb to find out the
domainname:
domain = Facter::Util::Resolution.exec('dnsdomainname')
next domain if domain =~ /.+\..+/
domainname must contain a dot, which is not completely compliant with RFCs[¹]
and prevent using facter on tld servers.
How to reproduce:
On a server with fqdn ns01.tld, this is the result of some commands:
* hostname = ns01 (OK)
* hostname -f = ns01.tld (OK)
* facter hostname = ns01 (OK)
* facter fqdn = (bad)
* dnsdomainname = tld (OK) but dnsdomainname command had to be installed
facter fqdn should return ns01.tld and should be (insvery important/ins)
consistent with hostname -f.
[1]: RFC921: Every current name in this new system has the form
old-simple-name.ARPA. That is, the all the hosts are in a
domain called ARPA
--
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.
