[Puppet - Bug #5240] Default ownership for newly created files when uid/gid are unspecified
Issue #5240 has been updated by Thomas Guthmann.
Bump.
I am using puppet 3.0.1 and we still have this problem. 99% of the time we set
owner, group and mode but lately we found some oversights. In puppet 2.7 all
files were owned by root and since we've migrated to our new puppet 3 platform
files are own by puppet (not your fault it's how we set it up). And
consequently, we discover this issue. You talked about a change for a major
version, looks like you missed a chance to fix this bug for puppet 3.x.
I believe we should be able to set the default in the main config therefore
people can setup whatever they prefer. If no defaults are set in the main
config, I would recommend deploy the file as root:root. But, yes this can be a
philosophical discussion. You just have to take a decision and document it.
Bug #5240: Default ownership for newly created files when uid/gid are
unspecified
https://projects.puppetlabs.com/issues/5240#change-75474
Author: Markus Falb
Status: Investigating
Priority: Normal
Assignee: Nigel Kersten
Category: file
Target version:
Affected Puppet version: 0.25.5
Keywords:
Branch:
file { /bla/bla.txt:
ensure = file,
source = puppet:///bla/bla.txt,
}
The file on puppetmaster belongs to user x with uid y and it is created on the
client with uid y whatever user this translates to.
A user for uid y may or may not exists on the client. uids/gids on puppetmaster
and puppetd are not necessarily synchronised. If I forget to set a ownership
explicitly possibly unrelated users on the client may access files. This
behaviour is potentially unsecure.
On puppetmaster (note the -n switch):
#$ ls -n bla.txt
-rw-r--r-- 1 502 301 4 8 Nov 16:25 bla.txt
The result on the client (user/group does not exist):
#$ ls -l bla.txt
-rw-r--r-- 1 502 301 4 Nov 8 16:39 bla.txt
Expected behaviour: I would like to rely on reasonable defaults. When no
user/group is explicitly defined, files should be created with ownership of the
user puppet runs as:
#$ ls -l bla.txt
-rw-r--r-- 1 root root 4 Nov 8 16:39 bla.txt
--
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 #16730] (In Topic Branch Pending Review) Hiera ignores calling_module and calling_class pseudo variables
Issue #16730 has been updated by Avishai Ish-Shalom.
Status changed from Code Insufficient to In Topic Branch Pending Review
Fixed the nil issue.
Bug #16730: Hiera ignores calling_module and calling_class pseudo variables
https://projects.puppetlabs.com/issues/16730#change-75475
Author: Avishai Ish-Shalom
Status: In Topic Branch Pending Review
Priority: Urgent
Assignee:
Category:
Target version:
Affected Puppet version: 3.0.1
Keywords: hiera
Branch: https://github.com/puppetlabs/puppet/pull/1214
in puppet 2.7.x with hiera, one could use the following hierarchy:
pre
:hierarchy:
- %{calling_module}
- common
/pre
In 3.x calling_module is no longer replaced with the proper value. This is
because lookup is given a Puppet::Parser::Scope object which does not have the
calling_module and calling_class keys. We need hiera to wrap the scope object
with Hiera::Scope
pre
--- puppet/lib/hiera_puppet.rb.bak 2012-10-03 08:16:04.641709827 -0400
+++ puppet/lib/hiera_puppet.rb 2012-10-03 08:16:15.982710195 -0400
@@ -6,9 +6,7 @@
module_function
def lookup(key, default, scope, override, resolution_type)
-unless scope.respond_to?([])
- scope = Hiera::Scope.new(scope)
-end
+scope = Hiera::Scope.new(scope)
answer = hiera.lookup(key, default, scope, override, resolution_type)
/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 #14857] gid on files and directories don't change if group's gid is changed
Issue #14857 has been updated by Bram Mertens. Hi, I agree that puppet shouldn't alter the ownership of files just anywhere on the file system but it should change the ownership in the user's home directory. On my fedora 17 system running version 2.7.18 changing the user ID and group ID of one of my test accounts the group ownership was not modified when puppet changed the UID and GID of an account. [m8ram@lxde puppet]$ sudo find /home/thor/ -ls 23592974 drwx-- 4 thor thor 4096 Nov 1 14:18 /home/thor/ 23593044 drwxr-xr-x 2 thor thor 4096 Jan 14 2012 /home/thor/.gnome2 23592984 -rw-r--r-- 1 thor thor 124 Jul 24 10:38 /home/thor/.bashrc 23592994 -rw-r--r-- 1 thor thor 18 Jul 24 10:38 /home/thor/.bash_logout 23593014 drwxr-xr-x 4 thor thor 4096 May 22 22:40 /home/thor/.mozilla 23593024 drwxr-xr-x 2 thor thor 4096 Jan 14 2012 /home/thor/.mozilla/plugins 23593034 drwxr-xr-x 2 thor thor 4096 Jan 14 2012 /home/thor/.mozilla/extensions 23593004 -rw-r--r-- 1 thor thor 193 Jul 24 10:38 /home/thor/.bash_profile [m8ram@lxde puppet]$ id thor uid=503(thor) gid=1028(thor) groups=1028(thor) [m8ram@lxde puppet]$ sudo puppet agent --server=lxde --test /usr/share/rubygems/rubygems/custom_require.rb:36:in `require': iconv will be deprecated in the future, use String#encode instead. /usr/share/ruby/vendor_ruby/puppet/provider/service/bsd.rb:12: warning: class variable access from toplevel /usr/share/ruby/vendor_ruby/puppet/provider/service/freebsd.rb:8: warning: class variable access from toplevel /usr/share/ruby/vendor_ruby/puppet/provider/service/freebsd.rb:9: warning: class variable access from toplevel /usr/share/ruby/vendor_ruby/puppet/provider/service/freebsd.rb:10: warning: class variable access from toplevel info: Caching catalog for lxde info: Applying configuration version '1351775820' notice: /Stage[main]/Arda/Group[thor]/gid: gid changed '1028' to '1003' notice: /Stage[main]/Arda/User[thor]/uid: uid changed '503' to '1003' notice: /Stage[main]/Arda/User[thor]/comment: comment changed '' to 'thor' notice: Finished catalog run in 2.03 seconds [m8ram@lxde puppet]$ sudo find /home/thor/ -ls 23592974 drwx-- 4 thor 1028 4096 Nov 1 14:18 /home/thor/ 23593044 drwxr-xr-x 2 thor 1028 4096 Jan 14 2012 /home/thor/.gnome2 23592984 -rw-r--r-- 1 thor 1028 124 Jul 24 10:38 /home/thor/.bashrc 23592994 -rw-r--r-- 1 thor 1028 18 Jul 24 10:38 /home/thor/.bash_logout 23593014 drwxr-xr-x 4 thor 1028 4096 May 22 22:40 /home/thor/.mozilla 23593024 drwxr-xr-x 2 thor 1028 4096 Jan 14 2012 /home/thor/.mozilla/plugins 23593034 drwxr-xr-x 2 thor 1028 4096 Jan 14 2012 /home/thor/.mozilla/extensions 23593004 -rw-r--r-- 1 thor 1028 193 Jul 24 10:38 /home/thor/.bash_profile [m8ram@lxde puppet]$ id thor uid=1003(thor) gid=1003(thor) groups=1003(thor) [m8ram@lxde puppet]$ Regards Bram Bug #14857: gid on files and directories don't change if group's gid is changed https://projects.puppetlabs.com/issues/14857#change-75478 Author: jist anidiot Status: Needs More Information Priority: Normal Assignee: jist anidiot Category: Target version: Affected Puppet version: 2.7.12 Keywords: Branch: Problem: Someone created a group on a RHEL 5 box manually (in my specific case it was in conjunction with a user). Puppet comes along and changes that's group's gid (as well as the uid for the user). However all the files and directories that had that group do not get updated with the new gid (as an aside the uid does seem to get changed). I would think a gid id change for a group should result in something similar as a uid change for a user. -- 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 #16728] puppet agent --verbose has lost notice tag
Issue #16728 has been updated by Malcolm Howe.
If I'm understanding it correctly then, yes, Pieter van de Bruggen's described
behaviour would address my problem as in the example I gave it would be
possible to tell that the diff output was being logged at a notice level, not a
debug level.
Bug #16728: puppet agent --verbose has lost notice tag
https://projects.puppetlabs.com/issues/16728#change-75482
Author: Malcolm Howe
Status: Needs Decision
Priority: Normal
Assignee: eric sorenson
Category: agent
Target version:
Affected Puppet version: 3.0.0
Keywords: ux
Branch:
In puppet 2.7 lines output from puppet agent --verbose start with a level tag
such as debug, notice, info, warning, err with the exception of lines that
could be considered as continuation lines. In puppet 3.0 these have become
capitalized (Debug, Info etc) and the range of the colouring has changed which
are fine but notice has disappeared. Example:
Puppet 2.7
^[[0;37mdebug: /File[/usr/local/admin/etc/cronjobs]/content: Executing
'diff /usr/local/admin/etc/cronjobs
/tmp/puppet-file20121003-21437-1039k7-0'^[[0m
^[[0;36mnotice: /File[/usr/local/admin/etc/cronjobs]/content:
394c394
On OX_HFS_DD At 07:31
---
On OX_HFS_DD At 07:30
^[[0m
^[[0;36mnotice: /File[/usr/local/admin/etc/cronjobs]/content: content
changed '{md5}bab2e7212b6dbf31a4aa24d80af20dff' to
'{md5}7a959b40ab3403d747fe953c1855343d'^[[0m
puppet 3.0.0
^[[0;36mDebug^[[0m: Executing 'diff /usr/local/admin/etc/cronjobs
/tmp/puppet-file20121003-18288-1q7segx-0'
/File[/usr/local/admin/etc/cronjobs]/content:
394c394
On OX_HFS_DD At 07:31
---
On OX_HFS_DD At 07:30
/File[/usr/local/admin/etc/cronjobs]/content: content changed
'{md5}d89edc6045aa721fba77ec0f54c8c2d2' to
'{md5}101441e8bf893cce06ccb87983626b8b'
This is a nuisance when trying to analyse the output with a script.
I am, of course, assuming it isn't an intentional change. If not I'm reporting
it as a bug.
--
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 #1107] Allow exclusion in tags specified on the command line
Issue #1107 has been updated by Andrew Stangl. I would also like to see this feature become available, it opens up lots of possibilities Feature #1107: Allow exclusion in tags specified on the command line https://projects.puppetlabs.com/issues/1107#change-75489 Author: Martha Greenberg Status: Accepted Priority: Low Assignee: Category: executables Target version: Affected Puppet version: 0.24.4 Keywords: Branch: Tags should allow exclusions, i.e. all,!test That's probably the most common case you would want to use tags, so that rather than tagging everything as production, you can just tag those items you are playing with. -- 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 #17350] (Unreviewed) improve invalid parameter error message from create resources
Issue #17350 has been reported by Luke Bigum. Bug #17350: improve invalid parameter error message from create resources https://projects.puppetlabs.com/issues/17350 Author: Luke Bigum Status: Unreviewed Priority: Normal Assignee: Category: Target version: Affected Puppet version: 3.0.0 Keywords: Branch: The error message from create_resources() when an invalid parameter is given is a little difficult to understand. For example if I have some Hiera data like this (where the 'enable' parameter is mis-spelt as 'enabled'): service: puppet: enabled: true Then it would be more helpful if the error message looked something like this: Invalid parameter enabled for resource type 'service' via create_resources() on node foo Instead of what it does now: Invalid parameter enabled on node foo -- 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 #17129] (Accepted) SSL REST API bails out completely on permissions errors
Issue #17129 has been updated by Josh Cooper. Status changed from In Topic Branch Pending Review to Accepted The current behavior in 2.7.x is: rest client issues a request, and receives an 400 HTTP response: pre $ curl -v --insecure -H Accept: yaml https://sirrus.puppetlabs.lan:8140/production/certificate_requests/all ... HTTP/1.1 400 Permission denied - /Users/josh/scratch/master/badperms/ssl/ca/requests/agent1.pem /pre And I see the exception and error message in syslog: pre Nov 1 10:27:11 sirrus puppet-master[86589]: Permission denied - /Users/josh/scratch/master/badperms/ssl/ca/requests/agent1.pem /pre If we were to change the behavior as proposed, then it means `puppet cert list --all` would return 0, instead of 24 as it does now. The change also wouldn't handle cases where the pem file is corrupt (asn.1 parsing fails, we except pem encoding, but it's der, it's encrypted with a passphrase, etc). In other words, I don't think we should be clever and try to infer the client's intent. I would rather us fail fast and report the unrecoverable error to the client as we currently do. Alternatively, we could return the exception instance instead of the certificate instance: pre HTTP/1.1 200 OK ... - !ruby/exception:Errno::EACCES message: Permission denied - /Users/josh/scratch/master/badperms/ssl/ca/requests/agent1.pem /pre But rest clients expect certificate instances: pre $ puppet cert list --all err: Could not call list: undefined method `name' for #lt;Errno::EACCES:0x10ec69e90 /pre Comments? Bug #17129: SSL REST API bails out completely on permissions errors https://projects.puppetlabs.com/issues/17129#change-75500 Author: Max Martin Status: Accepted Priority: Normal Assignee: Josh Cooper Category: Target version: 2.7.20 Affected Puppet version: Keywords: ssl Branch: https://github.com/puppetlabs/puppet/pull/1248 If the puppetmaster doesn't have permission to access any of the .pem files waiting in the requests directory (in this case, `/etc/puppetlabs/puppet/ssl/ca/requests`), it will bail out completely when all CSRs are requested by hitting `/certificate_statuses/all`. In this example, I have a number of .pem files which the puppetmaster can access, and one that it cannot: pre root@master:/etc/puppetlabs/puppet/ssl/ca/requests# ls -al total 60 drwxr-xr-x 2 pe-puppet pe-puppet 4096 2012-10-19 21:18 . drwxrwx--- 5 pe-puppet pe-puppet 4096 2012-10-19 01:55 .. rw-r 1 peadmin peadmin 1590 2012-10-19 20:06 example_38463.pem rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 20:06 example_46536.pem rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 20:06 example_62602.pem rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 20:06 example_66483.pem rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 21:15 example_67152.pem rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 20:06 example_69811.pem rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 20:06 example_7469.pem rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 21:15 example_78904.pem rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 21:15 example_90326.pem rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 21:15 example_90906.pem rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 21:15 example_92088.pem rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 20:06 example_93947.pem /pre when I attempt to hit `certificate_statuses/all` for the production environment, the whole response is `Permission denied - /etc/puppetlabs/puppet/ssl/ca/requests/example_38463.pem` The API should be able handle the permissions error and return information about all the waiting CSRs, at least those with correct permissions. It should possibly also return information about the .pem file with incorrect permissions. -- 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 #17358] (Unreviewed) Requiring a non-available gem in a plugin causes unrelated things to blow up
Issue #17358 has been reported by Ben Ford. Bug #17358: Requiring a non-available gem in a plugin causes unrelated things to blow up https://projects.puppetlabs.com/issues/17358 Author: Ben Ford Status: Unreviewed Priority: Normal Assignee: Category: Target version: Affected Puppet version: 2.7.19 Keywords: Branch: I wrote a Hiera backend for a client. I wrote against PE, so i used ActiveSupport, forgetting that it's not installed on POSS. Immediately after adding it as a backend in my hiera.yaml, the metaphorical doody started flying. The backend obviously didn't work, but facts and other plugins also stopped working. Facter didn't even work from the command line unless I set FACTERLIB. And worse, there was absolutely no notice of the failed require in the output, even with --debug. Unfortunately, I cannot replicate this on my own install! -- 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 #17361] (Unreviewed) Daemon forking for catalog run disabled by code merge
Issue #17361 has been reported by Patrick Mooney. Bug #17361: Daemon forking for catalog run disabled by code merge https://projects.puppetlabs.com/issues/17361 Author: Patrick Mooney Status: Unreviewed Priority: Normal Assignee: eric sorenson Category: agent Target version: Affected Puppet version: 3.0.1 Keywords: puppet agent daemon fork forking Branch: Back in January, functionality was added to allow the agent daemon to fork prior to a catalog run. This was introduced in 6812ee9fc51f327f3a74fc6a6c0eefd9758d0134. In a later merge (23a1a17bebaadbb9b3a1611f34ae46d06b531136), the changes to lib/puppet/daemon.rb that enabled the forking function (agent.should_fork = true) were discarded. As such, the forking code path is inaccessible in the current version. -- 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 #17129] (Rejected) SSL REST API bails out completely on permissions errors
Issue #17129 has been updated by Josh Cooper. Status changed from Accepted to Rejected Target version deleted (2.7.20) After talking this over with Jeff and Max, there's no good way in our current REST API for a `search` method to return a combination of success and failed results. Since changing the implementation as described in this ticket to ignore bad certs would cause `puppet cert list --all` to return 0, when previously it didn't, I'm rejecting this. Bug #17129: SSL REST API bails out completely on permissions errors https://projects.puppetlabs.com/issues/17129#change-75515 Author: Max Martin Status: Rejected Priority: Normal Assignee: Josh Cooper Category: Target version: Affected Puppet version: Keywords: ssl Branch: https://github.com/puppetlabs/puppet/pull/1248 If the puppetmaster doesn't have permission to access any of the .pem files waiting in the requests directory (in this case, `/etc/puppetlabs/puppet/ssl/ca/requests`), it will bail out completely when all CSRs are requested by hitting `/certificate_statuses/all`. In this example, I have a number of .pem files which the puppetmaster can access, and one that it cannot: pre root@master:/etc/puppetlabs/puppet/ssl/ca/requests# ls -al total 60 drwxr-xr-x 2 pe-puppet pe-puppet 4096 2012-10-19 21:18 . drwxrwx--- 5 pe-puppet pe-puppet 4096 2012-10-19 01:55 .. rw-r 1 peadmin peadmin 1590 2012-10-19 20:06 example_38463.pem rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 20:06 example_46536.pem rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 20:06 example_62602.pem rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 20:06 example_66483.pem rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 21:15 example_67152.pem rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 20:06 example_69811.pem rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 20:06 example_7469.pem rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 21:15 example_78904.pem rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 21:15 example_90326.pem rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 21:15 example_90906.pem rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 21:15 example_92088.pem rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 20:06 example_93947.pem /pre when I attempt to hit `certificate_statuses/all` for the production environment, the whole response is `Permission denied - /etc/puppetlabs/puppet/ssl/ca/requests/example_38463.pem` The API should be able handle the permissions error and return information about all the waiting CSRs, at least those with correct permissions. It should possibly also return information about the .pem file with incorrect permissions. -- 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 #15669] A more helpful error message when the puppet master is at the wrong version (2.7.x to 3.0)
Issue #15669 has been updated by Lee Lowder. Saw this brought up in IRC recently, so thought I'd add a few comments. I've got a 2.7.19 master and inadvertently wound up with a couple of 3.0.0 nodes. I get a similar message when these nodes run, but as a warning. The full output is available at https://gist.github.com/3996305 but the key parts are: Warning: Unable to fetch my node definition, but the agent run will continue: Warning: Could not intern from pson: source '#Puppet::Node:0x7f' not in PSON! Feature #15669: A more helpful error message when the puppet master is at the wrong version (2.7.x to 3.0) https://projects.puppetlabs.com/issues/15669#change-75517 Author: Ben Hughes Status: Needs Decision Priority: Normal Assignee: eric sorenson Category: usability Target version: 3.x Affected Puppet version: Keywords: errors Branch: At present, between the 2.7.x and 3.0 transition, when you have a 3.0 agent talk to a 2.7.x master you get the following: pre Error: Failed to apply catalog: Could not intern from pson: source '#lt;Puppet::Node:0x7f' not in PSON! /pre I imagine it won't be this simple, and this may not be the only case where that output is produced, but could we not add some code to the 2.7.x branch that detects that, and maybe goes Hey, I'm not saying it's definitely this, but is your master older than your client? That's not cool buddy. With the move to semver, can we not have that in the handshake, before we get to this part? So the agent/master tell each other what they are and what to expect? Like SSH does with it's connect. I imagine this bump is going to be hit a few times for people. Partly why I'm documenting it here. (and added the doc team as watchers) -- 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 #16637] Puppet confdir and vardir are wrong when running non-root
Issue #16637 has been updated by Jeff McCune.
Curtis Ruck wrote:
So looking at my issues deeper...
I am using a puppet manifest to build my puppet master (for production). So
my steps currently are creating the two sets of certificates (including CAs).
1) su - puppet -s /bin/bash -c puppet master --no-daemonize -v
Ah, I think I see your problem. When you start Puppet as non-root, it's going
to use the $HOME directory of the puppet user instead of the system wide
`$vardir`.
I think if you change your script to be something like this, you should be OK.
But remember, you're going to have to make sure the puppet user is able to
write into the system directories.
# These run as root, so they'll return the system directories:
confdir=$(puppet master --configprint confdir)
vardir=$(puppet master --configprint vardir)
# Have the non-root process use the system directories
# instead of the default personal directories:
su - puppet -s /bin/bash -c puppet master --confdir='${confdir}'
--vardir='${vardir}' --no-daemonize -v
2) puppet apply /etc/puppet/manifests/build.pp
In Step 1, it generates the /var/lib/puppet/.puppet/ssl directory.
In Step 2, it generates the /var/lib/puppet/ssl directory.
I can't seem to get #2 to not generate its own CA and certificates.
Step 1 is running as non-root so it has different default directories than Step
2, which _is_ running as root. I think you just need to make these two steps
match up. You could either run them both as the same effective UID, or
explicitly set `confdir` and `vardir` on one or both to match up with the other.
Hope this helps,
-Jeff
Bug #16637: Puppet confdir and vardir are wrong when running non-root
https://projects.puppetlabs.com/issues/16637#change-75524
Author: Jeff McCune
Status: Closed
Priority: Normal
Assignee:
Category: settings
Target version: 3.0.0
Affected Puppet version: 3.0.0
Keywords: telly settings defaults confdir vardir runmode run_mode master system
Branch: https://github.com/puppetlabs/puppet/pull/1194
# Overview
Puppet master should default to confdir of `~/.puppet` and vardir of
`~/.puppet/var` when running as non-root, instead defaults to `/etc/puppet` and
`/var/lib/puppet` respectively.
In Puppet 3.0.0, the semantics of the term, configuration directory (confdir)
are as follows:
1. If `confdir` is explicitly configured, this value wins.
2. If Puppet is running as root (or the OS equivalent) then use the system
configuration directory. (e.g. `/etc/puppet` for FOSS or
`/etc/puppetlabs/puppet` for PE)
3. In all other situations use `~/.puppet`
These semantics are no longer affected by the specific username when running
non-root, or the application being run (master, agent, etc...).
This is not actually the case in 3.0.0 though:
# Actual Behavior
pre
$ puppet master --verbose --no-daemonize
Error: Could not set 'directory' on ensure: Permission denied - /etc/puppet
Error: Could not set 'directory' on ensure: Permission denied -
/etc/puppetWrapped exception:
Permission denied - /etc/puppet
Error: /File[/etc/puppet]/ensure: change from absent to directory failed: Could
not set 'directory' on ensure: Permission denied - /etc/puppet
/File[/etc/puppet/var.master]: Dependency File[/etc/puppet] has failures: true
Warning: /File[/etc/puppet/var.master]: Skipping because of failed dependencies
/File[/etc/puppet/var.master/bucket]: Dependency File[/etc/puppet] has
failures: true
Warning: /File[/etc/puppet/var.master/bucket]: Skipping because of failed
dependencies
/File[/etc/puppet/var.master/log]: Dependency File[/etc/puppet] has failures:
true
Warning: /File[/etc/puppet/var.master/log]: Skipping because of failed
dependencies
/File[/etc/puppet/var.master/log/masterhttp.log]: Dependency File[/etc/puppet]
has failures: true
Warning: /File[/etc/puppet/var.master/log/masterhttp.log]: Skipping because of
failed dependencies
/File[/etc/puppet/var.master/yaml]: Dependency File[/etc/puppet] has failures:
true
Warning: /File[/etc/puppet/var.master/yaml]: Skipping because of failed
dependencies
/File[/etc/puppet/var.master/ssl]: Dependency File[/etc/puppet] has failures:
true
Warning: /File[/etc/puppet/var.master/ssl]: Skipping because of failed
dependencies
/File[/etc/puppet/var.master/ssl/public_keys]: Dependency File[/etc/puppet] has
failures: true
Warning: /File[/etc/puppet/var.master/ssl/public_keys]: Skipping because of
failed dependencies/File[/etc/puppet/var.master/lib]: Dependency
File[/etc/puppet] has failures: trueWarning: /File[/etc/puppet/var.master/lib]:
Skipping because of failed
dependencies/File[/etc/puppet/var.master/ssl/certificate_requests]: Dependency
File[/etc/puppet] has failures: true
Warning: /File[/etc/puppet/var.master/ssl/certificate_requests]: Skipping
because of failed dependencies/File[/etc/puppet/var.master/run]: Dependency
File[/etc/puppet] has failures: true
Warning:
[Puppet - Bug #17361] Daemon forking for catalog run disabled by code merge
Issue #17361 has been updated by Patrick Mooney. Added pull request [1253](https://github.com/puppetlabs/puppet/pull/1253) with a potential fix implementation. The feature was documented as being present in 3.0 [here](http://docs.puppetlabs.com/puppet/3/reference/release_notes.html#puppet-agent-is-more-efficient-in-daemon-mode). It would be really nice to see it functional in the next minor/patch release. Bug #17361: Daemon forking for catalog run disabled by code merge https://projects.puppetlabs.com/issues/17361#change-75525 Author: Patrick Mooney Status: Unreviewed Priority: Normal Assignee: eric sorenson Category: agent Target version: Affected Puppet version: 3.0.1 Keywords: puppet agent daemon fork forking Branch: Back in January, functionality was added to allow the agent daemon to fork prior to a catalog run. This was introduced in 6812ee9fc51f327f3a74fc6a6c0eefd9758d0134. In a later merge (23a1a17bebaadbb9b3a1611f34ae46d06b531136), the changes to lib/puppet/daemon.rb that enabled the forking function (agent.should_fork = true) were discarded. As such, the forking code path is inaccessible in the current version. -- 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 #17319] (Needs Decision) show_diff should honor loglevel
Issue #17319 has been updated by Andrew Parker.
Tracker changed from Bug to Feature
Status changed from Unreviewed to Needs Decision
Assignee set to eric sorenson
Target version deleted (2.7.20)
This is a request for a new feature, and after a bit of discussion with Nan and
Josh Cooper, this isn't a regression of functionality in 2.7. I'm removing the
target of 2.7.20 and sending this over to Eric for a decision about this.
Feature #17319: show_diff should honor loglevel
https://projects.puppetlabs.com/issues/17319#change-75533
Author: Jo Rhett
Status: Needs Decision
Priority: Normal
Assignee: eric sorenson
Category: reports
Target version:
Affected Puppet version: 2.7.19
Keywords:
Branch:
Right now the show_diff is shown every time the file is modified, no matter
what loglevel the file changes are set for. This defeats the entire purpose of
loglevel.
pre
On Tue, Mar 8, 2011 at 4:46 PM, Mohamed Lrhazi lrh...@gmail.com wrote:
I have resource for which I set this to debug, like so:
file { /tmp/foo:
content = inline_template(...),
loglevel = debug,
}
I was expecting the following command to not log anything about it,
but it does, it logs the diff of the file.. Why?
If you don't want to see the diff output when the file changes, turn
off the show_diff option.
Thanks,
Nan/pre
Sure, Nan. Perhaps if we don't want to see every resource changed, we should
turn off reporting altogether? Is this not exactly the purpose for loglevel?
Especially given that the diff is included with the resource report which is
properly included or not by loglevel, this could be easily handled the same way.
--
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 Moses Mendoza. Wiki: https://projects.puppetlabs.com/projects/facter/wiki/Wiki View differences: https://projects.puppetlabs.com/projects/facter/wiki/Wiki/diff/53 -- 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 Moses Mendoza. Downloading Puppet: https://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet View differences: https://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet/diff/215 -- 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 #17319] show_diff should honor loglevel
Issue #17319 has been updated by Jo Rhett.
I would argue that it is an implementation inconsistent with the existing
functionality. If one were to read the descriptions of tagmail reports in
conjunction with loglevel, the current implementation does not align with what
they say.
At the very least, documentation for show_diff needs to be created which says
is not logged at the same level as the file resource and will show up in
every report regardless of settings. Because without those clarifications, it
does not work as documented.
Anyway, this is all mincing words. I look forward to having this work as the
documentation would suggest.
Feature #17319: show_diff should honor loglevel
https://projects.puppetlabs.com/issues/17319#change-75535
Author: Jo Rhett
Status: Needs Decision
Priority: Normal
Assignee: eric sorenson
Category: reports
Target version:
Affected Puppet version: 2.7.19
Keywords:
Branch:
Right now the show_diff is shown every time the file is modified, no matter
what loglevel the file changes are set for. This defeats the entire purpose of
loglevel.
pre
On Tue, Mar 8, 2011 at 4:46 PM, Mohamed Lrhazi lrh...@gmail.com wrote:
I have resource for which I set this to debug, like so:
file { /tmp/foo:
content = inline_template(...),
loglevel = debug,
}
I was expecting the following command to not log anything about it,
but it does, it logs the diff of the file.. Why?
If you don't want to see the diff output when the file changes, turn
off the show_diff option.
Thanks,
Nan/pre
Sure, Nan. Perhaps if we don't want to see every resource changed, we should
turn off reporting altogether? Is this not exactly the purpose for loglevel?
Especially given that the diff is included with the resource report which is
properly included or not by loglevel, this could be easily handled the same way.
--
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] 'Puppet Augeas' wiki page has been updated
The 'Puppet Augeas' wiki page has been updated by Nick Fagerlund. Everybody must stop nesting defines inside classes, ugh. Puppet Augeas: https://projects.puppetlabs.com/projects/puppet/wiki/Puppet_Augeas View differences: https://projects.puppetlabs.com/projects/puppet/wiki/Puppet_Augeas/diff/38 -- 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 #17371] Setting owner, group, mode for files specified in puppet.conf no longer seems to work
Issue #17371 has been updated by eric sorenson.
Project changed from Puppet Community Package Repository to Puppet
Bug #17371: Setting owner, group, mode for files specified in puppet.conf no
longer seems to work
https://projects.puppetlabs.com/issues/17371#change-75549
Author: Andreas Ntaflos
Status: Unreviewed
Priority: Normal
Assignee:
Category:
Target version:
Affected Puppet version:
Keywords:
Branch:
It seems that setting owner, group and mode for files in puppet.conf by using
the following method, as explained in the configuration guide, no longer works
in Puppet 3.0 (using Puppet 3.0.1 here on Ubuntu 12.04):
/etc/puppet/puppet.conf:
[master]
...
autosign = /etc/puppet/autosign.conf { owner = puppet, group = puppet, mode
= 0664 }
The settings specified in the curly braces do not get applied to the file.
Instead, after changing the mode manually (`chmod 0664
/etc/puppet/autosign.conf`) it is reset to 0644 after a request to the
puppetmaster comes in. Interestingly it seems that when manually changing the
owner of the file it stays changed, even after a request comes in that triggers
the manually changed mode to be reset.
And as nfagerlund observed on IRC it seems that specifying an owner keeps the
mode setting from working. Setting a mode alone, i.e. `autosign =
/etc/puppet/autosign.conf { mode = 0664 }` works.
--
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 #15669] (Closed) A more helpful error message when the puppet master is at the wrong version (2.7.x to 3.0)
Issue #15669 has been updated by Andrew Parker. Status changed from Needs Decision to Closed This changed from a fatal error to just a warning because of the fix for #16327. Providing any more information about this isn't really reasonable without fixing #6789 or something else related to content negotiation and versioned protocols. Feature #15669: A more helpful error message when the puppet master is at the wrong version (2.7.x to 3.0) https://projects.puppetlabs.com/issues/15669#change-75550 Author: Ben Hughes Status: Closed Priority: Normal Assignee: eric sorenson Category: usability Target version: 3.x Affected Puppet version: Keywords: errors Branch: At present, between the 2.7.x and 3.0 transition, when you have a 3.0 agent talk to a 2.7.x master you get the following: pre Error: Failed to apply catalog: Could not intern from pson: source '#lt;Puppet::Node:0x7f' not in PSON! /pre I imagine it won't be this simple, and this may not be the only case where that output is produced, but could we not add some code to the 2.7.x branch that detects that, and maybe goes Hey, I'm not saying it's definitely this, but is your master older than your client? That's not cool buddy. With the move to semver, can we not have that in the handshake, before we get to this part? So the agent/master tell each other what they are and what to expect? Like SSH does with it's connect. I imagine this bump is going to be hit a few times for people. Partly why I'm documenting it here. (and added the doc team as watchers) -- 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 #15669] A more helpful error message when the puppet master is at the wrong version (2.7.x to 3.0)
Issue #15669 has been updated by Andrew Parker. Assignee deleted (eric sorenson) Target version deleted (3.x) Feature #15669: A more helpful error message when the puppet master is at the wrong version (2.7.x to 3.0) https://projects.puppetlabs.com/issues/15669#change-75551 Author: Ben Hughes Status: Closed Priority: Normal Assignee: Category: usability Target version: Affected Puppet version: Keywords: errors Branch: At present, between the 2.7.x and 3.0 transition, when you have a 3.0 agent talk to a 2.7.x master you get the following: pre Error: Failed to apply catalog: Could not intern from pson: source '#lt;Puppet::Node:0x7f' not in PSON! /pre I imagine it won't be this simple, and this may not be the only case where that output is produced, but could we not add some code to the 2.7.x branch that detects that, and maybe goes Hey, I'm not saying it's definitely this, but is your master older than your client? That's not cool buddy. With the move to semver, can we not have that in the handshake, before we get to this part? So the agent/master tell each other what they are and what to expect? Like SSH does with it's connect. I imagine this bump is going to be hit a few times for people. Partly why I'm documenting it here. (and added the doc team as watchers) -- 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 #17371] Setting owner, group, mode for files specified in puppet.conf no longer seems to work
Issue #17371 has been updated by Andrew Parker.
Affected Puppet version set to 3.0.1
Bug #17371: Setting owner, group, mode for files specified in puppet.conf no
longer seems to work
https://projects.puppetlabs.com/issues/17371#change-75553
Author: Andreas Ntaflos
Status: Unreviewed
Priority: Normal
Assignee:
Category:
Target version:
Affected Puppet version: 3.0.1
Keywords:
Branch:
It seems that setting owner, group and mode for files in puppet.conf by using
the following method, as explained in the configuration guide, no longer works
in Puppet 3.0 (using Puppet 3.0.1 here on Ubuntu 12.04):
/etc/puppet/puppet.conf:
[master]
...
autosign = /etc/puppet/autosign.conf { owner = puppet, group = puppet, mode
= 0664 }
The settings specified in the curly braces do not get applied to the file.
Instead, after changing the mode manually (`chmod 0664
/etc/puppet/autosign.conf`) it is reset to 0644 after a request to the
puppetmaster comes in. Interestingly it seems that when manually changing the
owner of the file it stays changed, even after a request comes in that triggers
the manually changed mode to be reset.
And as nfagerlund observed on IRC it seems that specifying an owner keeps the
mode setting from working. Setting a mode alone, i.e. `autosign =
/etc/puppet/autosign.conf { mode = 0664 }` works.
--
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 #14055] Windows packages should ignore exit code 3010
Issue #14055 has been updated by Josh Cooper. Target version changed from 3.0.x to 2.7.19 This was marked as fixed in 2.7.19, and reopened, but that turned out to be a different issue in puppet 3.0, so marking this as released in 2.7.19 again. Bug #14055: Windows packages should ignore exit code 3010 https://projects.puppetlabs.com/issues/14055#change-75557 Author: Wouter verhelst Status: Closed Priority: Normal Assignee: Josh Cooper Category: windows Target version: 2.7.19 Affected Puppet version: 2.7.13 Keywords: windows msi reboot Branch: https://github.com/puppetlabs/puppet/pull/851 Hi, I've been trying out puppet to manage some Windows machines. Installing MSI packages works most of the time, but in some cases an MSI will exit with exit state 3010. A quick google search revealed that this exit state means installation was successful, reboot pending. Unfortunately, puppet does not seem to know this, and marks the installation as failed, resulting in it being retried on every puppet run. It might be good if puppet ignored that exit state, so that the installation would at least be marked as done. -- 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 #17382] (Unreviewed) exec command quote handling
Issue #17382 has been reported by Chad Huneycutt.
Bug #17382: exec command quote handling
https://projects.puppetlabs.com/issues/17382
Author: Chad Huneycutt
Status: Unreviewed
Priority: Normal
Assignee:
Category:
Target version:
Affected Puppet version:
Keywords:
Branch:
I am having a hard time searching for this to see if it has already been
reported.
This worked on puppet 2.6, but since I upgraded to 2.7.19 it does not.
I have an exec like this:
exec { foo:
path = '/usr/bin',
command = printf '%s\t%s(rw,sync,no_root_squash)\n' '/export/$name'
'$name' bar,
}
puppet returns this when it tries to compile it:
err: /Stage[main]//Exec[foo]/returns: change from notrun to 0 failed: Could not
find command ' '
I suspect the quoting in the command, but I haven't had a chance to simplify it
and figure out exactly where the extraction is messing up.
--
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.
