[Puppet - Bug #5300] Header in exported ssh_authorized_keys changes even when contents do not
Issue #5300 has been updated by Peter Meier.
An example of the export is:
@@ssh_authorized_key { 't...@localhost':
key = $::the_key,
type = 'ssh-rsa',
user = 'test',
options = command=\rsync --server --sender -pr .
/var/cache/stuff/hosts/$::fqdn\,no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,from=\$::ipaddress\,
target = '/etc/ssh/user-authorized-keys/test',
require = Exec[make_key],
subscribe = Exec[make_key],
}
I expected it to be something like that. So the [Type
Reference](http://docs.puppetlabs.com/references/stable/type.html#sshauthorizedkey)
states that if defining multiple options they should be defined as an array.
Can you change that to an array?
pre
@@ssh_authorized_key { 't...@localhost':
key = $::the_key,
type = 'ssh-rsa',
user = 'test',
options = [command=\rsync --server --sender -pr .
/var/cache/stuff/hosts/$::fqdn\,'no-port-forwarding','no-X11-forwarding','no-agent-forwarding','no-pty',from=\$::ipaddress\],
target = '/etc/ssh/user-authorized-keys/test',
require = Exec[make_key],
}
/pre
and then it should not anymore change the date field.
The issue is that if your not defining options as an array puppet thinks the
options field is not in sync and rewrites it hence updates the date field. From
the outside it doesn't look different, but internally puppet see it different.
Therefore the update.
You see that also in the debug message when the provider is telling you over
and over again that it is updating the options field.
This is a known issue/feature/limitation/whatever of the ssh_autorized_key Type
and if you closely follow the docs you won't encounter your problem. So if this
fixes your problem can you close/reject that ticket? (If my assumptions are
correct...)
Bug #5300: Header in exported ssh_authorized_keys changes even when contents do
not
https://projects.puppetlabs.com/issues/5300
Author: Nick Moffitt
Status: Unreviewed
Priority: Normal
Assignee:
Category:
Target version:
Affected Puppet version:
Keywords:
Branch:
I'm using exported resources to collect ssh keys from custom facts and compile
a command-locked authorized_keys on a central machine. While investigating
some anomalies involving checksums in state.yaml for the exported
authorized_keys file, I noticed that the checksums for this file were unique to
a run. Setting a copy aside, I see:
pre
--- authorized_keys.old 2010-11-15 14:35:02.0 +
+++ authorized_keys 2010-11-15 14:35:09.0 +
@@ -1,4 +1,4 @@
-# HEADER: This file was autogenerated at Mon Nov 15 14:26:20 + 2010
+# HEADER: This file was autogenerated at Mon Nov 15 14:35:09 + 2010
# HEADER: by puppet. While it can still be managed manually, it
# HEADER: is definitely not recommended.
/pre
This timestamp is causing a new copy of this file to appear in my filebuckets
on each run even though the rest of the file is unchanged. This has no upper
limit, and if the file were to grow significantly it could result in an
enormous amount of space being taken up.
It would appear that any provider that uses the parsedfile provider classes
gets this header, regardless of what comment delimiter the file uses. I'd
appreciate some way to turn this off, supply my own, or at least shut off that
timestamp. Ideally I suppose the exported resource ought not to re-generate it
if the only change would be that header.
The system collecting the authorized_keys file is puppet client at version
0.25.4-2ubuntu6 and puppet master at 2.6.1-0ubuntu2. Other clients are mostly
0.25.4-2ubuntu6 with a few 2.6.1-0ubuntu2 systems.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please 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-b...@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 #5428] Catalog compile fails citing to_hash error
Issue #5428 has been updated by Brice Figureau.
I got the same issue when migrating to 2.6.3.
Basically the problem is the following:
* under some version of 0.25 (potentially 0.25.4), resource references were not
stored as strings (ie File[blah]) in the param values, but serialized as YAML.
* in 2.6, we removed Puppet::Resource::Reference, so the unserialization
doesn't work anymore.
I see only one fix, reintroduce a stub Puppet::Resource::Reference class that
does translate itself when unserialized from Yaml to real resource ref strings
(if that's possible).
Bug #5428: Catalog compile fails citing to_hash error
https://projects.puppetlabs.com/issues/5428
Author: Eric Shamow
Status: Unreviewed
Priority: Urgent
Assignee:
Category:
Target version:
Affected Puppet version: 2.6.3
Keywords:
Branch:
Running client and server 2.6.3. CentOS 5.5 on both sides; Puppetmaster was
upgraded from 0.25.4 - 0.25.5 - 2.6.2 - 2.6.3. Client is fresh build.
On every run of Puppet on particular hosts, we receive a variant the following
error on both the agent and master:
Could not retrieve catalog from remote server: Error 400 on SERVER: undefined
method `to_hash' for #Puppet::Resource::Reference:0x2b38ce4140d8
The situation was 100% reproduceable, but exhibits some strange behavior. If
the same client is moved to another Puppetmaster, running the same classes with
the same manifest, compilation succeeds. If the manifest is changed to include
no classes, and then all classes are reintroduced one at a time, the client can
be made to compile. However once I point other clients at the new manifest
with all classes included, they too fail.
Some googling turned up one link, an IRC log
(http://pelin.lovedthanlost.net/puppet/%23puppet-2010-11-19.log.html) which
suggested that the problematic code was located in resource.rb. Line 123 of
resource.rb is:
return false unless to_hash == other.to_hash
Running with this, I wrapped that line in a rescue block:
begin
return false unless to_hash == other.to_hash
rescue = e
Puppet.notice #{e} - Lost it on #{other.title}
return false
end
I return false based on the assumption that, if a hash value cannot be
calculated, then the two objects are not equivalent. Running this, I end up
with lines from nearly every module called by the manifest in my error log.
I'll post a portion of it sanitized here; if there's a desire to see more
contact me and I'll post the whole lot:
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b0996434f48 - Lost it on
/var/www/mte/SIGNUP/adv/design
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b0996432338 - Lost it on httpd
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b099642e558 - Lost it on sysklogd
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b0996430a10 - Lost it on vixie-cron
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b099642d4f0 - Lost it on rpm
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b099642c488 - Lost it on
/var/www/mte/STATIC/design
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b099642aca0 - Lost it on var_machdb
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b0996429af8 - Lost it on nfs-utils
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b099636d150 - Lost it on postmap
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b0996428388 - Lost it on
/var/www/mte/SIGNUP/adv/design
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b09964268f8 - Lost it on httpd
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b0996422d98 - Lost it on /var/www/cgi-bin
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b0996423e00 - Lost it on httpd
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b0996420f48 - Lost it on httpd
I'm worried that my assumption about returning false is not valid, and also
worried that a critical comparison is getting lost somewhere...this one looks
worrisome.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please 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-b...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
[Puppet - Bug #5428] (Accepted) Catalog compile fails citing to_hash error
Issue #5428 has been updated by James Turnbull.
Category set to plumbing
Status changed from Unreviewed to Accepted
Target version set to 2.6.5
Bug #5428: Catalog compile fails citing to_hash error
https://projects.puppetlabs.com/issues/5428
Author: Eric Shamow
Status: Accepted
Priority: Urgent
Assignee:
Category: plumbing
Target version: 2.6.5
Affected Puppet version: 2.6.3
Keywords:
Branch:
Running client and server 2.6.3. CentOS 5.5 on both sides; Puppetmaster was
upgraded from 0.25.4 - 0.25.5 - 2.6.2 - 2.6.3. Client is fresh build.
On every run of Puppet on particular hosts, we receive a variant the following
error on both the agent and master:
Could not retrieve catalog from remote server: Error 400 on SERVER: undefined
method `to_hash' for #Puppet::Resource::Reference:0x2b38ce4140d8
The situation was 100% reproduceable, but exhibits some strange behavior. If
the same client is moved to another Puppetmaster, running the same classes with
the same manifest, compilation succeeds. If the manifest is changed to include
no classes, and then all classes are reintroduced one at a time, the client can
be made to compile. However once I point other clients at the new manifest
with all classes included, they too fail.
Some googling turned up one link, an IRC log
(http://pelin.lovedthanlost.net/puppet/%23puppet-2010-11-19.log.html) which
suggested that the problematic code was located in resource.rb. Line 123 of
resource.rb is:
return false unless to_hash == other.to_hash
Running with this, I wrapped that line in a rescue block:
begin
return false unless to_hash == other.to_hash
rescue = e
Puppet.notice #{e} - Lost it on #{other.title}
return false
end
I return false based on the assumption that, if a hash value cannot be
calculated, then the two objects are not equivalent. Running this, I end up
with lines from nearly every module called by the manifest in my error log.
I'll post a portion of it sanitized here; if there's a desire to see more
contact me and I'll post the whole lot:
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b0996434f48 - Lost it on
/var/www/mte/SIGNUP/adv/design
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b0996432338 - Lost it on httpd
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b099642e558 - Lost it on sysklogd
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b0996430a10 - Lost it on vixie-cron
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b099642d4f0 - Lost it on rpm
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b099642c488 - Lost it on
/var/www/mte/STATIC/design
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b099642aca0 - Lost it on var_machdb
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b0996429af8 - Lost it on nfs-utils
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b099636d150 - Lost it on postmap
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b0996428388 - Lost it on
/var/www/mte/SIGNUP/adv/design
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b09964268f8 - Lost it on httpd
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b0996422d98 - Lost it on /var/www/cgi-bin
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b0996423e00 - Lost it on httpd
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b0996420f48 - Lost it on httpd
I'm worried that my assumption about returning false is not valid, and also
worried that a critical comparison is getting lost somewhere...this one looks
worrisome.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please 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-b...@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 #5428] Catalog compile fails citing to_hash error
Issue #5428 has been updated by Eric Shamow.
Helpful additional information -- we are running storeconfigs.
Bug #5428: Catalog compile fails citing to_hash error
https://projects.puppetlabs.com/issues/5428
Author: Eric Shamow
Status: Accepted
Priority: Urgent
Assignee:
Category: plumbing
Target version: 2.6.5
Affected Puppet version: 2.6.3
Keywords:
Branch:
Running client and server 2.6.3. CentOS 5.5 on both sides; Puppetmaster was
upgraded from 0.25.4 - 0.25.5 - 2.6.2 - 2.6.3. Client is fresh build.
On every run of Puppet on particular hosts, we receive a variant the following
error on both the agent and master:
Could not retrieve catalog from remote server: Error 400 on SERVER: undefined
method `to_hash' for #Puppet::Resource::Reference:0x2b38ce4140d8
The situation was 100% reproduceable, but exhibits some strange behavior. If
the same client is moved to another Puppetmaster, running the same classes with
the same manifest, compilation succeeds. If the manifest is changed to include
no classes, and then all classes are reintroduced one at a time, the client can
be made to compile. However once I point other clients at the new manifest
with all classes included, they too fail.
Some googling turned up one link, an IRC log
(http://pelin.lovedthanlost.net/puppet/%23puppet-2010-11-19.log.html) which
suggested that the problematic code was located in resource.rb. Line 123 of
resource.rb is:
return false unless to_hash == other.to_hash
Running with this, I wrapped that line in a rescue block:
begin
return false unless to_hash == other.to_hash
rescue = e
Puppet.notice #{e} - Lost it on #{other.title}
return false
end
I return false based on the assumption that, if a hash value cannot be
calculated, then the two objects are not equivalent. Running this, I end up
with lines from nearly every module called by the manifest in my error log.
I'll post a portion of it sanitized here; if there's a desire to see more
contact me and I'll post the whole lot:
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b0996434f48 - Lost it on
/var/www/mte/SIGNUP/adv/design
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b0996432338 - Lost it on httpd
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b099642e558 - Lost it on sysklogd
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b0996430a10 - Lost it on vixie-cron
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b099642d4f0 - Lost it on rpm
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b099642c488 - Lost it on
/var/www/mte/STATIC/design
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b099642aca0 - Lost it on var_machdb
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b0996429af8 - Lost it on nfs-utils
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b099636d150 - Lost it on postmap
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b0996428388 - Lost it on
/var/www/mte/SIGNUP/adv/design
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b09964268f8 - Lost it on httpd
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b0996422d98 - Lost it on /var/www/cgi-bin
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b0996423e00 - Lost it on httpd
puppet-master[10279]: undefined method `to_hash' for
#Puppet::Resource::Reference:0x2b0996420f48 - Lost it on httpd
I'm worried that my assumption about returning false is not valid, and also
worried that a critical comparison is getting lost somewhere...this one looks
worrisome.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please 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-b...@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 #3962] 0.25.5 fails to start if /var/lib does not exist
Issue #3962 has been updated by Nigel Kersten. Assignee changed from Matt Robinson to Nigel Kersten Keywords set to mac Bug #3962: 0.25.5 fails to start if /var/lib does not exist https://projects.puppetlabs.com/issues/3962 Author: eric sorenson Status: Accepted Priority: Normal Assignee: Nigel Kersten Category: Target version: Affected Puppet version: 0.25.5 Keywords: mac Branch: Due to #86 and the 0.25.4-0.25.5 move of $vardir from /var (which always exists on Unix) to /var/lib (which might or might not exist), puppetd now fails to start on OSes without a /var/lib. This broke out of the box for me on both OS X and Solaris machines. The attached patch fixes the issue by adding a 'varparentdir' resource which is conditional upon root/not root EUID as confdir and vardir are. I'm not sure this is the best way to go about it and will happily take improvements that address the issue. before patch: pre err: /File[/var/lib/puppet]/ensure: change from absent to directory failed: Cannot create /var/lib/puppet; parent directory /var/lib does not exist [ ... dependencies fail, startup aborts ... ] /pre patched, as root: pre debug: /File[/var/lib]: Changing ensure debug: /File[/var/lib]: 1 change(s) debug: /File[/var/lib]/ensure: created [ .. startup succeeds ... ] /pre not as root: pre debug: /File[/Users/eric/.puppet]: Autorequiring File[/Users/eric] [ no-op as this exists ] [ ... startup succeeds ... ] /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-b...@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 #4528] cron gets updates everytime if wildcard is set
Issue #4528 has been updated by Alan Barrett.
Affected Puppet version deleted (2.6.1rc2)
Workaround for puppet-0.25: Use absent (no quotes) as a magic value to tell
puppet that you actually want * in the relevant field, like this:
pre
cron{'gpg_crontab':
command = '/usr/bin/gpg --refresh-keys /dev/null 21',
minute = 0,
hour = 12,
month = absent,
}
/pre
Bug #4528: cron gets updates everytime if wildcard is set
https://projects.puppetlabs.com/issues/4528
Author: Peter Meier
Status: Closed
Priority: Normal
Assignee:
Category: cron
Target version: 2.6.1
Affected Puppet version:
Keywords:
Branch: http://github.com/duritong/puppet/tree/ticket/2.6.x/4528
The following cronjob:
pre
cron{'gpg_crontab':
command = '/usr/bin/gpg --refresh-keys /dev/null 21',
minute = 0,
hour = 12,
month = '*',
}
/pre
Triggers a crontab update on every run:
pre
$ puppet foo.pp
notice: /Stage[main]//Cron[gpg_crontab]/month: defined 'month' as '*'
$ puppet foo.pp
notice: /Stage[main]//Cron[gpg_crontab]/month: defined 'month' as '*'
/pre
puppet should not detect this as a change.
Why anyway defining '*'? There are 2 reasons:
1. unset a previously set weekday, as we want the cronjob now to run everytime.
2. I have manifests
(http://git.puppet.immerda.ch/?p=module-puppet.git;a=blob;f=manifests/cron/openbsd.pp;h=bca3dc68104834da15fbd8237eeab7ecb1ff102b;hb=9f83acbda5baf8bda129cbe7e8114d5b7b87)
that generate the invidual cron time paramateres from a string, so users can
define something like @$puppet_crontime = '0,30 * * * *'@ which will then
converted into cron resource time parameters.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please 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-b...@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 #5211] (Available In Testing Branch) Augeas resource type match size != operator does not work properly
Issue #5211 has been updated by Matt Robinson.
Status changed from Ready for Testing to Available In Testing Branch
Assignee deleted (Nigel Kersten)
commit:ab7de670a13eff599b6b725513fcb8a67e12136b
Bug #5211: Augeas resource type match size != operator does not work properly
https://projects.puppetlabs.com/issues/5211
Author: Steve Nielsen
Status: Available In Testing Branch
Priority: High
Assignee:
Category: augeas
Target version: Statler
Affected Puppet version: 2.6.2
Keywords: communitypatch
Branch: https://github.com/bkearney/puppet/tree/ticket/2.6.2/5211
The '!=' comparator in the Augeas resource type (specifically with onlyif match
size) does not work properly in puppet due to the underlying Ruby interpreter
not supporting '!=' with send. Here is thread discussing the ruby issue:
http://www.ruby-forum.com/topic/174382. The thread seems to indicate that Ruby
versions greater than 1.9 support it '!=' with send but I have not tested this.
I am using puppet 2.6.2 with ruby 1.8.5 on CentOS 5.5.
Puppet code that illustrates the problem:
pre
augeas {
grub:
context = /files/etc/grub.conf,
onlyif = match timeout[.='30'] size != 1,
changes = [
rm timeout,
ins timeout before title[1],
set timeout 30,
],
}
/pre
With the code snippet above, puppet will execute the augeas statements on every
run despite timeout 30 line being present in the grub.conf file.
Attached is a patch against puppet 2.6.2.
I also notice there are no debug() statements in process_match(). Might be
useful to have a couple statements in there to at least indicate that the
onlyif/match statement is being processed.
I think this issue should be fixed sooner than later because it makes it that
much harder and frustrating to debug the augeas resource type when the
underlying implementation does not work.
Thanks,
Steve
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please 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-b...@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 #4792] (Closed) Duplicate definition since 2.6.1 upgrade
Issue #4792 has been updated by Matt Robinson.
Status changed from Re-opened to Closed
Assignee deleted (Paul Berry)
The reason for reopening this ticket was separated out into it's own ticket
#5447. The orignal manifest to reproduce the error doesn't currently cause it,
but we were able to pare down Jos's reported manifest to reproduce the issue,
and that manifest code is in the new ticket.
Bug #4792: Duplicate definition since 2.6.1 upgrade
https://projects.puppetlabs.com/issues/4792
Author: James Turnbull
Status: Closed
Priority: High
Assignee:
Category: parser
Target version: 2.6.5
Affected Puppet version: 2.6.1
Keywords:
Branch: http://github.com/stereotype441/puppet/tree/ticket/2.6.x/4792
Class, users::virtual which has all the user{} statements for all users. Then
have classes like users::cms and users::developers that inherit users::virtual
and then realize some of the users. This all worked perfectly fine in 2.5 but
since 2.6.1 runs now fail with:
pre
err: Could not retrieve catalog from remote server: Error 400 on SERVER:
Duplicate definition: User[apen
ney] is already defined in file
/etc/puppet/modules/testing/users/manifests/virtual.pp at line 19; canno
t redefine at /etc/puppet/modules/testing/users/manifests/virtual.pp:19 on node
hlslinutil1.law.harvard.
edu
/pre
pre
realize(
User['user'],
)
}
# cat virtual.pp
class users::virtual {
##
## Sysadmins
##
@user { user:
ensure = present,
uid = 35421,
gid = 100,
groups = wheel,
comment = User Name,
home = /home/user,
shell = /bin/zsh,
password = password,
managehome = true,
}
}
/pre
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-b...@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 #5447] Fix duplicate definition error
Issue #5447 has been updated by Matt Robinson.
Reordering the manifest gets rid of the error.
pre
class { kbase: }
class kbase { }
class { s_riak: }
class s_riak inherits kbase { }
/pre
Bug #5447: Fix duplicate definition error
https://projects.puppetlabs.com/issues/5447
Author: Matt Robinson
Status: Unreviewed
Priority: Normal
Assignee:
Category:
Target version:
Affected Puppet version: 2.6.4
Keywords:
Branch:
Jos Boumans reported a manifest that results in the following error:
Duplicate definition: Class[Kbase] is already defined; cannot redefine at
/Users/matthewrobinson/work/puppet/4792:5 on node mattmac.puppetlabs.lan
He thought this was related to ticket 4792 and thus reopened it, but it appears
to be a separate issue. He posted his full set of manifests on that ticket,
but we reduced that to a much smaller manifest that reproduces the problem:
pre
class { s_riak: }
class s_riak inherits kbase { }
class { kbase: }
class kbase { }
/pre
Note that no external node classification or anything fancy was involved, you
should be able to reproduce the error on this manifest by simply running it
through puppet apply.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please 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-b...@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 #5447] Fix duplicate definition error
Issue #5447 has been updated by Matt Robinson.
Here's an even shorter manifest that exhibits the problem:
pre
class kbase { }
include kbase
class { kbase: }
/pre
Again, if you reverse order the error goes away:
pre
class kbase { }
class { kbase: }
include kbase
/pre
Bug #5447: Fix duplicate definition error
https://projects.puppetlabs.com/issues/5447
Author: Matt Robinson
Status: Unreviewed
Priority: Normal
Assignee:
Category:
Target version:
Affected Puppet version: 2.6.4
Keywords:
Branch:
Jos Boumans reported a manifest that results in the following error:
Duplicate definition: Class[Kbase] is already defined; cannot redefine at
/Users/matthewrobinson/work/puppet/4792:5 on node mattmac.puppetlabs.lan
He thought this was related to ticket 4792 and thus reopened it, but it appears
to be a separate issue. He posted his full set of manifests on that ticket,
but we reduced that to a much smaller manifest that reproduces the problem:
pre
class { s_riak: }
class s_riak inherits kbase { }
class { kbase: }
class kbase { }
/pre
Note that no external node classification or anything fancy was involved, you
should be able to reproduce the error on this manifest by simply running it
through puppet apply.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please 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-b...@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 #5447] Fix duplicate definition error
Issue #5447 has been updated by Paul Berry.
Keywords set to parameterized_classes
Bug #5447: Fix duplicate definition error
https://projects.puppetlabs.com/issues/5447
Author: Matt Robinson
Status: Unreviewed
Priority: Normal
Assignee:
Category:
Target version:
Affected Puppet version: 2.6.4
Keywords: parameterized_classes
Branch:
Jos Boumans reported a manifest that results in the following error:
Duplicate definition: Class[Kbase] is already defined; cannot redefine at
/Users/matthewrobinson/work/puppet/4792:5 on node mattmac.puppetlabs.lan
He thought this was related to ticket 4792 and thus reopened it, but it appears
to be a separate issue. He posted his full set of manifests on that ticket,
but we reduced that to a much smaller manifest that reproduces the problem:
pre
class { s_riak: }
class s_riak inherits kbase { }
class { kbase: }
class kbase { }
/pre
Note that no external node classification or anything fancy was involved, you
should be able to reproduce the error on this manifest by simply running it
through puppet apply.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please 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-b...@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 #5368] Using a parameterized class that doesn't exist results in a confusing error.
Issue #5368 has been updated by Paul Berry.
Keywords changed from parameterized class classes confusing error message to
parameterized class classes confusing error message
parameterized_classes
Bug #5368: Using a parameterized class that doesn't exist results in a
confusing error.
https://projects.puppetlabs.com/issues/5368
Author: Jordan Sissel
Status: Accepted
Priority: Normal
Assignee:
Category: error reporting
Target version: Statler
Affected Puppet version: 2.6.2
Keywords: parameterized class classes confusing error message
parameterized_classes
Branch:
Error message: Puppet::Parser::AST::Resource failed with error ArgumentError:
Invalid resource type class at ...
I expected that 'include foo' and 'class { foo: ...; }' should result in the
same error message if class 'foo' does not exist.
For example:
pre
% puppet apply -e 'include notbar'
Could not find class notbar at line 1 on node snack.home
% puppet apply -e 'class { notbar: ; }'
Puppet::Parser::AST::Resource failed with error ArgumentError: Invalid resource
type class at line 1 on node snack.home
/pre
Confirmed this problem is in both 2.6.2 and 2.6.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-b...@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 #5236] Ruby DSL cannot declare parameterized classes
Issue #5236 has been updated by Paul Berry. Keywords changed from internal dsl hostclass to internal dsl hostclass parameterized_classes Bug #5236: Ruby DSL cannot declare parameterized classes https://projects.puppetlabs.com/issues/5236 Author: Dan Bode Status: Accepted Priority: High Assignee: Category: API Target version: Affected Puppet version: Keywords: internal dsl hostclass parameterized_classes Branch: it should be possible to declare parameterized classes using the ruby dsl: /tmp/notify.rb pre hostclass 'foo', 'bar' do notify 'foop', :message = 'foobar' end node 'default' do hostclass 'foo', :bar = 'test' end /pre trying to apply the above manifest, results in the error below. pre #puppet apply /tmp/notify.rb --debug --trace /usr/lib/ruby/site_ruby/1.8/puppet/dsl/resource_api.rb:38:in `method_missing' (eval):7:in `parse_ruby_file' /usr/lib/ruby/site_ruby/1.8/puppet/dsl/resource_api.rb:19:in `instance_eval' /usr/lib/ruby/site_ruby/1.8/puppet/dsl/resource_api.rb:19:in `evaluate' /usr/lib/ruby/site_ruby/1.8/puppet/resource/type.rb:295:in `evaluate_ruby_code' /usr/lib/ruby/site_ruby/1.8/puppet/resource/type.rb:78:in `evaluate_code' /usr/lib/ruby/site_ruby/1.8/puppet/parser/resource.rb:71:in `evaluate' /usr/lib/ruby/site_ruby/1.8/puppet/parser/compiler.rb:225:in `evaluate_ast_node' /usr/lib/ruby/site_ruby/1.8/puppet/parser/compiler.rb:103:in `compile' /usr/lib/ruby/site_ruby/1.8/puppet/parser/compiler.rb:18:in `compile' /usr/lib/ruby/site_ruby/1.8/puppet/indirector/catalog/compiler.rb:77:in `compile' /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:188:in `benchmark' /usr/lib/ruby/site_ruby/1.8/puppet/indirector/catalog/compiler.rb:75:in `compile' /usr/lib/ruby/site_ruby/1.8/puppet/indirector/catalog/compiler.rb:34:in `find' /usr/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:193:in `find' /usr/lib/ruby/site_ruby/1.8/puppet/indirector.rb:50:in `find' /usr/lib/ruby/site_ruby/1.8/puppet/application/apply.rb:115:in `main' /usr/lib/ruby/site_ruby/1.8/puppet/application/apply.rb:35:in `run_command' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:287:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:393:in `exit_on_fail' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:287:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/util/command_line.rb:55:in `execute' /usr/bin/puppet:4 /usr/lib/ruby/site_ruby/1.8/puppet/parser/compiler.rb:21:in `compile' /usr/lib/ruby/site_ruby/1.8/puppet/indirector/catalog/compiler.rb:77:in `compile' /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:188:in `benchmark' /usr/lib/ruby/site_ruby/1.8/puppet/indirector/catalog/compiler.rb:75:in `compile' /usr/lib/ruby/site_ruby/1.8/puppet/indirector/catalog/compiler.rb:34:in `find' /usr/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:193:in `find' /usr/lib/ruby/site_ruby/1.8/puppet/indirector.rb:50:in `find' /usr/lib/ruby/site_ruby/1.8/puppet/application/apply.rb:115:in `main' /usr/lib/ruby/site_ruby/1.8/puppet/application/apply.rb:35:in `run_command' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:287:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:393:in `exit_on_fail' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:287:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/util/command_line.rb:55:in `execute' /usr/bin/puppet:4 undefined method `hostclass' for #Puppet::DSL::ResourceAPI:0xb790786c on node puppetfoo.localdomain /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-b...@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 #5089] when combining include with declaration of parameterized classes, order matters
Issue #5089 has been updated by Paul Berry.
Keywords changed from include parameterized class order to include
parameterized class order
parameterized_classes
Bug #5089: when combining include with declaration of parameterized classes,
order matters
https://projects.puppetlabs.com/issues/5089
Author: Dan Bode
Status: Duplicate
Priority: Normal
Assignee:
Category:
Target version:
Affected Puppet version:
Keywords: include parameterized class order
parameterized_classes
Branch:
I would not expect the code order to matter when combining includes with param
class declarations:
* this works fine:
pre
class foo($bar='foo') {
notice($bar)
}
class{'foo': bar = 'baz'}
include foo
/pre
pre
notice: Scope(Class[Foo]): baz
/pre
* changing the order of the include breaks it:
pre
class foo($bar='foo') {
notice($bar)
}
include foo
class{'foo': bar = 'baz'}
/pre
pre
notice: Scope(Class[Foo]): foo
Duplicate definition: Class[Foo] is already defined; cannot redefine at
/tmp/example.pp:5 on node puppetmaster.localdomain
/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-b...@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 #5074] declaring a parameterized class does not make its enclosed variables accessible
Issue #5074 has been updated by Paul Berry.
Keywords changed from include class parameterized scope to include class
parameterized scope
parameterized_classes
Bug #5074: declaring a parameterized class does not make its enclosed variables
accessible
https://projects.puppetlabs.com/issues/5074
Author: Dan Bode
Status: Duplicate
Priority: Normal
Assignee:
Category:
Target version:
Affected Puppet version:
Keywords: include class parameterized scope
parameterized_classes
Branch:
The following code
pre
class { 'motd':
override_data = 'override'
}
notice($motd::override_data)
/pre
results in:
pre
warning: Scope(Class[main]): Could not look up qualified variable
'motd::override_data'; class motd has not been evaluated
notice: Scope(Class[main]):
/pre
I can fix this, by putting an include before I want to use the qualified
variable.
pre
class { 'motd':
override_data = 'override'
}
include motd
notice($motd::local_var)
/pre
pre
notice: Scope(Class[main]): override
/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-b...@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 #5045] External node classifiers should be able to specify parameters for parameterized classes
Issue #5045 has been updated by Paul Berry.
Keywords set to parameterized_classes
Bug #5045: External node classifiers should be able to specify parameters for
parameterized classes
https://projects.puppetlabs.com/issues/5045
Author: Paul Berry
Status: Accepted
Priority: Normal
Assignee: Paul Berry
Category: language
Target version: 2.6.x
Affected Puppet version:
Keywords: parameterized_classes
Branch:
Currently, parameterized classes cannot be invoked by an external node
classifier because there is no way to specify parameters. For example:
Manifest:
pre
class foo($customizeable_file_name) {
file { $customizeable_file_name: ensure = present }
}
/pre
Data output by external node classifier:
pre
---
parameters: {}
classes:
- foo
/pre
This produces the error message:
pre
Must pass customizeable_file_name to Class[Foo] at ...
/pre
I propose that we change the format for data returned by the external node
classifier so that classes is a hash rather than an array, where each key is
a class to invoke, and the corresponding value is a hash of parameters to pass
to the class. Non-parameterized classes can use a value of either {} or nil.
For example:
pre
---
parameters: {}
classes:
parameterized_class:
param: value
normal_class_1: {}
normal_class_2:
/pre
For backward compatibility we should also support the old format; if classes
is an array, then all the classes are interpreted as taking no parameters.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please 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-b...@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 #4428] Parameterized classes in namespaces result in strange syntax in nodes
Issue #4428 has been updated by Paul Berry.
Keywords changed from parameterized classes
namespaces
parser to parameterized classes
namespaces
parser
parameterized_classes
Bug #4428: Parameterized classes in namespaces result in strange syntax in nodes
https://projects.puppetlabs.com/issues/4428
Author: Stefan Schimanski
Status: Needs design decision
Priority: Normal
Assignee: Jesse Wolfe
Category: parser
Target version: queued
Affected Puppet version:
Keywords: parameterized classes
namespaces
parser
parameterized_classes
Branch:
Consider a namespace with a parameterized class:
class bla {
class foo {
}
class bar ($x=42) {
notify { x = $x: }
}
}
To include the nested class into a node one would write:
node default {
include bla::foo
class { bla::bar: x = 42 }
}
which does not work as bla::bar is not a allowed symbol by the parser. You have
to quote it:
node default {
include bla::foo
class { bla::bar: x = 42 }
}
IMHO, Using the title attribute is very strange with this odd syntax as a
consequence. Why isn't there something like:
include bla::foo { x = 42 }
?
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please 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-b...@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 #4427] Deriving from parameterized classes not implemented or not documented
Issue #4427 has been updated by Paul Berry.
Keywords changed from parameterized classes
inheritence to parameterized classes
inheritence
parameterized_classes
Feature #4427: Deriving from parameterized classes not implemented or not
documented
https://projects.puppetlabs.com/issues/4427
Author: Stefan Schimanski
Status: Needs design decision
Priority: Normal
Assignee: anarcat -
Category: parameterized classes
Target version: Statler
Affected Puppet version:
Keywords: parameterized classes
inheritence
parameterized_classes
Branch:
Consider the following parameterized baseclass:
class foo ($x=42) {
notify { x = $x: }
}
There seems to be no way (or it's not documented) to derive another class from
foo. Neither
class bar inherits foo (x = 0) {
}
nor
class bar {
class { foo: x = 0 }
}
seems to work.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please 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-b...@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 #4943] (Available In Testing Branch) New Puppet executable, inspect for inspecting resource state and reporting on it.
Issue #4943 has been updated by Nick Lewis. Status changed from Accepted to Available In Testing Branch Merged to 2.6.next in commit:93526712755d5c30e020754a6f759b204921f423 Feature #4943: New Puppet executable, inspect for inspecting resource state and reporting on it. https://projects.puppetlabs.com/issues/4943 Author: Nan Liu Status: Available In Testing Branch Priority: High Assignee: Nan Liu Category: Target version: Affected Puppet version: Keywords: ae8890f89d318e0c2716bb0d9ba4e90e iteration_2010-12-01 Branch: **Historical description. See update 5 by Nigel** puppet audit should be the equivalent of puppet agent --noop but with auditing of resources. It should also support --report to submit results to puppet master. (maybe this should be puppet agent --audit/puppet apply --audit instead?) puppet audit should support the following features: * Create a state.yaml file after auditing the existing system state against the catalog. * Generate a list of resources that are out of compliance. This is similar to puppet agent --noop. * Compare the system against a known state. i.e. audit the system current state against an state.yaml file from 2010/1/1. This will be helpful in conjunction with the negate tag feature request: http://projects.puppetlabs.com/issues/1107 -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please 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-b...@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 #2191] Ruby 1.9 portability
Issue #2191 has been updated by Matt Robinson. Keywords set to ruby19 Bug #2191: Ruby 1.9 portability https://projects.puppetlabs.com/issues/2191 Author: Stéphan Gorget old account Status: Accepted Priority: Normal Assignee: Markus Roberts Category: plumbing Target version: queued Affected Puppet version: 0.25.0 Keywords: ruby19 Branch: I tried to use Puppet and Facter (master version) with Ruby 1.9.1 on CentOS 5.2 and I succeed to make Facter work but I still have some errors : pre # facter Could not retrieve ipaddress_eth0: undefined method `each' for #String:0xa08ed8c Could not retrieve macaddress_eth0: undefined method `each' for #String:0xa08e724 Could not retrieve netmask_eth0: undefined method `each' for #String: 0xa08e0d0 Could not retrieve ipaddress_eth1: undefined method `each' for #String:0xa08da7c Could not retrieve macaddress_eth1: undefined method `each' for #String:0xa08d428 Could not retrieve netmask_eth1: undefined method `each' for #String: 0xa08cdd4 Could not retrieve ipaddress_sit0: undefined method `each' for #String:0xa2ea9c8 Could not retrieve macaddress_sit0: undefined method `each' for #String:0xa2ea374 Could not retrieve netmask_sit0: undefined method `each' for #String: 0xa2e9d20 Could not retrieve network_eth0: undefined method `each' for #String: 0xa5a274c Could not retrieve network_eth1: undefined method `each' for #String: 0xa5a1fb8 Could not retrieve network_sit0: undefined method `each' for #String: 0xa5a1824 Could not retrieve macaddress: undefined method `each' for #String: 0xa54acb8 Could not retrieve virtual: undefined method `each' for #String: 0xa55a6a4 Could not retrieve virtual: undefined method `each' for #String: 0xa559e98 architecture = i386 /pre ... and then it goes ok. but puppetmasterd doesn't work and the errors are : pre # puppetmasterd Could not autoload file: constant Puppet::Type::File not defined Could not autoload file: constant Puppet::Type::File not defined ... Could not autoload file: constant Puppet::Type::File not defined Could not autoload file: constant Puppet::Type::File not defined Invalid method to apply /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-b...@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 #4572] Invalid next (SyntaxError) in application/kick.rb under Ruby 1.9.1
Issue #4572 has been updated by Matt Robinson.
Keywords set to ruby19
Bug #4572: Invalid next (SyntaxError) in application/kick.rb under Ruby 1.9.1
https://projects.puppetlabs.com/issues/4572
Author: Brett Bender
Status: Accepted
Priority: Normal
Assignee:
Category: executables
Target version:
Affected Puppet version:
Keywords: ruby19
Branch:
% sudo puppetmasterd
/var/lib/gems/1.9.1/gems/puppet-2.6.0/lib/puppet/application/kick.rb:
/var/lib/gems/1.9.1/gems/puppet-2.6.0/lib/puppet/application/kick.rb:107:
Invalid next (SyntaxError)
I believe the next should perhaps be:
exit($CHILD_STATUS)
in the following from application/kick.rb:
pre
102def run_for_host(host)
103 if options[:ping]
104out = %x{ping -c 1 #{host}}
105unless $CHILD_STATUS == 0
106 $stderr.print Could not contact #{host}\n
107 next
108end
109 end
/pre
Under Ruby 1.8.7 I get an error only if the next is reached, while in 1.9.1
it complains even when the next is not executed. That is, the following example
code runs without error on 1.8.7 but dies on 1.9.1
pre
def fun(word)
puts the word is #{word}
if false
next
end
end
%w( foo bar baz ).each do |word|
fun(word)
end
/pre
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-b...@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 #2782] Changes in Ruby 1.9.x const_set and const_get prevent puppetd from properly executing
Issue #2782 has been updated by Matt Robinson. Keywords changed from Ruby 1.9 to Ruby 1.9 ruby19 Bug #2782: Changes in Ruby 1.9.x const_set and const_get prevent puppetd from properly executing https://projects.puppetlabs.com/issues/2782 Author: Al Hoang Status: Code Insufficient Priority: Low Assignee: Markus Roberts Category: unknown Target version: queued Affected Puppet version: 0.25.1 Keywords: Ruby 1.9 ruby19 Branch: http://github.com/hoanga/puppet/tree/0.25.x_1.9.1 Hello, Attached is a patch with modifications to get puppetd to properly execute when puppetd --trace --verbose --debug is run on the command line. Some changes are: * Explicitly use the top-level File object in lib/puppet/type/file.rb * Add some checks on RUBY_VERSION and avoid called @resource.stat(false) * Call a Ruby 1.8.x compatible version of const_defined? if RUBY_VERSION looks like it is 1.9.x Here are some useful links that might help explain some of the changes to const_set and const_set in Ruby 1.9.x: http://issues.apache.org/jira/browse/BUILDR-140 http://jira.codehaus.org/browse/JRUBY-4197 http://redmine.ruby-lang.org/issues/show/1915 http://markmail.org/message/zr5vh2333yr3k3qi Please note that this assumes that the changes from ticket #2781 are already applied -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please 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-b...@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 #4487] Environment column in hosts table updating incorrectly
Issue #4487 has been updated by Cody Herriges. This looks like an incompatibility of Puppet 2.6.x and older rails/activerecord/mysql gem versions. Reproducible with Centos 5.5 and Debian Lenny running rails 2.2.1 and 2.2.0. Installed Ruby EE 1.8.7 on Centos 5.5, installed rails through gems instead of through yum and the errors subside completely. Bug #4487: Environment column in hosts table updating incorrectly https://projects.puppetlabs.com/issues/4487 Author: Jason Koppe Status: Re-opened Priority: High Assignee: Matt Robinson Category: Target version: Affected Puppet version: 2.6.0 Keywords: storedconfig, mysql, environment, hosts table Branch: http://github.com/MarkusQ/puppet/tree/ticket/2.6.x/4487 Posted on puppet-users at [thread/7237b49342ff9890](http://groups.google.com/group/puppet-users/browse_thread/thread/7237b49342ff9890) Below I null out the environment column, show that it's null for a particular host, then run puppetd a few times on the host. pre mysql for r...@localhost on indadm1 select * from hosts where name like 'iad-web2%'; ++-+---+-+-+-+-+-++-+ | id | name| ip| environment | last_compile | last_freshcheck | last_report | updated_at |source_file_id | created_at | ++-+---+-+-+-+-+-++-+ | 9 | iad-web2.indeed.net | 10.24.186.136 | NULL| 2010-08-06 03:31:23 | NULL| NULL| 2010-08-06 03:31:23 | NULL | 2010-06-08 19:47:22 | ++-+---+-+-+-+-+-++-+ 1 row in set (0.00 sec) mysql for r...@localhost on indadm1 select * from hosts where name like'iad-web2%'; ++-+---++-+-+-+-++-+ | id | name| ip| environment| last_compile | last_freshcheck | last_report | updated_at | source_file_id | created_at | ++-+---++-+-+-+-++-+ | 9 | iad-web2.indeed.net | 10.24.186.136 | --- production | 2010-08-06 03:31:23 | NULL| NULL| 2010-08-06 03:32:42 | NULL | 2010-06-08 19:47:22 | ++-+---++-+-+-+-++-+ 1 row in set (0.00 sec) mysql for r...@localhost on indadm1 select * from hosts where name like 'iad-web2%'; ++-+---+--+-+-+-+-++-+ | id | name| ip| environment | last_compile| last_freshcheck | last_report | updated_at | source_file_id | created_at | ++-+---+--+-+-+-+-++-+ | 9 | iad-web2.indeed.net | 10.24.186.136 | --- --- production | 2010-08-06 03:32:50 | NULL| NULL| 2010-08-06 03:32:50 | NULL | 2010-06-08 19:47:22 | ++-+---+--+-+-+-+-++-+ 1 row in set (0.00 sec) /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-b...@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 #4487] Environment column in hosts table updating incorrectly
Issue #4487 has been updated by Jordan Sissel. Cody, My systems use newer versions than 2.2.x: * activerecord (3.0.3) * ruby-mysql (2.9.3) Also observed this problem with the non-pure-ruby mysql gem 'mysql' latest version. Bug #4487: Environment column in hosts table updating incorrectly https://projects.puppetlabs.com/issues/4487 Author: Jason Koppe Status: Re-opened Priority: High Assignee: Matt Robinson Category: Target version: Affected Puppet version: 2.6.0 Keywords: storedconfig, mysql, environment, hosts table Branch: http://github.com/MarkusQ/puppet/tree/ticket/2.6.x/4487 Posted on puppet-users at [thread/7237b49342ff9890](http://groups.google.com/group/puppet-users/browse_thread/thread/7237b49342ff9890) Below I null out the environment column, show that it's null for a particular host, then run puppetd a few times on the host. pre mysql for r...@localhost on indadm1 select * from hosts where name like 'iad-web2%'; ++-+---+-+-+-+-+-++-+ | id | name| ip| environment | last_compile | last_freshcheck | last_report | updated_at |source_file_id | created_at | ++-+---+-+-+-+-+-++-+ | 9 | iad-web2.indeed.net | 10.24.186.136 | NULL| 2010-08-06 03:31:23 | NULL| NULL| 2010-08-06 03:31:23 | NULL | 2010-06-08 19:47:22 | ++-+---+-+-+-+-+-++-+ 1 row in set (0.00 sec) mysql for r...@localhost on indadm1 select * from hosts where name like'iad-web2%'; ++-+---++-+-+-+-++-+ | id | name| ip| environment| last_compile | last_freshcheck | last_report | updated_at | source_file_id | created_at | ++-+---++-+-+-+-++-+ | 9 | iad-web2.indeed.net | 10.24.186.136 | --- production | 2010-08-06 03:31:23 | NULL| NULL| 2010-08-06 03:32:42 | NULL | 2010-06-08 19:47:22 | ++-+---++-+-+-+-++-+ 1 row in set (0.00 sec) mysql for r...@localhost on indadm1 select * from hosts where name like 'iad-web2%'; ++-+---+--+-+-+-+-++-+ | id | name| ip| environment | last_compile| last_freshcheck | last_report | updated_at | source_file_id | created_at | ++-+---+--+-+-+-+-++-+ | 9 | iad-web2.indeed.net | 10.24.186.136 | --- --- production | 2010-08-06 03:32:50 | NULL| NULL| 2010-08-06 03:32:50 | NULL | 2010-06-08 19:47:22 | ++-+---+--+-+-+-+-++-+ 1 row in set (0.00 sec) /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-b...@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.
