[Puppet - Bug #11984] improperly configured storeconfigs do not return valuable exit codes
Issue #11984 has been updated by Peter Meier.
Imho it is fine if the exit code 0, as it is only a warning and imho it
actually doesn't happen during a transaction, but rather at compile time.
Related is also the discussion in #7078 Where the long standing request was
discussed to not pollute the output with tons of such warnings. If we do any
changes we should imho address both discussions at once. Otherwise things will
get messier.
Bug #11984: improperly configured storeconfigs do not return valuable exit codes
https://projects.puppetlabs.com/issues/11984
Author: Justin Stoller
Status: Accepted
Priority: Normal
Assignee:
Category: stored configuration
Target version:
Affected Puppet version: 2.7.9
Keywords: exit codes, storeconfigs
Branch:
Noticed this while writing tests:
pre
root@ubuntu-beta:~# puppet --version
2.7.9
root@ubuntu-beta:~# puppet apply --detailed-exitcodes -e '@@notify {
$hostname: tag = storeconfgs }'
warning: You cannot collect without storeconfigs being set on line 1
notice: Finished catalog run in 0.03 seconds
root@ubuntu-beta:~# echo $?
0
/pre
as well as
pre
root@ubuntu-beta:~# puppet apply --detailed-exitcodes -e Notify | tag ==
'storeconfig_test' |
warning: You cannot collect exported resources without storeconfigs being set;
the collection will be ignored on line 1
warning: Not collecting exported resources without storeconfigs
notice: Finished catalog run in 0.03 seconds
root@ubuntu-beta:~# echo $?
0
/pre
checking
pre
* --detailed-exitcodes:
Provide transaction information via exit codes. If this is enabled, an exit
code of '2' means there were changes, an exit code of '4' means there were
failures during the transaction, and an exit code of '6' means there were both
changes and failures.
/pre
From reading this I was expecting, if not a 1, at least a 4 as the exit code.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #11988] Augeas provider can clobber symlinks
Issue #11988 has been updated by Peter Meier. In my experience this can hit you quite badly, as RHEL (and its derivates) for example have a symlink for grub.conf. While it worked imho earlier, it doesn't work anymore nowadays and your manifests will constantly update the wrong config file, also other tools that relay on /etc/grub.conf being a symlink will start to fail. Bug #11988: Augeas provider can clobber symlinks https://projects.puppetlabs.com/issues/11988 Author: Nathan Huff Status: Accepted Priority: Normal Assignee: Category: augeas Target version: Affected Puppet version: 2.7.9 Keywords: augeas Branch: If the augeas resource is fed a symlink as the target file and it makes changes it will overwrite it with a regular file. It creates and .augnew file and just blindly moves it into place without checking if the target file was a symlink. The provider should either check whether the target was a symlink and dereference it or it should rerun augeas in overwrite mode since augeas does take care to dereference if necessary. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To 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 #11995] Add group install to Package
Issue #11995 has been updated by Peter Meier.
Imho this was already discussed a couple of times (mailing list, probably also
bugtracker). One (big) issue is that you can tell yum to install a group, but
afair you can't query yum if a certain group is installed. So how would you do
that, to fit into puppet's idea of managing state of resources?
Bug #11995: Add group install to Package
https://projects.puppetlabs.com/issues/11995
Author: Charlie Wyse
Status: Unreviewed
Priority: Normal
Assignee:
Category:
Target version:
Affected Puppet version:
Keywords:
Branch: puppet-2.6.12-1
This is my first ticket so if I do anything wrong let me know. When trying to
install a package group in Red Hat 6, I get a failure. I don't think puppet
understands package groups. Could this be added to the package feature?
My manifest:
package { 'MRG Grid':
ensure = present,
}
Error:
err: /Stage[main]/Mrg/Package[MRG Grid]/ensure: change from absent to present
failed: Execution of '/usr/bin/yum -d 0 -e 0 -y install MRG Grid' returned 1:
Error: Nothing to do
If the package could have a command to encapsulate anything in the naming list
like 'MRG Grid' and change install to groupinstall, this should do the trick.
Example:
'/usr/bin/yum -d 0 -e 0 -y groupinstall MRG Grid'
Anyhow, as I said this is my first ticket so let me know what I can do to help
move this along without any helpful knowledge in ruby programming.
--
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 #11044] Puppet agent should fork when applying the catalog
Issue #11044 has been updated by Brice Figureau. Daniel Pittman wrote: It sounds like this is generally satisfactory to everyone, if we target Telly? This is more or less the last chance to speak up because, frankly, it seems like a good change to me. I can't see it harming things, and it certainly helps more effective garbage collection on the agent. Bryce, if we accept this would you be willing to rebase on current master and resubmit the code? Yes, I'll do that during the week. Feature #11044: Puppet agent should fork when applying the catalog https://projects.puppetlabs.com/issues/11044 Author: Brice Figureau Status: Needs Decision Priority: Normal Assignee: Daniel Pittman Category: agent Target version: Telly Affected Puppet version: Keywords: Branch: https://github.com/masterzen/puppet/tree/tickets/2.7.x/11044 The current best practice among Puppet users is to run the puppet agent out of cron with --onetime. The rationale is that the puppet agent is a memory hog during a run, but due to the way the ruby interpreter works this memory can never be returned to the OS between runs. Running on cron makes sure puppet doesn't hold this memory for more than the run. A simple solution to this issue is to fork into a child process and do the catalog run. This process would exit at the end of the catalog execution, thus freeing the memory used during the run. -- 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 #11990] PuppetDoc should use also README.rdoc files
Issue #11990 has been updated by Brice Figureau.
Alessandro Franceschi wrote:
I attach the patch in a more readable format... sorry for the mess
I will produce a better patch (ie with spec coverage) soon.
Feature #11990: PuppetDoc should use also README.rdoc files
https://projects.puppetlabs.com/issues/11990
Author: Alessandro Franceschi
Status: Unreviewed
Priority: Normal
Assignee:
Category:
Target version:
Affected Puppet version:
Keywords: puppetdoc
Branch:
This is a feature request for which there's already a solution.
Hope you will review and eventually accept it.
PuppetDoc uses the file README in a module to generate the main page of a
module's documentation.
If this file is in rdoc format it renders it nicely.
At the same time many modules are published on GitHub, where README files are
rendered as rdoc if they are named README.rdoc
The request is to make puppetdoc renders files called README.rdoc ad module
documentation if they are found on the module, otherwise it falls back to the
standard README.
I already asked Brice an help about this and he replied, in very few minutes
with this:
Here is a patch that should quite do what you need:
diff --git a/lib/puppet/util/rdoc/parser.rb b/lib/puppet/util/rdoc/parser.rb
index a8996ee..5fa3246 100644
--- a/lib/puppet/util/rdoc/parser.rb
+++ b/lib/puppet/util/rdoc/parser.rb
@@ -129,8 +129,10 @@ class Parser
def scan_top_level(container)
# use the module README as documentation for the module
comment =
-readme = File.join(File.dirname(File.dirname(@input_file_name)), README)
-comment = File.open(readme,r) { |f| f.read } if
FileTest.readable?(readme)
+%w{README README.rdoc}.each do |rfile|
+ readme = File.join(File.dirname(File.dirname(@input_file_name)), rfile)
+ comment = File.open(readme,r) { |f| f.read } if
FileTest.readable?(readme)
+end
look_for_directives_in(container, comment) unless comment.empty?
# infer module name from directory
It is fully untested :)
It should prefer a README.rdoc over a README if both are present.
---
I've tested this patch on Puppet 2.7.9 and it seems to work as expected:
- modules with a README are rendered well
- modules with a README.rdoc are rendered well
- modules with both render README.rdoc
--
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 #7788] Puppet should allow rubygems to deliver new functionality
Issue #7788 has been updated by R.I. Pienaar. I think it still has value, unless you also let us control what gets pluginsynced to what places. With gems if we wanted some plugin on a subset of machines we just install it on those machines. With pluginsync thats not possible. Feature #7788: Puppet should allow rubygems to deliver new functionality https://projects.puppetlabs.com/issues/7788 Author: R.I. Pienaar Status: Needs Decision Priority: Normal Assignee: Nigel Kersten Category: plug-ins Target version: 2.7.x Affected Puppet version: Keywords: Branch: ripienaar/feature/master/7788 It would be desirable to use Rubygems to install things like parser functions. There might be cases where you only want a function on the master, pluginsync would copy it everywhere and everywhere might not have the dependencies needed to run it. If the autoloader considered the rubygem search path while autoloading this should allow gems to extend puppet. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Facter - Feature #1424] Zone facts for Solaris
Issue #1424 has been updated by Martin Englund. the reason for having zones as a fact is to be able to gather information about the zones you have running on a system, and then zonename helps you act differently if you are dealing with a zone that hasn't been created by puppet (i.e. being managed as a normal solaris instance) Feature #1424: Zone facts for Solaris https://projects.puppetlabs.com/issues/1424 Author: Martin Englund Status: Code Insufficient Priority: Low Assignee: Paul Nasrat Category: library Target version: 2.0.0 Keywords: solaris zone Branch: Affected Facter version: Two new facts should be added for Solaris (10): zonename and zones zonename is the output of /usr/bin/zonename which MAY differ from hostname. zones is the number of zones on the system, and then one zone_zonename is added for each zone, which should contain the state of the zone, e.g. running, installed, incomplete, 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 - Feature #11727] Add stdin parsing to puppet parser validate
Issue #11727 has been updated by Dominic Maraglia. Assignee changed from Dominic Maraglia to Daniel Pittman Test looks good; commented on pull request as well. Feature #11727: Add stdin parsing to puppet parser validate https://projects.puppetlabs.com/issues/11727 Author: James Turnbull Status: In Topic Branch Pending Review Priority: High Assignee: Daniel Pittman Category: executables Target version: Affected Puppet version: Keywords: Branch: https://github.com/puppetlabs/puppet/pull/329 Git pre-commit hooks everywhere relied on the stdin parsing that existed before faces. This restores that behavior if stdin is not a tty. -- 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 Matthaus Litteken. Downloading Puppet: https://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet View differences: https://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet/diff/136 -- 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 #11995] Add group install to Package
Issue #11995 has been updated by Charlie Wyse.
That is a very good point and explains why it wasn't in there yet. Some code
around doing a yum groupinfo %= GROUP NAME % then searching for any
packages listed under Mandatory Packages. Finally using the regular rpm
check on each package listed would be necessary. So it is possible for a more
advanced ruby programmer than I. Currently I'm just using an exec string to
get the job done, or I guess since 'MRG Grid' only needs 3 packages I could
make there separate package lines. But this feature would be very helpful to
many admins that would like to have a desktop class that installs 'GNOME
Desktop' or in my case a server group that needs MRG.
Bug #11995: Add group install to Package
https://projects.puppetlabs.com/issues/11995
Author: Charlie Wyse
Status: Unreviewed
Priority: Normal
Assignee:
Category:
Target version:
Affected Puppet version:
Keywords:
Branch: puppet-2.6.12-1
This is my first ticket so if I do anything wrong let me know. When trying to
install a package group in Red Hat 6, I get a failure. I don't think puppet
understands package groups. Could this be added to the package feature?
My manifest:
package { 'MRG Grid':
ensure = present,
}
Error:
err: /Stage[main]/Mrg/Package[MRG Grid]/ensure: change from absent to present
failed: Execution of '/usr/bin/yum -d 0 -e 0 -y install MRG Grid' returned 1:
Error: Nothing to do
If the package could have a command to encapsulate anything in the naming list
like 'MRG Grid' and change install to groupinstall, this should do the trick.
Example:
'/usr/bin/yum -d 0 -e 0 -y groupinstall MRG Grid'
Anyhow, as I said this is my first ticket so let me know what I can do to help
move this along without any helpful knowledge in ruby programming.
--
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 - Refactor #10309] (Closed) Standardize fixture handling using Puppets methodology
Issue #10309 has been updated by Matthaus Litteken. Status changed from Merged - Pending Release to Closed Released in Facter 1.6.5rc1 Refactor #10309: Standardize fixture handling using Puppets methodology https://projects.puppetlabs.com/issues/10309 Author: Ken Barber Status: Closed Priority: Low Assignee: Category: testing Target version: 1.6.5 Keywords: fixtures, rspec Branch: Affected Facter version: It was suggested by dpittman that we could use the fixture handling framework in Puppet: https://github.com/puppetlabs/puppet/blob/master/spec/lib/puppet_spec/fixtures.rb It would be nice to standardize the way we handle this - and also move our fixture data into the same place instead of having 2 locations. -- 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 #11196] (Closed) EC2 facts do not get created when the arp table contains more than 1 entry (patch included)
Issue #11196 has been updated by Matthaus Litteken. Status changed from Merged - Pending Release to Closed Released in 1.6.5rc1 Bug #11196: EC2 facts do not get created when the arp table contains more than 1 entry (patch included) https://projects.puppetlabs.com/issues/11196 Author: Pieter Lexis Status: Closed Priority: Normal Assignee: Category: library Target version: 1.6.5 Keywords: ec2 arp Branch: Affected Facter version: 1.6.3 We have an EC2 instance with a QEMU vm on it (don't ask, we cried as well when this was the only solution). This means that we have a bridge interface on the EC2 instance and that the arp table contains more than 1 entry (on EC2 the only entry is the gateway). The code in the arp module does not take this into account. Than the ec2 code infers that this isn't an ec2 instance (and doesn't create the ec2 facts), but it is. If you would be running a VPN service on EC2, this bug could hit you as well (as you have more than 1 interface). This patch fixes that. Pull request follows. -- 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 #11328] (Closed) Provide OpenBSD Facter support for uptime virtual facts
Issue #11328 has been updated by Matthaus Litteken. Status changed from Merged - Pending Release to Closed Released in 1.6.5rc1 Feature #11328: Provide OpenBSD Facter support for uptime virtual facts https://projects.puppetlabs.com/issues/11328 Author: Matt Dainty Status: Closed Priority: Normal Assignee: Category: library Target version: 1.6.5 Keywords: openbsd, virtual, uptime Branch: https://github.com/puppetlabs/facter/pull/112 Affected Facter version: 1.6.0 Facter seems to lack virtualisation uptime facts on OpenBSD. -- 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 #11436] (Closed) The total amount of memory uses a different fact on the Mac than on Linux
Issue #11436 has been updated by Matthaus Litteken. Status changed from Merged - Pending Release to Closed Released in 1.6.5rc1 Bug #11436: The total amount of memory uses a different fact on the Mac than on Linux https://projects.puppetlabs.com/issues/11436 Author: Nick Fagerlund Status: Closed Priority: Normal Assignee: Adrien Thebo Category: Target version: 1.6.5 Keywords: Branch: https://github.com/puppetlabs/facter/pull/118 Affected Facter version: In issue #11086, we got bitten by the fact that the total memory for a Mac is in the `memorytotal` fact, and the total memory for a Linux box is in `memorysize`. It seems like these should be unified. -- 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/158 -- 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 #11559] (Closed) Use RbConfig instead of obsolete and deprecated Config.
Issue #11559 has been updated by Matthaus Litteken. Status changed from Merged - Pending Release to Closed Released in 1.6.5rc1 Bug #11559: Use RbConfig instead of obsolete and deprecated Config. https://projects.puppetlabs.com/issues/11559 Author: James Gifford Status: Closed Priority: Normal Assignee: Category: installation Target version: 1.6.5 Keywords: Branch: https://github.com/puppetlabs/facter/pull/142 Affected Facter version: 1.6.4 System: Ubuntu 11.10 64 bit Ruby version: ruby 1.9.3p0 When I attempt to do anything with the gem, I get the following error: Use RbConfig instead of obsolete and deprecated Config. -- 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 #11566] (Closed) Windows EC2 meta data support
Issue #11566 has been updated by Matthaus Litteken. Status changed from Merged - Pending Release to Closed Released in 1.6.5rc1 Feature #11566: Windows EC2 meta data support https://projects.puppetlabs.com/issues/11566 Author: Feifei Jia Status: Closed Priority: Immediate Assignee: Ken Barber Category: library Target version: 1.6.5 Keywords: Branch: https://github.com/puppetlabs/facter/pull/140 Affected Facter version: Hi, I sent a pull request to support this feature, the link is here: https://github.com/puppetlabs/facter/pull/125 Any feedback welcomed, thanks. -- 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/159 -- 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/160 -- 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/161 -- 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/162 -- 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 #11201] (Closed) Add a rake task to build Apple Packages
Issue #11201 has been updated by Matthaus Litteken. Status changed from Merged - Pending Release to Closed Released in 1.6.5rc1 Feature #11201: Add a rake task to build Apple Packages https://projects.puppetlabs.com/issues/11201 Author: Gary Larizza Status: Closed Priority: Normal Assignee: Gary Larizza Category: installation Target version: 1.6.5 Keywords: Branch: https://github.com/glarizza/facter/tree/feature/master/Rakefile_DMG Affected Facter version: To help out the Release Team, a rake action is needed to allow for the creation of Apple packages for Facter. -- 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 #9789] (Closed) Improved test coverage for operatingsystem
Issue #9789 has been updated by Matthaus Litteken. Status changed from Merged - Pending Release to Closed Released in 1.6.5rc1 Feature #9789: Improved test coverage for operatingsystem https://projects.puppetlabs.com/issues/9789 Author: Adrien Thebo Status: Closed Priority: Normal Assignee: Adrien Thebo Category: testing Target version: 1.6.5 Keywords: Branch: https://github.com/adrienthebo/facter/tree/ticket/1.6.x/9789-add_operatingsystem_specs Affected Facter version: We do a ton of work in the operatingsystem fact, but we have zero test coverage. Some decent test coverage would be very nice. -- 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 - Refactor #9708] (Closed) Remove redundancy from operatingsystem confines
Issue #9708 has been updated by Matthaus Litteken.
Status changed from Merged - Pending Release to Closed
Released in 1.6.5rc1
Refactor #9708: Remove redundancy from operatingsystem confines
https://projects.puppetlabs.com/issues/9708
Author: Adrien Thebo
Status: Closed
Priority: Normal
Assignee: Ken Barber
Category: library
Target version: 1.6.5
Keywords:
Branch: https://github.com/kbarber/facter/tree/ticket/1.6.x/9708-os_confines
Affected Facter version:
There are instances inside facter that that look like this
pre
confine :operatingsystem = %w{Solaris Linux Fedora RedHat CentOS Scientific
SuSE SLES Debian Ubuntu Gentoo FreeBSD OpenBSD NetBSD OEL OVS GNU/kFreeBSD}
/pre
Which should be written more cleanly as
pre
confine :kernel = %w{SunOS Linux FreeBSD OpenBSD NetBSD GNU/kFreeBSD}
/pre
/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 #9599] (Closed) Add Nexenta to operatingsystem fact
Issue #9599 has been updated by Matthaus Litteken. Status changed from Merged - Pending Release to Closed Released in 1.6.5rc1 Feature #9599: Add Nexenta to operatingsystem fact https://projects.puppetlabs.com/issues/9599 Author: Jonathan Boyett Status: Closed Priority: Normal Assignee: Adrien Thebo Category: library Target version: 1.6.5 Keywords: Branch: https://github.com/adrienthebo/facter/tree/ticket/1.6.x/9599-nexenta_operatingsystem Affected Facter version: Just a simple change to add Nexenta support. The commit can be found [here](https://github.com/saysjonathan/facter/commit/be7445ab77ff6c76ffce32fe0f54cdf3779ea047) -- 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 #8279] (Closed) ec2_security_groups concatenates multiple groups instead of separating by a comma
Issue #8279 has been updated by Matthaus Litteken. Status changed from Merged - Pending Release to Closed Released in 1.6.5rc1 Bug #8279: ec2_security_groups concatenates multiple groups instead of separating by a comma https://projects.puppetlabs.com/issues/8279 Author: Michael Halligan Status: Closed Priority: Normal Assignee: Adrien Thebo Category: library Target version: 1.6.5 Keywords: Branch: https://github.com/adrienthebo/facter/tree/ticket/1.6.x/8279-ec2_join_facts_with_comma Affected Facter version: 1.6.0 When you run facter on an ec2 node, the ec2_security_groups fact joins all of the groups a node belongs to. Separating by a , or even a space would make this fact much easier to act on. -- 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 #7753] (Closed) Errors when adding a resolve should not crash facter
Issue #7753 has been updated by Matthaus Litteken. Status changed from Merged - Pending Release to Closed Released in 1.6.5rc1 Bug #7753: Errors when adding a resolve should not crash facter https://projects.puppetlabs.com/issues/7753 Author: Adrien Thebo Status: Closed Priority: Normal Assignee: Adrien Thebo Category: Target version: 1.6.5 Keywords: Branch: https://github.com/puppetlabs/facter/pull/116 Affected Facter version: As evidenced by #7038, if an exception is thrown when adding a resolve to a fact, facter crashes. Instead of just failing, facter should catch any errors when adding a resolution to a fact and then discard the failed resolution. -- 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 #11848] (Closed) facter.bat cannot be relocated on Windows
Issue #11848 has been updated by Matthaus Litteken. Status changed from Merged - Pending Release to Closed Released in 1.6.5rc1 Bug #11848: facter.bat cannot be relocated on Windows https://projects.puppetlabs.com/issues/11848 Author: Josh Cooper Status: Closed Priority: Normal Assignee: Josh Cooper Category: installation Target version: 1.6.5 Keywords: Branch: https://github.com/puppetlabs/facter/pull/141 Affected Facter version: Facter's `install.rb` script creates wrapper batch scripts in ruby's bin directory. The batch file contains full paths to where it was installed and its current working directory. This makes it impossible to move the ruby directory (and the script) and have the script still work. The preferred way of doing this on Windows is to use `%~dp0`, which is dynamically set to the full path of the directory that contains the script, i.e. what is currently `C:\Ruby187\bin` -- 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 #11661] (Closed) ec2 tests use 'throws' instead of 'raises' for timeout emulation
Issue #11661 has been updated by Matthaus Litteken. Status changed from Merged - Pending Release to Closed Released in 1.6.5rc1 Bug #11661: ec2 tests use 'throws' instead of 'raises' for timeout emulation https://projects.puppetlabs.com/issues/11661 Author: Ken Barber Status: Closed Priority: Normal Assignee: Category: testing Target version: 1.6.5 Keywords: Branch: Affected Facter version: So #11583 had a mistake in the timeout emulation tests. Instead of using 'throws' I should have used 'raises'. -- 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 #11583] (Closed) ec2 fact has no unit tests
Issue #11583 has been updated by Matthaus Litteken. Status changed from Merged - Pending Release to Closed Released in 1.6.5rc1 Bug #11583: ec2 fact has no unit tests https://projects.puppetlabs.com/issues/11583 Author: Ken Barber Status: Closed Priority: Normal Assignee: Ken Barber Category: library Target version: 1.6.5 Keywords: rspec Branch: https://github.com/kbarber/facter/tree/ticket/1.6.x/11583-ec2_tests Affected Facter version: There are no unit tests for the EC2 fact. We need to fix this now I think, since we are taking changes on it recently. -- 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 #10271] (Closed) Amazon Linux operatingsytem and operatingsystemrelease and osfamily facts do not work
Issue #10271 has been updated by Matthaus Litteken. Status changed from Merged - Pending Release to Closed Released in 1.6.5rc1 Bug #10271: Amazon Linux operatingsytem and operatingsystemrelease and osfamily facts do not work https://projects.puppetlabs.com/issues/10271 Author: Dan Bode Status: Closed Priority: Normal Assignee: Marcus Ferreira Category: library Target version: 1.6.5 Keywords: amazonlinux Branch: Affected Facter version: 1.6.4 I am using the latest AMI (ami-7f418316) for Amazon Linux and it has no /etc/redhat-release In the documentation (http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/index.html?LinuxAMIUserGuide.html) it states that /etc/system-release should be used to determine current release: pre Amazon linux AMIs contain a /etc/system-release file that specifies the current release that is installed. This file is updated through yum and is part of the system-release rpm. Following is an example of /etc/system-release file: # cat /etc/system-release Amazon Linux AMI release 2011.09 An Amazon Linux AMI also contains a machine readable version of the /etc/system-release file found in /etc/system-release-cpe and follows the CPE specification from MITRE (CPE). /pre pre # cat /etc/system-release Amazon Linux AMI release 2011.09 /pre It looks like release version is 2011.09, I am not sure how to map that to rhel5/rhel6 -- 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/163 -- 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 #11220] execute bits for directories are not being added
Issue #11220 has been updated by Garrett Honeycutt.
This is a dupe of #10269
Bug #11220: execute bits for directories are not being added
https://projects.puppetlabs.com/issues/11220
Author: Garrett Honeycutt
Status: Duplicate
Priority: Normal
Assignee:
Category:
Target version:
Affected Puppet version: 2.7.6
Keywords:
Branch:
This is shown using Puppet Enterprise 2.0 (2.7.6). The following code should
create /tmp/defaults as a directory with mode 0755 and two files
/tmp/defaults/[hello,goodbye] with mode 0644.
pre
File {
owner = 'root',
group = 'root',
mode = '0644',
}
file { '/tmp/defaults':
ensure = directory,
}
file { '/tmp/defaults/hello':
content = hello\n,
}
file { '/tmp/defaults/goodbye':
content = goodbye\n,
}
/pre
Upon using PE 2.0 the following behavior is observed, which is incorrect.
Here are two puppet agent runs done back to back. Notice it takes two runs and
that on the first run /tmp/defaults has mode 0644.
pre
[root@puppet manifests]# puppet apply -v resource_defaults.pp
info: Loading facts in facter_dot_d
info: Loading facts in facter_dot_d
info: Applying configuration version '1323209170'
notice: /Stage[main]//File[/tmp/defaults]/ensure: created
notice: /Stage[main]//File[/tmp/defaults/hello]/ensure: defined content as
'{md5}b1946ac92492d2347c6235b4d2611184'
notice: /Stage[main]//File[/tmp/defaults/goodbye]/ensure: defined content as
'{md5}32d6c11747e03715521007d8c84b5aff'
notice: Finished catalog run in 0.06 seconds
[root@puppet manifests]# puppet apply -v resource_defaults.pp
info: Loading facts in facter_dot_d
info: Loading facts in facter_dot_d
info: Applying configuration version '1323209175'
notice: /Stage[main]//File[/tmp/defaults]/mode: mode changed '644' to '755'
/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 Matthaus Litteken. Downloading Puppet: https://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet View differences: https://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet/diff/137 -- 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 #11968] Errors from Exec resources when source param of a File resource is a softlink
Issue #11968 has been updated by Stefan Schulte.
Hi Steve,
can you please paste your exec resource `Exec['etc-services-nrpe]`? And does
`etc/puppet/dev/modules/nrpe/manifests/init.pp:92` reference to your file or to
your exec resource?
Bug #11968: Errors from Exec resources when source param of a File resource is
a softlink
https://projects.puppetlabs.com/issues/11968
Author: Steve Shipway
Status: Unreviewed
Priority: Normal
Assignee:
Category: file
Target version:
Affected Puppet version: 2.7.6
Keywords:
Branch:
If the location pointed to by source= in a file{} resource is a softlink, and
you do not have links=follow, then you get some wierd errors relating to
getcwd appearing. This is understandable but it should probably give a more
helpful error message.
I have reliably duplicated this with
file { /usr/local/nrpe:
ensure=present, replace=yes, recurse=true, recurselimit=2,
backup=false, force=true,
ignore='.svn',
owner=root, group=root, mode=0755,
sourceselect=all,
source=[
puppet:///modules/nrpe/plugins/$operatingsystem.$architecture,
],
}
If the puppet: link points to a softlink you get all the Exec errors about
getcwd. Replacing with a real directory, or using links=follow, and all is OK.
err: /Stage[main]/Nrpe/File[/usr/local/nrpe]/ensure: change from directory
to link failed: Could not set 'link on ensure:
No such file or directory - getcwd at
/etc/puppet/dev/modules/nrpe/manifests/init.pp:92
err: /Stage[main]/Nrpe/Exec[etc-services-nrpe]: Could not evaluate: No such
file or directory - getcwd
All the additional errors are with Exec resources.
--
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 Matthaus Litteken. Wiki: https://projects.puppetlabs.com/projects/facter/wiki/Wiki View differences: https://projects.puppetlabs.com/projects/facter/wiki/Wiki/diff/26 -- 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 #10962] (Merged - Pending Release) The pw user provider on FreeBSD doesn't respect managehome when changing a user's a home directory
Issue #10962 has been updated by Patrick Carlisle. Status changed from In Topic Branch Pending Review to Merged - Pending Release Target version set to 2.7.10 Merged in https://github.com/puppetlabs/puppet/commit/75d7cad19be95760bc08e2ce4a67208aec5c6af7 Bug #10962: The pw user provider on FreeBSD doesn't respect managehome when changing a user's a home directory https://projects.puppetlabs.com/issues/10962 Author: Tim Bishop Status: Merged - Pending Release Priority: Normal Assignee: Category: FreeBSD Target version: 2.7.10 Affected Puppet version: 2.7.6 Keywords: Branch: https://github.com/puppetlabs/puppet/pull/210 *Please note the pull request referenced on this issue includes more than just this change* When a user's home directory is changed using the pw user provider the executed command is: pre pw usermod [name] -d [home] /pre If managehome is set to true the `-m` flag should also be given. This happens correctly at create time but not if the home directory is changed on an existing resource. As an aside, the behaviour of `-m` on an existing user is to create the new home directory, assuming it doesn't already exist, in the same way it would when creating a new user. I've produced a fix for this issue (on a branch with a bunch of other related FreeBSD pw improvements): https://github.com/tdb/puppet/commit/ec452a8f1932ab8ce41e460f83ca8782016328aa With this fix applied the command executed would be: pre pw usermod [name] -d [home] -m /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 #7500] (Merged - Pending Release) Don't let pw provider use -p
Issue #7500 has been updated by Patrick Carlisle. Status changed from In Topic Branch Pending Review to Merged - Pending Release Target version set to 2.7.10 Merged in https://github.com/puppetlabs/puppet/commit/75d7cad19be95760bc08e2ce4a67208aec5c6af7 Bug #7500: Don't let pw provider use -p https://projects.puppetlabs.com/issues/7500 Author: Douglas Rand Status: Merged - Pending Release Priority: Normal Assignee: Douglas Rand Category: FreeBSD Target version: 2.7.10 Affected Puppet version: 2.6.7 Keywords: freebsd pw password Branch: The -p option to pw is documented as: pre -p date Set the account's password expiration date. This field is similar to the account expiration date option, except that it applies to forced password changes. This is set in the same manner as the -e option. /pre But provider/user/pw.rb takes the first character of each property as the option to pw (through provider/nameservice/objectadd.rb I think). The problem is that that sets the password as expiring now(). Here is a patch to ignore the password property, which is already handled via cryptpw in pw.rb: pre --- pw.rb-orig 2011-05-12 16:47:24.0 -0500 +++ pw.rb 2011-05-12 16:47:16.0 -0500 @@ -24,7 +24,7 @@ def addcmd cmd = [command(:pw), useradd, @resource[:name]] @resource.class.validproperties.each do |property| - next if property == :ensure + next if property == :ensure or property == :password # the value needs to be quoted, mostly because -c might # have spaces in it if value = @resource.should(property) and value != /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 - Feature #11318] (Merged - Pending Release) [Patch] Add the manages_passwords feature for users on FreeBSD
Issue #11318 has been updated by Patrick Carlisle. Status changed from In Topic Branch Pending Review to Merged - Pending Release Target version set to 2.7.10 Merged in https://github.com/puppetlabs/puppet/commit/75d7cad19be95760bc08e2ce4a67208aec5c6af7 Feature #11318: [Patch] Add the manages_passwords feature for users on FreeBSD https://projects.puppetlabs.com/issues/11318 Author: Brad Davis Status: Merged - Pending Release Priority: Normal Assignee: Category: FreeBSD Target version: 2.7.10 Affected Puppet version: Keywords: FreeBSD pw manages_passwords user Branch: https://github.com/puppetlabs/puppet/pull/264 Hi, A friend of mine wrote up a patch to implement manages_passwords on FreeBSD. The Pull request is here: https://github.com/puppetlabs/puppet/pull/264 -- 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 #11845] exec's as non-root user execute with a mixed environment
Issue #11845 has been updated by Daniel Pittman.
Description updated
Bug #11845: exec's as non-root user execute with a mixed environment
https://projects.puppetlabs.com/issues/11845
Author: Chris MacLeod
Status: Investigating
Priority: Normal
Assignee: Daniel Pittman
Category: exec
Target version:
Affected Puppet version: 2.7.9
Keywords:
Branch:
Given the following exec type you would expect it to run as the defined user
with a correctly set environment (or at least a sanitized one).
pre
exec { 'test-cmd':
command = 'env',
path = [ '/bin', '/usr/bin', '/usr/local/bin' ],
logoutput = 'true',
user = 'testuser',
}
/pre
In reality what you get is:
pre
debug: Exec[test-cmd](provider=posix): Executing '/bin/env'
debug: Executing '/bin/env'
notice: /Stage[main]//Exec[test-cmd]/returns: HOSTNAME=vm02.X.com
notice: /Stage[main]//Exec[test-cmd]/returns: TERM=screen
notice: /Stage[main]//Exec[test-cmd]/returns: SHELL=/bin/bash
notice: /Stage[main]//Exec[test-cmd]/returns: HISTSIZE=1000
notice: /Stage[main]//Exec[test-cmd]/returns: SSH_CLIENT=172.17.2.137 62498 22
notice: /Stage[main]//Exec[test-cmd]/returns: SSH_TTY=/dev/pts/0
notice: /Stage[main]//Exec[test-cmd]/returns: USER=root
notice: /Stage[main]//Exec[test-cmd]/returns:
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=01;05;37;41:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.tbz=01;31:*.tbz2=01;31:*.bz=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=01;36:*.au=01;36:*.flac=01;36:*.mid=01;36:*.midi=01;36:*.mka=01;36:*.mp3=01;36:*.mpc=01;36:*.ogg=01;36:*.ra=01;36:*.wav=01;36:*.axa=01;36:*.oga=01;36:*.spx=01;36:*.xspf=01;36:
notice: /Stage[main]//Exec[test-cmd]/returns:
SSH_AUTH_SOCK=/tmp/ssh-QorKX31223/agent.31223
notice: /Stage[main]//Exec[test-cmd]/returns: COBBLER_SERVER=10.4.0.210
notice: /Stage[main]//Exec[test-cmd]/returns: MAIL=/var/spool/mail/root
notice: /Stage[main]//Exec[test-cmd]/returns:
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/scala/bin:/root/bin
notice: /Stage[main]//Exec[test-cmd]/returns: PWD=/root
notice: /Stage[main]//Exec[test-cmd]/returns: LANG=C
notice: /Stage[main]//Exec[test-cmd]/returns: HISTCONTROL=ignoredups
notice: /Stage[main]//Exec[test-cmd]/returns: SHLVL=1
notice: /Stage[main]//Exec[test-cmd]/returns: HOME=/root
notice: /Stage[main]//Exec[test-cmd]/returns: LOGNAME=root
notice: /Stage[main]//Exec[test-cmd]/returns: CVS_RSH=ssh
notice: /Stage[main]//Exec[test-cmd]/returns: SSH_CONNECTION=XX 62498
X 22
notice: /Stage[main]//Exec[test-cmd]/returns: LESSOPEN=|/usr/bin/lesspipe.sh %s
notice: /Stage[main]//Exec[test-cmd]/returns: SCALA_HOME=/usr/local/scala
notice: /Stage[main]//Exec[test-cmd]/returns: G_BROKEN_FILENAMES=1
notice: /Stage[main]//Exec[test-cmd]/returns: _=/usr/bin/puppet
notice: /Stage[main]//Exec[test-cmd]/returns: OLDPWD=/root
notice: /Stage[main]//Exec[test-cmd]/returns: LANGUAGE=C
notice: /Stage[main]//Exec[test-cmd]/returns: LC_MESSAGES=C
notice: /Stage[main]//Exec[test-cmd]/returns: LC_ALL=C
notice: /Stage[main]//Exec[test-cmd]/returns: executed successfully
/pre
Contrast this with the following exec
pre
exec { 'test-cmd2':
command = 'id',
path = [ '/bin', '/usr/bin', '/usr/local/bin' ],
logoutput = 'true',
user = 'testuser',
}
/pre
The output looks as follows:
pre
debug: Exec[test-cmd](provider=posix): Executing '/usr/bin/id'
debug: Executing '/usr/bin/id'
notice: /Stage[main]//Exec[test-cmd]/returns: uid=500(testuser)
gid=501(testuser)
groups=501(testuser),0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
notice: /Stage[main]//Exec[test-cmd]/returns: executed successfully
/pre
What's additionally interesting is that the environment is a mix, you have all
the groups of the root user in addition to the groups of the target user.
Some executions this doesn't bother, but others interpret the environment as
root's environment rather than the user in question, which could have
potentially harmful side effects when commands are intended to run as an
unprivileged user.
[Puppet - Bug #11968] Errors from Exec resources when source param of a File resource is a softlink
Issue #11968 has been updated by Steve Shipway.
exec { etc-services-nrpe:
command=echo 'nrpe5666/tcpnagios netsaint'
/etc/services,
unless=/bin/egrep -i '^nrpe' /etc/services 2/dev/null,
user='root', timeout=4, cwd=/etc,
path = /usr/bin:/usr/sbin:/bin:/sbin
}
The path you mention, /etc/puppet/dev/modules/nrpe/manifests/init.pp is the
file containing the exec resource (in the 'nrpe' class). It would probably be
more elegant to create a 'services' define to control the /etc/services file
but we only need it for this one case...
Bug #11968: Errors from Exec resources when source param of a File resource is
a softlink
https://projects.puppetlabs.com/issues/11968
Author: Steve Shipway
Status: Unreviewed
Priority: Normal
Assignee:
Category: file
Target version:
Affected Puppet version: 2.7.6
Keywords:
Branch:
If the location pointed to by source= in a file{} resource is a softlink, and
you do not have links=follow, then you get some wierd errors relating to
getcwd appearing. This is understandable but it should probably give a more
helpful error message.
I have reliably duplicated this with
file { /usr/local/nrpe:
ensure=present, replace=yes, recurse=true, recurselimit=2,
backup=false, force=true,
ignore='.svn',
owner=root, group=root, mode=0755,
sourceselect=all,
source=[
puppet:///modules/nrpe/plugins/$operatingsystem.$architecture,
],
}
If the puppet: link points to a softlink you get all the Exec errors about
getcwd. Replacing with a real directory, or using links=follow, and all is OK.
err: /Stage[main]/Nrpe/File[/usr/local/nrpe]/ensure: change from directory
to link failed: Could not set 'link on ensure:
No such file or directory - getcwd at
/etc/puppet/dev/modules/nrpe/manifests/init.pp:92
err: /Stage[main]/Nrpe/Exec[etc-services-nrpe]: Could not evaluate: No such
file or directory - getcwd
All the additional errors are with Exec resources.
--
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 #11845] (Duplicate) exec's as non-root user execute with a mixed environment
Issue #11845 has been updated by Daniel Pittman.
Status changed from Investigating to Duplicate
I found the duplicate, #5224, and have linked the two tickets together.
Bug #11845: exec's as non-root user execute with a mixed environment
https://projects.puppetlabs.com/issues/11845
Author: Chris MacLeod
Status: Duplicate
Priority: Normal
Assignee: Daniel Pittman
Category: exec
Target version:
Affected Puppet version: 2.7.9
Keywords:
Branch:
Given the following exec type you would expect it to run as the defined user
with a correctly set environment (or at least a sanitized one).
pre
exec { 'test-cmd':
command = 'env',
path = [ '/bin', '/usr/bin', '/usr/local/bin' ],
logoutput = 'true',
user = 'testuser',
}
/pre
In reality what you get is:
pre
debug: Exec[test-cmd](provider=posix): Executing '/bin/env'
debug: Executing '/bin/env'
notice: /Stage[main]//Exec[test-cmd]/returns: HOSTNAME=vm02.X.com
notice: /Stage[main]//Exec[test-cmd]/returns: TERM=screen
notice: /Stage[main]//Exec[test-cmd]/returns: SHELL=/bin/bash
notice: /Stage[main]//Exec[test-cmd]/returns: HISTSIZE=1000
notice: /Stage[main]//Exec[test-cmd]/returns: SSH_CLIENT=172.17.2.137 62498 22
notice: /Stage[main]//Exec[test-cmd]/returns: SSH_TTY=/dev/pts/0
notice: /Stage[main]//Exec[test-cmd]/returns: USER=root
notice: /Stage[main]//Exec[test-cmd]/returns:
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=01;05;37;41:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.tbz=01;31:*.tbz2=01;31:*.bz=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=01;36:*.au=01;36:*.flac=01;36:*.mid=01;36:*.midi=01;36:*.mka=01;36:*.mp3=01;36:*.mpc=01;36:*.ogg=01;36:*.ra=01;36:*.wav=01;36:*.axa=01;36:*.oga=01;36:*.spx=01;36:*.xspf=01;36:
notice: /Stage[main]//Exec[test-cmd]/returns:
SSH_AUTH_SOCK=/tmp/ssh-QorKX31223/agent.31223
notice: /Stage[main]//Exec[test-cmd]/returns: COBBLER_SERVER=10.4.0.210
notice: /Stage[main]//Exec[test-cmd]/returns: MAIL=/var/spool/mail/root
notice: /Stage[main]//Exec[test-cmd]/returns:
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/scala/bin:/root/bin
notice: /Stage[main]//Exec[test-cmd]/returns: PWD=/root
notice: /Stage[main]//Exec[test-cmd]/returns: LANG=C
notice: /Stage[main]//Exec[test-cmd]/returns: HISTCONTROL=ignoredups
notice: /Stage[main]//Exec[test-cmd]/returns: SHLVL=1
notice: /Stage[main]//Exec[test-cmd]/returns: HOME=/root
notice: /Stage[main]//Exec[test-cmd]/returns: LOGNAME=root
notice: /Stage[main]//Exec[test-cmd]/returns: CVS_RSH=ssh
notice: /Stage[main]//Exec[test-cmd]/returns: SSH_CONNECTION=XX 62498
X 22
notice: /Stage[main]//Exec[test-cmd]/returns: LESSOPEN=|/usr/bin/lesspipe.sh %s
notice: /Stage[main]//Exec[test-cmd]/returns: SCALA_HOME=/usr/local/scala
notice: /Stage[main]//Exec[test-cmd]/returns: G_BROKEN_FILENAMES=1
notice: /Stage[main]//Exec[test-cmd]/returns: _=/usr/bin/puppet
notice: /Stage[main]//Exec[test-cmd]/returns: OLDPWD=/root
notice: /Stage[main]//Exec[test-cmd]/returns: LANGUAGE=C
notice: /Stage[main]//Exec[test-cmd]/returns: LC_MESSAGES=C
notice: /Stage[main]//Exec[test-cmd]/returns: LC_ALL=C
notice: /Stage[main]//Exec[test-cmd]/returns: executed successfully
/pre
Contrast this with the following exec
pre
exec { 'test-cmd2':
command = 'id',
path = [ '/bin', '/usr/bin', '/usr/local/bin' ],
logoutput = 'true',
user = 'testuser',
}
/pre
The output looks as follows:
pre
debug: Exec[test-cmd](provider=posix): Executing '/usr/bin/id'
debug: Executing '/usr/bin/id'
notice: /Stage[main]//Exec[test-cmd]/returns: uid=500(testuser)
gid=501(testuser)
groups=501(testuser),0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
notice: /Stage[main]//Exec[test-cmd]/returns: executed successfully
/pre
What's additionally interesting is that the environment is a mix, you have all
the groups of the root user in addition to the groups of the target user.
Some executions this doesn't bother, but others interpret the environment as
root's environment rather than the user in question, which could have
[Puppet - Bug #11968] Errors from Exec resources when source param of a File resource is a softlink
Issue #11968 has been updated by Steve Shipway.
Sorry, to be more clear: both the file and exec resources above are in this
same .pp file. I can't remember if other exec resources were also affected by
this bug but I think there were as I remember a rather large number of exec
errors being produced.
Bug #11968: Errors from Exec resources when source param of a File resource is
a softlink
https://projects.puppetlabs.com/issues/11968
Author: Steve Shipway
Status: Unreviewed
Priority: Normal
Assignee:
Category: file
Target version:
Affected Puppet version: 2.7.6
Keywords:
Branch:
If the location pointed to by source= in a file{} resource is a softlink, and
you do not have links=follow, then you get some wierd errors relating to
getcwd appearing. This is understandable but it should probably give a more
helpful error message.
I have reliably duplicated this with
file { /usr/local/nrpe:
ensure=present, replace=yes, recurse=true, recurselimit=2,
backup=false, force=true,
ignore='.svn',
owner=root, group=root, mode=0755,
sourceselect=all,
source=[
puppet:///modules/nrpe/plugins/$operatingsystem.$architecture,
],
}
If the puppet: link points to a softlink you get all the Exec errors about
getcwd. Replacing with a real directory, or using links=follow, and all is OK.
err: /Stage[main]/Nrpe/File[/usr/local/nrpe]/ensure: change from directory
to link failed: Could not set 'link on ensure:
No such file or directory - getcwd at
/etc/puppet/dev/modules/nrpe/manifests/init.pp:92
err: /Stage[main]/Nrpe/Exec[etc-services-nrpe]: Could not evaluate: No such
file or directory - getcwd
All the additional errors are with Exec resources.
--
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 #5224] puppetd does not set environment correctly from Exec
Issue #5224 has been updated by Chris Price. Assignee changed from Daniel Pittman to Chris Price Bug #5224: puppetd does not set environment correctly from Exec https://projects.puppetlabs.com/issues/5224 Author: Simon Mudd Status: Accepted Priority: High Assignee: Chris Price Category: exec Target version: Affected Puppet version: 0.25.5 Keywords: exec,crontab,service,environment,HOME Branch: It's possible to run a script using Exec. This can sometimes cause confusion if the environment is not set correctly. It's not terribly clear to me exactly what environment the user should expect when running Exec. This should be better documented if nothing else. In any case I see on a box we use to run puppet: # ps auwx | grep puppetd root 25736 0.1 0.1 173072 78728 ?Ssl 04:02 0:52 /usr/bin/ruby /usr/sbin/puppetd --logdest=/var/log/puppet/puppetd.log root 30268 0.0 0.0 61148 756 pts/0S+ 14:11 0:00 grep puppetd # strings /proc/25736/environ SHELL=/bin/bash MAILTO=root USER=root PATH=/sbin:/usr/sbin:/bin:/usr/bin PWD=/ LANG=en_US.UTF-8 HOME=/ started at boot and HOME here is _not_ root's HOME directory. SHLVL=6 LOGNAME=root _=/usr/sbin/puppetd # Now if I restart puppet using service(5) or directly with /etc/init.d/puppet restart I get different results: ### Using service(5) # service puppet restart Stopping puppet: [ OK ] Starting puppet: [ OK ] # ps auwx | grep puppetd root 13089 1.8 0.0 128100 35264 ?Ssl 14:24 0:00 /usr/bin/ruby /usr/sbin/puppetd --logdest=/var/log/puppet/puppetd.log root 13158 0.0 0.0 61148 756 pts/0S+ 14:25 0:00 grep puppetd [root@bc29bprdb-01 ~]# strings /proc/13089/environ TERM=xterm-color PATH=/sbin:/usr/sbin:/bin:/usr/bin PWD=/ LANG=en_US.UTF-8 SHLVL=2 _=/usr/sbin/puppetd # cat /etc/redhat-release CentOS release 5.4 (Final) ### Using /etc/init.d/puppet # /etc/init.d/puppet restart Stopping puppet: [ OK ] Starting puppet: [ OK ] # ps auwx | grep puppetd root 14328 3.0 0.0 128108 35272 ?Ssl 14:26 0:00 /usr/bin/ruby /usr/sbin/puppetd --logdest=/var/log/puppet/puppetd.log root 14808 0.0 0.0 61148 752 pts/0S+ 14:26 0:00 grep puppetd [root@bc29bprdb-01 ~]# strings /proc/14328/environ HOSTNAME=x.xxx.com TERM=xterm-color SHELL=/bin/bash HISTSIZE=1000 SSH_CLIENT=10.111.22.33 38508 22 SSH_TTY=/dev/pts/0 USER=root LS_COLORS=no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:ex=01;32:*.cmd=01;32:*.exe=01;32:*.com=01;32:*.btm=01;32:*.bat=01;32:*.sh=01;32:*.csh=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.bz2=01;31:*.bz=01;31:*.tz=01;31:*.rpm=01;31:*.cpio=01;31:*.jpg=01;35:*.gif=01;35:*.bmp=01;35:*.xbm=01;35:*.xpm=01;35:*.png=01;35:*.tif=01;35: SSH_AUTH_SOCK=/tmp/ssh-GrzGm30026/agent.30026 MAIL=/var/spool/mail/root PATH=/sbin:/usr/sbin:/bin:/usr/bin INPUTRC=/etc/inputrc PWD=/root LANG=en_US.UTF-8 SHLVL=3 HOME=/root LOGNAME=root SSH_CONNECTION= LESSOPEN=|/usr/bin/lesspipe.sh %s G_BROKEN_FILENAMES=1 _=/usr/sbin/puppetd # This box runs CentOS Linux and root's home directory is /root. The end result is that the environment may vary quite considerably depending on the precise puppetd innovation. Looking at the service man page in Linux (RH's is a bit vague) or better still FreeBSD's which does the same you see it says: ENVIRONMENT When used to run rc.d scripts the service command sets HOME to / and PATH to /sbin:/bin:/usr/sbin:/usr/bin which is how they are set in /etc/rc at boot time. This makes sense as during startup the only filesystem and directory you can be sure to exist is /. I'd suggest that the environment is set prior to using Exec as follows being compatible with crontab(5): Several environment variables are set up automatically by the cron(8) daemon. SHELL is set to /bin/sh, PATH is set to /usr/bin:/bin, and LOGNAME and HOME are set from the /etc/passwd line of the crontab's owner. HOME, PATH and SHELL may be overridden by settings in the crontab; LOGNAME may not. (Another note: the LOGNAME variable is sometimes called USER on BSD sys- tems... On these systems, USER will be set also). This behaviour seems standard in Linux and the various BSD flavours. That is while you can't expect many environment variables to be set when running Exec you do expect $HOME to be set, $SHELL
[Puppet - Bug #11860] Puppet ovewriting the LANG environment variable.
Issue #11860 has been updated by Chris Price. Assignee set to Chris Price Bug #11860: Puppet ovewriting the LANG environment variable. https://projects.puppetlabs.com/issues/11860 Author: Marek Marek Status: Accepted Priority: Urgent Assignee: Chris Price Category: exec Target version: Telly Affected Puppet version: 2.7.0 Keywords: Branch: As far as I can see puppet is changing system's LANG environment variable - this causes unexpected bahaviour of applications that use this setting (as LANG is different when you run /etc/init.d/foo stop/start/restart, and different when service is restarted by puppet!). -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #11499] (Merged - Pending Release) validation code for puppet resource host does not properly check if ip is valid
Issue #11499 has been updated by Jeff McCune.
Status changed from In Topic Branch Pending Review to Merged - Pending Release
Target version set to 2.7.10
# Merged into 2.7.x #
Merged into 2.7.x as
https://github.com/puppetlabs/puppet/commit/c8f5cd6d1a43f07cabeba29940bb487c1c273953
From pull request: https://github.com/puppetlabs/puppet/pull/296
Bug #11499: validation code for puppet resource host does not properly check if
ip is valid
https://projects.puppetlabs.com/issues/11499
Author: Garrett Honeycutt
Status: Merged - Pending Release
Priority: Normal
Assignee: Daniel Pittman
Category: host
Target version: 2.7.10
Affected Puppet version: 2.7.6
Keywords:
Branch: https://github.com/puppetlabs/puppet/pull/296
It appears that we only check that the digits are [0-9] and period, while we
should be doing an actual IP check
Attempting to use a letter. Fails as expected.
pre
[root@puppet ~]# puppet resource host junk.tld ip=1.2.3.a ensure=present
Could not run: Parameter ip failed: Invalid IP address
/pre
Attempting to use a bad IP, which works and should not.
pre
[root@puppet ~]# puppet resource host junk.tld ip=10.10.10.10.10 ensure=present
notice: /Host[junk.tld]/ensure: created
host { 'junk.tld':
ensure = 'present',
ip = '10.10.10.10.10',
target = '/etc/hosts',
}
/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] 'Internal Development Process' wiki page has been updated
The 'Internal Development Process' wiki page has been updated by Daniel Pittman. Internal Development Process: https://projects.puppetlabs.com/projects/puppet/wiki/Internal_Development_Process View differences: https://projects.puppetlabs.com/projects/puppet/wiki/Internal_Development_Process/diff/88 -- 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] 'Engineering done done' wiki page has been updated
The 'Engineering done done' wiki page has been updated by Jeff McCune. Added hint to Jenkins and some post-push sanity checks. Engineering done done: https://projects.puppetlabs.com/projects/puppet/wiki/Engineering_done_done View differences: https://projects.puppetlabs.com/projects/puppet/wiki/Engineering_done_done/diff/12 -- 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/138 -- 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 #11057] (Merged - Pending Release) Better debugging output when skipping an agent/master run.
Issue #11057 has been updated by Jeff McCune. Status changed from In Topic Branch Pending Review to Merged - Pending Release Target version changed from 2.7.x to 2.7.10 # Merged into 2.7.x # Merged into 2.7.x as https://github.com/puppetlabs/puppet/commit/e78dc4cfa7c3eeaba9c1c5115c51c8738ac6d46b Build wasn't broken, tests added, ticket updated. Bug #11057: Better debugging output when skipping an agent/master run. https://projects.puppetlabs.com/issues/11057 Author: Daniel Pittman Status: Merged - Pending Release Priority: Normal Assignee: Daniel Pittman Category: agent Target version: 2.7.10 Affected Puppet version: Keywords: Branch: https://github.com/puppetlabs/puppet/pull/235 At the moment we will skip a run if the agent is waiting on a restart because of an external signal, etc. This is necessary because we have an inescapable race around signal handling in that regard. Unfortunately, it was very opaque: there was no information about *why* the restart was skipped. This becomes more important when something else goes wrong and the only diagnostics we have are that we are skipping the scheduled run. -- 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 #11888] Oracle keeps renaming their Linux version
Issue #11888 has been updated by Daniel Pittman. Target version changed from 2.7.10 to Telly This is remerged, targetted to telly, because raising the minimum version of Facter required in a stable series is not permitted. Bug #11888: Oracle keeps renaming their Linux version https://projects.puppetlabs.com/issues/11888 Author: James Turnbull Status: In Topic Branch Pending Review Priority: Normal Assignee: Daniel Pittman Category: provider Target version: Telly Affected Puppet version: Keywords: Branch: https://github.com/puppetlabs/puppet/pull/326 Everywhere in providers we cite OEL/OVM we also need to cite OracleLinux. -- 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] 'Engineering done done' wiki page has been updated
The 'Engineering done done' wiki page has been updated by Jeff McCune. Replaced old ticket status name with current ticket status name for merged pending release. Engineering done done: https://projects.puppetlabs.com/projects/puppet/wiki/Engineering_done_done View differences: https://projects.puppetlabs.com/projects/puppet/wiki/Engineering_done_done/diff/13 -- 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/164 -- 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 #11057] Better debugging output when skipping an agent/master run.
Issue #11057 has been updated by Jeff McCune. Target version changed from 2.7.10 to 2.7.11 # Targeting 2.7.11 # Missed the 2.7.10rc1 by a few minutes so I'm re-targeting this at 2.7.11. Bug #11057: Better debugging output when skipping an agent/master run. https://projects.puppetlabs.com/issues/11057 Author: Daniel Pittman Status: Merged - Pending Release Priority: Normal Assignee: Daniel Pittman Category: agent Target version: 2.7.11 Affected Puppet version: Keywords: Branch: https://github.com/puppetlabs/puppet/pull/235 At the moment we will skip a run if the agent is waiting on a restart because of an external signal, etc. This is necessary because we have an inescapable race around signal handling in that regard. Unfortunately, it was very opaque: there was no information about *why* the restart was skipped. This becomes more important when something else goes wrong and the only diagnostics we have are that we are skipping the scheduled run. -- 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 #10066] puppet agent --fingerprint should not daemonize
Issue #10066 has been updated by Michael Stahnke. Target version changed from 2.7.x to 2.7.10 Released in 2.7.10rc1 Bug #10066: puppet agent --fingerprint should not daemonize https://projects.puppetlabs.com/issues/10066 Author: Hunter Haugen Status: Merged - Pending Release Priority: Normal Assignee: Brice Figureau Category: agent Target version: 2.7.10 Affected Puppet version: 2.6.0 Keywords: agent, fingerprint Branch: https://github.com/puppetlabs/puppet/pull/215 It seems from the docs that `puppet agent --fingerprint` is to print out the fingerprint, but this is really only useful via `--fingerprint --no-daemonize` as the agent will fork into the background before printing. If we want it to fork, it should mention that in the docs. -- 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 #10109] (Closed) Composite keys cause Invalid parameter false error
Issue #10109 has been updated by Michael Stahnke. Status changed from Merged - Pending Release to Closed released as part 2.7.10rc1 Bug #10109: Composite keys cause Invalid parameter false error https://projects.puppetlabs.com/issues/10109 Author: Brandon Turner Status: Closed Priority: Normal Assignee: Brandon Turner Category: agent Target version: 2.7.10 Affected Puppet version: 2.7.4 Keywords: Branch: When using a type with more than one name var (composite keys), the agent outputs an error: err: Could not create resource file /var/lib/puppet/state/resources.txt: Invalid parameter false(false) at filename:line This first appeared in version 2.7.4, most likely in commit:7a39ca72e64. When multiple key attributes exist, `resource.name_var` is false. The new `write_resource_file` method attempts to call `Puppet::Type#[]` with `false` which causes the Invalid parameter error. The new resource list file should support types with composite keys. -- 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 #10321] (Closed) Schedule type range parameter array support isn't working
Issue #10321 has been updated by Michael Stahnke. Status changed from Merged - Pending Release to Closed Released 2.7.10rc1 Bug #10321: Schedule type range parameter array support isn't working https://projects.puppetlabs.com/issues/10321 Author: Sean Millichamp Status: Closed Priority: Normal Assignee: Sean Millichamp Category: schedule Target version: 2.7.10 Affected Puppet version: 2.7.6 Keywords: schedule range Branch: There is a test that is supposed to make sure that you can pass an array to the 'range' parameter in the schedule type. Due to the bug in Issue #10296 this has been reporting as passing even though it does not work. The first member of the array is processed and the remainder are never evaluated. -- 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 #10586] (Closed) Windows puppet cannot source files remotely if owner and group are not specified
Issue #10586 has been updated by Michael Stahnke.
Status changed from Merged - Pending Release to Closed
Target version changed from 2.7.x to 2.7.10
released in 2.7.10rc1
Bug #10586: Windows puppet cannot source files remotely if owner and group are
not specified
https://projects.puppetlabs.com/issues/10586
Author: Steve Shipway
Status: Closed
Priority: Normal
Assignee: Josh Cooper
Category: windows
Target version: 2.7.10
Affected Puppet version: 2.7.6
Keywords:
Branch: https://github.com/puppetlabs/puppet/pull/280
If you have a file resource pulling content from a puppet: URL, windows file
provider gives error Cannot convert Fixnum into string. The content is set
correctly, but the permissions are not.
C:\emspuppet agent -t --environment=dev
info: Caching catalog for emscmdprd01
info: Applying configuration version '1320628565'
err:
/Stage[main]//Node[emscmdprddrsdd]/File[C:/ems/certs/id_rsa.key]/ensure: ch
ange from absent to file failed: Could not set 'file on ensure: can't
convert Fi
xnum into String at /etc/puppet/dev/manifests/nodes/systems/esg/ems.pp:160
notice:
/Stage[main]//Node[emscmdprddrsdd]/File[C:/ems/certs/readme.txt]/ensure:
defined content as '{md5}bcfdf561fb19f6a296f162d35cc0f9a6'
notice: Finished catalog run in 55.56 seconds
C:\emspuppet --version
2.7.6
Manifest shows:
node /^emscmd(prd|drs)\d\d$/ {
$mycerts = 'C:/ems/certs'
# This works
file { $mycerts/readme.txt: ensure='file', mode='666',
group=undef, owner='Administrators',
content=Certificates Managed by Puppet;
}
# This does not
file { $mycerts/id_rsa.key: ensure='file', mode='666',
group=undef, owner='Administrators',
source=puppet:///files/ssh-keys/sitescope.private,
}
}
I believe this might be connected with the Windows puppet agent attepting to
set group ownership based on the file metadata (IE its group ownership under
unix) and failing to make the conversion, but in any case this should give a
meaningful message or default. We also need clearer documentation as to
exactly what 'mode' means in the ACL world of Windows...
--
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 #10676] (Closed) last run summary is an inconsistent data structure
Issue #10676 has been updated by Michael Stahnke. Status changed from Merged - Pending Release to Closed released in 2.7.10rc1 Bug #10676: last run summary is an inconsistent data structure https://projects.puppetlabs.com/issues/10676 Author: Nigel Kersten Status: Closed Priority: High Assignee: Category: reports Target version: 2.7.10 Affected Puppet version: Keywords: Branch: https://github.com/masterzen/puppet/tree/tickets/2.7.x/10676 * If a run has a failed resource such that all the subsequent events don't fire, we don't write out 'events 0', we simply don't put in the events key. RI's real world use of this file led him to need to create a hash with the following data and merge it in. We should be consistent so this isn't needed. * failed * changed * total * restarted * out of sync We should just do something similar but with absolutely every top level item. Start with the base data structure, and merge into it, rather than building it up as it sounds like we're doing. -- 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 #10807] (Closed) SMF provider should use svcadm with -s option
Issue #10807 has been updated by Michael Stahnke. Status changed from Merged - Pending Release to Closed released in 2.7.10rc1 Bug #10807: SMF provider should use svcadm with -s option https://projects.puppetlabs.com/issues/10807 Author: Dominic Cleal Status: Closed Priority: Normal Assignee: Category: Solaris Target version: 2.7.10 Affected Puppet version: 2.6.9 Keywords: smf solaris service Branch: https://github.com/domcleal/puppet/tree/tickets/2.7.x/10807 The SMF provider currently runs `svcadm enable svcname` to start up services, but the startup can later fail as it happens in the background. Examples include: * Dependencies aren't met, service goes to offline state * Method fails to run Instead the provider should run `svcadm enable -s svcname` which will wait for the service to start or exit with a non-zero exit code on failure. To quote the man page: citeIf the -s option is specified, svcadm enables each service instance and then waits for each service instance to enter the online or degraded state. svcadm will return early if it determines that the service cannot reach these states without administrator intervention./cite There's a possible issue (regression?) that when multiple services are started with Puppet now, the dependencies don't have to be explicitly listed. Services started in the wrong order will transition to offline until the dependencies are started. It seems acceptable to me to change this, as unspecified dependencies shouldn't be relied upon in Puppet. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #10940] (Closed) puppet apply --apply catalog should be deprecated in favor of puppet apply --catalog catalog
Issue #10940 has been updated by Michael Stahnke. Status changed from Merged - Pending Release to Closed Target version changed from 2.7.x to 2.7.10 released in 2.7.10rc1 Feature #10940: puppet apply --apply catalog should be deprecated in favor of puppet apply --catalog catalog https://projects.puppetlabs.com/issues/10940 Author: Kelsey Hightower Status: Closed Priority: Normal Assignee: Kelsey Hightower Category: Target version: 2.7.10 Affected Puppet version: Keywords: empathy Branch: https://github.com/puppetlabs/puppet/pull/231 The current `puppet apply --apply` interface is a bit confusing; we are using the verb apply as the flag name to reference a catalog, which is a noun. I propose we deprecate the `--apply` flag in favor of `--catalog` by creating an alias mapping `--catalog` to `--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-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 #10962] (Closed) The pw user provider on FreeBSD doesn't respect managehome when changing a user's a home directory
Issue #10962 has been updated by Michael Stahnke. Status changed from Merged - Pending Release to Closed released in 2.7.10rc1 Bug #10962: The pw user provider on FreeBSD doesn't respect managehome when changing a user's a home directory https://projects.puppetlabs.com/issues/10962 Author: Tim Bishop Status: Closed Priority: Normal Assignee: Category: FreeBSD Target version: 2.7.10 Affected Puppet version: 2.7.6 Keywords: Branch: https://github.com/puppetlabs/puppet/pull/210 *Please note the pull request referenced on this issue includes more than just this change* When a user's home directory is changed using the pw user provider the executed command is: pre pw usermod [name] -d [home] /pre If managehome is set to true the `-m` flag should also be given. This happens correctly at create time but not if the home directory is changed on an existing resource. As an aside, the behaviour of `-m` on an existing user is to create the new home directory, assuming it doesn't already exist, in the same way it would when creating a new user. I've produced a fix for this issue (on a branch with a bunch of other related FreeBSD pw improvements): https://github.com/tdb/puppet/commit/ec452a8f1932ab8ce41e460f83ca8782016328aa With this fix applied the command executed would be: pre pw usermod [name] -d [home] -m /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 - Feature #11046] (Closed) Improve user and group pw providers on FreeBSD
Issue #11046 has been updated by Michael Stahnke. Status changed from Merged - Pending Release to Closed released in 2.7.10rc1 Feature #11046: Improve user and group pw providers on FreeBSD https://projects.puppetlabs.com/issues/11046 Author: Tim Bishop Status: Closed Priority: Normal Assignee: Category: FreeBSD Target version: 2.7.10 Affected Puppet version: 2.7.6 Keywords: Branch: https://github.com/puppetlabs/puppet/pull/210 This issue incorporates the fixes in #7500 and #10962. I've improved the pw user and group providers on FreeBSD. Here's a summary of the changes: The user provider now supports managing passwords and user expiry. A bug which caused a changed home directory not to be created when managehome is enabled has been fixed. The group provider now supports managing group members. I've also re-added the allowdupe feature which works on FreeBSD 7, 8 and 9. I've also added tests for both the user and group providers. All of the changes to the group provider are mine and so are all the tests. The changes to the user provider have been partially taken from elsewhere, but the other changes are mine - see the commits for details. Some of these changes are already included in the FreeBSD port. -- 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 #11198] (Closed) Modules generated by PMT should have a default license
Issue #11198 has been updated by Michael Stahnke. Status changed from Merged - Pending Release to Closed Target version changed from 2.7.x to 2.7.10 released at 2.7.10rc1 Bug #11198: Modules generated by PMT should have a default license https://projects.puppetlabs.com/issues/11198 Author: Kelsey Hightower Status: Closed Priority: Normal Assignee: Kelsey Hightower Category: Target version: 2.7.10 Affected Puppet version: Keywords: Branch: https://github.com/kelseyhightower/puppet/tree/ticket/2.7.x/11198_generated_module_templates_should_have_a_default_license During a recent code review it was highlight that modules generated by PMT have a default license of UNKNOWN. This feels more like a business decision and requires further discussion before any changes are made to the code. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #7788] Puppet should allow rubygems to deliver new functionality
Issue #7788 has been updated by Daniel Pittman. R.I. Pienaar wrote: I think it still has value, unless you also let us control what gets pluginsynced to what places. With gems if we wanted some plugin on a subset of machines we just install it on those machines. With pluginsync thats not possible. How do environments fail to meet your needs here? Feature #7788: Puppet should allow rubygems to deliver new functionality https://projects.puppetlabs.com/issues/7788 Author: R.I. Pienaar Status: Needs Decision Priority: Normal Assignee: Nigel Kersten Category: plug-ins Target version: 2.7.x Affected Puppet version: Keywords: Branch: ripienaar/feature/master/7788 It would be desirable to use Rubygems to install things like parser functions. There might be cases where you only want a function on the master, pluginsync would copy it everywhere and everywhere might not have the dependencies needed to run it. If the autoloader considered the rubygem search path while autoloading this should allow gems to extend puppet. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #11246] (Closed) Puppet should work with UTF-8 encoded ERB templates
Issue #11246 has been updated by Michael Stahnke.
Status changed from Merged - Pending Release to Closed
Target version changed from 2.7.9 to 2.7.10
released in 2.7.10rc1
Bug #11246: Puppet should work with UTF-8 encoded ERB templates
https://projects.puppetlabs.com/issues/11246
Author: Jeff McCune
Status: Closed
Priority: High
Assignee:
Category: ruby19
Target version: 2.7.10
Affected Puppet version: 2.7.6
Keywords: support535 support utf unicode encoding internationalization template
zaml yaml report
Branch: https://github.com/puppetlabs/puppet/pull/250
# Overview #
A support customer reported this issue with Puppet 2.7.6 and Ruby 1.9.2-p290.
When using an ERB template with the template() function Puppet throws an
exception. Reproducing this error I've determined the issue comes from writing
out the YAML report.
# Steps to reproduce #
Using this simple class in a module the error is triggered when producing the
serialized report:
support535/manifests/utf8template.pp
pre
# Class: support535::utf8template
#
# This class uses the template() function with a UTF-8 encoded ERB file. The
# manifest itself does not actually contain UTF8 encoded strings.
#
# Parameters:
#
# Actions:
#
# Requires:
#
# Sample Usage:
#
class support535::utf8template {
notify { utf8template:
message = template(support535/snowman.erb),
}
}
# EOF
/pre
support535/templates/snowman.erb
pre
This is a simple text file with a snowman.
The snowman is here: (☃) EOL
EOF
/pre
# Actual Behavior #
With reporting turned on:
pre
% puppet apply -v --debug --trace -e 'include support535::utf8template'
info: Loading facts in facter_dot_d
info: Loading facts in root_home
debug: importing '/vagrant/modules/support535/manifests/init.pp' in environment
production
debug: importing '/vagrant/modules/support535/manifests/utf8template.pp' in
environment production
debug: Automatically imported support535::utf8template from
support535/utf8template into production
debug: Scope(Class[Support535::Utf8template]): Retrieving template
support535/snowman.erb
debug: template[/vagrant/modules/support535/templates/snowman.erb]: Bound
template variables for /vagrant/modules/support535/templates/snowman.erb in
0.00 seconds
debug: template[/vagrant/modules/support535/templates/snowman.erb]:
Interpolated template /vagrant/modules/support535/templates/snowman.erb in 0.00
seconds
debug: Creating default schedules
debug: Failed to load library 'selinux' for feature 'selinux'
debug: Failed to load library 'shadow' for feature 'libshadow'
debug: Failed to load library 'ldap' for feature 'ldap'
debug: /File[/Users/jeff/.puppet/var]: Autorequiring File[/Users/jeff/.puppet]
debug: /File[/Users/jeff/.puppet/var/log]: Autorequiring
File[/Users/jeff/.puppet/var]
debug: /File[/Users/jeff/.puppet/var/state]: Autorequiring
File[/Users/jeff/.puppet/var]
debug: /File[/Users/jeff/.puppet/var/run]: Autorequiring
File[/Users/jeff/.puppet/var]
debug: /File[/Users/jeff/.puppet/var/lib]: Autorequiring
File[/Users/jeff/.puppet/var]
debug: /File[/Users/jeff/.puppet/var/ssl/certs]: Autorequiring
File[/Users/jeff/.puppet/var/ssl]
debug: /File[/Users/jeff/.puppet/var/ssl]: Autorequiring
File[/Users/jeff/.puppet/var]
debug: /File[/Users/jeff/.puppet/var/ssl/public_keys]: Autorequiring
File[/Users/jeff/.puppet/var/ssl]
debug: /File[/Users/jeff/.puppet/var/ssl/certificate_requests]: Autorequiring
File[/Users/jeff/.puppet/var/ssl]
debug: /File[/Users/jeff/.puppet/var/ssl/private_keys]: Autorequiring
File[/Users/jeff/.puppet/var/ssl]
debug: /File[/Users/jeff/.puppet/var/ssl/private]: Autorequiring
File[/Users/jeff/.puppet/var/ssl]
debug: /File[/Users/jeff/.puppet/var/ssl/certs/ca.pem]: Autorequiring
File[/Users/jeff/.puppet/var/ssl/certs]
debug: /File[/Users/jeff/.puppet/var/ssl/crl.pem]: Autorequiring
File[/Users/jeff/.puppet/var/ssl]
debug: /File[/Users/jeff/.puppet/var/state/state.yaml]: Autorequiring
File[/Users/jeff/.puppet/var/state]
debug: /File[/Users/jeff/.puppet/var/client_yaml]: Autorequiring
File[/Users/jeff/.puppet/var]
debug: /File[/Users/jeff/.puppet/var/client_data]: Autorequiring
File[/Users/jeff/.puppet/var]
debug: /File[/Users/jeff/.puppet/var/clientbucket]: Autorequiring
File[/Users/jeff/.puppet/var]
debug: /File[/Users/jeff/.puppet/var/state/last_run_summary.yaml]:
Autorequiring File[/Users/jeff/.puppet/var/state]
debug: /File[/Users/jeff/.puppet/var/state/last_run_report.yaml]: Autorequiring
File[/Users/jeff/.puppet/var/state]
debug: /File[/Users/jeff/.puppet/var/state/graphs]: Autorequiring
File[/Users/jeff/.puppet/var/state]
debug: /File[/Users/jeff/.puppet/var/facts]: Autorequiring
File[/Users/jeff/.puppet/var]
debug: Finishing transaction 70320110466340
debug: Loaded state in 0.00 seconds
debug: Loaded state in 0.00 seconds
info: Applying configuration version '1323223267'
debug: /Schedule[daily]: Skipping device resources because running on a host
debug: /Schedule[monthly]:
[Puppet - Feature #11990] PuppetDoc should use also README.rdoc files
Issue #11990 has been updated by Daniel Pittman.
Description updated
Brice Figureau wrote:
Alessandro Franceschi wrote:
I attach the patch in a more readable format... sorry for the mess
I will produce a better patch (ie with spec coverage) soon.
Awesome. We are also going to need a CLA signed by Alessandro, and ideally the
code as a pull request. Alessandro, can you sign the CLA?
Feature #11990: PuppetDoc should use also README.rdoc files
https://projects.puppetlabs.com/issues/11990
Author: Alessandro Franceschi
Status: Unreviewed
Priority: Normal
Assignee:
Category:
Target version:
Affected Puppet version:
Keywords: puppetdoc
Branch:
This is a feature request for which there's already a solution.
Hope you will review and eventually accept it.
PuppetDoc uses the file README in a module to generate the main page of a
module's documentation.
If this file is in rdoc format it renders it nicely.
At the same time many modules are published on GitHub, where README files are
rendered as rdoc if they are named README.rdoc
The request is to make puppetdoc renders files called README.rdoc ad module
documentation if they are found on the module, otherwise it falls back to the
standard README.
I already asked Brice an help about this and he replied, in very few minutes
with this:
Here is a patch that should quite do what you need:
pre
diff --git a/lib/puppet/util/rdoc/parser.rb b/lib/puppet/util/rdoc/parser.rb
index a8996ee..5fa3246 100644
--- a/lib/puppet/util/rdoc/parser.rb
+++ b/lib/puppet/util/rdoc/parser.rb
@@ -129,8 +129,10 @@ class Parser
def scan_top_level(container)
# use the module README as documentation for the module
comment =
-readme = File.join(File.dirname(File.dirname(@input_file_name)), README)
-comment = File.open(readme,r) { |f| f.read } if
FileTest.readable?(readme)
+%w{README README.rdoc}.each do |rfile|
+ readme = File.join(File.dirname(File.dirname(@input_file_name)), rfile)
+ comment = File.open(readme,r) { |f| f.read } if
FileTest.readable?(readme)
+end
look_for_directives_in(container, comment) unless comment.empty?
# infer module name from directory
/pre
It is fully untested :)
It should prefer a README.rdoc over a README if both are present.
---
I've tested this patch on Puppet 2.7.9 and it seems to work as expected:
- modules with a README are rendered well
- modules with a README.rdoc are rendered well
- modules with both render README.rdoc
--
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 #11996] (Closed) Spec test failures in 1.8.7p357 due to hash ordering changes...
Issue #11996 has been updated by Daniel Pittman.
Status changed from In Topic Branch Pending Review to Closed
Reviewed and merged by Josh, and then shipped in 2.7.10.
Refactor #11996: Spec test failures in 1.8.7p357 due to hash ordering changes...
https://projects.puppetlabs.com/issues/11996
Author: Daniel Pittman
Status: Closed
Priority: Normal
Assignee:
Category: Doh!
Target version:
Affected Puppet version: 2.7.0
Keywords:
Branch:
Now the hash order changes when Ruby is run, some tests are failing because
they look to be dependent on the order in which the hash is processed.
Typically is this:
pre
1) Puppet::Parser::AST::ASTHash should return a valid string with to_s
Failure/Error: hash.to_s.should == '{a = b, c = d}'
expected: {a = b, c = d}
got: {c = d, a = b} (using ==)
# ./spec/unit/parser/ast/asthash_spec.rb:95
2) Puppet::Property::KeyValue as an instance should return the passed in
array values joined with the delimiter from is_to_s
Failure/Error: @property.is_to_s({foo = baz , bar = boo}).should
== foo=baz;bar=boo
expected: foo=baz;bar=boo
got: bar=boo;foo=baz (using ==)
# ./spec/unit/property/keyvalue_spec.rb:39
/pre
Note the output reverses the previous order, and is still likely correct, just
disordered? Also, kind of random because the hash seed is random, I believe,
in this patch.
--
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 #11291] (Closed) Configuration reference for show_diff is incorrect as of 845825a
Issue #11291 has been updated by Michael Stahnke. Status changed from Merged - Pending Release to Closed Affected Puppet version deleted (2.7.8rc2) released in 2.7.10rc1 Bug #11291: Configuration reference for show_diff is incorrect as of 845825a https://projects.puppetlabs.com/issues/11291 Author: Nick Fagerlund Status: Closed Priority: Normal Assignee: Nick Fagerlund Category: Target version: 2.7.8 Affected Puppet version: Keywords: Branch: https://github.com/nfagerlund/puppet/pull/new/ticket/2.7.x/11291_show_diffs_description Issue #2744 changed our behavior when show_diff is set, but the description of this option in defaults.rb never got 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 #11291] Configuration reference for show_diff is incorrect as of 845825a
Issue #11291 has been updated by Michael Stahnke. Target version changed from 2.7.8 to 2.7.10 Bug #11291: Configuration reference for show_diff is incorrect as of 845825a https://projects.puppetlabs.com/issues/11291 Author: Nick Fagerlund Status: Closed Priority: Normal Assignee: Nick Fagerlund Category: Target version: 2.7.10 Affected Puppet version: Keywords: Branch: https://github.com/nfagerlund/puppet/pull/new/ticket/2.7.x/11291_show_diffs_description Issue #2744 changed our behavior when show_diff is set, but the description of this option in defaults.rb never got 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 #11293] (Closed) Password parameter for the User resource is broke in OS X version 10.7
Issue #11293 has been updated by Michael Stahnke.
Status changed from Merged - Pending Release to Closed
released in 2.7.10rc1
Bug #11293: Password parameter for the User resource is broke in OS X version
10.7
https://projects.puppetlabs.com/issues/11293
Author: Gary Larizza
Status: Closed
Priority: Normal
Assignee: Gary Larizza
Category: OSX
Target version: 2.7.10
Affected Puppet version: 2.7.9
Keywords:
Branch: https://github.com/puppetlabs/puppet/pull/308
As of 10.7, OS X uses a SHA512 hash for their passwords. In the past, they
used SHA1 hashes, which are supported with the user resource. As it stands
right now, the password parameter is broken. Doing a sudo puppet resource user
username results in the following:
pre
users root $ sudo puppet resource user demouser
user { 'demouser':
ensure = 'present',
comment = 'Demo User',
gid = '20',
home= '/Users/demouser',
shell = '/bin/bash',
uid = '504',
}
/pre
Accessing the hash in 10.7 requires the following steps:
* Grabbing the user's plist file in
/var/db/dslocal/nodes/Default/users/username.plist
* Converting it to XML (since it's a binary plist)
plutil -convert xml1 username.plist
* Inspecting the XML file, getting the data string from the ShadowHashData key,
and base64-decoding it
echo Data from ShadowHashData Key | base64 -d ShadowHashData
* The file we created in the previous step is ACTUALLY A BINARY PLIST that
needs to be converted to XML
plutil -convert xml1 ShadowHashData
* In that XML file, there's a key named SALTED-SHA512. Grab the data string
from that key and base64-decode it
echo Data from SALTED-SHA512 Key | base64 -d hashfile
* Finally, reveal the hash using the xxd tool (which I presume takes hex and
converts to a string? Or vice versa?) and cutting the first portion (which
should be the salt)
xxd -p -c 256 hashfile | cut -c 9-
Because the password was stored as SHA1 in versions 10.4 - 10.6 and SHA512 in
10.7, there doesn't seem to be a way that we can have a universal password
attribute for the user resource (unless we store the password in plaintext,
which is not ideal).
--
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 #11318] (Closed) [Patch] Add the manages_passwords feature for users on FreeBSD
Issue #11318 has been updated by Michael Stahnke. Status changed from Merged - Pending Release to Closed released in 2.7.10rc1 Feature #11318: [Patch] Add the manages_passwords feature for users on FreeBSD https://projects.puppetlabs.com/issues/11318 Author: Brad Davis Status: Closed Priority: Normal Assignee: Category: FreeBSD Target version: 2.7.10 Affected Puppet version: Keywords: FreeBSD pw manages_passwords user Branch: https://github.com/puppetlabs/puppet/pull/264 Hi, A friend of mine wrote up a patch to implement manages_passwords on FreeBSD. The Pull request is here: https://github.com/puppetlabs/puppet/pull/264 -- 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 #11333] (Closed) Incorrect Puppet::Type.ensurable? behaviour
Issue #11333 has been updated by Michael Stahnke. Status changed from Merged - Pending Release to Closed released in 2.7.10rc1 Bug #11333: Incorrect Puppet::Type.ensurable? behaviour https://projects.puppetlabs.com/issues/11333 Author: Ilya Sher Status: Closed Priority: Normal Assignee: Daniel Pittman Category: plumbing Target version: 2.7.10 Affected Puppet version: 2.7.6 Keywords: Branch: https://github.com/puppetlabs/puppet/pull/270 `Puppet::Type.ensurable?` incorrectly returns true even when `public_method_defined?(:exists?)` is false because the check never actually happens due to a bug. This fix handles this and simplifies the code. Attaching patch against commit 464a279c7425643188024ba7f98392b9057d6e35 Only tested in an isolated file, so it needs testing (which I currently don't have the time to do.) -- 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 #11404] (Closed) Indentation gets borked when generating the @doc string for a type's :provider parameter
Issue #11404 has been updated by Michael Stahnke.
Status changed from Merged - Pending Release to Closed
Target version changed from 2.7.x to 2.7.10
released in 2.7.10rc1
Bug #11404: Indentation gets borked when generating the @doc string for a
type's :provider parameter
https://projects.puppetlabs.com/issues/11404
Author: Nick Fagerlund
Status: Closed
Priority: Normal
Assignee: Nick Fagerlund
Category: documentation
Target version: 2.7.10
Affected Puppet version: 2.7.8
Keywords: references, providers, types
Branch:
Formatting tweaks to the type and provider desc strings for version 2.7.8
revealed a longstanding bug in the way indentation is handled when assembling
parameter doc fragments to create the `:provider` parameter's doc string. In
summary:
* Using an indented code example in a provider's desc string will cause the
type reference to blow up.
* The multi-paragraph unordered list element in which we wrap the list of
providers should actually not work, but we've been getting by on luck until now.
In detail:
Markdown uses hanging indents (canonically four spaces, but most
implementations also allow alignment to the first text following a list marker)
to delimit the content of multi-paragraph list items. The doc fragments
scattered throughout our type and provider code use indents to preserve the
structure of the files they're contained in. Thus, when assembling fragments
into a document, we have to remove the purely cosmetic indents while preserving
the semantic indents. This is done with the `scrub()` method in
`Puppet::Util::Docs`.
Unfortunately, we're assembling fragments into fragments when building the
provider parameter's documentation, and we weren't handling indentation
recursively. This meant we were assembling a string that:
* Started with a block of eight-space indented text:
desc -EOT
The specific backend to use for this
`#{self.to_s.split('::')[2].downcase}`
resource. You will seldom need to specify this --- Puppet will usually
discover the appropriate provider for your platform.
EOT
* ...followed by a block of two-space indented text (which looked outdented
compared to its parent):
def self.doc
@doc + Available providers are:\n\n + ...
* ...followed by a series of fragments, each of which started with a flush-left
list item and continued with a block of text (pulled from a provider) with a
completely unreliable and arbitrary indent, depending on how its surrounding
code was indented.
}.collect { |i|
* **#{i}**: #{parenttype().provider(i).doc}
}.join(\n)
This USUALLY -- by coincidence alone -- came out to an amount of indent
that our markdown processor would accept as a multi-paragraph list item. Note
that these blocks still appeared outdented compared to the initial
eight-space indent.
Then, once the whole thing was assembled, it would be fed through `scrub`.
Scrub actually leaves outdented text alone, it turns out! It determines the
amount of space it should be trimming, attempts to trim that from each line,
and leaves the line alone if it doesn't find that amount of space. This usually
resulted in making the original intro text flush left, leaving the list bullets
flush left, and leaving the per-provider text at the (totally coincidental)
correct indentation necessary to stay within its list item element.
However, if you added an indented code example to a parameter's description,
the space of the code indent plus the space of the arbitrary formatting indent
would add up to eight or more spaces, which would cause `scrub` to attack and
allow the code example to escape its enclosing list item element. Which in turn
would cause everything BELOW the code example (indented somewhere kinda-sorta
around four spaces, remember) to look like a really big code block.
This was being hidden before by anemic indentation for the parameters'
description text -- the initial line of the code examples wasn't being
outdented, although the attributes in the example resource were:
service { myservice:
provider = daemontools,
path = /path/to/daemons,
}
...and so it wasn't escaping its list item.
In conclusion, we need to strip cosmetic indents recursively when assembling
fragments out of other fragments, and then specify the exact amount of semantic
indent we want instead of just leaking the cosmetic indent into the final
product and hoping it comes out right.
We should also use definition lists for the lists of providers instead of
unordered lists where each item begins with a bolded label, just because that's
a better conceptual match for what these lists are.
--
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
--
[Puppet - Bug #11408] (Closed) Windows fact and pluginsync are broken
Issue #11408 has been updated by Michael Stahnke. Status changed from Merged - Pending Release to Closed released in 2.7.10rc1 Bug #11408: Windows fact and pluginsync are broken https://projects.puppetlabs.com/issues/11408 Author: Mark Plaksin Status: Closed Priority: High Assignee: Josh Cooper Category: windows Target version: 2.7.10 Affected Puppet version: 2.7.6 Keywords: Branch: https://github.com/puppetlabs/puppet/pull/281 [ Yikes, sorry for the terrible formatting! Here's try #2 :) ] Hi, I'm a *nix admin testing Puppet on Windows for the first time. Everything installed fine but I get Could not evaluate: can't convert Fixnum into String when I run Puppet. Versions: - Windows 2008 - Puppet 2.7.9 on client and server - Facter 1.6.4 This looks similar to #10586 which is marked as a duplicate of #10614. I don't know enough to know whether my problem is really related or not. I'm running Puppet like this: C:\ProgramData\PuppetLabs\puppet\etcpuppet agent --verbose --server puppet.example.com -t --debug --trace --ignores --pluginsync and I get this stack trace: pre info: Retrieving plugin debug: file_metadata supports formats: b64_zlib_yaml marshal pson raw yaml; using pson debug: Using cached certificate for ca debug: Using cached certificate for yar debug: Using cached certificate_revocation_list for ca C:/Ruby187/lib/ruby/site_ruby/1.8/puppet/util/windows/security.rb:577:in `pack' C:/Ruby187/lib/ruby/site_ruby/1.8/puppet/util/windows/security.rb:577:in `string_to_sid_ptr' C:/Ruby187/lib/ruby/site_ruby/1.8/puppet/provider/file/windows.rb:40:in `name2uid' C:/Ruby187/lib/ruby/site_ruby/1.8/puppet/type/file/owner.rb:13:in `insync?' C:/Ruby187/lib/ruby/site_ruby/1.8/puppet/type/file/owner.rb:12:in `map!' C:/Ruby187/lib/ruby/site_ruby/1.8/puppet/type/file/owner.rb:12:in `insync?' C:/Ruby187/lib/ruby/site_ruby/1.8/puppet/property.rb:162:in `safe_insync?' C:/Ruby187/lib/ruby/site_ruby/1.8/puppet/transaction/resource_harness.rb:61:in `perform_changes' C:/Ruby187/lib/ruby/site_ruby/1.8/puppet/transaction/resource_harness.rb:60:in `each' C:/Ruby187/lib/ruby/site_ruby/1.8/puppet/transaction/resource_harness.rb:60:in `perform_changes' C:/Ruby187/lib/ruby/site_ruby/1.8/puppet/transaction/resource_harness.rb:133:in `evaluate' C:/Ruby187/lib/ruby/site_ruby/1.8/puppet/transaction.rb:49:in `apply' C:/Ruby187/lib/ruby/site_ruby/1.8/puppet/transaction.rb:84:in `eval_resource' C:/Ruby187/lib/ruby/site_ruby/1.8/puppet/transaction.rb:103:in `evaluate' C:/Ruby187/lib/ruby/site_ruby/1.8/puppet/util.rb:476:in `thinmark' C:/Ruby187/lib/ruby/1.8/benchmark.rb:308:in `realtime' C:/Ruby187/lib/ruby/site_ruby/1.8/puppet/util.rb:475:in `thinmark' C:/Ruby187/lib/ruby/site_ruby/1.8/puppet/transaction.rb:103:in `evaluate' C:/Ruby187/lib/ruby/site_ruby/1.8/puppet/transaction.rb:380:in `traverse' C:/Ruby187/lib/ruby/site_ruby/1.8/puppet/transaction.rb:99:in `evaluate' C:/Ruby187/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:141:in `apply' C:/Ruby187/lib/ruby/site_ruby/1.8/puppet/configurer/downloader.rb:32:in `evaluate' C:/Ruby187/lib/ruby/1.8/timeout.rb:67:in `timeout' C:/Ruby187/lib/ruby/site_ruby/1.8/puppet/configurer/downloader.rb:31:in `evaluate' C:/Ruby187/lib/ruby/site_ruby/1.8/puppet/configurer/plugin_handler.rb:19:in `download_plugins' C:/Ruby187/lib/ruby/site_ruby/1.8/puppet/configurer.rb:77:in `prepare' C:/Ruby187/lib/ruby/site_ruby/1.8/puppet/configurer.rb:137:in `run' C:/Ruby187/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run' C:/Ruby187/lib/ruby/site_ruby/1.8/puppet/agent/locker.rb:21:in `lock' C:/Ruby187/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run' C:/Ruby187/lib/ruby/1.8/sync.rb:230:in `synchronize' C:/Ruby187/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run' C:/Ruby187/lib/ruby/site_ruby/1.8/puppet/agent.rb:103:in `with_client' C:/Ruby187/lib/ruby/site_ruby/1.8/puppet/agent.rb:37:in `run' C:/Ruby187/lib/ruby/site_ruby/1.8/puppet/application.rb:172:in `call' C:/Ruby187/lib/ruby/site_ruby/1.8/puppet/application.rb:172:in `controlled_run' C:/Ruby187/lib/ruby/site_ruby/1.8/puppet/agent.rb:35:in `run' C:/Ruby187/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:336:in `onetime' C:/Ruby187/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:310: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 err: /File[C:/ProgramData/PuppetLabs/puppet/var/lib]: Could not evaluate: can't convert Fixnum into String /pre I have no idea whether this this is in the right ballpark or not but If I add 'string = string.to_s' on line 577 of security.rb
[Puppet - Bug #11414] (Closed) augeas provider version checks fails when version 0.9
Issue #11414 has been updated by Michael Stahnke.
Status changed from Merged - Pending Release to Closed
Target version changed from 2.7.x to 2.7.10
released in 2.7.10rc1
Bug #11414: augeas provider version checks fails when version 0.9
https://projects.puppetlabs.com/issues/11414
Author: Theo Cabrerizo Diem
Status: Closed
Priority: High
Assignee: Dominic Cleal
Category: augeas
Target version: 2.7.10
Affected Puppet version: 0.24.8
Keywords: augeas
Branch: https://github.com/puppetlabs/puppet/pull/283
Just found that augeas resource isn't saving my changes, although reporting
successful in my environment (libaugeas 0.10.0).
Looking into lib/puppet/provider/augeas/augeas.rb , I've found some occurrences
of like :
if get_augeas_version = 0.3.6
Using irb shell :
irb 0.9.0 = 0.3.6
= true
irb 0.10.0 = 0.3.6
= false
irb require 'augeas'
= true
irb aug = Augeas::open('/').get('/augeas/version')
= 0.10.0
I'm not a ruby expert thus I cannot provide a patch, but I take that would be a
better approach to compare versions using versioncmp from
lib/puppet/util/package.rb ?
This bug makes augeas resource being unusable on environments that have
upgraded augeas libraries to = 0.10.0 . Also it doesn't produce any errors but
changes don't get applied.
Sample output (when using 0.10.0, it does not apply changes) :
# puppet apply -d -v -e 'augeas { abc: context =
/files/etc/puppet/puppet.conf, force = true, changes = [set agent/server
changeme,], }'
snip
debug: Augeas[abc](provider=augeas): Opening augeas with root /, lens path
, flags 0
debug: Augeas[abc](provider=augeas): Closed the augeas connection
debug: Augeas[abc](provider=augeas): Opening augeas with root /, lens path
, flags 0
debug: Augeas[abc](provider=augeas): Closed the augeas connection
notice: /Stage[main]//Augeas[abc]/returns: executed successfully
snip
--
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 #11423] (Closed) Misleading error message when you import duplicate resources from StoreConfigs
Issue #11423 has been updated by Michael Stahnke. Status changed from In Topic Branch Pending Review to Closed Target version set to 2.7.10 released in 2.7.10rc1 Bug #11423: Misleading error message when you import duplicate resources from StoreConfigs https://projects.puppetlabs.com/issues/11423 Author: Daniel Pittman Status: Closed Priority: Normal Assignee: Category: stored configuration Target version: 2.7.10 Affected Puppet version: 2.7.0 Keywords: Branch: https://github.com/puppetlabs/puppet/pull/277 The code in `collect_exported` in `lib/puppet/parser/collector.rb` has some poor logic: if you import two resources with the same type and title from two other machines, it will report that Exported resource foo cannot override *local* resource. This is because it walks through all the resources it finds and checks if they duplicate something already known about. If not, they get added to the collection. If there is a duplicate, though, it assumes that is local, and issues a message as such. -- 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 #11499] (Closed) validation code for puppet resource host does not properly check if ip is valid
Issue #11499 has been updated by Michael Stahnke.
Status changed from Merged - Pending Release to Closed
released in 2.7.10rc1
Bug #11499: validation code for puppet resource host does not properly check if
ip is valid
https://projects.puppetlabs.com/issues/11499
Author: Garrett Honeycutt
Status: Closed
Priority: Normal
Assignee: Daniel Pittman
Category: host
Target version: 2.7.10
Affected Puppet version: 2.7.6
Keywords:
Branch: https://github.com/puppetlabs/puppet/pull/296
It appears that we only check that the digits are [0-9] and period, while we
should be doing an actual IP check
Attempting to use a letter. Fails as expected.
pre
[root@puppet ~]# puppet resource host junk.tld ip=1.2.3.a ensure=present
Could not run: Parameter ip failed: Invalid IP address
/pre
Attempting to use a bad IP, which works and should not.
pre
[root@puppet ~]# puppet resource host junk.tld ip=10.10.10.10.10 ensure=present
notice: /Host[junk.tld]/ensure: created
host { 'junk.tld':
ensure = 'present',
ip = '10.10.10.10.10',
target = '/etc/hosts',
}
/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 #11641] (Closed) After 2.7.9 update, Tidy resource can only tidy a single file per run
Issue #11641 has been updated by Michael Stahnke.
Status changed from Merged - Pending Release to Closed
released in 2.7.10rc1
Bug #11641: After 2.7.9 update, Tidy resource can only tidy a single file per
run
https://projects.puppetlabs.com/issues/11641
Author: Rob Terhaar
Status: Closed
Priority: Normal
Assignee: Nick Lewis
Category: tidy
Target version: 2.7.10
Affected Puppet version: 2.7.9
Keywords:
Branch:
We use the Tidy resource to clean up old apt files from
/var/cache/apt/archives, and after upgrading from 2.7.6 to 2.7.9, it is no
longer able to tidy more than file per Puppet agent run. I now receive a
warning that says appears to have a negative number of dependencies
pre
...
notice: /Stage[main]/Apt::Cleaner/Tidy[/var/cache/apt/archives]: Tidying
File[/var/cache/apt/archives/libaprutil1_1.3.9+dfsg-3ubuntu0.10.04.1_i386.deb]
notice: /Stage[main]/Apt::Cleaner/Tidy[/var/cache/apt/archives]: Tidying
File[/var/cache/apt/archives/postfix-pcre_2.7.0-1ubuntu0.2_i386.deb]
notice: /Stage[main]/Apt::Cleaner/Tidy[/var/cache/apt/archives]: Tidying
File[/var/cache/apt/archives/pflogsumm_1.1.2-2_all.deb]
info: Applying configuration version 'fabric-rterhaar-master-1325104418'
notice:
/File[/var/cache/apt/archives/snmpd_5.4.2.1~dfsg0ubuntu1-0ubuntu2.1_i386.deb]/ensure:
removed
warning: /Stage[main]/Apt::Cleaner/Tidy[/var/cache/apt/archives]: appears to
have a negative number of dependencies
warning: Class[Apt::Cleaner]: appears to have a negative number of dependencies
...
/pre
The Tidy resource code that generates this error is very simple:
pre
tidy{'/var/cache/apt/archives':
age = '1d',
rmdirs = false,
recurse = true,
matches = '*.deb',
}
/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 #11714] (Closed) puppet --version returns Error: Unknown Puppet subcommand 'apply' on windows
Issue #11714 has been updated by Michael Stahnke. Status changed from Merged - Pending Release to Closed released in 2.7.10rc1 Bug #11714: puppet --version returns Error: Unknown Puppet subcommand 'apply' on windows https://projects.puppetlabs.com/issues/11714 Author: Jeff McCune Status: Closed Priority: Normal Assignee: Jeff McCune Category: windows Target version: 2.7.10 Affected Puppet version: 2.7.9 Keywords: windows apply subcommand puppet Branch: https://github.com/puppetlabs/puppet/pull/322 # Overview # I'm getting this error with Puppet 2.7.9, Facter 1.6.x, and Ruby 1.9.7p334 on Windows 2003 x64. pre C:\envpuppet puppet --version --debug --trace Error: Unknown Puppet subcommand 'apply' See 'puppet help' for help on available puppet subcommands /pre # Expected Behavior # I'd expect this error not to be raised and the version string 2.7.9 to be printed. # Actual Behavior # See above error message # Steps to reproduce # I'm running Puppet from source using this envpuppet.bat wrapper script in my PATH. Facter and Puppet are located on a windows mapped drive readable by my security context and process. pre @echo off SETLOCAL SET RUBYLIB=Z:\vagrant\src\facter\lib;Z:\vagrant\src\puppet\lib;%RUBYLIB% SET PATH=Z:\vagrant\src\facter\bin;Z:\vagrant\src\puppet\bin;%PATH% ruby -S %* /pre * Windows 2003 x64 patched up. * Ruby 1.8.7 p334 * Gems: pre C:\gem list *** LOCAL GEMS *** sys-admin (1.5.6 x86-mingw32) win32-api (1.4.8 x86-mingw32) win32-dir (0.3.7) win32-process (0.6.5) win32-security (0.1.2) win32-service (0.7.1 x86-mswin32-60) win32-taskscheduler (0.2.1) windows-api (0.4.0) windows-pr (1.2.1) /pre # Additional Information # Using this envpuppet wrapper script, Facter appears to work just fine running out of source leading me to believe my RUBYLIB and PATH are setup correctly: pre C:\envpuppet facter --version 1.6.4 C:\envpuppet facter operatingsystem windows /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 #11717] (Closed) Windows ADSI user provider won't create users if a password policy is in place
Issue #11717 has been updated by Michael Stahnke. Status changed from Merged - Pending Release to Closed released in 2.7.10rc1 Bug #11717: Windows ADSI user provider won't create users if a password policy is in place https://projects.puppetlabs.com/issues/11717 Author: Paul Tinsley Status: Closed Priority: Normal Assignee: Josh Cooper Category: windows Target version: 2.7.10 Affected Puppet version: 2.7.9 Keywords: Branch: https://github.com/puppetlabs/puppet/pull/304 The creation of a user in puppet currently creates the account then sets the password, that won't meet the complexity requirement since the password is blank. It's the same behavior you would receive if you went into computer manager and added one by hand with no password. As the provider is currently written this requires a one line code change: pre $ diff /cygdrive/c/Users/puppet/Desktop/puppetlabs-puppet-26093a8/lib/puppet/provider/user/windows_adsi.rb puppet/provider/user/windows_adsi.rb 25c25,28 @user.commit --- #if a windows complexity policy is set you have to set the password when the # account is created, a call to .password is all that is needed it does it's # own commit. @user.password = @resource[:password] /pre I can't certify this will work in every environment but I have had luck in windows 7 and windows 2003 r2. -- 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 #11740] (Closed) Puppet sometimes reports 'The handle is invalid'
Issue #11740 has been updated by Michael Stahnke. Status changed from Accepted to Closed Target version changed from 2.7.x to 2.7.10 released in 2.7.10rc1 Bug #11740: Puppet sometimes reports 'The handle is invalid' https://projects.puppetlabs.com/issues/11740 Author: Josh Cooper Status: Closed Priority: Normal Assignee: Josh Cooper Category: windows Target version: 2.7.10 Affected Puppet version: 2.7.6 Keywords: Branch: One of the spec tests is suddenly failing on win2003. It appears to be a race condition in the Process::waitpid2 call. The windows win32-process gem will throw an error if the child has exited whereas the normal semantics are to return a Process::Status object that contains the exit code of the process. -- 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 #11844] (Closed) Fix command typo in exec documentation
Issue #11844 has been updated by Michael Stahnke. Status changed from Merged - Pending Release to Closed Target version changed from 2.7.x to 2.7.10 released in 2.7.10rc1 Bug #11844: Fix command typo in exec documentation https://projects.puppetlabs.com/issues/11844 Author: James Turnbull Status: Closed Priority: Normal Assignee: Nick Fagerlund Category: documentation Target version: 2.7.10 Affected Puppet version: Keywords: Branch: https://github.com/puppetlabs/puppet/pull/317 pre -running commnands as different users in the shell./p +running commands as different users in the shell./p /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 #11847] (Closed) puppet.bat cannot be relocated on Windows
Issue #11847 has been updated by Michael Stahnke. Status changed from Merged - Pending Release to Closed released in 2.7.10rc1 Bug #11847: puppet.bat cannot be relocated on Windows https://projects.puppetlabs.com/issues/11847 Author: Josh Cooper Status: Closed Priority: Normal Assignee: Josh Cooper Category: windows Target version: 2.7.10 Affected Puppet version: 2.7.6 Keywords: Branch: https://github.com/puppetlabs/puppet/pull/320 Puppet's `install.rb` script creates wrapper batch scripts in ruby's bin directory. The batch file contains full paths to where it was installed and its current working directory. This makes it impossible to move the ruby directory (and the script) and have the script still work. The preferred way of doing this on Windows is to use `%~dp0`, which is dynamically set to the full path of the directory that contains the script, i.e. what is currently `C:\Ruby187\bin` -- 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 #11929] (Closed) Cannot serve local binary files on Windows
Issue #11929 has been updated by Michael Stahnke.
Status changed from Merged - Pending Release to Closed
released at 2.7.10rc1
Bug #11929: Cannot serve local binary files on Windows
https://projects.puppetlabs.com/issues/11929
Author: Josh Cooper
Status: Closed
Priority: Normal
Assignee: Josh Cooper
Category: windows
Target version: 2.7.10
Affected Puppet version: 2.7.6
Keywords:
Branch: https://github.com/puppetlabs/puppet/pull/331
`Puppet::FileServing::Content.content` is not specifying binary mode when
reading its file. This is okay when the code runs on a Unix master. But if the
Windows agent is its own fileserver, such as retrieving files from a local
module, then the file is opened in text mode, which corrupts binaries.
To reproduce:
Given a module:
pre
C:\modules
└splunk
├files
│ splunk-4.2.4-110225-x64-release.msi
└manifests
init.pp
/pre
Where init.pp is:
pre
class splunk {
file { 'c:\packages\splunk-4.2.4-110225-x64-release.msi':
ensure = present,
source = 'puppet:///modules/splunk/splunk-4.2.4-110225-x64-release.msi',
}
package { 'splunk':
ensure = installed,
provider = 'msi',
source = 'c:\packages\splunk-4.2.4-110225-x64-release.msi',
install_options = { 'INSTALLDIR' = 'C:\splunk' },
require = File['c:\packages\splunk-4.2.4-110225-x64-release.msi'],
}
}
/pre
And site.pp:
pre
class { 'splunk': }
/pre
Trying to apply the local module:
pre
puppet apply c:\modules\site.pp --modulepath c:/modules
/pre
Puppet corrupts the file while copying it from the local file server:
pre
err: /Stage[main]/Splunk/Package[splunk]/ensure: change from absent to present
failed: Execution of 'msiexec.exe /qn /no
restart /i c:\packages\splunk-4.2.4-110225-x64-release.msi
INSTALLDIR=C:\splunk' returned 1620: T h i s i n s t a l l
a t i o n p a c k a g e c o u l d n o t b e o p e n e d . C o n t
a c t t h e a p p l i c a t i o n
v e n d o r t o v e r i f y t h a t t h i s i s a v a l i d W i
n d o w s I n s t a l l e r p a c k
a g e .
/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 #11958] (Closed) obscure error message from pip package provider when python-pip is not installed
Issue #11958 has been updated by Michael Stahnke. Status changed from Merged - Pending Release to Closed released in 2.7.10rc1 Bug #11958: obscure error message from pip package provider when python-pip is not installed https://projects.puppetlabs.com/issues/11958 Author: Ahmed El Gamil Status: Closed Priority: Normal Assignee: Kelsey Hightower Category: provider Target version: 2.7.10 Affected Puppet version: 2.7.6 Keywords: error usability ux Branch: https://github.com/puppetlabs/puppet/pull/337 Hi, Puppet generates an obscure error when the pip command is not installed or not in PATH. Error is like : [default] err: /Stage[main]/Uwsgi/Package[uwsgi]/ensure: change from absent to latest failed: Could not update: undefined method `pip' for #Puppet::Type::Package::ProviderPip:0xb72b8998 at /tmp/vagrant-puppet/manifests/nodes-vagrant.pp:17 A more informative error message should be displayed, or even stopping the puppet run. Thanks -- 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 #1886] (Closed) Add node cleanup capability
Issue #1886 has been updated by Michael Stahnke.
Status changed from Merged - Pending Release to Closed
released in 2.7.10rc1
Feature #1886: Add node cleanup capability
https://projects.puppetlabs.com/issues/1886
Author: micah -
Status: Closed
Priority: Normal
Assignee: Daniel Pittman
Category: newfeature
Target version: 2.7.10
Affected Puppet version: 0.25.0
Keywords: communitypatch
Branch: https://github.com/puppetlabs/puppet/pull/92
There really isn't a good mechanism to clean up when a node no longer exits.
You can remove it from your node definition, but there is a lot of junk hanging
around that should be cleaned up too. It would be really cool if the ability to
wipe a node was built into puppetmaster so you could just simply do something
like:
pre
puppetmaster --clean node
puppetmaster --clean node.domain.name
/pre
and this would clean up everything that puppet can find on that node. The
things that I can think of that need to get cleaned up are:
1. Signed certificates ($vardir/ssl/ca/signed/node.domain.pem)
2. Cached facts ($vardir/yaml/facts/node.domain.yaml)
3. Cached node stuff ($vardir/yaml/node/node.domain.yaml)
4. Reports ($vardir/reports/node.domain)
5. Stored configs. I found a script on the wiki that takes care of this:
pre
#!/usr/bin/env ruby
## Usage: sudo ./kill_node_in_storeconfigs_db.rb hostname as stored in hosts
table
require 'puppet/rails'
Puppet[:config] = /etc/puppet/puppet.conf
Puppet.parse_config
pm_conf = Puppet.settings.instance_variable_get(:@values)[:puppetmasterd]
adapter = pm_conf[:dbadapter]
args = {:adapter = adapter, :log_level = pm_conf[:rails_loglevel]}
case adapter
when sqlite3:
args[:dbfile] = pm_conf[:dblocation]
when mysql, postgresql:
args[:host] = pm_conf[:dbserver] unless pm_conf[:dbserver].empty?
args[:username] = pm_conf[:dbuser] unless pm_conf[:dbuser].empty?
args[:password] = pm_conf[:dbpassword] unless pm_conf[:dbpassword].empty?
args[:database] = pm_conf[:dbname]
else
raise ArgumentError, Invalid db adapter %s % adapter
end
ActiveRecord::Base.establish_connection(args)
if @host = Puppet::Rails::Host.find_by_name(ARGV[0].strip)
print Killing #{ARGV[0]}...
$stdout.flush
@host.destroy
puts done.
else
puts Can't find host #{ARGV[0]}.
end
/end
Sure, I can do all this manually, but this is a feature request because its a
little annoying and you forget all the pieces.
--
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 #2773] (Closed) buglet in provider/service/launchd.rb
Issue #2773 has been updated by Michael Stahnke. Status changed from Merged - Pending Release to Closed released in 2.7.10rc1 Bug #2773: buglet in provider/service/launchd.rb https://projects.puppetlabs.com/issues/2773 Author: eric sorenson Status: Closed Priority: High Assignee: Gary Larizza Category: service Target version: 2.7.10 Affected Puppet version: 0.25.1 Keywords: osx launchd Branch: https://github.com/puppetlabs/puppet/pull/324 I added a persistent postfix plist to replace the run-on-demand one distributed with OSX. (Which causes our nagios mailqueue check to fail annoyingly because qmgr doesn't run all the time). So upon copying the plist, process status should have been 'enabled' but 'stopped'. But it wouldn't start up by itself: pre debug: Service[postfix](provider=launchd): Executing 'launchctl load /System/Library/LaunchDaemons/org.postfix.master.plist' err: //mail::nullclient/Service[postfix]/ensure: change from stopped to running failed: Unable to start service: org.postfix.master at path: /System/Library/LaunchDaemons/org.postfix.master.plist /pre I manually got it working with 'launchctl load -w' , but the conditional in the start() method was not being triggered. After resetting my system back to previous state and changing the check as below, I get the expected result: pre debug: //mail::nullclient/Service[postfix]: Changing ensure debug: //mail::nullclient/Service[postfix]: 1 change(s) debug: Service[postfix](provider=launchd): Executing 'launchctl load -w /System/Library/LaunchDaemons/org.postfix.master.plist' notice: //mail::nullclient/Service[postfix]/ensure: ensure changed 'stopped' to 'running' /pre So it seems 'enabled' (in puppet's view of things) but 'stopped' may still need -w to overcome a 'disabled' key in launchd's little mind. What do you think? pre --- a/lib/puppet/provider/service/launchd.rb +++ b/lib/puppet/provider/service/launchd.rb @@ -163,7 +163,7 @@ Puppet::Type.type(:service).provide :launchd, :parent = :base do did_enable_job = false cmds = [] cmds :launchctl :load -if self.enabled? == :false # launchctl won't load disabled jobs +if self.enabled? == :false || self.status == :stopped # launchctl won't load disabled jobs cmds -w did_enable_job = true 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 - Feature #2927] (Closed) Symbolic Modes for the File type.
Issue #2927 has been updated by Michael Stahnke. Status changed from Merged - Pending Release to Closed released in 2.7.10rc1 Feature #2927: Symbolic Modes for the File type. https://projects.puppetlabs.com/issues/2927 Author: Trevor Vaughan Status: Closed Priority: High Assignee: Daniel Pittman Category: file Target version: 2.7.10 Affected Puppet version: development Keywords: file, mode, symbolic Branch: https://github.com/puppetlabs/puppet/pull/230 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 #3419] (Closed) OS X 10.6 Ruby can't set supplementary groups
Issue #3419 has been updated by Michael Stahnke. Status changed from Merged - Pending Release to Closed Target version changed from 2.7.x to 2.7.10 released in 2.7.10rc1 Bug #3419: OS X 10.6 Ruby can't set supplementary groups https://projects.puppetlabs.com/issues/3419 Author: Nigel Kersten Status: Closed Priority: Normal Assignee: Krzysztof Wilczynski Category: OSX Target version: 2.7.10 Affected Puppet version: 0.25.4 Keywords: Branch: https://github.com/puppetlabs/puppet/pull/328 pre nigelk$ sudo ruby -e old_groups = Process.groups; Process.groups = old_groups -e:1:in `groups=': Invalid argument (Errno::EINVAL) from -e:1 /pre This causes suidmanager to blow up. I'm marking this to be fixed for 0.25.5 unless anyone violently objects. It's a platform bug yes, but look at all the stuff you guys do for RHEL :) -- 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 #3757] (Closed) --enable and --disable should be improved
Issue #3757 has been updated by Michael Stahnke. Status changed from Merged - Pending Release to Closed released in 2.7.10rc1 Feature #3757: --enable and --disable should be improved https://projects.puppetlabs.com/issues/3757 Author: R.I. Pienaar Status: Closed Priority: Normal Assignee: Category: executables Target version: 2.7.10 Affected Puppet version: 0.25.4 Keywords: mcollective enabledisable Branch: https://github.com/puppetlabs/puppet/pull/216 At present the --enable/--disable and associated checks on the puppetd is all done via a lock file /var/lib/puppet/state/puppetdlock. My investigations reveal the behavior of this file to be: * if exist and it's empty, someone ran --disable * if exist and it's got a PID in it puppetd is doing a manifest run at present * if it's absent its enabled and not running The problem comes when you want to disable the daemon while it's running a manifest. The lock file with PID in it will remain in place and once puppetd is done doing its run it will remove the lock file, leaving your client enabled when infact it was asked to disable the client and not run in future. So I want to be able to disable future runs even while a current run is happening. The easiest might be to have 2 lock files - one to indicate enabled/disabled and one to indicate running dont start another concurrent run. -- 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 #4836] (Closed) puppetd --disable improvements
Issue #4836 has been updated by Michael Stahnke. Status changed from Merged - Pending Release to Closed released in 2.7.10rc1 Feature #4836: puppetd --disable improvements https://projects.puppetlabs.com/issues/4836 Author: micah - Status: Closed Priority: Low Assignee: Category: error reporting Target version: 2.7.10 Affected Puppet version: 0.25.5 Keywords: enabledisable Branch: https://github.com/puppetlabs/puppet/pull/216 Occasionally I disable regular puppetd runs on a system by doing: pre # puppetd --disable /pre This works fine, except that it could be improved in two ways: 1. If it has been manually disabled, then when a run is attempted, it should print something more useful than this: pre notice: Run of Puppet configuration client already in progress; skipping /pre because well... that message isn't really true, its not in progress, rather it is currently disabled. 2. The something more useful that it could print could be either a default message notice: Puppet administratively disabled on this system; skipping, or a custom message that you can pass to the puppetd --disable, eg. puppetd --disable micah is fixing stunnel template would then print the following when a puppetd was running: notice: Puppet is administratively disabled because micah is fixing stunnel template; skipping run -- 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 #4855] (Closed) group resources on OS X may fail is group members are non-existant
Issue #4855 has been updated by Michael Stahnke.
Status changed from Merged - Pending Release to Closed
released in 2.7.10rc1
Bug #4855: group resources on OS X may fail is group members are non-existant
https://projects.puppetlabs.com/issues/4855
Author: Clay Caviness
Status: Closed
Priority: Normal
Assignee: Gary Larizza
Category: OSX
Target version: 2.7.10
Affected Puppet version: 2.6.1
Keywords:
Branch: https://github.com/puppetlabs/puppet/pull/325
The group provider on OS X uses dseditgroup to manage group membership. Due
to Apple bug 8481241 (dseditgroup can't remove unknown users from groups),
however, if the puppet group provider needs to remove a non-existant user from
a group it manages, it will fail.
To reproduce, first apply:
pre
group { testgroup: ensure = present, members = [testuser, root],
require = User[testuser] }
user { testuser: ensure = present }
[...]info: Applying configuration version '1285616257'
debug: Puppet::Type::User::ProviderDirectoryservice: Executing '/usr/bin/dscl
-plist . -list /Users'
debug: Puppet::Type::User::ProviderDirectoryservice: Executing '/usr/bin/dscl
-plist . -list /Users'
debug: User[testuser](provider=directoryservice): Executing '/usr/bin/dscl
-plist . -create /Users/testuser GeneratedUID
90209F1B-B066-4630-8BD0-5B19C640CBFF'
notice: /Stage[main]//User[testuser]/ensure: created
debug: Puppet::Type::Group::ProviderDirectoryservice: Executing '/usr/bin/dscl
-plist . -list /Groups'
debug: Puppet::Type::Group::ProviderDirectoryservice: Executing '/usr/bin/dscl
-plist . -read /Groups/testgroup'
debug: Group[testgroup](provider=directoryservice): Executing 'dseditgroup -o
edit -n . -a root testgroup'
notice: /Stage[main]//Group[testgroup]/members: members changed 'testuser' to
'testuser,root'
debug: Finishing transaction 2194047380
/pre
Delete the user via:
predscl . -delete /Users/testuser/pre
(Alternatively, the user can be deleted via puppet, though ordering may allow
this to be successful.)
Now try to apply a change to the group that would cause the testuser user to be
removed from group membership:
pre
group { testgroup: ensure = present, members = root}
[...]
info: Applying configuration version '1285616630'
debug: Puppet::Type::Group::ProviderDirectoryservice: Executing '/usr/bin/dscl
-plist . -list /Groups'
debug: Puppet::Type::Group::ProviderDirectoryservice: Executing '/usr/bin/dscl
-plist . -read /Groups/testgroup'
debug: Group[testgroup](provider=directoryservice): Executing 'dseditgroup -o
edit -n . -d testuser testgroup'
err: /Stage[main]//Group[testgroup]/members: change from roottestuser to root
failed: Could not remove testuser from group: testgroup, Execution of
'dseditgroup -o edit -n . -d testuser testgroup' returned 200: Record was not
found.
debug: Finishing transaction 2190850540
/pre
**All** attempts to make changes to the group membership from this point will
fail, as dseditgroup cannot remove a user from a group if that user does not
exist.
Running puppet 2.6.1 on OS X 10.6.4.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #4865] (Closed) Puppet debug mode should print resource type/title before resource evaluation and time taken after.
Issue #4865 has been updated by Michael Stahnke. Status changed from Merged - Pending Release to Closed released in 2.7.10rc1 Feature #4865: Puppet debug mode should print resource type/title before resource evaluation and time taken after. https://projects.puppetlabs.com/issues/4865 Author: James Turnbull Status: Closed Priority: High Assignee: Daniel Pittman Category: error reporting Target version: 2.7.10 Affected Puppet version: 2.6.1 Keywords: usability Branch: https://github.com/puppetlabs/puppet/pull/202 1) Only on the client 2) Time taken during each atomic activity So: notice: File... 0.05s notice: Exec.. 1.2s Ideally, this data would only be collected during debug mode. This is for the case where you have something hanging, but you can't figure out what it is because the debug mode in puppet only prints the statement *after* it has run it. This would let everyone determine the hang points, or points of precise optimization. If there's already a way to get this information, that would be great too. --summarize just isn't quite fine grained enough. -- 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 #5246] (Closed) Puppetd does not remove it's pidfile when it exits
Issue #5246 has been updated by Michael Stahnke. Status changed from Merged - Pending Release to Closed Target version changed from 2.7.x to 2.7.10 released in 2.7.10rc1 Bug #5246: Puppetd does not remove it's pidfile when it exits https://projects.puppetlabs.com/issues/5246 Author: R.I. Pienaar Status: Closed Priority: Normal Assignee: Category: agent Target version: 2.7.10 Affected Puppet version: 2.6.2 Keywords: mcollective Branch: When running puppetd it should delete its pid file when it exits pre root 20572 2.0 0.5 116736 35256 ?Ss 23:10 0:00 /usr/bin/ruby /usr/sbin/puppetd --onetime --splaylimit 30 --splay /pre The pid file /var/run/puppet/agent.pid would have 20572 as expected, the puppet run completes ok: pre Nov 9 23:11:27 xen1 puppet-agent[20572]: Finished catalog run in 19.68 seconds /pre But it leaves the pid file on the disk after exiting -- 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 #5421] (Closed) Fileresource: Link should autorequire target
Issue #5421 has been updated by Michael Stahnke.
Status changed from Merged - Pending Release to Closed
Target version changed from 2.7.9 to 2.7.10
released in 2.7.10rc1
Feature #5421: Fileresource: Link should autorequire target
https://projects.puppetlabs.com/issues/5421
Author: Stefan Schulte
Status: Closed
Priority: Normal
Assignee: Stefan Schulte
Category: file
Target version: 2.7.10
Affected Puppet version:
Keywords:
Branch: https://github.com/stschulte/puppet/tree/feature/2.7.x/5421
When you manage links with puppet it's possible that you have to define
explicit requires. Example:
file { '/foo/bar':
ensure = directory,
}
file { '/link':
ensure = link,
target = '/foo/bar',
}
This works, because you can create a dead link. But if you now do
file { '/link/i_dont_care_it_was_a_link':
ensure = file,
}
this fileresource does autorequire the link, but you cannot be sure, that the
target exists. I would like that `File['/link']` autorequires
`File['/foo/bar']`.
Anything that speaks against this autorequire?
--
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 #6412] (Closed) Can not test hash key exist?, or array element exist? in puppet
Issue #6412 has been updated by Michael Stahnke.
Status changed from Merged - Pending Release to Closed
released in 2.7.10rc1
Bug #6412: Can not test hash key exist?, or array element exist? in puppet
https://projects.puppetlabs.com/issues/6412
Author: Nan Liu
Status: Closed
Priority: Normal
Assignee:
Category: language
Target version: 2.7.10
Affected Puppet version: 2.6.4
Keywords:
Branch: https://github.com/puppetlabs/puppet/pull/211
The following tests fails in puppet for both array and hash:
$a=['1', '2', '3']
if $a[4] {
notice (a[4] exists.)
}
$b={}
$b['bar'] = 'foo'
if $b['baz'] {
notice (b['baz'] exists.)
}
The test is actually checking for the existence of variable $a, $b, testing
using == undef, == '' does not correct this behavior.
--
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 #6830] (Closed) Specs should all pass under Ruby 1.9
Issue #6830 has been updated by Michael Stahnke. Status changed from Accepted to Closed Target version changed from 2.7.x to 2.7.10 released in 2.7.10rc1 Bug #6830: Specs should all pass under Ruby 1.9 https://projects.puppetlabs.com/issues/6830 Author: Matt Robinson Status: Closed Priority: Normal Assignee: Category: Target version: 2.7.10 Affected Puppet version: Keywords: ruby19 Branch: I got the tests so that they would run in #6820. That left 2003 failures in the specs (not sure about the Test::Unit tests), so this ticket can serve as an umbrella for commits that fix these specs. I doubt all specs will be fixed in one commit series. -- 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 #7106] (Closed) last_run_summary.yaml is only readable by root
Issue #7106 has been updated by Michael Stahnke. Status changed from Merged - Pending Release to Closed released in 2.7.10rc1 Bug #7106: last_run_summary.yaml is only readable by root https://projects.puppetlabs.com/issues/7106 Author: R.I. Pienaar Status: Closed Priority: Normal Assignee: Category: plumbing Target version: 2.7.10 Affected Puppet version: Keywords: Branch: https://github.com/puppetlabs/puppet/pull/213 The last_run_summary.yaml file in 2.6.8 is created as root only readable: pre -rw-rw 1 root root 413 Apr 14 13:18 /var/lib/puppet/state/last_run_summary.yaml /pre Most monitoring tend to not run as root, it would be nice if the modes/ownership were configurable. -- 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 #7110] (Closed) Better SSL error message when retrieved certificate does not match private key
Issue #7110 has been updated by Michael Stahnke. Status changed from Merged - Pending Release to Closed Target version set to 2.7.10 released in 2.7.10rc1 Bug #7110: Better SSL error message when retrieved certificate does not match private key https://projects.puppetlabs.com/issues/7110 Author: Matt Robinson Status: Closed Priority: Normal Assignee: Joshua Lifton Category: SSL Target version: 2.7.10 Affected Puppet version: 2.6.0 Keywords: Branch: If you try to connect to a puppet master fort the first time using an agent that already has a signed cert on the master (this may happen if you need to wipe your agent but forget to revoke the dead agent's cert on the master), you get the following: /Users/matthewrobinson/work/puppet/lib/puppet/ssl/host.rb:166:in `certificate' /Users/matthewrobinson/work/puppet/lib/puppet/ssl/host.rb:227:in `wait_for_cert' /Users/matthewrobinson/work/puppet/lib/puppet/application/agent.rb:194:in `setup_host' /Users/matthewrobinson/work/puppet/lib/puppet/application/agent.rb:259:in `setup' /Users/matthewrobinson/work/puppet/lib/puppet/application.rb:304:in `run' /Users/matthewrobinson/work/puppet/lib/puppet/application.rb:420:in `hook' /Users/matthewrobinson/work/puppet/lib/puppet/application.rb:304:in `run' /Users/matthewrobinson/work/puppet/lib/puppet/application.rb:411:in `exit_on_fail' /Users/matthewrobinson/work/puppet/lib/puppet/application.rb:304:in `run' /Users/matthewrobinson/work/puppet/sbin/puppetd:4 err: Could not request certificate: Retrieved certificate does not match private key; please remove certificate from server and regenerate it with the current key The error message should say which retrieved certificate (presumably it's retrieving the the already signed cert for the old agent) and which private key (presumably it's the private key that was generated before sending a CSR to the master) don't match. This could be done by including the CN for the cert and some fingerprints or something so you can tell what doesn't match what. And then some more detail on HOW to remove the certificate from the server would be helpful. -- 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.
