[Puppet - Bug #18172] Puppet issues a restart despite config copy failure
Issue #18172 has been updated by Dominic Cleal.
Description updated
Bug #18172: Puppet issues a restart despite config copy failure
https://projects.puppetlabs.com/issues/18172#change-79677
Author: Bart Bialek
Status: Unreviewed
Priority: Normal
Assignee:
Category:
Target version:
Affected Puppet version:
Keywords:
Branch:
We currently have sshd_config immutable for a reason. Puppet recognizes a
change in the config and restarts the service despite the config not really
being updated:
2012-12-17T14:31:47.227752-05:00 myhost puppet-agent[4642]:
(/Stage[main]/Securitylevel/File[/etc/ssh/sshd_config]/content) change from
{md5}504b89e2d56a71127c90954c2b2833b1 to {md5}cfb54dfc00a739eafd63cadb5c927d19
failed: Could not rename temporary file /etc/ssh/sshd_config.puppettmp_374 to
/etc/ssh/sshd_config: Operation not permitted -
/etc/ssh/sshd_config.puppettmp_374 or /etc/ssh/sshd_config at
/etc/puppet/production/manifests/includes/securitylevel.pp:8
2012-12-17T14:31:47.229710-05:00 myhost puppet-agent[4642]:
(/Stage[main]/default/Service[sshd]) Dependency File[/etc/ssh/sshd_config] has
failures: true
2012-12-17T14:31:47.230240-05:00 myhost puppet-agent[4642]:
(/Stage[main]/default/Service[sshd]) Skipping because of failed dependencies
2012-12-17T14:31:47.560808-05:00 myhost puppet-agent[4642]:
(/Stage[main]/default/Service[sshd]) Triggered 'refresh' from 1 events
I believe the service restart should not take place under these conditions.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #18026] SELinux warnings when using ensure = absent on file
Issue #18026 has been updated by Dominic Cleal.
Category set to SELinux
Affected Puppet version set to 3.0.2
Bug #18026: SELinux warnings when using ensure = absent on file
https://projects.puppetlabs.com/issues/18026#change-79678
Author: Malcolm Howe
Status: Unreviewed
Priority: Normal
Assignee:
Category: SELinux
Target version:
Affected Puppet version: 3.0.2
Keywords:
Branch:
When using, for example,
file {/etc/exclude.systemdump: ensure = absent }
If the file is already absent Puppet 3.0.2rc1 gives the following warnings not
seen in Puppet 3.0.1
Warning: /File[/etc/exclude.systemdump]/seluser: Could not stat; No such
file or directory - /etc/exclude.systemdump
Warning: /File[/etc/exclude.systemdump]/selrole: Could not stat; No such
file or directory - /etc/exclude.systemdump
Warning: /File[/etc/exclude.systemdump]/seltype: Could not stat; No such
file or directory - /etc/exclude.systemdump
Warning: /File[/etc/exclude.systemdump]/selrange: Could not stat; No such
file or directory - /etc/exclude.systemdump
System is running Centos 6 with SELinux in permissive mode.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #18127] (Accepted) puppet resource error with no suitable provider: Could not run: undefined method `exists?' for nil:NilClass
Issue #18127 has been updated by Dominic Cleal.
Subject changed from puppet resource user root: Error: Could not run: undefined
method `exists?' for nil:NilClass to puppet resource error with no suitable
provider: Could not run: undefined method `exists?' for nil:NilClass
Category set to ralsh
Status changed from Unreviewed to Accepted
This is happening because no suitable provider can be found for the type, since
`useradd` is often only executable by root, so the provider's confines won't
match. `puppet resource` should fail with a message similar to a normal puppet
run, indicating no suitable provider's available.
Bug #18127: puppet resource error with no suitable provider: Could not run:
undefined method `exists?' for nil:NilClass
https://projects.puppetlabs.com/issues/18127#change-79679
Author: Igor Galić
Status: Accepted
Priority: Normal
Assignee:
Category: ralsh
Target version:
Affected Puppet version: 3.0.1
Keywords:
Branch:
Following [the resources
documentation](http://docs.puppetlabs.com/learning/ral.html) I execute the
following command as normal user and get:
pre
igalic@tynix ~ % puppet resource user root
Error: Could not run: undefined method `exists?' for nil:NilClass
1 igalic@tynix ~ % puppet resource user igalic
Error: Could not run: undefined method `exists?' for nil:NilClass
1 igalic@tynix ~ %
/pre
When executing the same commands as root, I get the expected results:
pre
tynix ~ # puppet resource user root
user { 'root':
ensure = 'present',
comment = 'root',
gid = '0',
groups = ['root', 'bin', 'daemon', 'sys', 'adm', 'disk', 'wheel'],
home= '/root',
shell = '/bin/bash',
uid = '0',
}
tynix ~ # puppet resource user igalic
user { 'igalic':
ensure = 'present',
comment = 'Igor Galić',
gid = '501',
groups = ['wheel', 'jupiter', 'rvm'],
home= '/home/igalic',
shell = '/bin/zsh',
uid = '500',
}
tynix ~ #
/pre
Environment: @ruby 1.9.3p327 (2012-11-10 revision 37606) [x86_64-linux]@
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please 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 #18229] (Accepted) Eroneous command given in puppet module error message
Issue #18229 has been updated by Dominic Cleal.
Status changed from Unreviewed to Accepted
Keywords set to module error message
It should be recommending `--target-dir` instead.
Bug #18229: Eroneous command given in puppet module error message
https://projects.puppetlabs.com/issues/18229#change-79680
Author: Gerard Hickey
Status: Accepted
Priority: Normal
Assignee:
Category: module tool
Target version:
Affected Puppet version: 3.0.1
Keywords: module error message
Branch:
I executed the following and the error output of the puppet module command gave
an invalid switch.
ghickey@lm-sjn-00712956.local:puppet/common-modules puppet module install
ghoneycutt-ntp
Preparing to install into /Users/ghickey/.puppet/modules ...
Downloading from http://forge.puppetlabs.com ...
Error: Could not install module 'ghoneycutt-ntp' (latest: v1.0.0)
Installation would overwrite /Users/ghickey/.puppet/modules/ntp
Currently, 'puppetlabs-ntp' (v0.2.0) is installed to that directory
Use `puppet module install --dir DIR` to install modules elsewhere
Use `puppet module install --force` to install this module anyway
ghickey@lm-sjn-00712956.local:puppet/common-modules{1} puppet module
install --dir . ghoneycutt-ntp
Could not parse options: invalid option: --dir
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please 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 #18229] Eroneous command given in puppet module error message
Issue #18229 has been updated by Dominic Cleal.
Keywords changed from module error message to module error message simplefix
Bug #18229: Eroneous command given in puppet module error message
https://projects.puppetlabs.com/issues/18229#change-79681
Author: Gerard Hickey
Status: Accepted
Priority: Normal
Assignee:
Category: module tool
Target version:
Affected Puppet version: 3.0.1
Keywords: module error message simplefix
Branch:
I executed the following and the error output of the puppet module command gave
an invalid switch.
ghickey@lm-sjn-00712956.local:puppet/common-modules puppet module install
ghoneycutt-ntp
Preparing to install into /Users/ghickey/.puppet/modules ...
Downloading from http://forge.puppetlabs.com ...
Error: Could not install module 'ghoneycutt-ntp' (latest: v1.0.0)
Installation would overwrite /Users/ghickey/.puppet/modules/ntp
Currently, 'puppetlabs-ntp' (v0.2.0) is installed to that directory
Use `puppet module install --dir DIR` to install modules elsewhere
Use `puppet module install --force` to install this module anyway
ghickey@lm-sjn-00712956.local:puppet/common-modules{1} puppet module
install --dir . ghoneycutt-ntp
Could not parse options: invalid option: --dir
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please 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 #18172] Puppet issues a restart despite config copy failure
Issue #18172 has been updated by R.I. Pienaar.
Sounds like it might be #5876, would need to see the code
Bug #18172: Puppet issues a restart despite config copy failure
https://projects.puppetlabs.com/issues/18172#change-79682
Author: Bart Bialek
Status: Unreviewed
Priority: Normal
Assignee:
Category:
Target version:
Affected Puppet version:
Keywords:
Branch:
We currently have sshd_config immutable for a reason. Puppet recognizes a
change in the config and restarts the service despite the config not really
being updated:
2012-12-17T14:31:47.227752-05:00 myhost puppet-agent[4642]:
(/Stage[main]/Securitylevel/File[/etc/ssh/sshd_config]/content) change from
{md5}504b89e2d56a71127c90954c2b2833b1 to {md5}cfb54dfc00a739eafd63cadb5c927d19
failed: Could not rename temporary file /etc/ssh/sshd_config.puppettmp_374 to
/etc/ssh/sshd_config: Operation not permitted -
/etc/ssh/sshd_config.puppettmp_374 or /etc/ssh/sshd_config at
/etc/puppet/production/manifests/includes/securitylevel.pp:8
2012-12-17T14:31:47.229710-05:00 myhost puppet-agent[4642]:
(/Stage[main]/default/Service[sshd]) Dependency File[/etc/ssh/sshd_config] has
failures: true
2012-12-17T14:31:47.230240-05:00 myhost puppet-agent[4642]:
(/Stage[main]/default/Service[sshd]) Skipping because of failed dependencies
2012-12-17T14:31:47.560808-05:00 myhost puppet-agent[4642]:
(/Stage[main]/default/Service[sshd]) Triggered 'refresh' from 1 events
I believe the service restart should not take place under these conditions.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please 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 #18234] (In Topic Branch Pending Review) Booleans used from within hashes not working correctly.
Issue #18234 has been updated by Dominic Cleal.
Status changed from Accepted to In Topic Branch Pending Review
Assignee set to Andrew Hendry
Affected Puppet version set to 3.0.1
Branch set to https://github.com/puppetlabs/puppet/pull/1357
Bug #18234: Booleans used from within hashes not working correctly.
https://projects.puppetlabs.com/issues/18234#change-79683
Author: Andrew Hendry
Status: In Topic Branch Pending Review
Priority: Normal
Assignee: Andrew Hendry
Category: language
Target version:
Affected Puppet version: 3.0.1
Keywords: puppet hashes booleans defaults evaluation
Branch: https://github.com/puppetlabs/puppet/pull/1357
booleans_from_hashes.pp
pre$puppet_hash = {
hflag1 = true,
hflag2 = false
}
notice(hflag1 should be true = '${puppet_hash[hflag1]}')
notice(hflag2 should be false = '${puppet_hash[hflag2]}')
dummy {'fromhash':
flag1 = $puppet_hash[hflag1],
flag2 = $puppet_hash[hflag2]
}
dummy {'assigned':
flag1 = true,
flag2 = false
}
define dummy
(
$flag1 = true,
$flag2 = true,
) {
notice(${name} flag1 should be true = '${flag1}')
notice(${name} flag2 should be false = '${flag2}')
}
/pre
Output:
pre
puppet apply booleans_from_hashes.pp
notice: Scope(Class[main]): hflag1 should be true = 'true'
notice: Scope(Class[main]): hflag2 should be false = ''
notice: Scope(Dummy[fromhash]): fromhash flag1 should be true = 'true'
notice: Scope(Dummy[fromhash]): fromhash flag2 should be false = 'true'
notice: Scope(Dummy[assigned]): assigned flag1 should be true = 'true'
notice: Scope(Dummy[assigned]): assigned flag2 should be false = 'false'
notice: Finished catalog run in 0.04 seconds
/pre
pre
puppet --version
2.7.14
ruby --version
ruby 1.8.7 (2010-06-23 patchlevel 299) [x86_64-linux]
/pre
flag2 should be false when pulled from the hash but it appears to be empty,
resulting in the default being used.
This does not happen when passing booleans directly.
Does anyone know a workaround or fix?
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Facter - Feature #7559] Fact for identifying Amazon VPC instances.
Issue #7559 has been updated by Jeff McCune.
Brian Wong wrote:
Jeff McCune wrote:
The course we plan to pursue is:
1. Confine the metadata API availability check to `virtual = xenu` in
an effort to limit this network call to a subset of Facter users.
2. Confine the metadata API check to a x millisecond timeout. Amazon
says the metadata server responds quickly so let's take their word for
it. We'll compute x by sampling these response times on some EC2
instances in various regions. If x turns out to be 20ms then we're
probably not going to take this approach. because it would negatively
impact everyone running Facter on Xen hypervisors.
3. Check to see if http://169.254.169.254/latest/meta-data/ responds
with a header of Server: EC2ws
4. If so, define a fact indicating we're inside of EC2.
5. Confine all of the meta-data and user-data facts to the fact set in 4.
Baring any major objections I'll implement this soon. Thoughts?
-Jeff
I just wanted to mention that my instances in VPC have `virtual = physical`.
Therefore I do not believe it is an appropriate method to limit the scope of
systems of which the network call to http://169.254.169.254 is made.
This information changes the plan... We can't make this blocking I/O call over
the network when facter runs on a physical host. There's just too big of an
impact.
I'm curious why your instance isn't reporting physical = xen. Could you let
me know what Facter version you're running Brian?
-Jeff
Feature #7559: Fact for identifying Amazon VPC instances.
https://projects.puppetlabs.com/issues/7559#change-79684
Author: Nigel Kersten
Status: Accepted
Priority: Normal
Assignee:
Category: library
Target version:
Keywords: vpc ec2 arp
Branch:
Affected Facter version: 1.6.10
(From the list)
I ran into a buglet in facter 1.5.9rc6 (from tmz repo). In normal AWS
instances it works great. In VPC instances if doesn't work. This seems
to be because VPC instances don't use the fe:ff:ff:... MAC addresses.
pre
/sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 02:67:4E:E1:26:30
inet addr:172.17.129.24 ...
/sbin/arp
Address HWtype HWaddress Flags Mask Iface
169.254.169.253 ether 02:67:4E:C0:00:01 C eth0
172.17.128.1 ether 02:67:4E:C0:00:01 C eth0
/sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 02:67:4E:DA:58:16
inet addr:172.17.128.126
/sbin/arp
Address HWtype HWaddress Flags Mask Iface
169.254.169.253 ether 02:67:4E:C0:00:01 C eth0
172.17.128.1 ether 02:67:4E:C0:00:01 C eth0
/pre
Of the two VPC EC2 instances I've seen, the MAC address always start
with 02:67:4E. I have only seen two instances, both in the same VPC, so
I don't know if this holds for every VPC instance, YMMV.
in ec2.rb , the following seemed to work:
pre
def has_euca_mac?
!!(Facter.value(:macaddress) =~ %r{^02:67:4[eE]:})
end
/pre
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Facter - Feature #7559] Fact for identifying Amazon VPC instances.
Issue #7559 has been updated by Justin Lambert.
Jeff McCune wrote:
Brian Wong wrote:
Jeff McCune wrote:
I just wanted to mention that my instances in VPC have `virtual =
physical`. Therefore I do not believe it is an appropriate method to limit
the scope of systems of which the network call to http://169.254.169.254 is
made.
This information changes the plan... We can't make this blocking I/O call
over the network when facter runs on a physical host. There's just too big
of an impact.
I'm curious why your instance isn't reporting physical = xen. Could you let
me know what Facter version you're running Brian?
-Jeff
Mine is showing virtual = physical as well, facter 1.6.13 on CentOS 6.3 It
looks like Facter::Util::Virtual.xen? returns true (/proc/xen exists), but
/proc/xen is empty so Facter::Virtual does not find either /proc/xen/xsd_kva or
/proc/xen/capabilities.
Feature #7559: Fact for identifying Amazon VPC instances.
https://projects.puppetlabs.com/issues/7559#change-79686
Author: Nigel Kersten
Status: Accepted
Priority: Normal
Assignee:
Category: library
Target version:
Keywords: vpc ec2 arp
Branch:
Affected Facter version: 1.6.10
(From the list)
I ran into a buglet in facter 1.5.9rc6 (from tmz repo). In normal AWS
instances it works great. In VPC instances if doesn't work. This seems
to be because VPC instances don't use the fe:ff:ff:... MAC addresses.
pre
/sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 02:67:4E:E1:26:30
inet addr:172.17.129.24 ...
/sbin/arp
Address HWtype HWaddress Flags Mask Iface
169.254.169.253 ether 02:67:4E:C0:00:01 C eth0
172.17.128.1 ether 02:67:4E:C0:00:01 C eth0
/sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 02:67:4E:DA:58:16
inet addr:172.17.128.126
/sbin/arp
Address HWtype HWaddress Flags Mask Iface
169.254.169.253 ether 02:67:4E:C0:00:01 C eth0
172.17.128.1 ether 02:67:4E:C0:00:01 C eth0
/pre
Of the two VPC EC2 instances I've seen, the MAC address always start
with 02:67:4E. I have only seen two instances, both in the same VPC, so
I don't know if this holds for every VPC instance, YMMV.
in ec2.rb , the following seemed to work:
pre
def has_euca_mac?
!!(Facter.value(:macaddress) =~ %r{^02:67:4[eE]:})
end
/pre
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #17887] Failure during property sync results in Puppet::Util::Log requires a message
Issue #17887 has been updated by Dominic Cleal. Subject changed from Mocha expectation failure during property sync results in Puppet::Util::Log requires a message to Failure during property sync results in Puppet::Util::Log requires a message Priority changed from Low to Normal Branch changed from https://github.com/puppetlabs/puppet/pull/1307 to https://github.com/puppetlabs/puppet/pull/1358 This also happens if an exception is raised that isn't derived from StandardError. The resource harness uses a simple `rescue` and so core Ruby exceptions (OOMs etc) also get masked by this problem. Example of a masked SignalException: [puppet-dev: Any advice on Puppet::Util::Log requires a message failure](http://groups.google.com/group/puppet-dev/browse_thread/thread/7613831f39d6f8c3#) Bug #17887: Failure during property sync results in Puppet::Util::Log requires a message https://projects.puppetlabs.com/issues/17887#change-79687 Author: Dominic Cleal Status: In Topic Branch Pending Review Priority: Normal Assignee: Dominic Cleal Category: transactions Target version: 3.0.x Affected Puppet version: development Keywords: resource harness, transaction Branch: https://github.com/puppetlabs/puppet/pull/1358 During provider development and testing with rspec+mocha and using a test catalog, an expectation failure can cause the following log message: Could not evaluate: Puppet::Util::Log requires a message This occurs if the property sync calls a method that has a mocha expectation set, but has reached the max call count or similar. When testing a catalog from a test, the `Puppet::Transaction::ResourceHarness` calls `apply_parameter` for a given parameter, which then calls `property.sync`. If the mocha expectation fails inside this sync, the `rescue` block is never called (it isn't an exception) but the `ensure` block is still run. This calls `send_log` on the event, but the message is uninitialised at that point so the logging fails with the above error. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please 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.
