[Puppet - Bug #5239] Exported resources are hard to collect by environment
Issue #5239 has been updated by Jordan Sissel.
For clarity, my feature request here is to allow exported resource collection
by environment without requiring the use of tags.
Some::Resource | enviroment == ... |
Bug #5239: Exported resources are hard to collect by environment
https://projects.puppetlabs.com/issues/5239
Author: Jordan Sissel
Status: Needs More Information
Priority: Normal
Assignee: Nigel Kersten
Category:
Target version:
Affected Puppet version: 2.6.2
Keywords: exported resources collection environments
Branch:
I noticed today that Foo | | collects all Foo resources regardless of
environment. Doing Foo | environment == ... | would be cool, but I don't
think that works.
Why was this a problem? I have multiple deployments; some of which cannot see
each other on the network (outside of the storeconfigs db). As a result of this
behavior (collect all resources in all environments), I have nagios instances
that try to monitor machines they can't see and thus all checks fail and pager
goes beep beep. ;)
I found a work around using tags.
pre
node default {
# Globally apply an environment-based tag to all resources on each node.
tag(deployment::$environment)
...
}
# And later ...
SomeResource | tag == deployment::$environment |
/pre
The above workaround is sufficient for me to continue deploying exported
resources (not a blocker).
I was expecting collectors of exported resources would only, by default, get
resources from the same environment. Barring that, I think a query of |
environment == ... | would be quite useful rather than resorting to tagging.
--
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 #9672] ssh ecdsa keys
Issue #9672 has been updated by Stefan Schulte.
this is a duplication of #8193 and given that the first have of the patch is
exactly the patch in #8193 why not comment on the original code ;-)?
Feature #9672: ssh ecdsa keys
https://projects.puppetlabs.com/issues/9672
Author: David Hill
Status: In Topic Branch Pending Review
Priority: Normal
Assignee: David Hill
Category: ssh
Target version: 2.7.x
Affected Puppet version:
Keywords: ssh
Branch:
The following patches allows puppet to properly identify ecdsa keys use by SSH.
These are now enabled by default in OpenBSD. I'd like to see these put into
puppet. See ticket #4488 as well.
pre
--- lib/puppet/type/ssh_authorized_key.rb.orig Sat Aug 6 14:18:42 2011
+++ lib/puppet/type/ssh_authorized_key.rb Thu Sep 22 16:22:13 2011
@@ -23,11 +23,10 @@ module Puppet
newproperty(:type) do
desc The encryption type used: ssh-dss or ssh-rsa.
- newvalue(ssh-dss)
- newvalue(ssh-rsa)
-
- aliasvalue(:dsa, ssh-dss)
- aliasvalue(:rsa, ssh-rsa)
+ newvalues :'ssh-dss', :'ssh-rsa', :'ecdsa-sha2-nistp256',
:'ecdsa-sha2-nistp384', :'ecdsa-sha2-nistp521'
+
+ aliasvalue(:dsa, :'ssh-dss')
+ aliasvalue(:rsa, :'ssh-rsa')
end
newproperty(:key) do
--- spec/unit/type/ssh_authorized_key_spec.rb.orig Sat Aug 6 14:19:01 2011
+++ spec/unit/type/ssh_authorized_key_spec.rb Thu Sep 22 16:23:15 2011
@@ -70,23 +70,11 @@ describe ssh_authorized_key do
describe for type do
-
- it should support ssh-dss do
-proc { @class.new(:name = whev, :type = ssh-dss, :user =
nobody) }.should_not raise_error
- end
-
- it should support ssh-rsa do
-proc { @class.new(:name = whev, :type = ssh-rsa, :user =
nobody) }.should_not raise_error
- end
-
- it should support :dsa do
-proc { @class.new(:name = whev, :type = :dsa, :user = nobody)
}.should_not raise_error
- end
-
- it should support :rsa do
-proc { @class.new(:name = whev, :type = :rsa, :user = nobody)
}.should_not raise_error
- end
-
+ [:'ssh-dss', :'ssh-rsa', :rsa, :dsa, :'ecdsa-sha2-nistp256',
:'ecdsa-sha2-nistp384', :'ecdsa-sha2-nistp521'].each do |keytype|
+it should support #{keytype} do
+ proc { @class.new(:name = whev, :type = keytype, :user =
nobody) }.should_not raise_error
+end
+ end
it should alias :rsa to :ssh-rsa do
key = @class.new(:name = whev, :type = :rsa, :user = nobody)
key.should(:type).should == :'ssh-rsa'
--- lib/puppet/provider/ssh_authorized_key/parsed.rb.orig Sat Aug 6
14:18:42 2011
+++ lib/puppet/provider/ssh_authorized_key/parsed.rbFri Sep 23 09:30:15 2011
@@ -17,7 +17,11 @@ require 'puppet/provider/parsedfile'
:fields = %w{options type key name},
:optional = %w{options},
:rts = /^\s+/,
-:match= /^(?:(.+) )?(ssh-dss|ssh-rsa) ([^ ]+) ?(.*)$/,
+# The name field is not optional here. Lines without a name
+# will be matched by the text_line :unrecognised rule instead.
+# (Do not change the (.+) at the end to (.*), or make the preceding
+# space optional.)
+:match= /^(?:(.+)
)?(ssh-dss|ssh-rsa|ecdsa-sha2-nistp256|ecdsa-sha2-nistp384|ecdsa-sha2-nistp521)
([^ ]+) (.+)$/,
:post_parse = proc { |h|
h[:name] = if h[:name] == :absent
h[:options] ||= [:absent]
@@ -33,6 +37,8 @@ require 'puppet/provider/parsedfile'
:optional = %w{options},
:rts = /^\s+/,
:match= /^(?:(.+) )?(\d+) (\d+) (\d+)(?: (.+))?$/
+
+ text_line :unrecognised, :match = //
def dir_perm
0700
/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 #8193] ssh_authorized_keys should support new key types
Issue #8193 has been updated by Stefan Schulte. updated branch after reading #9672 by David Hill. I apparently forgot to patch the `ssh_authorized_key` provider to be able to parse the new keyentries. Bug #8193: ssh_authorized_keys should support new key types https://projects.puppetlabs.com/issues/8193 Author: Stig Sandbeck Mathisen Status: In Topic Branch Pending Review Priority: Normal Assignee: Category: Target version: Affected Puppet version: Keywords: ssh, ssh key, ssh_authorized_key, sshkey, ecdsa Branch: https://github.com/stschulte/puppet/tree/ticket/2.7.x/8193 SSH now supports additional key types. From the sshd man page (openssh version 5.8p1 on ubuntu): blockquote For protocol version 2 the keytype is “ecdsa-sha2-nistp256”, “ecdsa-sha2-nistp384”, “ecdsa-sha2-nistp521”, “ssh-dss” or “ssh-rsa”. /blockquote The puppet ssh_authorized_key and sshkey types only support ssh-dss and ssh-rsa. -- 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 #8239] zombie getconf processes, possibly from facter
Issue #8239 has been updated by John Florian. I'm consistently experiencing this bug. I get one more zombie every time puppet executes the custom module fact shown below. This is with puppet-2.6.6-1.fc15.noarch and facter-1.6.0-2.fc15.noarch on Fedora 15. Please let me know if I can provide other details. (This immediately reminded me of the problems I saw and reported when I created #2211, but I see that's already linked here.) pre Facter.add(plant_number) do begin gw = IO.popen(/sbin/ip route show 0.0.0.0/0).read().split()[2] if gw plant = %02d % gw.split(.)[1] else plant = nil end end setcode do plant end end /pre Bug #8239: zombie getconf processes, possibly from facter https://projects.puppetlabs.com/issues/8239 Author: Giles Constant Status: Investigating Priority: Normal Assignee: Adrien Thebo Category: agent Target version: Affected Puppet version: 2.7.1 Keywords: getconf zombie defunct Branch: I'm seeing this.. [root@x001 ~]# pstree |grep getconf |-puppetd---574*[getconf] 574 getconf zombies! root 32530 17822 0 Jun27 ?00:00:00 [getconf] defunct root 32532 17822 0 Jun29 ?00:00:00 [getconf] defunct root 32546 17822 0 Jul05 ?00:00:00 [getconf] defunct ...etc... Facter version 1.5.8, Puppet 2.6.6. I've had a look at the old bug relating to 'timeout' in resolution.rb, but setting it to an integer other than 0 didn't make the problem go away. -- 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 #9854] (Unreviewed) extlookup_datadir and extlookup_precedence not being set in puppet 2.7.1
Issue #9854 has been reported by Lex van Roon.
Bug #9854: extlookup_datadir and extlookup_precedence not being set in puppet
2.7.1
https://projects.puppetlabs.com/issues/9854
Author: Lex van Roon
Status: Unreviewed
Priority: Normal
Assignee:
Category: server
Target version:
Affected Puppet version: 2.7.1
Keywords:
Branch:
During tests on a puppet 2.7.1 setup, we've discovered that we could no longer
use extlookups. With 2.6, we use the following (cleaned up) manifest to perform
extlookups. Note that we use a custom fact to derive the zone + location
variables from the domain name, which are 'core' and 'ams01' in our situation.
We derive the datadir from the currently used module using an inline template.
class test {
$extlookup_datadir = inline_template(%=
Puppet::Node::Environment.current.module('${module_name}').path %/extdata)
$extlookup_precedence = [hosts/%{fqdn}, %{zone}-%{location},
%{location}, inline_template(%= if defined? @location then
location.gsub(/[^a-z\s]/, \\) end%), 'default']
notify { extlookup_datadir: ${extlookup_datadir}:; }
notify { extlookup_precedence: ${extlookup_precedence}:; }
$msg = extlookup(hello)
notify { hello ${msg}:; }
notify { zone: ${zone}:; }
notify { location: ${location}:; }
}
For the purpose of this bugreport, I've got one variable defined in my CSV file
named 'hello' with the value of 'world'. Using puppet 2.7.1, this gives us the
following error:
root@puppetmaster002:~# puppet agent --test
info: Retrieving plugin
info: Loading facts in environment
info: Loading facts in interfaces
info: Loading facts in zone
info: Loading facts in puppet_var_path
info: Loading facts in acpi_available
info: Loading facts in mountpoints
info: Loading facts in location
info: Loading facts in environment
info: Loading facts in interfaces
info: Loading facts in zone
info: Loading facts in puppet_var_path
info: Loading facts in acpi_available
info: Loading facts in mountpoints
info: Loading facts in location
err: Could not retrieve catalog from remote server: Error 400 on SERVER: No
match found for 'hello' in any data file during extlookup()
at /etc/puppet/modules/shared/test/manifests/init.pp:9 on node
puppetmaster002.core.ams01.domain.tld
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
Both this output and the puppetmaster logs do not give any hints as to whats
going on (see #7158), nor do debug/verbose mode give more info. Using strace
attached to the puppetmaster process, I found that the puppetmaster process is
trying to open the following CSV file:
root@puppetmaster002:~# grep stat\(.*csv /tmp/out
14959 stat(/.csv, 0x7fff144f5390) = -1 ENOENT (No such file or
directory)
This leads me to think that both extlookup_datadir and extlookup_preference are
not being parsed correctly under 2.7.1, or are being ignored completely. Using
puppet 2.6.8, we get the following output:
root@puppetmaster002:~# puppet agent --test
info: Retrieving plugin
info: Loading facts in environment
info: Loading facts in acpi_available
info: Loading facts in puppet_var_path
info: Loading facts in location
info: Loading facts in mountpoints
info: Loading facts in zone
info: Loading facts in interfaces
info: Loading facts in environment
info: Loading facts in acpi_available
info: Loading facts in puppet_var_path
info: Loading facts in location
info: Loading facts in mountpoints
info: Loading facts in zone
info: Loading facts in interfaces
info: Caching catalog for puppetmaster002.core.ams01.sn.ecg
info: Applying configuration version '1317646685'
notice: hello world
notice: /Stage[main]/Test/Notify[hello world]/message: defined 'message' as
'hello world'
notice: extlookup_precedence:
hosts/%{fqdn}%{zone}-%{location}%{location}amsdefault
notice: /Stage[main]/Test/Notify[extlookup_precedence:
hosts/%{fqdn}%{zone}-%{location}%{location}amsdefault]/message: defined
'message'
as 'extlookup_precedence:
hosts/%{fqdn}%{zone}-%{location}%{location}amsdefault'
notice: location: ams01
notice: /Stage[main]/Test/Notify[location: ams01]/message: defined
'message' as 'location: ams01'
notice: extlookup_datadir: /etc/puppet/modules/shared/test/extdata
notice: /Stage[main]/Test/Notify[extlookup_datadir:
/etc/puppet/modules/shared/test/extdata]/message: defined 'message' as
'extlookup_datadir: /etc/puppet/modules/shared/test/extdata'
notice: zone: core
notice: /Stage[main]/Test/Notify[zone: core]/message: defined 'message' as
'zone: core'
notice: Finished catalog run in 0.05 seconds
which is correct. Verifying the opened files with strace gives us the following:
root@puppetmaster002:~# grep
[Puppet - Bug #9854] extlookup_datadir and extlookup_precedence not being set in puppet 2.7.1
Issue #9854 has been updated by Lex van Roon.
Just to test I replaced extlookup.rb from 2.7.1 with the version that came with
2.6.8, and this makes extlookups work again.
Bug #9854: extlookup_datadir and extlookup_precedence not being set in puppet
2.7.1
https://projects.puppetlabs.com/issues/9854
Author: Lex van Roon
Status: Unreviewed
Priority: Normal
Assignee:
Category: server
Target version:
Affected Puppet version: 2.7.1
Keywords:
Branch:
During tests on a puppet 2.7.1 setup, we've discovered that we could no longer
use extlookups. With 2.6, we use the following (cleaned up) manifest to perform
extlookups. Note that we use a custom fact to derive the zone + location
variables from the domain name, which are 'core' and 'ams01' in our situation.
We derive the datadir from the currently used module using an inline template.
class test {
$extlookup_datadir = inline_template(%=
Puppet::Node::Environment.current.module('${module_name}').path %/extdata)
$extlookup_precedence = [hosts/%{fqdn}, %{zone}-%{location},
%{location}, inline_template(%= if defined? @location then
location.gsub(/[^a-z\s]/, \\) end%), 'default']
notify { extlookup_datadir: ${extlookup_datadir}:; }
notify { extlookup_precedence: ${extlookup_precedence}:; }
$msg = extlookup(hello)
notify { hello ${msg}:; }
notify { zone: ${zone}:; }
notify { location: ${location}:; }
}
For the purpose of this bugreport, I've got one variable defined in my CSV file
named 'hello' with the value of 'world'. Using puppet 2.7.1, this gives us the
following error:
root@puppetmaster002:~# puppet agent --test
info: Retrieving plugin
info: Loading facts in environment
info: Loading facts in interfaces
info: Loading facts in zone
info: Loading facts in puppet_var_path
info: Loading facts in acpi_available
info: Loading facts in mountpoints
info: Loading facts in location
info: Loading facts in environment
info: Loading facts in interfaces
info: Loading facts in zone
info: Loading facts in puppet_var_path
info: Loading facts in acpi_available
info: Loading facts in mountpoints
info: Loading facts in location
err: Could not retrieve catalog from remote server: Error 400 on SERVER: No
match found for 'hello' in any data file during extlookup()
at /etc/puppet/modules/shared/test/manifests/init.pp:9 on node
puppetmaster002.core.ams01.domain.tld
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
Both this output and the puppetmaster logs do not give any hints as to whats
going on (see #7158), nor do debug/verbose mode give more info. Using strace
attached to the puppetmaster process, I found that the puppetmaster process is
trying to open the following CSV file:
root@puppetmaster002:~# grep stat\(.*csv /tmp/out
14959 stat(/.csv, 0x7fff144f5390) = -1 ENOENT (No such file or
directory)
This leads me to think that both extlookup_datadir and extlookup_preference are
not being parsed correctly under 2.7.1, or are being ignored completely. Using
puppet 2.6.8, we get the following output:
root@puppetmaster002:~# puppet agent --test
info: Retrieving plugin
info: Loading facts in environment
info: Loading facts in acpi_available
info: Loading facts in puppet_var_path
info: Loading facts in location
info: Loading facts in mountpoints
info: Loading facts in zone
info: Loading facts in interfaces
info: Loading facts in environment
info: Loading facts in acpi_available
info: Loading facts in puppet_var_path
info: Loading facts in location
info: Loading facts in mountpoints
info: Loading facts in zone
info: Loading facts in interfaces
info: Caching catalog for puppetmaster002.core.ams01.sn.ecg
info: Applying configuration version '1317646685'
notice: hello world
notice: /Stage[main]/Test/Notify[hello world]/message: defined 'message' as
'hello world'
notice: extlookup_precedence:
hosts/%{fqdn}%{zone}-%{location}%{location}amsdefault
notice: /Stage[main]/Test/Notify[extlookup_precedence:
hosts/%{fqdn}%{zone}-%{location}%{location}amsdefault]/message: defined
'message'
as 'extlookup_precedence:
hosts/%{fqdn}%{zone}-%{location}%{location}amsdefault'
notice: location: ams01
notice: /Stage[main]/Test/Notify[location: ams01]/message: defined
'message' as 'location: ams01'
notice: extlookup_datadir: /etc/puppet/modules/shared/test/extdata
notice: /Stage[main]/Test/Notify[extlookup_datadir:
/etc/puppet/modules/shared/test/extdata]/message: defined 'message' as
'extlookup_datadir: /etc/puppet/modules/shared/test/extdata'
notice: zone: core
notice: /Stage[main]/Test/Notify[zone: core]/message: defined 'message' as
'zone: core'
notice: Finished catalog run in 0.05
[Puppet - Bug #9854] (Needs More Information) extlookup_datadir and extlookup_precedence not being set in puppet 2.7.1
Issue #9854 has been updated by James Turnbull.
Status changed from Unreviewed to Needs More Information
Assignee set to Lex van Roon
Hi Lex
Have you tried using the 2.6 function with 2.7? That's the fastest workaround
I could suggest.
Bug #9854: extlookup_datadir and extlookup_precedence not being set in puppet
2.7.1
https://projects.puppetlabs.com/issues/9854
Author: Lex van Roon
Status: Needs More Information
Priority: Normal
Assignee: Lex van Roon
Category: server
Target version:
Affected Puppet version: 2.7.1
Keywords:
Branch:
During tests on a puppet 2.7.1 setup, we've discovered that we could no longer
use extlookups. With 2.6, we use the following (cleaned up) manifest to perform
extlookups. Note that we use a custom fact to derive the zone + location
variables from the domain name, which are 'core' and 'ams01' in our situation.
We derive the datadir from the currently used module using an inline template.
class test {
$extlookup_datadir = inline_template(%=
Puppet::Node::Environment.current.module('${module_name}').path %/extdata)
$extlookup_precedence = [hosts/%{fqdn}, %{zone}-%{location},
%{location}, inline_template(%= if defined? @location then
location.gsub(/[^a-z\s]/, \\) end%), 'default']
notify { extlookup_datadir: ${extlookup_datadir}:; }
notify { extlookup_precedence: ${extlookup_precedence}:; }
$msg = extlookup(hello)
notify { hello ${msg}:; }
notify { zone: ${zone}:; }
notify { location: ${location}:; }
}
For the purpose of this bugreport, I've got one variable defined in my CSV file
named 'hello' with the value of 'world'. Using puppet 2.7.1, this gives us the
following error:
root@puppetmaster002:~# puppet agent --test
info: Retrieving plugin
info: Loading facts in environment
info: Loading facts in interfaces
info: Loading facts in zone
info: Loading facts in puppet_var_path
info: Loading facts in acpi_available
info: Loading facts in mountpoints
info: Loading facts in location
info: Loading facts in environment
info: Loading facts in interfaces
info: Loading facts in zone
info: Loading facts in puppet_var_path
info: Loading facts in acpi_available
info: Loading facts in mountpoints
info: Loading facts in location
err: Could not retrieve catalog from remote server: Error 400 on SERVER: No
match found for 'hello' in any data file during extlookup()
at /etc/puppet/modules/shared/test/manifests/init.pp:9 on node
puppetmaster002.core.ams01.domain.tld
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
Both this output and the puppetmaster logs do not give any hints as to whats
going on (see #7158), nor do debug/verbose mode give more info. Using strace
attached to the puppetmaster process, I found that the puppetmaster process is
trying to open the following CSV file:
root@puppetmaster002:~# grep stat\(.*csv /tmp/out
14959 stat(/.csv, 0x7fff144f5390) = -1 ENOENT (No such file or
directory)
This leads me to think that both extlookup_datadir and extlookup_preference are
not being parsed correctly under 2.7.1, or are being ignored completely. Using
puppet 2.6.8, we get the following output:
root@puppetmaster002:~# puppet agent --test
info: Retrieving plugin
info: Loading facts in environment
info: Loading facts in acpi_available
info: Loading facts in puppet_var_path
info: Loading facts in location
info: Loading facts in mountpoints
info: Loading facts in zone
info: Loading facts in interfaces
info: Loading facts in environment
info: Loading facts in acpi_available
info: Loading facts in puppet_var_path
info: Loading facts in location
info: Loading facts in mountpoints
info: Loading facts in zone
info: Loading facts in interfaces
info: Caching catalog for puppetmaster002.core.ams01.sn.ecg
info: Applying configuration version '1317646685'
notice: hello world
notice: /Stage[main]/Test/Notify[hello world]/message: defined 'message' as
'hello world'
notice: extlookup_precedence:
hosts/%{fqdn}%{zone}-%{location}%{location}amsdefault
notice: /Stage[main]/Test/Notify[extlookup_precedence:
hosts/%{fqdn}%{zone}-%{location}%{location}amsdefault]/message: defined
'message'
as 'extlookup_precedence:
hosts/%{fqdn}%{zone}-%{location}%{location}amsdefault'
notice: location: ams01
notice: /Stage[main]/Test/Notify[location: ams01]/message: defined
'message' as 'location: ams01'
notice: extlookup_datadir: /etc/puppet/modules/shared/test/extdata
notice: /Stage[main]/Test/Notify[extlookup_datadir:
/etc/puppet/modules/shared/test/extdata]/message: defined 'message' as
'extlookup_datadir: /etc/puppet/modules/shared/test/extdata'
notice: zone: core
notice: /Stage[main]/Test/Notify[zone:
[Puppet - Bug #9854] (Needs Decision) extlookup_datadir and extlookup_precedence not being set in puppet 2.7.1
Issue #9854 has been updated by James Turnbull.
Status changed from Needs More Information to Needs Decision
Assignee changed from Lex van Roon to Nigel Kersten
Priority changed from Normal to Urgent
Oops missed your update. :)
Nigel - think this one needs prompt action.
Bug #9854: extlookup_datadir and extlookup_precedence not being set in puppet
2.7.1
https://projects.puppetlabs.com/issues/9854
Author: Lex van Roon
Status: Needs Decision
Priority: Urgent
Assignee: Nigel Kersten
Category: server
Target version:
Affected Puppet version: 2.7.1
Keywords:
Branch:
During tests on a puppet 2.7.1 setup, we've discovered that we could no longer
use extlookups. With 2.6, we use the following (cleaned up) manifest to perform
extlookups. Note that we use a custom fact to derive the zone + location
variables from the domain name, which are 'core' and 'ams01' in our situation.
We derive the datadir from the currently used module using an inline template.
class test {
$extlookup_datadir = inline_template(%=
Puppet::Node::Environment.current.module('${module_name}').path %/extdata)
$extlookup_precedence = [hosts/%{fqdn}, %{zone}-%{location},
%{location}, inline_template(%= if defined? @location then
location.gsub(/[^a-z\s]/, \\) end%), 'default']
notify { extlookup_datadir: ${extlookup_datadir}:; }
notify { extlookup_precedence: ${extlookup_precedence}:; }
$msg = extlookup(hello)
notify { hello ${msg}:; }
notify { zone: ${zone}:; }
notify { location: ${location}:; }
}
For the purpose of this bugreport, I've got one variable defined in my CSV file
named 'hello' with the value of 'world'. Using puppet 2.7.1, this gives us the
following error:
root@puppetmaster002:~# puppet agent --test
info: Retrieving plugin
info: Loading facts in environment
info: Loading facts in interfaces
info: Loading facts in zone
info: Loading facts in puppet_var_path
info: Loading facts in acpi_available
info: Loading facts in mountpoints
info: Loading facts in location
info: Loading facts in environment
info: Loading facts in interfaces
info: Loading facts in zone
info: Loading facts in puppet_var_path
info: Loading facts in acpi_available
info: Loading facts in mountpoints
info: Loading facts in location
err: Could not retrieve catalog from remote server: Error 400 on SERVER: No
match found for 'hello' in any data file during extlookup()
at /etc/puppet/modules/shared/test/manifests/init.pp:9 on node
puppetmaster002.core.ams01.domain.tld
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
Both this output and the puppetmaster logs do not give any hints as to whats
going on (see #7158), nor do debug/verbose mode give more info. Using strace
attached to the puppetmaster process, I found that the puppetmaster process is
trying to open the following CSV file:
root@puppetmaster002:~# grep stat\(.*csv /tmp/out
14959 stat(/.csv, 0x7fff144f5390) = -1 ENOENT (No such file or
directory)
This leads me to think that both extlookup_datadir and extlookup_preference are
not being parsed correctly under 2.7.1, or are being ignored completely. Using
puppet 2.6.8, we get the following output:
root@puppetmaster002:~# puppet agent --test
info: Retrieving plugin
info: Loading facts in environment
info: Loading facts in acpi_available
info: Loading facts in puppet_var_path
info: Loading facts in location
info: Loading facts in mountpoints
info: Loading facts in zone
info: Loading facts in interfaces
info: Loading facts in environment
info: Loading facts in acpi_available
info: Loading facts in puppet_var_path
info: Loading facts in location
info: Loading facts in mountpoints
info: Loading facts in zone
info: Loading facts in interfaces
info: Caching catalog for puppetmaster002.core.ams01.sn.ecg
info: Applying configuration version '1317646685'
notice: hello world
notice: /Stage[main]/Test/Notify[hello world]/message: defined 'message' as
'hello world'
notice: extlookup_precedence:
hosts/%{fqdn}%{zone}-%{location}%{location}amsdefault
notice: /Stage[main]/Test/Notify[extlookup_precedence:
hosts/%{fqdn}%{zone}-%{location}%{location}amsdefault]/message: defined
'message'
as 'extlookup_precedence:
hosts/%{fqdn}%{zone}-%{location}%{location}amsdefault'
notice: location: ams01
notice: /Stage[main]/Test/Notify[location: ams01]/message: defined
'message' as 'location: ams01'
notice: extlookup_datadir: /etc/puppet/modules/shared/test/extdata
notice: /Stage[main]/Test/Notify[extlookup_datadir:
/etc/puppet/modules/shared/test/extdata]/message: defined 'message' as
'extlookup_datadir: /etc/puppet/modules/shared/test/extdata'
notice: zone: core
notice:
[Puppet - Feature #8411] File type working on Windows
Issue #8411 has been updated by Josh Cooper. Target version changed from 2.7.x to 2.7.5 % Done changed from 0 to 100 There was a problem setting file group on posix platforms. This has been merged to 2.7.x in commit 214b92979b1c789fac1c6cc1fa4df9cf8d5f3158 Feature #8411: File type working on Windows https://projects.puppetlabs.com/issues/8411 Author: Jacob Helwig Status: Merged - Pending Release Priority: Normal Assignee: Josh Cooper Category: windows Target version: 2.7.5 Affected Puppet version: Keywords: Branch: Support for managing content (via source, and content), owner, group, and basic permissions. No support for full ACLs. Managing directories will turn off permission inheritance from the parent, and blow away any existing ACL settings on the file/directory. -- 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 #9027] (In Topic Branch Pending Review) groupadd provider throws spurious warnings about AIX feature on non-AIX platforms.
Issue #9027 has been updated by Josh Cooper.
Status changed from Accepted to In Topic Branch Pending Review
Assignee changed from Jacob Helwig to Josh Cooper
Target version changed from 2.7.x to 2.7.5
Branch set to https://github.com/puppetlabs/puppet/pull/151
This change is ready to be merged. It is the same as was done for in commit
49c5152d64bb2d73a2751e9844bb2b92b14b88eb for issue #7137
Bug #9027: groupadd provider throws spurious warnings about AIX feature on
non-AIX platforms.
https://projects.puppetlabs.com/issues/9027
Author: Jeremy Bowers
Status: In Topic Branch Pending Review
Priority: Normal
Assignee: Josh Cooper
Category: group
Target version: 2.7.5
Affected Puppet version: 2.7.3
Keywords:
Branch: https://github.com/puppetlabs/puppet/pull/151
`info: /Group[developer]: Provider groupadd does not support features
manages_aix_lam; not managing attribute ia_load_module`
Not sure when it started but seems to be related to #7137
I can reproduce this bug by creating a group on a non-AIX system (Mine is
Ubuntu 10.04 LTS)
pre
class users::developers {
group { developer:
ensure = present,
gid= '1001',
}
}
/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 #8651] Indirector does not handle windows paths
Issue #8651 has been updated by Josh Cooper.
Target version changed from 2.7.x to 2.7.5
Additional changes were made to the indirector as part of the file provider
refactor #8411 in merge commit ec587b449e56050afca9838b23df9f0d8ffc7a63 to
2.7.x. Specifically, commit:5fea1dc64829e9c8178937764faccd51131b2a77
Bug #8651: Indirector does not handle windows paths
https://projects.puppetlabs.com/issues/8651
Author: Josh Cooper
Status: Merged - Pending Release
Priority: Normal
Assignee: Jacob Helwig
Category: windows
Target version: 2.7.5
Affected Puppet version:
Keywords:
Branch:
Various indirections encode file paths in URI's such as file dipper, file
bucket, file server, but do not work with Windows paths.
For example, in lib/puppet/file_bucket/dipper.rb:
pre
Puppet::FileBucket::File.indirection.head(#{@rest_path}#{file_bucket_file.checksum_type}/#{file_bucket_file.checksum_data}#{files_original_path})
/pre
where files_original_path is of the form C:/foo/bar. But later in
lib/puppet/indirector/file_bucket_file/file.rb this is parsed as:
pre
checksum_type, checksum, path = request.key.split(/\//, 3)
/pre
The split causes C: to be included in the checksum, which results in an
exception Invalid checksum on line 107
Note that any changes made should not break backwards compatibility between
newer puppetmasters and older agents.
--
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 #8658] The file source parameter does not accept Windows paths
Issue #8658 has been updated by Josh Cooper. Target version changed from 2.7.x to 2.7.5 Additional changes were made to the file source as part of the file provider refactor #8411 in merge commit ec587b449e56050afca9838b23df9f0d8ffc7a63 to 2.7.x. Specifically, commit:5fea1dc64829e9c8178937764faccd51131b2a77 Bug #8658: The file source parameter does not accept Windows paths https://projects.puppetlabs.com/issues/8658 Author: Josh Cooper Status: Merged - Pending Release Priority: Normal Assignee: Jacob Helwig Category: windows Target version: 2.7.5 Affected Puppet version: Keywords: Branch: When a Windows path is specified as a file source, the C:/ is interpreted as a URL where C is the protocol. It should be possible to specify Windows file paths and have them be interpretered as local file paths. -- 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 #9186] Windows file security support
Issue #9186 has been updated by Josh Cooper. Target version changed from 2.7.x to 2.7.5 Additional commit 4c3aae84702225f441eb080ddbf6ff9121c1b49c was merged into 2.7.x in merge commit ec587b449e56050afca9838b23df9f0d8ffc7a63 where FILE_DELETE_CHILD was not being set on directories for group and other. Bug #9186: Windows file security support https://projects.puppetlabs.com/issues/9186 Author: Josh Cooper Status: Merged - Pending Release Priority: Normal Assignee: Josh Cooper Category: windows Target version: 2.7.5 Affected Puppet version: development Keywords: Branch: Ruby on Windows does not support methods for changing file owner, permissions, etc. But puppet needs to be able to manage these aspects of files and directories on Windows. At a minimum, we need the ability to get/set file owner and group, and managing DACLs. In the latter case, we are assuming puppet is managing the complete set of access control entries, as opposed to adding or subtracting specific ones. We also need the ability to specify the inheritance. For example, when managing a set of directories and files, we envision needing to stop inheritance at the root directory, but have the subdirectories and files inherit from the entries we specify. We also need to consider different file types, links, etc. -- 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 #9326] Password management on windows
Issue #9326 has been updated by Josh Cooper. Target version changed from 2.7.x to 2.7.5 Bug #9326: Password management on windows https://projects.puppetlabs.com/issues/9326 Author: Josh Cooper Status: Merged - Pending Release Priority: Normal Assignee: Cameron Thomas Category: windows Target version: 2.7.5 Affected Puppet version: development Keywords: Branch: From Nigel, we need to be able to manage passwords for users. -- 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 #9329] Puppet agent daemonize option doesn't work on Windows
Issue #9329 has been updated by Josh Cooper. Target version changed from 2.7.x to 2.7.5 Bug #9329: Puppet agent daemonize option doesn't work on Windows https://projects.puppetlabs.com/issues/9329 Author: Josh Cooper Status: Merged - Pending Release Priority: Normal Assignee: Josh Cooper Category: windows Target version: 2.7.5 Affected Puppet version: development Keywords: Branch: On windows, the daemonize setting should default to false, and it is configured to true, e.g. through the command line --daemonize, etc, then it should print out an error message and exit. We considered more complicated handling, such as connecting to the service control manager and starting the puppet service. However, since we are not providing running puppet as a service out of the box, it's not clear that puppet will even be installed as a service, what it's service name will be, or what service control wrapper will be used. -- 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 #9435] Log destinations are broken on Windows
Issue #9435 has been updated by Josh Cooper. Target version changed from 2.7.x to 2.7.5 Bug #9435: Log destinations are broken on Windows https://projects.puppetlabs.com/issues/9435 Author: Josh Cooper Status: Merged - Pending Release Priority: Normal Assignee: Josh Cooper Category: windows Target version: 2.7.5 Affected Puppet version: development Keywords: Branch: If no logging destination is set, puppet agent will attempt to add the syslog log destination, but this feature is not available on Windows and this generates an error (though puppet continues running): pre c:/ruby187/lib/ruby/site_ruby/1.8/puppet/util/log/destinations.rb:7:in `initialize' c:/ruby187/lib/ruby/site_ruby/1.8/puppet/util/log.rb:129:in `new' c:/ruby187/lib/ruby/site_ruby/1.8/puppet/util/log.rb:129:in `newdestination' c:/ruby187/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:380:in `setup_logs' c:/ruby187/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:422:in `setup' c:/ruby187/lib/ruby/site_ruby/1.8/puppet/application.rb:304:in `run' c:/ruby187/lib/ruby/site_ruby/1.8/puppet/application.rb:410:in `hook' c:/ruby187/lib/ruby/site_ruby/1.8/puppet/application.rb:304:in `run' c:/ruby187/lib/ruby/site_ruby/1.8/puppet/application.rb:401:in `exit_on_fail' c:/ruby187/lib/ruby/site_ruby/1.8/puppet/application.rb:304:in `run' c:/ruby187/lib/ruby/site_ruby/1.8/puppet/util/command_line.rb:69:in `execute' c:/ruby187/bin/puppet:4 /pre If a file destination is specified, e.g. puppet agent --logdest=c:\log.txt, puppet doesn't log to the file, because the file log destination only matches paths that start with '/': pre Puppet::Util::Log.newdesttype :file do match(/^\//) /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] 'Downloading Puppet' wiki page has been updated
The 'Downloading Puppet' wiki page has been updated by Michael Stahnke. Downloading Puppet: https://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet View differences: https://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet/diff/101 -- 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] 'Downloading Puppet' wiki page has been updated
The 'Downloading Puppet' wiki page has been updated by Michael Stahnke. Downloading Puppet: https://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet View differences: https://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet/diff/102 -- 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 #2927] Symbolic Modes for the File type.
Issue #2927 has been updated by Daniel Pittman. Sorry for the delays around merging this: the code is still correct, and it just needs the merge conflicts sorted out by hand because it was outstanding for so long. The security issues last week got in the way of the merge, but I hope to get it in by the end of this week. Thanks for your patience. Feature #2927: Symbolic Modes for the File type. https://projects.puppetlabs.com/issues/2927 Author: Trevor Vaughan Status: In Topic Branch Pending Review Priority: High Assignee: Nigel Kersten Category: file Target version: Telly Affected Puppet version: development Keywords: file, mode, symbolic Branch: https://github.com/jes5199/puppet/tree/ticket/next/2927 Symbolic modes should be included in the mode option for the File type. The GNU coreutils version of chmod is the intended reference implementation. -- 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 #8444] Cacher not robust enough on Windows
Issue #8444 has been updated by Josh Cooper. Target version changed from 2.7.x to 2.7.5 This commit was originally merged into master and then backported to 2.7.x in commit 49d1e9da1381c77a3873965bad36ba6b33316882 and merged as 384302af6dec8c51442f2f29a4c7c555379cd297 This change was then included in 2.7.4rc1, but that target version cannot be selected. Bug #8444: Cacher not robust enough on Windows https://projects.puppetlabs.com/issues/8444 Author: Josh Cooper Status: Merged - Pending Release Priority: Normal Assignee: Nick Lewis Category: windows Target version: 2.7.5 Affected Puppet version: Keywords: Branch: Time.now on Windows has a lower resolution on Unix. As a result, two problems can occur with Puppet::Util::Cacher 1. If an entry is expired and accessed soon after (within a second), the entry will not be treated as being expired, because the @cache_timestamp is not strictly less than the expiration timeout (the values will be equal). 1. If an entry is expired (time A) and soon after accessed twice (time B and C), and A, B, C are within one second, then the entry at time B will be considered expired and so at time C the cache will be cleared again and the value initialized an extra time. There are also some general issues that need further investigation: 1. The cache_timestamp is only updated when an entry is initially added or deleted, but not when it is updated. This doesn't seem correct, but more investigation is needed to see if that is semantically the correct behavior. See Cacher.cache_timestamp 1. expired_by_expirer? accesses self.class.attr_ttl without first checking that it responds to that method. However, expired_by_ttl? which is called later, does check. 1. If a single entry is expired_by_expirer?, then the entire value_cache is cleared and the cache timestamp updated, but if the entry is expired by its ttl, then only that entry is deleted from the cache, but the cache_timestamp is not updated. -- 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 #9459] Puppet fails to create user when groups are specified
Issue #9459 has been updated by Josh Cooper.
Branch set to https://github.com/puppetlabs/puppet/pull/141
Bug #9459: Puppet fails to create user when groups are specified
https://projects.puppetlabs.com/issues/9459
Author: Josh Cooper
Status: In Topic Branch Pending Review
Priority: High
Assignee: Cameron Thomas
Category: windows
Target version: 2.7.x
Affected Puppet version: development
Keywords:
Branch: https://github.com/puppetlabs/puppet/pull/141
Given the manifest test.pp:
pre
user { foobar:
groups = [Users]
}
/pre
If the user foobar does not yet exist, then running puppet apply test.pp,
generates an error because it's trying to connect to ADSI before the foobar
user has been created:
pre
Z:\work\puppetpuppet apply --trace test.pp
c:/ruby187/lib/ruby/site_ruby/1.8/puppet/util/adsi.rb:15:in `connect'
c:/ruby187/lib/ruby/site_ruby/1.8/puppet/util/adsi.rb:64:in `native_user'
c:/ruby187/lib/ruby/site_ruby/1.8/puppet/util/adsi.rb:130:in `groups'
c:/ruby187/lib/ruby/site_ruby/1.8/puppet/provider/user/windows_adsi.rb:17:in
`groups'
c:/ruby187/lib/ruby/site_ruby/1.8/puppet/property/list.rb:54:in `send'
c:/ruby187/lib/ruby/site_ruby/1.8/puppet/property/list.rb:54:in `retrieve'
c:/ruby187/lib/ruby/site_ruby/1.8/puppet/property/list.rb:43:in `should'
c:/ruby187/lib/ruby/site_ruby/1.8/puppet/type.rb:599:in `managed?'
c:/ruby187/lib/ruby/site_ruby/1.8/puppet/type.rb:598:in `each'
c:/ruby187/lib/ruby/site_ruby/1.8/puppet/type.rb:598:in `managed?'
c:/ruby187/lib/ruby/site_ruby/1.8/puppet/type/user.rb:63:in `default'
c:/ruby187/lib/ruby/site_ruby/1.8/puppet/type.rb:531:in `set_default'
c:/ruby187/lib/ruby/site_ruby/1.8/puppet/type.rb:1792:in `set_parameters'
c:/ruby187/lib/ruby/site_ruby/1.8/puppet/type.rb:1791:in `each'
c:/ruby187/lib/ruby/site_ruby/1.8/puppet/type.rb:1791:in `set_parameters'
c:/ruby187/lib/ruby/site_ruby/1.8/puppet/type.rb:1755:in `initialize'
c:/ruby187/lib/ruby/site_ruby/1.8/puppet/resource.rb:285:in `new'
c:/ruby187/lib/ruby/site_ruby/1.8/puppet/resource.rb:285:in `to_ral'
c:/ruby187/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:601:in `send'
c:/ruby187/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:601:in `to_catalog'
c:/ruby187/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:579:in `each'
c:/ruby187/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:579:in `to_catalog'
c:/ruby187/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:521:in `to_ral'
c:/ruby187/lib/ruby/site_ruby/1.8/puppet/application/apply.rb:207:in `main'
c:/ruby187/lib/ruby/site_ruby/1.8/puppet/application/apply.rb:135:in
`run_command'
c:/ruby187/lib/ruby/site_ruby/1.8/puppet/application.rb:306:in `run'
c:/ruby187/lib/ruby/site_ruby/1.8/puppet/application.rb:410:in `hook'
c:/ruby187/lib/ruby/site_ruby/1.8/puppet/application.rb:306:in `run'
c:/ruby187/lib/ruby/site_ruby/1.8/puppet/application.rb:401:in `exit_on_fail'
c:/ruby187/lib/ruby/site_ruby/1.8/puppet/application.rb:306:in `run'
c:/ruby187/lib/ruby/site_ruby/1.8/puppet/util/command_line.rb:69:in `execute'
c:/ruby187/bin/puppet:4
ADSI connection error: failed to parse display name of moniker
`WinNT://JOSH-NY1PO54A0O/foobar,user'
HRESULT error code:0x800708ad
The user name could not be found.
/pre
If you remove the groups parameter from the manifest, then it works fine, at
which point you can add the groups parameter back (since the user now exists)
--
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] 'Wiki' wiki page has been updated
The 'Wiki' wiki page has been updated by Michael Stahnke. Wiki: https://projects.puppetlabs.com/projects/facter/wiki/Wiki View differences: https://projects.puppetlabs.com/projects/facter/wiki/Wiki/diff/17 -- 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] 'Wiki' wiki page has been updated
The 'Wiki' wiki page has been updated by Michael Stahnke. Wiki: https://projects.puppetlabs.com/projects/facter/wiki/Wiki View differences: https://projects.puppetlabs.com/projects/facter/wiki/Wiki/diff/18 -- 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 #9192] service (launchd) provider fails on OS X 10.7 (Lion)
Issue #9192 has been updated by Clay Caviness.
File launchd.rb.txt added
Gary's patch is failing on (at least one of our) 10.5 machines. I've attached
output of `sudo /usr/bin/ruby --debug /usr/bin/puppet resource service --debug
--trace --evaltrace`
Bug #9192: service (launchd) provider fails on OS X 10.7 (Lion)
https://projects.puppetlabs.com/issues/9192
Author: Clay Caviness
Status: Code Insufficient
Priority: Normal
Assignee: Gary Larizza
Category: OSX
Target version: 2.7.x
Affected Puppet version:
Keywords: lion
Branch: https://github.com/glarizza/puppet-1/tree/tickets/2.7.x/9192_launchd_fix
$ sudo puppet apply --debug
service { 'com.company.corp.somejob': ensure = running, enable = true, }
[...]
debug: Puppet::Type::Service::ProviderLaunchd: Executing '/usr/bin/plutil
-convert xml1 -o /dev/stdout
/Library/LaunchDaemons/com.company.corp.somejob.plist'
debug: Service[com.company.corp.somejob](provider=launchd): Executing
'launchctl load /Library/LaunchDaemons/com.company.corp.somejob.plist'
err: /Stage[main]//Service[com.company.corp.somejob]/ensure: change from
stopped to running failed: Unable to start service: com.company.corp.somejob at
path: /Library/LaunchDaemons/com.company.corp.somejob.plist
debug: Finishing transaction 2277069800
debug: Storing state
debug: Stored state in 0.13 seconds
notice: Finished catalog run in 1.27 seconds
Yet another instance where there an OS X version check. Lines 214, 239, and 254
of launchd.rb
(http://projects.puppetlabs.com/projects/puppet/repository/revisions/master/entry/lib/puppet/provider/service/launchd.rb):
if self.class.get_macosx_version_major == 10.6
10.7 _also_ uses the launchd overrides plist.
I'm using Mac OS X 10.7.1, Puppet 2.7.3.
--
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 #9192] service (launchd) provider fails on OS X 10.7 (Lion)
Issue #9192 has been updated by Gary Larizza.
Branch changed from
https://github.com/glarizza/puppet-1/tree/tickets/2.7.x/9192_launchd_fix to
https://github.com/glarizza/puppet-1/tree/feature/2.7.x/launchd_optimization
I changed the branch to reflect the patch that Clay is talking about. I'm
getting this branch to run fine on my VMs, but am trying to re-create the
problems Clay is having (so I can fix them).
Bug #9192: service (launchd) provider fails on OS X 10.7 (Lion)
https://projects.puppetlabs.com/issues/9192
Author: Clay Caviness
Status: Code Insufficient
Priority: Normal
Assignee: Gary Larizza
Category: OSX
Target version: 2.7.x
Affected Puppet version:
Keywords: lion
Branch:
https://github.com/glarizza/puppet-1/tree/feature/2.7.x/launchd_optimization
$ sudo puppet apply --debug
service { 'com.company.corp.somejob': ensure = running, enable = true, }
[...]
debug: Puppet::Type::Service::ProviderLaunchd: Executing '/usr/bin/plutil
-convert xml1 -o /dev/stdout
/Library/LaunchDaemons/com.company.corp.somejob.plist'
debug: Service[com.company.corp.somejob](provider=launchd): Executing
'launchctl load /Library/LaunchDaemons/com.company.corp.somejob.plist'
err: /Stage[main]//Service[com.company.corp.somejob]/ensure: change from
stopped to running failed: Unable to start service: com.company.corp.somejob at
path: /Library/LaunchDaemons/com.company.corp.somejob.plist
debug: Finishing transaction 2277069800
debug: Storing state
debug: Stored state in 0.13 seconds
notice: Finished catalog run in 1.27 seconds
Yet another instance where there an OS X version check. Lines 214, 239, and 254
of launchd.rb
(http://projects.puppetlabs.com/projects/puppet/repository/revisions/master/entry/lib/puppet/provider/service/launchd.rb):
if self.class.get_macosx_version_major == 10.6
10.7 _also_ uses the launchd overrides plist.
I'm using Mac OS X 10.7.1, Puppet 2.7.3.
--
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 #9555] (Merged - Pending Release) Whitespace in code
Issue #9555 has been updated by Ken Barber. Status changed from In Topic Branch Pending Review to Merged - Pending Release Bug #9555: Whitespace in code https://projects.puppetlabs.com/issues/9555 Author: Ken Barber Status: Merged - Pending Release Priority: Low Assignee: Ken Barber Category: Target version: 1.6.x Keywords: whitespace Branch: https://github.com/puppetlabs/facter/pull/75 Affected Facter version: 1.6.1 So there is some mismatched whitespace throughout the facter code due to an older 4 space convention I believe. This ticket is to cover that fix. It doesn't affect every file - just some of the core ones I believe. Anyway - someone will have to go through the files and fix this. I figured its better to fix this sooner rather then later :-). -- 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 #9158] Puppet master breaks on trying to send message to stomp queue
Issue #9158 has been updated by Digant Kasundra. Assignee changed from Digant Kasundra to James Turnbull Bug #9158: Puppet master breaks on trying to send message to stomp queue https://projects.puppetlabs.com/issues/9158 Author: Digant Kasundra Status: Needs More Information Priority: Normal Assignee: James Turnbull Category: queuing Target version: Affected Puppet version: 2.7.1 Keywords: Branch: When a client checks in to the puppetmaster, the puppet master attempts to send a message to the stomp queue (if async stored configs is on) and in doing so attempts to use a method that doesn't exist. This effectively completely breaks puppet in 2.7.1 for us. The following patch will fix this: --- stomp.rb.orig 2011-08-22 17:30:16.0 -0700 +++ stomp.rb2011-08-22 17:13:07.0 -0700 @@ -29,7 +29,7 @@ end def publish_message(target, msg) -stomp_client.publish(stompify_target(target), msg, :persistent = true) +stomp_client.send(stompify_target(target), msg, :persistent = true) end def subscribe(target) -- 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 #9547] (Closed) Modify acceptance test config file to suport new platfom names
Issue #9547 has been updated by Dominic Maraglia. Status changed from In Topic Branch Pending Review to Closed All configs updates Refactor #9547: Modify acceptance test config file to suport new platfom names https://projects.puppetlabs.com/issues/9547 Author: Dominic Maraglia Status: Closed Priority: Normal Assignee: Dominic Maraglia Category: testing Target version: Affected Puppet version: Keywords: Branch: rhel/centos/sci linux platforms are now identified as el- by the acceptance testing harness. All config files need to be updated to reflect change. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #9862] (Needs Decision) puppet 2.7 cannot run without puppet user on the system
Issue #9862 has been reported by Jeff McCune. Bug #9862: puppet 2.7 cannot run without puppet user on the system https://projects.puppetlabs.com/issues/9862 Author: Jeff McCune Status: Needs Decision Priority: Normal Assignee: Nigel Kersten Category: settings Target version: 2.7.x Affected Puppet version: 2.7.0 Keywords: Branch: # Overview # Working with Puppet 2.7.5 I notice that `puppet apply` fails to work properly if the user puppet is not present on the system. In previous versions of Puppet, `puppet apply` does not require the user puppet to be present. This is a problem because puppet apply may be responsible for managing the user puppet itself. This presents a chicken and an egg problem if puppet apply is not able to properly manage the resources puppet itself needs. # Steps to reproduce # With 2.7.5: pre root@pe-centos6:~# puppet apply --modulepath /vagrant/modules /vagrant/manifests/vmsetup.pp --noop notice: Finished catalog run in 0.74 seconds err: /File[/var/lib/puppet/rrd]: Could not evaluate: Could not find group puppet err: Could not send report: Got 1 failure(s) while initializing: Could not evaluate: Could not find group puppet root@pe-centos6:~# puppet --version 2.7.5 root@pe-centos6:~# facter --version 1.6.1 /pre # Expected Behavior # With 2.6.10 it works as expected: pre root@pe-centos6:~# puppet --version 2.6.10 root@pe-centos6:~# facter --version 1.6.1 root@pe-centos6:~# puppet apply --modulepath /vagrant/modules /vagrant/manifests/vmsetup.pp --noop notice: Finished catalog run in 0.67 seconds root@pe-centos6:~# /pre # Additional Information # This bug appears to have been introduced in 2.7.0: pre root@pe-centos6:~# facter --version 1.6.1 root@pe-centos6:~# puppet --version 2.7.0 root@pe-centos6:~# puppet apply --modulepath /vagrant/modules /vagrant/manifests/vmsetup.pp --noop notice: Finished catalog run in 0.75 seconds err: /File[/var/lib/puppet/rrd]: Could not evaluate: Could not find group puppet err: Could not send report: Got 1 failure(s) while initializing: Could not evaluate: Could not find group puppet /pre Also, I should note this problem exists in the default case. I have no customizations to puppet.conf at all: pre root@pe-centos6:~# cat /etc/puppet/puppet.conf cat: /etc/puppet/puppet.conf: No such file or directory /pre # Trace # Here is the trace when running against 2.7.x () pre notice: Finished catalog run in 1.04 seconds /root/src/puppet/lib/puppet/type/file/group.rb:18:in `insync?' /root/src/puppet/lib/puppet/type/file/group.rb:17:in `map!' /root/src/puppet/lib/puppet/type/file/group.rb:17:in `insync?' /root/src/puppet/lib/puppet/property.rb:162:in `safe_insync?' /root/src/puppet/lib/puppet/transaction/resource_harness.rb:61:in `perform_changes' /root/src/puppet/lib/puppet/transaction/resource_harness.rb:60:in `each' /root/src/puppet/lib/puppet/transaction/resource_harness.rb:60:in `perform_changes' /root/src/puppet/lib/puppet/transaction/resource_harness.rb:133:in `evaluate' /root/src/puppet/lib/puppet/transaction.rb:49:in `apply' /root/src/puppet/lib/puppet/transaction.rb:84:in `eval_resource' /root/src/puppet/lib/puppet/transaction.rb:103:in `evaluate' /root/src/puppet/lib/puppet/util.rb:459:in `thinmark' /usr/lib/ruby/1.8/benchmark.rb:308:in `realtime' /root/src/puppet/lib/puppet/util.rb:458:in `thinmark' /root/src/puppet/lib/puppet/transaction.rb:103:in `evaluate' /root/src/puppet/lib/puppet/transaction.rb:311:in `traverse' /root/src/puppet/lib/puppet/transaction.rb:99:in `evaluate' /root/src/puppet/lib/puppet/resource/catalog.rb:141:in `apply' /root/src/puppet/lib/puppet/util/settings.rb:629:in `use' /usr/lib/ruby/1.8/sync.rb:230:in `synchronize' /root/src/puppet/lib/puppet/util/settings.rb:612:in `use' /root/src/puppet/lib/puppet/indirector/report/processor.rb:10:in `initialize' /root/src/puppet/lib/puppet/indirector/indirection.rb:315:in `new' /root/src/puppet/lib/puppet/indirector/indirection.rb:315:in `make_terminus' /root/src/puppet/lib/puppet/indirector/indirection.rb:124:in `terminus' /root/src/puppet/lib/puppet/indirector/indirection.rb:303:in `prepare' /root/src/puppet/lib/puppet/indirector/indirection.rb:263:in `save' /root/src/puppet/lib/puppet/configurer.rb:174:in `send_report' /root/src/puppet/lib/puppet/configurer.rb:168:in `run' /root/src/puppet/lib/puppet/application/apply.rb:215:in `main' /root/src/puppet/lib/puppet/application/apply.rb:135:in `run_command' /root/src/puppet/lib/puppet/application.rb:306:in `run' /root/src/puppet/lib/puppet/application.rb:410:in `hook' /root/src/puppet/lib/puppet/application.rb:306:in `run' /root/src/puppet/lib/puppet/application.rb:401:in `exit_on_fail' /root/src/puppet/lib/puppet/application.rb:306:in `run' /root/src/puppet/lib/puppet/util/command_line.rb:69:in `execute' /root/src/puppet/bin/puppet:4 err: /File[/var/lib/puppet/rrd]: Could not evaluate: Could not find group puppet /root/src/puppet/lib/puppet/util/settings.rb:633:in
[Puppet - Bug #9027] (Merged - Pending Release) groupadd provider throws spurious warnings about AIX feature on non-AIX platforms.
Issue #9027 has been updated by Michael Stahnke.
Status changed from In Topic Branch Pending Review to Merged - Pending Release
Bug #9027: groupadd provider throws spurious warnings about AIX feature on
non-AIX platforms.
https://projects.puppetlabs.com/issues/9027
Author: Jeremy Bowers
Status: Merged - Pending Release
Priority: Normal
Assignee: Josh Cooper
Category: group
Target version: 2.7.5
Affected Puppet version: 2.7.3
Keywords:
Branch: https://github.com/puppetlabs/puppet/pull/151
`info: /Group[developer]: Provider groupadd does not support features
manages_aix_lam; not managing attribute ia_load_module`
Not sure when it started but seems to be related to #7137
I can reproduce this bug by creating a group on a non-AIX system (Mine is
Ubuntu 10.04 LTS)
pre
class users::developers {
group { developer:
ensure = present,
gid= '1001',
}
}
/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 #9027] groupadd provider throws spurious warnings about AIX feature on non-AIX platforms.
Issue #9027 has been updated by Michael Stahnke.
Closed in
https://github.com/puppetlabs/puppet/commit/81ff060f514f61ff143025156f47b4025b833165
Bug #9027: groupadd provider throws spurious warnings about AIX feature on
non-AIX platforms.
https://projects.puppetlabs.com/issues/9027
Author: Jeremy Bowers
Status: In Topic Branch Pending Review
Priority: Normal
Assignee: Josh Cooper
Category: group
Target version: 2.7.5
Affected Puppet version: 2.7.3
Keywords:
Branch: https://github.com/puppetlabs/puppet/pull/151
`info: /Group[developer]: Provider groupadd does not support features
manages_aix_lam; not managing attribute ia_load_module`
Not sure when it started but seems to be related to #7137
I can reproduce this bug by creating a group on a non-AIX system (Mine is
Ubuntu 10.04 LTS)
pre
class users::developers {
group { developer:
ensure = present,
gid= '1001',
}
}
/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 #9862] puppet 2.7 cannot run without puppet user on the system
Issue #9862 has been updated by Jeff McCune. Description updated Bug #9862: puppet 2.7 cannot run without puppet user on the system https://projects.puppetlabs.com/issues/9862 Author: Jeff McCune Status: Needs Decision Priority: Normal Assignee: Nigel Kersten Category: settings Target version: 2.7.x Affected Puppet version: 2.7.0 Keywords: Branch: # Overview # Working with Puppet 2.7.5 I notice that `puppet apply` fails to work properly if the user puppet is not present on the system. In previous versions of Puppet, `puppet apply` does not require the user puppet to be present. This is a problem because puppet apply may be responsible for managing the user puppet itself. This presents a chicken and an egg problem if puppet apply is not able to properly manage the resources puppet itself needs. # Steps to reproduce # With 2.7.5: pre root@pe-centos6:~# puppet apply --modulepath /vagrant/modules /vagrant/manifests/vmsetup.pp --noop notice: Finished catalog run in 0.74 seconds err: /File[/var/lib/puppet/rrd]: Could not evaluate: Could not find group puppet err: Could not send report: Got 1 failure(s) while initializing: Could not evaluate: Could not find group puppet root@pe-centos6:~# puppet --version 2.7.5 root@pe-centos6:~# facter --version 1.6.1 /pre # Expected Behavior # With 2.6.10 it works as expected: pre root@pe-centos6:~# puppet --version 2.6.10 root@pe-centos6:~# facter --version 1.6.1 root@pe-centos6:~# puppet apply --modulepath /vagrant/modules /vagrant/manifests/vmsetup.pp --noop notice: Finished catalog run in 0.67 seconds root@pe-centos6:~# /pre # Additional Information # This bug appears to have been introduced in 2.7.0: pre root@pe-centos6:~# facter --version 1.6.1 root@pe-centos6:~# puppet --version 2.7.0 root@pe-centos6:~# puppet apply --modulepath /vagrant/modules /vagrant/manifests/vmsetup.pp --noop notice: Finished catalog run in 0.75 seconds err: /File[/var/lib/puppet/rrd]: Could not evaluate: Could not find group puppet err: Could not send report: Got 1 failure(s) while initializing: Could not evaluate: Could not find group puppet /pre Also, I should note this problem exists in the default case. I have no customizations to puppet.conf at all: pre root@pe-centos6:~# cat /etc/puppet/puppet.conf cat: /etc/puppet/puppet.conf: No such file or directory /pre # Trace # Here is the trace when running against 2.7.x (2.7.5-91-g2958b05) pre notice: Finished catalog run in 1.04 seconds /root/src/puppet/lib/puppet/type/file/group.rb:18:in `insync?' /root/src/puppet/lib/puppet/type/file/group.rb:17:in `map!' /root/src/puppet/lib/puppet/type/file/group.rb:17:in `insync?' /root/src/puppet/lib/puppet/property.rb:162:in `safe_insync?' /root/src/puppet/lib/puppet/transaction/resource_harness.rb:61:in `perform_changes' /root/src/puppet/lib/puppet/transaction/resource_harness.rb:60:in `each' /root/src/puppet/lib/puppet/transaction/resource_harness.rb:60:in `perform_changes' /root/src/puppet/lib/puppet/transaction/resource_harness.rb:133:in `evaluate' /root/src/puppet/lib/puppet/transaction.rb:49:in `apply' /root/src/puppet/lib/puppet/transaction.rb:84:in `eval_resource' /root/src/puppet/lib/puppet/transaction.rb:103:in `evaluate' /root/src/puppet/lib/puppet/util.rb:459:in `thinmark' /usr/lib/ruby/1.8/benchmark.rb:308:in `realtime' /root/src/puppet/lib/puppet/util.rb:458:in `thinmark' /root/src/puppet/lib/puppet/transaction.rb:103:in `evaluate' /root/src/puppet/lib/puppet/transaction.rb:311:in `traverse' /root/src/puppet/lib/puppet/transaction.rb:99:in `evaluate' /root/src/puppet/lib/puppet/resource/catalog.rb:141:in `apply' /root/src/puppet/lib/puppet/util/settings.rb:629:in `use' /usr/lib/ruby/1.8/sync.rb:230:in `synchronize' /root/src/puppet/lib/puppet/util/settings.rb:612:in `use' /root/src/puppet/lib/puppet/indirector/report/processor.rb:10:in `initialize' /root/src/puppet/lib/puppet/indirector/indirection.rb:315:in `new' /root/src/puppet/lib/puppet/indirector/indirection.rb:315:in `make_terminus' /root/src/puppet/lib/puppet/indirector/indirection.rb:124:in `terminus' /root/src/puppet/lib/puppet/indirector/indirection.rb:303:in `prepare' /root/src/puppet/lib/puppet/indirector/indirection.rb:263:in `save' /root/src/puppet/lib/puppet/configurer.rb:174:in `send_report' /root/src/puppet/lib/puppet/configurer.rb:168:in `run' /root/src/puppet/lib/puppet/application/apply.rb:215:in `main' /root/src/puppet/lib/puppet/application/apply.rb:135:in `run_command' /root/src/puppet/lib/puppet/application.rb:306:in `run' /root/src/puppet/lib/puppet/application.rb:410:in `hook' /root/src/puppet/lib/puppet/application.rb:306:in `run' /root/src/puppet/lib/puppet/application.rb:401:in `exit_on_fail' /root/src/puppet/lib/puppet/application.rb:306:in `run' /root/src/puppet/lib/puppet/util/command_line.rb:69:in `execute' /root/src/puppet/bin/puppet:4 err: /File[/var/lib/puppet/rrd]: Could not evaluate: Could not find group puppet
[Puppet] 'Downloading Puppet' wiki page has been updated
The 'Downloading Puppet' wiki page has been updated by Michael Stahnke. Downloading Puppet: https://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet View differences: https://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet/diff/104 -- 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] 'Downloading Puppet' wiki page has been updated
The 'Downloading Puppet' wiki page has been updated by Michael Stahnke. Downloading Puppet: https://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet View differences: https://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet/diff/105 -- 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 #9158] (Accepted) Puppet master breaks on trying to send message to stomp queue
Issue #9158 has been updated by James Turnbull. Status changed from Needs More Information to Accepted Assignee changed from James Turnbull to Daniel Pittman Bug #9158: Puppet master breaks on trying to send message to stomp queue https://projects.puppetlabs.com/issues/9158 Author: Digant Kasundra Status: Accepted Priority: Normal Assignee: Daniel Pittman Category: queuing Target version: Affected Puppet version: 2.7.1 Keywords: Branch: When a client checks in to the puppetmaster, the puppet master attempts to send a message to the stomp queue (if async stored configs is on) and in doing so attempts to use a method that doesn't exist. This effectively completely breaks puppet in 2.7.1 for us. The following patch will fix this: --- stomp.rb.orig 2011-08-22 17:30:16.0 -0700 +++ stomp.rb2011-08-22 17:13:07.0 -0700 @@ -29,7 +29,7 @@ end def publish_message(target, msg) -stomp_client.publish(stompify_target(target), msg, :persistent = true) +stomp_client.send(stompify_target(target), msg, :persistent = true) end def subscribe(target) -- 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] 'Release Management' wiki page has been updated
The 'Release Management' wiki page has been updated by Michael Stahnke. Release Management: https://projects.puppetlabs.com/projects/puppet/wiki/Release_Management View differences: https://projects.puppetlabs.com/projects/puppet/wiki/Release_Management/diff/76 -- 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] 'Downloading Puppet' wiki page has been updated
The 'Downloading Puppet' wiki page has been updated by Michael Stahnke. Downloading Puppet: https://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet View differences: https://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet/diff/106 -- 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] 'Release Notes' wiki page has been updated
The 'Release Notes' wiki page has been updated by Michael Stahnke. Release Notes: https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes View differences: https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes/diff/133 -- 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.
