date:20130221

[Puppet - Bug #19315] puppet is buggy when using a hash as a $name

2013-02-21 Thread tickets


Issue #19315 has been updated by James Shubin.


You do have some interesting points. Hopefully I'll be able to address them 
adequately:

I guess the reason why I think it makes sense is that I see $name as a 
variable, and logically it makes sense to allow any first class type. (Why 
should a string be special?)

In practical terms, the $name is the unique identifier of the object; for a 
list:

$thing = [
{'keya' => 'value1', 'keyb' => 'value1'},
{'keya' => 'value2', 'keyb' => 'value2'}
]

that exists as input for a list of objects, using the hash is the only way to 
guarantee uniqueness.
I used to use the hash as the $name, but as mentioned in this bug report, I've 
had some bugs pop up. My workaround has been to "hash the hash" to create a new 
unique name:


$newname = split(inline_template('<%= thing.map{|x| x.is_a?(Hash) ? 
(x["keya"].to_s + "-" + x["keyb"].to_s) : x}.join("#") %>'), '#')


... and then inside the define, I split apart the values I wanted from the 
dashes, and use them. There's no other way to use an array of hashes, as input 
to a define, and be able to pass the hash into the define too, unless puppet 
invents some new constructs that you've alluded to.

Anyways, hopefully we can fix the 'pson' bug I'm seeing. It doesn't make sense 
that it only breaks when run through the puppetmaster, since the code itself 
obviously works fine when run in standalone mode. Let's let it keep working 
until we have something better in place.



Bug #19315: puppet is buggy when using a hash as a $name
https://projects.puppetlabs.com/issues/19315#change-83705

Author: James Shubin
Status: Unreviewed
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 
Keywords: 
Branch: 




It turns out if you're doing some fancy puppet work, it is sometimes useful to 
use a hash as a $name var.
In my particular case, I'm actually passing an array of hashes to a define 
(which ultimately causes the define to be called once for each hash).
This actually works perfectly when run locally with puppet apply, however when 
running with puppet agent --test, it sometimes works and sometimes fails with:

Error: Could not retrieve catalog from remote server: Could not intern from 
pson: Could not convert from pson: Could not find relationship source 
"Foo::Bar::My_define[sourcedmzaddress192.168.101.200]"

The hash I used was:
{'source' => 'dmz', 'address' => '192.168.101.200'}

A few comments:
1. It's strange that the execution is not deterministic. Why does it sometimes 
work and sometimes not?
2. It's odd that it *always* works locally, but not always when through the 
puppet master.
3. The error message is confusing, not sure what it is trying to tell me.

Thanks,
James




-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #17030] pip provider should handle multiple pips/pythons

2013-02-21 Thread tickets


Issue #17030 has been updated by Adrien Thebo.


I spoke with Jeff about this and the preferred resolution is to try pip if it's 
available and then fall back to pip-python on Redhat. On other platforms we 
just just probe for pip.

In addition it might be worthwhile to check the pip version to ensure that 
we're getting the python pip instead of the perl pip.

Bug #17030: pip provider should handle multiple pips/pythons
https://projects.puppetlabs.com/issues/17030#change-83703

Author: Bradley Kreider
Status: Needs More Information
Priority: Normal
Assignee: 
Category: provider
Target version: 
Affected Puppet version: 2.6.17
Keywords: 
Branch: https://github.com/puppetlabs/puppet/pull/1486


The Pip provider should provide a way to specify the path to pip.  This would 
allow people to manage multiple python installs, by point to the one they want 
to install into.  

In RHEL, this makes it easy to have a non-system python installed somewhere 
(ie: 2.7 or 3.x) and let puppet manage the python packages.

This is related to bug #15980.  (related in the way that if you could provide 
the path to the pip binary, 15980 would have a workaround).


-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #5517] behavior change within 2.6 makes it impossible to override class parameters of "included" parametrized classes

2013-02-21 Thread tickets


Issue #5517 has been updated by Luke Kanies.


You're right that it's basically impossible to escape pathological cases.

I think we can get fantastically close by switching to lazy on-demand 
evaluation and then at least throwing a warning if someone tries to override a 
class that's already been evaluated, though.

Bug #5517: behavior change within 2.6 makes it impossible to override class 
parameters of "included" parametrized classes
https://projects.puppetlabs.com/issues/5517#change-83702

Author: Peter Meier
Status: Accepted
Priority: High
Assignee: eric sorenson
Category: language
Target version: 3.x
Affected Puppet version: 3.0.2
Keywords: parameterized_classes
Branch: 


In 2.6.1 the following recipe:


class a(
  $b_c = { 'b' => 'foo' }
) {
  notice $a::b_c
  if $a::b_c {
notice $a::b_c['b']
  }
}

class b {
  class{'a': b_c => false }
}

class b::c inherits b {
  Class['a']{ b_c => { 'b' => 'bleh' } }
}

class b::d {
  include ::b::c
}

include b::d


produces the following output:


$ puppet foo.pp 
notice: Scope(Class[A]): bbleh
notice: Scope(Class[A]): bleh


Which is what I expected. However with 2.6.3 it produces the following output:


# puppet foo.pp 
notice: Scope(Class[A]): false


Imho likely the changes for #4778 and #5074 are responsible for that behavior 
change.

However this makes it impossible to overwrite parameters of a "included" 
parametrized class in a subclass. There are only ugly workarounds for that 
problem and I think this should actually work as it did within 2.6.1. Otherwise 
the usefulness of parametrized classes is quite reduced.


-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Feature #7243] Additional data in Puppet CSRs (certdnsnames, and custom data)

2013-02-21 Thread tickets


Issue #7243 has been updated by Adrien Thebo.


Hi Patrick,

Would you be able to file a pull request against the Github repo 
(https://github.com/puppetlabs/puppet) ? This well help us start reviewing the 
code on a more formal level. You might want to review 
https://github.com/puppetlabs/puppet/blob/master/CONTRIBUTING.md to see what we 
need when merging code into Puppet.

Feature #7243: Additional data in Puppet CSRs (certdnsnames, and custom data)
https://projects.puppetlabs.com/issues/7243#change-83701

Author: Matt Wise
Status: Tests Insufficient
Priority: Normal
Assignee: Daniel Pittman
Category: SSL
Target version: 
Affected Puppet version: 
Keywords: 
Branch: https://github.com/puppetlabs/puppet/pull/806


Puppet Clients currently do not support filling in 'certdnsnames' in their CSR. 
That is only done on the signing-server side of things. This should be updated 
so that either the client, or server can set the certdnsnames (or both). 

In addition to this, the Puppet CSR generation code should allow for the 
addition of arbitrary data in the form of keypairs (foo=xyz) that is embedded 
into the CSR. That data should then be accessible in some way to the Puppet 
master process itself during catalog compilation. This allows for companies to 
build in their own security models around the SSL certs.




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

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

[Puppet - Bug #19247] puppet no longer colorizes notice-level output

2013-02-21 Thread tickets


Issue #19247 has been updated by Adrien Thebo.


I was able to track down the original backstory behind this change.


- - -

The change to console logging conventions was a part of a couple of overlapping 
discussions.

Firstly, the work being done on the module tool had need of "undecorated" 
output, where the base color was neutral (white on black, black on white) and 
where output could be done without decoration.  This forced changes in the core 
logging mechanism when a few internal parties strongly objected to the use of a 
different logging mechanism.

Those objections resulted in the decisions to remove the "notice:" prefix from 
that logging level, to reduce the amount of color used in output (allowing it 
to accent the data, rather than overpower the data), and to move away from a 
default set of colors which were arbitrarily chosen to work well in Luke's 
terminal to a deliberately chosen set of colors (based on uncustomized terminal 
renderings and social understandings of color).

"Notice" level messages were asserted to be the most common, least interesting 
form of logging, and rather than adding a new log level for "normal" (which 
would break our adherence to standard Syslog levels), "notice" became 
"neutral".  This was intended to be the first step of several, where we 
continued to differentiate machine-facing and human-facing log output (e.g. 
automatically turning colors on and off), and to refine Puppet's logging to be 
increasingly human-friendly (without breaking machine-facing output). That plan 
has yet to be actualized.

At this point, I don't personally care what colors the log levels have 
associated with them.  On the one hand, it's easy enough to make the claim that 
this is a deliberate breaking change introduced with the 3.0.0 release; on the 
other hand, it's also easy enough to call it an experiment, a mistake, or a 
bug.  My own stake in the work is ensuring that the PMT (and other command line 
tools in Puppet's ecosystem) have a reasonable, blessed way of doing 
undecorated log output, and that any changes made to the core coloring don't 
cause regressions in the PMT.


Bug #19247: puppet no longer colorizes notice-level output
https://projects.puppetlabs.com/issues/19247#change-83700

Author: Patrick Schless
Status: Needs Decision
Priority: Normal
Assignee: 
Category: color
Target version: 3.x
Affected Puppet version: 3.0.0
Keywords: 
Branch: https://github.com/puppetlabs/puppet/pull/1472


When upgrading from 2.7.17 to 3.1.0, I no longer get the cyan coloring of 
notice-level output (which is the bulk of puppet's output in my case). The cyan 
coloring is very helpful for distinguishing between capistrano noise and the 
content I'm interested in.

The issue is at lib/puppet/util/log/destinations.rb:116, where the relationship 
between levels and colors includes {:notice => :reset} instead of {:notice => 
:notice}.

This affects both console output and html output.

I only use stand-alone puppet, so I don't know if this issue applies to a 
puppetmaster setup.


-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #14093] (Merged - Pending Release) variable called $string in scope prevents templates from working

2013-02-21 Thread tickets

Issue #14093 has been updated by Jeff McCune.

Category set to templates
Status changed from In Topic Branch Pending Review to Merged - Pending Release
Target version set to 3.2.0

Merged into master as 432850fb74813eded3036f861e05d9266289c16c.

This should be released in 3.2.0.

Thanks again for the contribution!

-Jeff

Bug #14093: variable called $string in scope prevents templates from working
https://projects.puppetlabs.com/issues/14093#change-83695

Author: R.I. Pienaar
Status: Merged - Pending Release
Priority: Normal
Assignee:
Category: templates
Target version: 3.2.0
Affected Puppet version:
Keywords:
Branch: https://github.com/puppetlabs/puppet/pull/1446

% FACTER_string="foo" puppet -e 'notice(inline_template("<%= Time.now %>"))'
notice: Scope(Class[main]): foo

Probably because
https://github.com/puppetlabs/puppet/blob/master/lib/puppet/parser/templatewrapper.rb#L90-99
will overwrite the @string in the class

tested against 2.6.x and master

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

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

[Puppet - Bug #15561] Fix for CVE-2012-3867 is too restrictive

2013-02-21 Thread tickets

Issue #15561 has been updated by Jeff McCune.

Yuri Arabadji wrote:
> okay, what if you try href="https://github.com/puppetlabs/puppet/pull/1490";>https://github.com/puppetlabs/puppet/pull/1490
> ? tnx.

Unfortunately this change does not sufficiently address the root cause of the
problem, and as a result risks regression of CVE-2012-3867. Please see the
comments I posted on Github for more information and next steps to proceed.

Bug #15561: Fix for CVE-2012-3867 is too restrictive
https://projects.puppetlabs.com/issues/15561#change-83690

Author: Dustin Mitchell
Status: Accepted
Priority: Urgent
Assignee:
Category: SSL
Target version:
Affected Puppet version: 2.7.18
Keywords: certificate
Branch: https://github.com/puppetlabs/puppet/pull/1101

The fix for CVE-2012-3867 involves checking certificate subjects for "weird"
characters. From my read of the CVE entry, this is to filter out characters
that would cause the name to display in a manner visually indistinguishable
from a valid hostname.

However, the check is too restrictive:

Could not retrieve catalog from remote server: Certname "puppetagain base
ca/emailaddress=rele...@mozilla.com/ou=release engineering/o=mozilla, inc."
must not contain unprintable or non-ASCII characters

In particular, / is a very common character in subjects, and should be allowed.
Puppet is seeing this subject on my base CA - I'm using certificate chaining.

The fix is one character, so I haven't included a patch, but I'm happy to make
a pull req if necessary.

Another fix would be to only verify certificate subjects for the leaf
certificate, and not any of the certs in its signing chain, but that seems less
secure.

It's also worth noting that the regex is overly broad, since it downcases the
string, then accepts A-Z among other characters.

[Puppet - Bug #17879] (Duplicate) extract cert name properly from subject DN

2013-02-21 Thread tickets


Issue #17879 has been updated by Jeff McCune.

Status changed from Re-opened to Duplicate

Unfortunately the pull request in 
https://github.com/puppetlabs/puppet/pull/1490 does not sufficiently address 
the root cause of this problem.

Here's the comment I posted on Github:

Thanks for this patch, but I don't understand how it adequately protects from 
the situation where Puppet writes the file to disk based on the name. For 
example, on windows the path separator is \ and this patch would cause Puppet 
to accept a cert name of ..\..\puppet.conf which could be used to overwrite the 
puppet configuration file.

I think this approach is insufficient because it does not address the root 
cause of the issue that's been mentioned in 
http://projects.puppetlabs.com/issues/15561#note-13

I'm happy to review and investigate alternative approaches to the problem, but 
for 15561 and 17879 to be resolved we need to address the fundamental problem 
of the file name on disk depending on the user-supplied certificate name. This 
dependency needs to be broken. Without addressing this problem we risk 
regression on important security fixes.

I'm going to go ahead and close this pull request for the time being. Please 
re-open this pull request once the next actions are addressed, new information 
is available, or you have a question related to this pull request. We've become 
aware of difficulties re-opening pull requests, in the event you cannot please 
mention jeffmccune or adrienthebo with an @ sign in front and we'll re-open 
this pull request.

Closing the pull request doesn't mean we don't consider this change valuable, 
just that there are things that need to be addressed before it can be merged. 
If you have any questions or concerns, please don't hesitate to ping us in 
#puppet-dev on irc.freenode.net.

Please don't re-open this issue as it is a duplicate of #15561.  If you'd like 
to work on this issue further, which I definitely encourage you to do, please 
file the pull request and comment against #15561.

Thanks,
-Jeff

Bug #17879: extract cert name properly from subject DN
https://projects.puppetlabs.com/issues/17879#change-83689

Author: Yuri Arabadji
Status: Duplicate
Priority: High
Assignee: 
Category: 
Target version: 
Affected Puppet version: 
Keywords: 
Branch: 


You owe me $200 for my time on debugging this. Hi.

--- 
/usr/local/rvm/gems/ruby-1.9.3-p286@puppet30/gems/puppet-3.0.1/lib/puppet/ssl/base.rb.orig
  2012-11-30 10:23:24.531533928 -0500
+++ 
/usr/local/rvm/gems/ruby-1.9.3-p286@puppet30/gems/puppet-3.0.1/lib/puppet/ssl/base.rb
   2012-11-30 10:35:25.653400099 -0500
@@ -49,7 +49,9 @@
 
   # Method to extract a 'name' from the subject of a certificate
   def self.name_from_subject(subject)
-subject.to_s.sub(/\/CN=/i, '')
+if triplet = subject.to_a.find {|name, data, type| name == 'CN' }
+  triplet[1]
+end
   end
 
   # Create an instance of our Puppet::SSL::* class using a given instance of 
the wrapped class

Otherwise subject DN /O=Organization/OU=Something/CN=host.name.com will be 
converted into some mess and fail validation with exception being thrown right 
in the middle of the code that doesn't expect it.
So don't be shy, make connection.verify_callback block catch the exception and 
actually raise SSLError or the like and actually fill in the error message 
(class not found, name incorrect and such).

That's all for now, dears.


-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #19396] Wrong environment being saved in yaml/database when using storeconfigs

2013-02-21 Thread tickets


Issue #19396 has been updated by eric sorenson.


This doesn't reproduce for me w/puppetdb so unless I've missed something it's 
specific to activerecord stored configs and therefore not very likely to be 
fixed.

Bug #19396: Wrong environment being saved in yaml/database when using 
storeconfigs
https://projects.puppetlabs.com/issues/19396#change-83687

Author: David K
Status: Investigating
Priority: Normal
Assignee: eric sorenson
Category: 
Target version: 
Affected Puppet version: 3.1.0
Keywords: yaml environment mysql activerecord
Branch: 


Using puppet 3.1 with multiple static environments and:
reports = store
storeconfigs = true
thin_storeconfigs = true

results in the wrong environment being stored in the mysql database as well as 
/var/lib/puppet/yaml/node/host.yaml file. The environment in the yaml file 
actually changes from the proper environment to the wrong one during the run.

The yaml file and database use whatever the masters default environment = is 
set to under the [master] section - I can make them save whatever value I want.

/var/lib/puppet/reports/host/.yaml contains the correct environment name.

If I disable storeconfigs the /var/lib/puppet/yaml/node is correct.


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

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

[Puppet - Bug #19396] (Investigating) Wrong environment being saved in yaml/database when using storeconfigs

2013-02-21 Thread tickets


Issue #19396 has been updated by eric sorenson.

Status changed from Re-opened to Investigating
Assignee set to eric sorenson

Going to try to reproduce this under puppetdb.

Bug #19396: Wrong environment being saved in yaml/database when using 
storeconfigs
https://projects.puppetlabs.com/issues/19396#change-83683

Author: David K
Status: Investigating
Priority: Normal
Assignee: eric sorenson
Category: 
Target version: 
Affected Puppet version: 3.1.0
Keywords: yaml environment mysql activerecord
Branch: 


Using puppet 3.1 with multiple static environments and:
reports = store
storeconfigs = true
thin_storeconfigs = true

results in the wrong environment being stored in the mysql database as well as 
/var/lib/puppet/yaml/node/host.yaml file. The environment in the yaml file 
actually changes from the proper environment to the wrong one during the run.

The yaml file and database use whatever the masters default environment = is 
set to under the [master] section - I can make them save whatever value I want.

/var/lib/puppet/reports/host/.yaml contains the correct environment name.

If I disable storeconfigs the /var/lib/puppet/yaml/node is correct.


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

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

[Puppet - Bug #19396] (Re-opened) Wrong environment being saved in yaml/database when using storeconfigs

2013-02-21 Thread tickets


Issue #19396 has been updated by David K.

Status changed from Closed to Re-opened

Not sure why it got closed

Bug #19396: Wrong environment being saved in yaml/database when using 
storeconfigs
https://projects.puppetlabs.com/issues/19396#change-83682

Author: David K
Status: Re-opened
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 3.1.0
Keywords: yaml environment mysql activerecord
Branch: 


Using puppet 3.1 with multiple static environments and:
reports = store
storeconfigs = true
thin_storeconfigs = true

results in the wrong environment being stored in the mysql database as well as 
/var/lib/puppet/yaml/node/host.yaml file. The environment in the yaml file 
actually changes from the proper environment to the wrong one during the run.

The yaml file and database use whatever the masters default environment = is 
set to under the [master] section - I can make them save whatever value I want.

/var/lib/puppet/reports/host/.yaml contains the correct environment name.

If I disable storeconfigs the /var/lib/puppet/yaml/node is correct.


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

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

[Puppet - Bug #19396] (Closed) Wrong environment being saved in yaml/database when using storeconfigs

2013-02-21 Thread tickets


Issue #19396 has been reported by David K.


Bug #19396: Wrong environment being saved in yaml/database when using 
storeconfigs
https://projects.puppetlabs.com/issues/19396

Author: David K
Status: Closed
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 3.1.0
Keywords: yaml environment mysql activerecord
Branch: 


Using puppet 3.1 with multiple static environments and:
reports = store
storeconfigs = true
thin_storeconfigs = true

results in the wrong environment being stored in the mysql database as well as 
/var/lib/puppet/yaml/node/host.yaml file. The environment in the yaml file 
actually changes from the proper environment to the wrong one during the run.

The yaml file and database use whatever the masters default environment = is 
set to under the [master] section - I can make them save whatever value I want.

/var/lib/puppet/reports/host/.yaml contains the correct environment name.

If I disable storeconfigs the /var/lib/puppet/yaml/node is correct.


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

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

[Puppet - Feature #19395] (Unreviewed) Detect client-server version mismatch, warn and optionally disallow

2013-02-21 Thread tickets


Issue #19395 has been reported by Aaron Grewell.


Feature #19395: Detect client-server version mismatch, warn and optionally 
disallow
https://projects.puppetlabs.com/issues/19395

Author: Aaron Grewell
Status: Unreviewed
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 
Keywords: 
Branch: 


I've seen a number of users run into version mismatch issues between client and 
server, and I recently installed a newer client than server by accident even 
though I know better.  Puppet does not even warn in this situation, it just 
breaks weirdly.  I'd like to request that in a future release Puppet would:
1) Warn on any client-server version mismatch.
2) Have a config option to disallow clients that are newer than the master from 
downloading a catalog.


-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #15561] Fix for CVE-2012-3867 is too restrictive

2013-02-21 Thread tickets

Issue #15561 has been updated by Yuri Arabadji.

okay, what if you try https://github.com/puppetlabs/puppet/pull/1490";>https://github.com/puppetlabs/puppet/pull/1490
? tnx.

Bug #15561: Fix for CVE-2012-3867 is too restrictive
https://projects.puppetlabs.com/issues/15561#change-83680

However, the check is too restrictive:

In particular, / is a very common character in subjects, and should be allowed.
Puppet is seeing this subject on my base CA - I'm using certificate chaining.

The fix is one character, so I haven't included a patch, but I'm happy to make
a pull req if necessary.

Another fix would be to only verify certificate subjects for the leaf
certificate, and not any of the certs in its signing chain, but that seems less
secure.

It's also worth noting that the regex is overly broad, since it downcases the
string, then accepts A-Z among other characters.

[Puppet - Bug #17879] (Re-opened) extract cert name properly from subject DN

2013-02-21 Thread tickets


Issue #17879 has been updated by Yuri Arabadji.

Status changed from Closed to Re-opened

Alrighty. Made a pull request. 

https://github.com/puppetlabs/puppet/pull/1490";>https://github.com/puppetlabs/puppet/pull/1490

Bug #17879: extract cert name properly from subject DN
https://projects.puppetlabs.com/issues/17879#change-83679

Author: Yuri Arabadji
Status: Re-opened
Priority: High
Assignee: 
Category: 
Target version: 
Affected Puppet version: 
Keywords: 
Branch: 


You owe me $200 for my time on debugging this. Hi.

--- 
/usr/local/rvm/gems/ruby-1.9.3-p286@puppet30/gems/puppet-3.0.1/lib/puppet/ssl/base.rb.orig
  2012-11-30 10:23:24.531533928 -0500
+++ 
/usr/local/rvm/gems/ruby-1.9.3-p286@puppet30/gems/puppet-3.0.1/lib/puppet/ssl/base.rb
   2012-11-30 10:35:25.653400099 -0500
@@ -49,7 +49,9 @@
 
   # Method to extract a 'name' from the subject of a certificate
   def self.name_from_subject(subject)
-subject.to_s.sub(/\/CN=/i, '')
+if triplet = subject.to_a.find {|name, data, type| name == 'CN' }
+  triplet[1]
+end
   end
 
   # Create an instance of our Puppet::SSL::* class using a given instance of 
the wrapped class

Otherwise subject DN /O=Organization/OU=Something/CN=host.name.com will be 
converted into some mess and fail validation with exception being thrown right 
in the middle of the code that doesn't expect it.
So don't be shy, make connection.verify_callback block catch the exception and 
actually raise SSLError or the like and actually fill in the error message 
(class not found, name incorrect and such).

That's all for now, dears.


-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #19390] Puppet agent getting stuck

2013-02-21 Thread tickets


Issue #19390 has been updated by Brian Rak.


Kernel version: 2.6.18-348.el5 x86_64

Bug #19390: Puppet agent getting stuck
https://projects.puppetlabs.com/issues/19390#change-83674

Author: Brian Rak
Status: Unreviewed
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 3.1.0
Keywords: 
Branch: 


I recently upgraded a number of CentOS 5 nodes from 2.7.x to 3.1.  After this 
upgrade, I've noticed a lot of the nodes are getting 'stuck'.  They'll run for 
awhile then randomly miss a scheduled run.

The log files look like this:


Feb 20 20:14:19 dl4 puppet-agent[28390]: Finished catalog run in 8.08 seconds
Feb 20 20:44:25 dl4 puppet-agent[29313]: Finished catalog run in 8.36 seconds
Feb 20 21:48:47 dl4 puppet-agent[30722]: Finished catalog run in 8.68 seconds


There's no indication of why it didn't run around 21:15, or any sign that it 
even attempted to.

A strace of the process shows:

Process 21298 attached - interrupt to quit
select(1, [], [], [], {2395, 665000} 

And the corresponding lsof:
# lsof -p 21298
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
puppet  21298 root  cwdDIR8,2 40962 /
puppet  21298 root  rtdDIR8,2 40962 /
puppet  21298 root  txtREG8,2 9352  6556131 
/usr/bin/ruby
puppet  21298 root  memREG8,2   144776  3401531 
/lib64/ld-2.5.so
puppet  21298 root  memREG8,2  1726320  3401532 
/lib64/libc-2.5.so
puppet  21298 root  memREG8,223360  3401533 
/lib64/libdl-2.5.so
puppet  21298 root  memREG8,2   614992  3401542 
/lib64/libm-2.5.so
puppet  21298 root  memREG8,2   149968  3401537 
/lib64/libpthread-2.5.so
puppet  21298 root  memREG8,285544  3401269 
/lib64/libz.so.1.2.3
puppet  21298 root  memREG8,295464  3401546 
/lib64/libselinux.so.1
puppet  21298 root  memREG8,2   247496  3401545 
/lib64/libsepol.so.1
puppet  21298 root  memREG8,253448  3401538 
/lib64/librt-2.5.so
puppet  21298 root  memREG8,248600  3401391 
/lib64/libcrypt-2.5.so
puppet  21298 root  memREG8,258400  3401543 
/lib64/libgcc_s-4.1.2-20080825.so.1
puppet  21298 root  memREG8,2  1367232  3401544 
/lib64/libcrypto.so.0.9.8e
puppet  21298 root  memREG8,210096  3401550 
/lib64/libcom_err.so.2.1
puppet  21298 root  memREG8,2 9472  3401554 
/lib64/libkeyutils-1.2.so
puppet  21298 root  memREG8,2   613928  6561354 
/usr/lib64/libkrb5.so.3.3
puppet  21298 root  memREG8,2   315080  3401552 
/lib64/libssl.so.0.9.8e
puppet  21298 root  memREG8,292816  3401281 
/lib64/libresolv-2.5.so
puppet  21298 root  memREG8,2   153720  6553592 
/usr/lib64/libk5crypto.so.3.1
puppet  21298 root  memREG8,235984  6557290 
/usr/lib64/libkrb5support.so.0.1
puppet  21298 root  memREG8,2   190976  6561355 
/usr/lib64/libgssapi_krb5.so.2.2
puppet  21298 root  memREG8,2   919480  6556130 
/usr/lib64/libruby.so.1.8.7
puppet  21298 root  memREG8,216296  6712775 
/usr/lib64/ruby/1.8/x86_64-linux/thread.so
puppet  21298 root  memREG8,2 9928  6704832 
/usr/lib64/ruby/1.8/x86_64-linux/etc.so
puppet  21298 root  memREG8,220064  6712770 
/usr/lib64/ruby/1.8/x86_64-linux/stringio.so
puppet  21298 root  memREG8,2   116824  6712772 
/usr/lib64/ruby/1.8/x86_64-linux/syck.so
puppet  21298 root  memREG8,2 5000  6712764 
/usr/lib64/ruby/1.8/x86_64-linux/fcntl.so
puppet  21298 root  memREG8,245440  6704845 
/usr/lib64/ruby/1.8/x86_64-linux/socket.so
puppet  21298 root  memREG8,2   254832  6712767 
/usr/lib64/ruby/1.8/x86_64-linux/openssl.so
puppet  21298 root  memREG8,212072  6712759 
/usr/lib64/ruby/1.8/x86_64-linux/digest.so
puppet  21298 root  memREG8,216064  6704836 
/usr/lib64/ruby/1.8/x86_64-linux/iconv.so
puppet  21298 root  memREG8,218192  6712771 
/usr/lib64/ruby/1.8/x86_64-linux/strscan.so
puppet  21298 root  memREG8,253880  3401243 
/lib64/libnss_files-2.5.so
puppet  21298 root  memREG8,212440  6712773 
/usr/lib64/ruby/1.8/x86_64-linux/syslog.so
puppet  21298 root  memREG8,2 5160  6704829 
/usr/lib64/ruby/1.8/x86_64-linux/digest/sha1.so
puppet  21298 root  memREG8,2   263072  6704838 
/usr/lib64/ruby/1.8/x86_64-linux/nkf.so
puppet  21298 root  memREG8,215048  6704841 
/usr/lib64/ruby/1

[Puppet - Bug #19390] Puppet agent getting stuck

2013-02-21 Thread tickets


Issue #19390 has been updated by Brian Rak.


Realized I forgot this, but these were run while stuck:

# puppet config print  | grep agent_catalog_run_lockfile 
agent_catalog_run_lockfile = /var/lib/puppet/state/agent_catalog_run.lock
# ls -l /var/lib/puppet/state/agent_catalog_run.lock
ls: /var/lib/puppet/state/agent_catalog_run.lock: No such file or directory


Bug #19390: Puppet agent getting stuck
https://projects.puppetlabs.com/issues/19390#change-83673

Author: Brian Rak
Status: Unreviewed
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 3.1.0
Keywords: 
Branch: 


I recently upgraded a number of CentOS 5 nodes from 2.7.x to 3.1.  After this 
upgrade, I've noticed a lot of the nodes are getting 'stuck'.  They'll run for 
awhile then randomly miss a scheduled run.

The log files look like this:


Feb 20 20:14:19 dl4 puppet-agent[28390]: Finished catalog run in 8.08 seconds
Feb 20 20:44:25 dl4 puppet-agent[29313]: Finished catalog run in 8.36 seconds
Feb 20 21:48:47 dl4 puppet-agent[30722]: Finished catalog run in 8.68 seconds


There's no indication of why it didn't run around 21:15, or any sign that it 
even attempted to.

A strace of the process shows:

Process 21298 attached - interrupt to quit
select(1, [], [], [], {2395, 665000} 

And the corresponding lsof:
# lsof -p 21298
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
puppet  21298 root  cwdDIR8,2 40962 /
puppet  21298 root  rtdDIR8,2 40962 /
puppet  21298 root  txtREG8,2 9352  6556131 
/usr/bin/ruby
puppet  21298 root  memREG8,2   144776  3401531 
/lib64/ld-2.5.so
puppet  21298 root  memREG8,2  1726320  3401532 
/lib64/libc-2.5.so
puppet  21298 root  memREG8,223360  3401533 
/lib64/libdl-2.5.so
puppet  21298 root  memREG8,2   614992  3401542 
/lib64/libm-2.5.so
puppet  21298 root  memREG8,2   149968  3401537 
/lib64/libpthread-2.5.so
puppet  21298 root  memREG8,285544  3401269 
/lib64/libz.so.1.2.3
puppet  21298 root  memREG8,295464  3401546 
/lib64/libselinux.so.1
puppet  21298 root  memREG8,2   247496  3401545 
/lib64/libsepol.so.1
puppet  21298 root  memREG8,253448  3401538 
/lib64/librt-2.5.so
puppet  21298 root  memREG8,248600  3401391 
/lib64/libcrypt-2.5.so
puppet  21298 root  memREG8,258400  3401543 
/lib64/libgcc_s-4.1.2-20080825.so.1
puppet  21298 root  memREG8,2  1367232  3401544 
/lib64/libcrypto.so.0.9.8e
puppet  21298 root  memREG8,210096  3401550 
/lib64/libcom_err.so.2.1
puppet  21298 root  memREG8,2 9472  3401554 
/lib64/libkeyutils-1.2.so
puppet  21298 root  memREG8,2   613928  6561354 
/usr/lib64/libkrb5.so.3.3
puppet  21298 root  memREG8,2   315080  3401552 
/lib64/libssl.so.0.9.8e
puppet  21298 root  memREG8,292816  3401281 
/lib64/libresolv-2.5.so
puppet  21298 root  memREG8,2   153720  6553592 
/usr/lib64/libk5crypto.so.3.1
puppet  21298 root  memREG8,235984  6557290 
/usr/lib64/libkrb5support.so.0.1
puppet  21298 root  memREG8,2   190976  6561355 
/usr/lib64/libgssapi_krb5.so.2.2
puppet  21298 root  memREG8,2   919480  6556130 
/usr/lib64/libruby.so.1.8.7
puppet  21298 root  memREG8,216296  6712775 
/usr/lib64/ruby/1.8/x86_64-linux/thread.so
puppet  21298 root  memREG8,2 9928  6704832 
/usr/lib64/ruby/1.8/x86_64-linux/etc.so
puppet  21298 root  memREG8,220064  6712770 
/usr/lib64/ruby/1.8/x86_64-linux/stringio.so
puppet  21298 root  memREG8,2   116824  6712772 
/usr/lib64/ruby/1.8/x86_64-linux/syck.so
puppet  21298 root  memREG8,2 5000  6712764 
/usr/lib64/ruby/1.8/x86_64-linux/fcntl.so
puppet  21298 root  memREG8,245440  6704845 
/usr/lib64/ruby/1.8/x86_64-linux/socket.so
puppet  21298 root  memREG8,2   254832  6712767 
/usr/lib64/ruby/1.8/x86_64-linux/openssl.so
puppet  21298 root  memREG8,212072  6712759 
/usr/lib64/ruby/1.8/x86_64-linux/digest.so
puppet  21298 root  memREG8,216064  6704836 
/usr/lib64/ruby/1.8/x86_64-linux/iconv.so
puppet  21298 root  memREG8,218192  6712771 
/usr/lib64/ruby/1.8/x86_64-linux/strscan.so
puppet  21298 root  memREG8,253880  3401243 
/lib64/libnss_files-2.5.so
puppet  21298 root  memREG8,212440  6712773 
/usr/lib64/ruby/1.8/x86_64-linux/syslog.so
puppet  21298 root  memREG

[Puppet - Bug #19390] (Unreviewed) Puppet agent getting stuck

2013-02-21 Thread tickets


Issue #19390 has been reported by Brian Rak.


Bug #19390: Puppet agent getting stuck
https://projects.puppetlabs.com/issues/19390

Author: Brian Rak
Status: Unreviewed
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 3.1.0
Keywords: 
Branch: 


I recently upgraded a number of CentOS 5 nodes from 2.7.x to 3.1.  After this 
upgrade, I've noticed a lot of the nodes are getting 'stuck'.  They'll run for 
awhile then randomly miss a scheduled run.

The log files look like this:


Feb 20 20:14:19 dl4 puppet-agent[28390]: Finished catalog run in 8.08 seconds
Feb 20 20:44:25 dl4 puppet-agent[29313]: Finished catalog run in 8.36 seconds
Feb 20 21:48:47 dl4 puppet-agent[30722]: Finished catalog run in 8.68 seconds


There's no indication of why it didn't run around 21:15, or any sign that it 
even attempted to.

A strace of the process shows:

Process 21298 attached - interrupt to quit
select(1, [], [], [], {2395, 665000} 

And the corresponding lsof:
# lsof -p 21298
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
puppet  21298 root  cwdDIR8,2 40962 /
puppet  21298 root  rtdDIR8,2 40962 /
puppet  21298 root  txtREG8,2 9352  6556131 
/usr/bin/ruby
puppet  21298 root  memREG8,2   144776  3401531 
/lib64/ld-2.5.so
puppet  21298 root  memREG8,2  1726320  3401532 
/lib64/libc-2.5.so
puppet  21298 root  memREG8,223360  3401533 
/lib64/libdl-2.5.so
puppet  21298 root  memREG8,2   614992  3401542 
/lib64/libm-2.5.so
puppet  21298 root  memREG8,2   149968  3401537 
/lib64/libpthread-2.5.so
puppet  21298 root  memREG8,285544  3401269 
/lib64/libz.so.1.2.3
puppet  21298 root  memREG8,295464  3401546 
/lib64/libselinux.so.1
puppet  21298 root  memREG8,2   247496  3401545 
/lib64/libsepol.so.1
puppet  21298 root  memREG8,253448  3401538 
/lib64/librt-2.5.so
puppet  21298 root  memREG8,248600  3401391 
/lib64/libcrypt-2.5.so
puppet  21298 root  memREG8,258400  3401543 
/lib64/libgcc_s-4.1.2-20080825.so.1
puppet  21298 root  memREG8,2  1367232  3401544 
/lib64/libcrypto.so.0.9.8e
puppet  21298 root  memREG8,210096  3401550 
/lib64/libcom_err.so.2.1
puppet  21298 root  memREG8,2 9472  3401554 
/lib64/libkeyutils-1.2.so
puppet  21298 root  memREG8,2   613928  6561354 
/usr/lib64/libkrb5.so.3.3
puppet  21298 root  memREG8,2   315080  3401552 
/lib64/libssl.so.0.9.8e
puppet  21298 root  memREG8,292816  3401281 
/lib64/libresolv-2.5.so
puppet  21298 root  memREG8,2   153720  6553592 
/usr/lib64/libk5crypto.so.3.1
puppet  21298 root  memREG8,235984  6557290 
/usr/lib64/libkrb5support.so.0.1
puppet  21298 root  memREG8,2   190976  6561355 
/usr/lib64/libgssapi_krb5.so.2.2
puppet  21298 root  memREG8,2   919480  6556130 
/usr/lib64/libruby.so.1.8.7
puppet  21298 root  memREG8,216296  6712775 
/usr/lib64/ruby/1.8/x86_64-linux/thread.so
puppet  21298 root  memREG8,2 9928  6704832 
/usr/lib64/ruby/1.8/x86_64-linux/etc.so
puppet  21298 root  memREG8,220064  6712770 
/usr/lib64/ruby/1.8/x86_64-linux/stringio.so
puppet  21298 root  memREG8,2   116824  6712772 
/usr/lib64/ruby/1.8/x86_64-linux/syck.so
puppet  21298 root  memREG8,2 5000  6712764 
/usr/lib64/ruby/1.8/x86_64-linux/fcntl.so
puppet  21298 root  memREG8,245440  6704845 
/usr/lib64/ruby/1.8/x86_64-linux/socket.so
puppet  21298 root  memREG8,2   254832  6712767 
/usr/lib64/ruby/1.8/x86_64-linux/openssl.so
puppet  21298 root  memREG8,212072  6712759 
/usr/lib64/ruby/1.8/x86_64-linux/digest.so
puppet  21298 root  memREG8,216064  6704836 
/usr/lib64/ruby/1.8/x86_64-linux/iconv.so
puppet  21298 root  memREG8,218192  6712771 
/usr/lib64/ruby/1.8/x86_64-linux/strscan.so
puppet  21298 root  memREG8,253880  3401243 
/lib64/libnss_files-2.5.so
puppet  21298 root  memREG8,212440  6712773 
/usr/lib64/ruby/1.8/x86_64-linux/syslog.so
puppet  21298 root  memREG8,2 5160  6704829 
/usr/lib64/ruby/1.8/x86_64-linux/digest/sha1.so
puppet  21298 root  memREG8,2   263072  6704838 
/usr/lib64/ruby/1.8/x86_64-linux/nkf.so
puppet  21298 root  memREG8,215048  6704841 
/usr/lib64/ruby/1.8/x86_64-linux/racc/cparse.so
puppet  21298 root

[Puppet - Feature #12260] All puppet module commands should support json and yaml output

2013-02-21 Thread tickets


Issue #12260 has been updated by Michael Hrivnak.


Pulp (http://www.pulpproject.org) invokes "puppet module" commands on remote 
machines and depends on the JSON output to report errors to users. It mostly 
works well, but there are certain cases (like installing a module that doesn't 
exist) where we don't display the error message, because there's no JSON.

Our code makes a best effort to find and display each error message, so as JSON 
support improves in the "puppet module" commands, Pulp will automatically take 
advantage of it.

Feature #12260: All puppet module commands should support json and yaml output
https://projects.puppetlabs.com/issues/12260#change-83668

Author: Matt Robinson
Status: Accepted
Priority: Low
Assignee: 
Category: 
Target version: 
Affected Puppet version: 
Keywords: geordi v2
Branch: 


This shouldn't be too difficult, but if it is, this can be broken down into 
smaller tickets per command.


-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #15561] Fix for CVE-2012-3867 is too restrictive

2013-02-21 Thread tickets


Issue #15561 has been updated by Jason Hancock.


You can also run into this bug when using the http report processor submitting 
to an https reporturl where the certificate has a '/' in it.

Bug #15561: Fix for CVE-2012-3867 is too restrictive
https://projects.puppetlabs.com/issues/15561#change-83664

Author: Dustin Mitchell
Status: Accepted
Priority: Urgent
Assignee: 
Category: SSL
Target version: 
Affected Puppet version: 2.7.18
Keywords: certificate
Branch: https://github.com/puppetlabs/puppet/pull/1101


The fix for CVE-2012-3867 involves checking certificate subjects for "weird" 
characters.  From my read of the CVE entry, this is to filter out characters 
that would cause the name to display in a manner visually indistinguishable 
from a valid hostname.

However, the check is too restrictive:

Could not retrieve catalog from remote server: Certname "puppetagain base 
ca/emailaddress=rele...@mozilla.com/ou=release engineering/o=mozilla, inc." 
must not contain unprintable or non-ASCII characters

In particular, / is a very common character in subjects, and should be allowed. 
 Puppet is seeing this subject on my base CA - I'm using certificate chaining.

The fix is one character, so I haven't included a patch, but I'm happy to make 
a pull req if necessary.

Another fix would be to only verify certificate subjects for the leaf 
certificate, and not any of the certs in its signing chain, but that seems less 
secure.

It's also worth noting that the regex is overly broad, since it downcases the 
string, then accepts A-Z among other characters.


-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #19385] (Rejected) Puppetdb installation via module

2013-02-21 Thread tickets


Issue #19385 has been updated by Ken Barber.

Status changed from Unreviewed to Rejected

Hiya Yannig, this problem should be logged here:



Thanks!

Bug #19385: Puppetdb installation via module
https://projects.puppetlabs.com/issues/19385#change-83663

Author: Yannig rousseau
Status: Rejected
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 
Keywords: 
Branch: 


Hi all,

I'm quite new here and I hope i'm on the right place...
I'm trying to install a puppet platform with puppetdb and I had some succes 
until today to install it correctly.
Issue is that from today the puppetdb installation via module no longer 
functions :

Error: Could not start Service[postgresqld]: Execution of '/sbin/service 
postgresql start' returned 1:

Within the postgres log => FATAL:  unrecognized configuration parameter 
"include"

I removed the include line within postgres.conf and I am able to start postgres 
process. But if I apply puppet catalog again (to install puppetdb via module) 
it does reinsert the include...

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 unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #19385] (Unreviewed) Puppetdb installation via module

2013-02-21 Thread tickets


Issue #19385 has been reported by Yannig rousseau.


Bug #19385: Puppetdb installation via module
https://projects.puppetlabs.com/issues/19385

Author: Yannig rousseau
Status: Unreviewed
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 
Keywords: 
Branch: 


Hi all,

I'm quite new here and I hope i'm on the right place...
I'm trying to install a puppet platform with puppetdb and I had some succes 
until today to install it correctly.
Issue is that from today the puppetdb installation via module no longer 
functions :

Error: Could not start Service[postgresqld]: Execution of '/sbin/service 
postgresql start' returned 1:

Within the postgres log => FATAL:  unrecognized configuration parameter 
"include"

I removed the include line within postgres.conf and I am able to start postgres 
process. But if I apply puppet catalog again (to install puppetdb via module) 
it does reinsert the include...

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 unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #2823] fail and unhelpful error message if a remote directory doesn't exist.

2013-02-21 Thread tickets


Issue #2823 has been updated by Alexander Komarov.


UPDATE: I found one workaround (use a failover directory):

source => ['/tmp/nonexist1', '/some/failover/directory/that/exists']

Now eval_generate() will not fail, but I still don't understand why puppet 
wants to traverse the whole source tree at compilation time, especially if the 
file resource isn't even tagged with the active tag(s).

Bug #2823: fail and unhelpful error message if a remote directory doesn't exist.
https://projects.puppetlabs.com/issues/2823#change-83656

Author: Peter Meier
Status: Rejected
Priority: Normal
Assignee: Dan Bode
Category: file
Target version: 0.25.2
Affected Puppet version: 0.25.1
Keywords: 
Branch: 


Given the following define


define modules_dir (
$mode = 0644, $owner = root, $group = 0
  )
{
  $dir = "/var/lib/puppet/modules/${name}"
  if defined(File[$dir]) {
debug("${dir} already defined")
  } else {
file {
  "/var/lib/puppet/modules/${name}":
source => [ "puppet://$server/modules/${name}/modules_dir", 
"puppet://$server//modules/common/empty"],
checksum => mtime,
# ignore the placeholder
ignore => '\.ignore',
recurse => true, purge => true, force => true,
mode => $mode, owner => $owner, group => $group;
}
  }
}


and the following call:


modules_dir { ["munin", "munin/nodes", "munin/plugins" ]: }


As @$modules/munin/files/nodes/modules_dir@ doesn't exist, it should take the 
second fallback and more generic one @$modules/common/files/empty@ which exists.

However the resource fails completely with the following 2 rather cryptic error 
messages:


/usr/lib/ruby/site_ruby/1.8/puppet/type/file.rb:588:in `recurse_remote'
/usr/lib/ruby/site_ruby/1.8/puppet/type/file.rb:587:in `each'
/usr/lib/ruby/site_ruby/1.8/puppet/type/file.rb:587:in `recurse_remote'
/usr/lib/ruby/site_ruby/1.8/puppet/type/file.rb:483:in `recurse'
/usr/lib/ruby/site_ruby/1.8/puppet/type/file.rb:385:in `eval_generate'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:347:in `send'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:347:in 
`generate_additional_resources'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:191:in `eval_generate'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:238:in 
`eval_children_and_apply_resource'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:205:in `eval_resource'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:294:in `evaluate'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:417:in `thinmark'
/usr/lib/ruby/1.8/benchmark.rb:293:in `measure'
/usr/lib/ruby/1.8/benchmark.rb:307:in `realtime'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:416:in `thinmark'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:293:in `evaluate'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:287:in `collect'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:287:in `evaluate'
/usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:142:in `apply'
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:153:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:177:in `benchmark'
/usr/lib/ruby/1.8/benchmark.rb:293:in `measure'
/usr/lib/ruby/1.8/benchmark.rb:307:in `realtime'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:176:in `benchmark'
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:152:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:53:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent/locker.rb:21:in `lock'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:53:in `run'
/usr/lib/ruby/1.8/sync.rb:229:in `synchronize'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:53:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:130:in `with_client'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:51:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application/puppetd.rb:103:in `onetime'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:226:in `send'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:226:in `run_command'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:217:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:306:in `exit_on_fail'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:217:in `run'
/usr/sbin/puppetd:159
err: //Modules_dir[virtual]/File[/var/lib/puppet/modules/virtual]: Failed to 
generate additional resources using 'eval_generate'
: undefined method `relative_path' for nil:NilClass
/usr/lib/ruby/site_ruby/1.8/puppet/parameter.rb:401:in `fail'
/usr/lib/ruby/site_ruby/1.8/puppet/type/file/source.rb:160:in `init_metadata'
/usr/lib/ruby/site_ruby/1.8/puppet/util/cacher.rb:106:in `send'
/usr/lib/ruby/site_ruby/1.8/puppet/util/cacher.rb:106:in `cached_value'
/usr/lib/ruby/site_ruby/1.8/puppet/util/cacher.rb:46:in `metadata'
/usr/lib/ruby/site_ruby/1.8/puppet/type/file/source.rb:115:in 
`copy_source_values'
/usr/lib/ruby/site_ruby/1.8/puppet/type/file.rb:638:in `retrieve'
/usr/lib/ruby/site_ruby/1.8/puppet/type.rb:726:in `evaluate'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:60:in `apply'
/usr/lib/ruby/site_ruby/1.8/puppet/transactio

[Puppet - Feature #19188] configurable behavior with non-existing hiera variables

2013-02-21 Thread tickets


Issue #19188 has been updated by micah -.


> So you would like to have something like a global default? 

Yeah, that is the point, a global default so you don't need to define a default 
for each key.

> Why don’t you define a default yourself directly in the code? 

I do that, it works, but if I have a lot of keys with the same default, it 
would be nice to just have one default that they all have without having to 
define it. 

> What speaks against a solution where you define all these defaults in your 
> lowest hierarchy level? That you might not be able to control it? –> Maybe 
> add a third level, that you can control. Can’t be another yaml hierarchy, but 
> could be a json one.

I'm not sure I understand that :o


Feature #19188: configurable behavior with non-existing hiera variables
https://projects.puppetlabs.com/issues/19188#change-83655

Author: micah -
Status: Unreviewed
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 
Keywords: hiera
Branch: 


puppet-hiera will fail if it wants to read a variable and can't find it.

It would be nice if you could configure the behaviour in hiera.yaml for how 
hiera would deal with non-existent variables.

For example:


--- dev/puppet » cat manifests/hiera_test2.pp 
$a=hiera('a')
$b=hiera('b')
notice($a)
notice($b)

--- dev/puppet » cat /home/varac/.puppet/hiera.yaml 
---
:backends:
  - yaml
  - puppet

:logger: console

:yaml:
   :datadir: /home/varac/.puppet 

:hierarchy:
  - hiera_test

:puppet:
   :datasource: data

--- dev/puppet » cat /home/varac/.puppet/hiera_test.yaml 
---
a: a
b: b

--- dev/puppet » puppet apply -v manifests/hiera_test2.pp
notice: Scope(Class[main]): a
notice: Scope(Class[main]): b
info: Applying configuration version '1360597894'
notice: Finished catalog run in 0.07 seconds

--- dev/puppet » vi /home/varac/.puppet/hiera_test.yaml # remove variable b

--- dev/puppet » puppet apply -v manifests/hiera_test2.pp
Could not find data item b in any Hiera data file and no default supplied at 
/home/varac/dev/Projects/Puppet/dev/puppet/manifests/hiera_test2.pp:2 on node 
rocinante.bitrigger.de




-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #5517] behavior change within 2.6 makes it impossible to override class parameters of "included" parametrized classes

2013-02-21 Thread tickets

Issue #5517 has been updated by John Bollinger.

Luke Kanies wrote:
> John Bollinger wrote:
> > 
> > 
> > Do you mean *any* class that hasn't yet been evaluated, or do you mean the 
> > class to which the variable belongs?  If the latter, then you are creating 
> > a new failure scenario.
> 
> I just mean the one to which it belongs.
> 
> And note that I don't ever mean that we'd parse classes that haven't been 
> parsed yet, just evaluate class objects that are sitting around unevaluated.  
> It's a much better form of lazy evaluation than we do right now, which just 
> has us waiting to do any evaluation until we've run out of other stuff to do.

It's not clear to me exactly where the separation between parsing and 
evaluation lies, but I don't think it's possible to construct a scheme that 
ensures all class variable references that are now allowed continue to work, 
while at the same time deferring binding of parameter values to classes until 
late enough that class parameter overrides work reliably.  (And this ignores 
defined() and any similar features that are parse- and/or evaluation-order 
dependent.)

Think about the extreme case: what's to prevent a class parameter override 
being the very last thing evaluated (which must fail)?  Lazy class evaluation 
only solves the problem if class parameter overrides are reliably evaluated 
before the classes whose parameters are overridden.  But variable references 
are associated with the overridden classes, not with the overrides.  Thus, 
although this approach to lazy evaluation might successfully defer some 
classes' evaluation longer or more intelligently than now happens, it cannot 
guarantee anything about when class parameter overrides are evaluated.  
Although it might be useful in its own right, it doesn't solve the problem at 
hand.

Bug #5517: behavior change within 2.6 makes it impossible to override class 
parameters of "included" parametrized classes
https://projects.puppetlabs.com/issues/5517#change-83654

Author: Peter Meier
Status: Accepted
Priority: High
Assignee: eric sorenson
Category: language
Target version: 3.x
Affected Puppet version: 3.0.2
Keywords: parameterized_classes
Branch: 

In 2.6.1 the following recipe:

class a(
  $b_c = { 'b' => 'foo' }
) {
  notice $a::b_c
  if $a::b_c {
notice $a::b_c['b']
  }
}

class b {
  class{'a': b_c => false }
}

class b::c inherits b {
  Class['a']{ b_c => { 'b' => 'bleh' } }
}

class b::d {
  include ::b::c
}

include b::d

produces the following output:

$ puppet foo.pp 
notice: Scope(Class[A]): bbleh
notice: Scope(Class[A]): bleh

Which is what I expected. However with 2.6.3 it produces the following output:

# puppet foo.pp 
notice: Scope(Class[A]): false

Imho likely the changes for #4778 and #5074 are responsible for that behavior 
change.

However this makes it impossible to overwrite parameters of a "included" 
parametrized class in a subclass. There are only ugly workarounds for that 
problem and I think this should actually work as it did within 2.6.1. Otherwise 
the usefulness of parametrized classes is quite reduced.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #2823] fail and unhelpful error message if a remote directory doesn't exist.

2013-02-21 Thread tickets


Issue #2823 has been updated by Alexander Komarov.


This problem still occurs in puppet 2.7.20 (not sure where to file this), but 
more importantly, it occurs when the catalog in question is excluded via tags, 
causing a major issue for selective deployments:

This works (when not using tags), as a workaround to pre-create the source if 
not there: 

file { '/tmp/nonexist1' :
ensure => directory
}
file { '/tmp/nonexist2':
recurse => true,
# dir does not exist
source => '/tmp/nonexist1',
}
File['/tmp/nonexist1'] -> File['/tmp/nonexist2']


But when running via 
puppet apply --tags junk file.pp

You get the same error, meaning that there isn't even an ugly workaround in 
this case.   Tagging the first resource with junk makes it work, but that's not 
a viable solution:


file { '/tmp/nonexist1' :
  ensure => directory,
 tag => 'junk'
}

Bug #2823: fail and unhelpful error message if a remote directory doesn't exist.
https://projects.puppetlabs.com/issues/2823#change-83653

Author: Peter Meier
Status: Rejected
Priority: Normal
Assignee: Dan Bode
Category: file
Target version: 0.25.2
Affected Puppet version: 0.25.1
Keywords: 
Branch: 


Given the following define


define modules_dir (
$mode = 0644, $owner = root, $group = 0
  )
{
  $dir = "/var/lib/puppet/modules/${name}"
  if defined(File[$dir]) {
debug("${dir} already defined")
  } else {
file {
  "/var/lib/puppet/modules/${name}":
source => [ "puppet://$server/modules/${name}/modules_dir", 
"puppet://$server//modules/common/empty"],
checksum => mtime,
# ignore the placeholder
ignore => '\.ignore',
recurse => true, purge => true, force => true,
mode => $mode, owner => $owner, group => $group;
}
  }
}


and the following call:


modules_dir { ["munin", "munin/nodes", "munin/plugins" ]: }


As @$modules/munin/files/nodes/modules_dir@ doesn't exist, it should take the 
second fallback and more generic one @$modules/common/files/empty@ which exists.

However the resource fails completely with the following 2 rather cryptic error 
messages:


/usr/lib/ruby/site_ruby/1.8/puppet/type/file.rb:588:in `recurse_remote'
/usr/lib/ruby/site_ruby/1.8/puppet/type/file.rb:587:in `each'
/usr/lib/ruby/site_ruby/1.8/puppet/type/file.rb:587:in `recurse_remote'
/usr/lib/ruby/site_ruby/1.8/puppet/type/file.rb:483:in `recurse'
/usr/lib/ruby/site_ruby/1.8/puppet/type/file.rb:385:in `eval_generate'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:347:in `send'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:347:in 
`generate_additional_resources'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:191:in `eval_generate'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:238:in 
`eval_children_and_apply_resource'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:205:in `eval_resource'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:294:in `evaluate'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:417:in `thinmark'
/usr/lib/ruby/1.8/benchmark.rb:293:in `measure'
/usr/lib/ruby/1.8/benchmark.rb:307:in `realtime'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:416:in `thinmark'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:293:in `evaluate'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:287:in `collect'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:287:in `evaluate'
/usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:142:in `apply'
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:153:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:177:in `benchmark'
/usr/lib/ruby/1.8/benchmark.rb:293:in `measure'
/usr/lib/ruby/1.8/benchmark.rb:307:in `realtime'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:176:in `benchmark'
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:152:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:53:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent/locker.rb:21:in `lock'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:53:in `run'
/usr/lib/ruby/1.8/sync.rb:229:in `synchronize'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:53:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:130:in `with_client'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:51:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application/puppetd.rb:103:in `onetime'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:226:in `send'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:226:in `run_command'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:217:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:306:in `exit_on_fail'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:217:in `run'
/usr/sbin/puppetd:159
err: //Modules_dir[virtual]/File[/var/lib/puppet/modules/virtual]: Failed to 
generate additional resources using 'eval_generate'
: undefined method `relative_path' for nil:NilClass
/usr/lib/ruby/site_ruby/1.8/puppet/parameter.rb:401:in `fail'
/usr/lib/ruby/site_ruby/1.8/puppet/type/file/source.rb:160:in `init_metad

[Puppet - Bug #19376] user/group Autorequire with resources{'group':purge=>true} and resources{'user':purge=>true}

2013-02-21 Thread tickets


Issue #19376 has been updated by Curtis Ruck.


This appears to be a relative of #9622 from PE.

Bug #19376: user/group Autorequire with resources{'group':purge=>true} and 
resources{'user':purge=>true}
https://projects.puppetlabs.com/issues/19376#change-83651

Author: Curtis Ruck
Status: Unreviewed
Priority: Normal
Assignee: 
Category: purge
Target version: 
Affected Puppet version: 3.1.0
Keywords: 
Branch: 


When attempting to manage every user/group on a system, and setting 
@purge=>true@ on both @group@ and @user@, the user autorequires the group, but 
the group can't be purged until there is no members.

User autorequire should not autorequire groups if ensure=>absent... or maybe 
when purge=>true


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

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

[Facter - Bug #12556] ipv6 address facts

2013-02-21 Thread tickets


Issue #12556 has been updated by Andre Nathan.


Any work being done on this? I believe the facts should contain a list of 
addresses, since multiple addresses in a single interface are supported by IPv6.

Bug #12556: ipv6 address facts
https://projects.puppetlabs.com/issues/12556#change-83650

Author: Jure Pecar
Status: Accepted
Priority: Normal
Assignee: 
Category: 
Target version: 
Keywords: 
Branch: 
Affected Facter version: 1.6.4


Consider the following interfaces and addresses:

# ip a l
1: lo:  mtu 16436 qdisc noqueue state UNKNOWN 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc pfifo_fast state 
UNKNOWN qlen 1000
link/ether 00:50:56:b3:6a:5d brd ff:ff:ff:ff:ff:ff
inet 192.168.140.1/17 brd 192.168.255.255 scope global eth0
inet6 fe80::250:56ff:feb3:6a5d/64 scope link 
   valid_lft forever preferred_lft forever
3: eth1:  mtu 1500 qdisc pfifo_fast state 
UP qlen 1000
link/ether 00:50:56:b3:6a:5e brd ff:ff:ff:ff:ff:ff
inet6 fd00:1001:0:50:56:b3:6a:5e/64 scope global 
   valid_lft forever preferred_lft forever
inet6 fe80::250:56ff:feb3:6a5e/64 scope link 
   valid_lft forever preferred_lft forever

Now see what facter produces:

# facter | grep addr
ipaddress => 192.168.140.1
ipaddress6 => fd00:1001:0:50:56:b3:6a:5e
ipaddress_eth0 => 192.168.140.1
ipaddress_lo => 127.0.0.1
macaddress => 00:50:56:B3:6A:5D
macaddress_eth0 => 00:50:56:B3:6A:5D
macaddress_eth1 => 00:50:56:B3:6A:5E

I would expect to see a global ipaddress6 being specified for each v6 enabled 
interface (ipaddress6_eth1 in my case), but this is not the 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 unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #14784] zypper provider mis-handles packages with specified repository

2013-02-21 Thread tickets


Issue #14784 has been updated by Joachim de Groot.


Title and description are misleading as the problem in this case is the epoch 
of the package.
The JDK rpm package has the epoch of **2000**, which seems to cause these 
issues:

/bin/rpm -q jdk --nosignature --nodigest --qf '%{NAME} 
%|EPOCH?{%{EPOCH}}:{0}| %{VERSION} %{RELEASE} %{ARCH}'
jdk 2000 1.6.0_06 fcs x86_64

Bug #14784: zypper provider mis-handles packages with specified repository
https://projects.puppetlabs.com/issues/14784#change-83648

Author: David Gwilliam
Status: Accepted
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 
Keywords: 
Branch: 


Given this manifest (on SLES11.1):
class jdktest {
  package{ 'jdk':
ensure  => '2000:1.7.0_02-fcs',
  }
}
the package is installed correctly, but on subsequent runs, the version check 
fails and this is seen in the logs repeatedly:
debug: Package[jdk](provider=zypper): Ensuring => 2000:1.7.0_02-fcs
debug: Puppet::Type::Package::ProviderZypper: Executing '/usr/bin/zypper 
--quiet install -l -y jdk-2000:1.7.0_02-fcs'
debug: Puppet::Type::Package::ProviderZypper: Executing '/bin/rpm -q jdk 
--nosignature --nodigest --qf %{NAME} %|EPOCH?{%{EPOCH}}:{0}| %{VERSION} 
%{RELEASE} %{ARCH}'
notice: /Stage[main]/Jdktest/Package[jdk]/ensure: ensure changed 
'1.7.0_02-fcs' to '2000:1.7.0_02-fcs' 

because the zypper provider falls back to rpm to check versions, and rpm 
doesn't support the same REPO:version syntax. When the "2000:" is removed from 
the ensure param, the following error is reported:
debug: Puppet::Type::Package::ProviderZypper: Executing '/bin/rpm -q jdk 
--nosignature --nodigest --qf %{NAME} %|EPOCH?{%{EPOCH}}:{0}| %{VERSION} 
%{RELEASE} %{ARCH}'
debug: Package[jdk](provider=zypper): Ensuring => 1.7.0_02-fcs
debug: Puppet::Type::Package::ProviderZypper: Executing '/usr/bin/zypper 
--quiet install -l -y jdk-1.7.0_02-fcs'
err: /Stage[main]/Jdktest/Package[jdk]/ensure: change from absent to 
1.7.0_02-fcs failed: Could not update: Execution of '/usr/bin/zypper --quiet 
install -l -y jdk-1.7.0_02-fcs' returned 104: 'jdk-1.7.0_02-fcs' not found.
at /data/ss/svn/puppet/modules/jdktest/manifests/init.pp:6


-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Feature #12179] Package resource should allow ensure=>">1.0" or ensure=>"<0.10" as well as 'latest', 'installed' and specific version number

2013-02-21 Thread tickets


Issue #12179 has been updated by Henrik Lindberg.


Suggest using a repository manager that includes a feature to define 
(constrained) views of the repository. Manage the constrained sets with the 
repository manager.
(Take a look at something like Sontatype's Nexus)

Feature #12179: Package resource should allow ensure=>">1.0" or ensure=>"<0.10" 
as well as 'latest', 'installed' and specific version number
https://projects.puppetlabs.com/issues/12179#change-83646

Author: Steve Shipway
Status: Needs Decision
Priority: Normal
Assignee: J.D. Welch
Category: language
Target version: 
Affected Puppet version: 2.7.9
Keywords: ux
Branch: 


It would be helpful if the 'ensure' parameter to the Package resrouce could 
also specify 'at least version **x**' and 'no later than version **y**' as well 
as 'latest version', 'installed' (IE, any version) or a specific version number.

EG:

package { 'foo': ensure=>'>1.0' }

would act as 'latest' if the current package was uninstalled or version before 
1.0, but would act as 'installed' otherwise. Similarly, 

package { 'foo': ensure=>'<4.0' }

would act as 'installed' if version is <4.0 but would produce an error 
otherwise.

This would allow us to set a manifest to avoid packages with known problems in 
a certain version, but not upgrade unless necessary. 


-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #7680] Checksum missmatch when copying followed symlinks

2013-02-21 Thread tickets


Issue #7680 has been updated by Chris Boot.


Hi,

I'm struggling to understand the updates from Adrien to this bug; I can confirm 
again that applying the patch to Puppet *clients* running version 2.7.18-2 (as 
packaged by Debian) resolves the problem for us and so far we have seen no 
adverse effects to carrying this patch locally on a number of systems.

Are you saying the patch doesn't fix the bug, or that applying the patch causes 
regressions?

Thanks,
Chris

Bug #7680: Checksum missmatch when copying followed symlinks
https://projects.puppetlabs.com/issues/7680#change-83644

Author: Mikael Svantesson
Status: Code Insufficient
Priority: Normal
Assignee: 
Category: file
Target version: 
Affected Puppet version: 2.6.8
Keywords: symlink file
Branch: https://github.com/puppetlabs/puppet/pull/1476


When trying to copy a file (using a symlink), Puppet does not calculate the 
correct checksum for the temporary file.

This work in 2.6.7, I have not tried 2.7.x.

**Error:**
err: /Stage[pre]/Sudo/File[/etc/sudoers]/ensure: change from absent to 
present failed: Could not rename temporary file /etc/sudoers.puppettmp_4293 to 
/etc/sudoers:
File written to disk did not match checksum; discarding changes ( vs 
{md5}d41d8cd98f00b204e9800998ecf8427e) at 
/etc/puppet/modules/sudo/manifests/init.pp:12 at 
/etc/puppet/modules/sudo/manifests/init.pp:12

**Manifest:**
class sudo {
  package { 'sudo': ensure => installed }

  file { '/etc/sudoers':
ensure  => file,
source  => ["puppet:///modules/sudo/sudoers-${hostname}", 
'puppet:///modules/sudo/sudoers'],
links   => follow,
replace => true,
owner   => 'root',
group   => 'root',
mode=> '0440',
  }
}

**File structure:**
modules/sudo/files
|-- sudoers
|-- sudoers-host1
`-- sudoers-host2 -> sudoers-host1




-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #19379] (Unreviewed) exec: logoutput=>on_error always logs

2013-02-21 Thread tickets


Issue #19379 has been reported by Chris Ritson.


Bug #19379: exec: logoutput=>on_error always logs
https://projects.puppetlabs.com/issues/19379

Author: Chris Ritson
Status: Unreviewed
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 2.7.14
Keywords: exec logoutput
Branch: 


We are using an exec construct to look for unwanted long-running processes and 
kill them. This is currently logging everything as "notice" messages. In an 
attempt to suppress this when it is not needed, I tried to use the logoutput 
parameter in the exec. The documentation contains the following mutually 
inconsistent statements:-

* Values are true, false, on_failure, and any legal log level
* Valid values are true, false, on_failure

Trying to use a legal syslog level either symbolically "info", info or 6 always 
raises a compilation/syntax error from the master at run time. Setting this 
parameter to "on_failure" or "false" always logs output even when this output 
states that the command was successful. Our master is on 2.7.14, the specific 
client I was testing on uses 2.6.16.


-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Feature #19162] Manage reboots

2013-02-21 Thread tickets


Issue #19162 has been updated by Curtis Ruck.


i've found this can be done by chaining stages together, with each stage having 
a refreshonly=>true exec to force reboot.  It shows "failed" a few times until 
it gets through all the stages though.

Feature #19162: Manage reboots
https://projects.puppetlabs.com/issues/19162#change-83643

Author: Josh Cooper
Status: Accepted
Priority: Normal
Assignee: eric sorenson
Category: 
Target version: 
Affected Puppet version: 
Keywords: windows reboot
Branch: 


We need to be able to manage reboots (mostly an issue on Windows), since a 
simple task like installing IIS-WebService using puppet's dism module requires 
a reboot.





-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #19315] puppet is buggy when using a hash as a $name

[Puppet - Bug #17030] pip provider should handle multiple pips/pythons

[Puppet - Bug #5517] behavior change within 2.6 makes it impossible to override class parameters of "included" parametrized classes

[Puppet - Feature #7243] Additional data in Puppet CSRs (certdnsnames, and custom data)

[Puppet - Bug #19247] puppet no longer colorizes notice-level output

[Puppet - Bug #14093] (Merged - Pending Release) variable called $string in scope prevents templates from working

[Puppet - Bug #15561] Fix for CVE-2012-3867 is too restrictive

[Puppet - Bug #17879] (Duplicate) extract cert name properly from subject DN

[Puppet - Bug #19396] Wrong environment being saved in yaml/database when using storeconfigs

[Puppet - Bug #19396] (Investigating) Wrong environment being saved in yaml/database when using storeconfigs

[Puppet - Bug #19396] (Re-opened) Wrong environment being saved in yaml/database when using storeconfigs

[Puppet - Bug #19396] (Closed) Wrong environment being saved in yaml/database when using storeconfigs

[Puppet - Feature #19395] (Unreviewed) Detect client-server version mismatch, warn and optionally disallow

[Puppet - Bug #15561] Fix for CVE-2012-3867 is too restrictive

[Puppet - Bug #17879] (Re-opened) extract cert name properly from subject DN

[Puppet - Bug #19390] Puppet agent getting stuck

[Puppet - Bug #19390] Puppet agent getting stuck

[Puppet - Bug #19390] (Unreviewed) Puppet agent getting stuck

[Puppet - Feature #12260] All puppet module commands should support json and yaml output

[Puppet - Bug #15561] Fix for CVE-2012-3867 is too restrictive

[Puppet - Bug #19385] (Rejected) Puppetdb installation via module

[Puppet - Bug #19385] (Unreviewed) Puppetdb installation via module

[Puppet - Bug #2823] fail and unhelpful error message if a remote directory doesn't exist.

[Puppet - Feature #19188] configurable behavior with non-existing hiera variables

[Puppet - Bug #5517] behavior change within 2.6 makes it impossible to override class parameters of "included" parametrized classes

[Puppet - Bug #2823] fail and unhelpful error message if a remote directory doesn't exist.

[Puppet - Bug #19376] user/group Autorequire with resources{'group':purge=>true} and resources{'user':purge=>true}

[Facter - Bug #12556] ipv6 address facts

[Puppet - Bug #14784] zypper provider mis-handles packages with specified repository

[Puppet - Feature #12179] Package resource should allow ensure=>">1.0" or ensure=>"<0.10" as well as 'latest', 'installed' and specific version number

[Puppet - Bug #7680] Checksum missmatch when copying followed symlinks

[Puppet - Bug #19379] (Unreviewed) exec: logoutput=>on_error always logs

[Puppet - Feature #19162] Manage reboots

33 matches

Site Navigation

Mail list logo

Footer information