Jira (PUP-10998) Cron Provider breaks on crontab with certain environment variables
Title: Message Title Joerg Jaspert commented on PUP-10998 Re: Cron Provider breaks on crontab with certain environment variables That may be true, sure. But Puppet should NOT crash on it. That is an EASY denial of service from any unpriviliged user you have on the system. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.393106.1617026085000.176985.1617091980149%40Atlassian.JIRA.
Jira (PUP-10998) Cron Provider breaks on crontab with certain environment variables
Title: Message Title Joerg Jaspert updated an issue Puppet / PUP-10998 Cron Provider breaks on crontab with certain environment variables Change By: Joerg Jaspert Agent OS: Debian 8 (i386, amd64) Other Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.393106.1617026085000.175942.1617027060100%40Atlassian.JIRA.
Jira (PUP-10998) Cron Provider breaks on crontab with certain environment variables
Title: Message Title Joerg Jaspert updated an issue Puppet / PUP-10998 Cron Provider breaks on crontab with certain environment variables Change By: Joerg Jaspert Agent OS: Debian 7 8 (i386, amd64) Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.393106.1617026085000.175941.1617027060039%40Atlassian.JIRA.
Jira (PUP-10998) Cron Provider breaks on crontab with certain environment variables
Title: Message Title Joerg Jaspert created an issue Puppet / PUP-10998 Cron Provider breaks on crontab with certain environment variables Issue Type: Bug Affects Versions: PUP 6.21.1 Assignee: Unassigned Created: 2021/03/29 6:54 AM Priority: Blocker Reporter: Joerg Jaspert Puppet Version: 6.21.1-1buster Puppet Server Version: 6.15.1-1buster OS Name/Version: Debian Buster A crontab that contains an environment variable with a - breaks puppet. Change - to _ and it works. Create a crontab like MAILTO=t...@example.com CONSOLE-LOG=/var/log/file */15 * * * * /bin/bash -c "echo test" Puppet goes boom: Error: Could not prefetch cron provider 'crontab': Could not parse line "CONSOLE-LOG=/var/log/file" (file: USERNAMEOFUNIXUSER, line: 2) /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/fileparsing.rb:260:in `block in parse' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/fileparsing.rb:252:in `collect' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/fileparsing.rb:252:in `parse' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/provider/parsedfile.rb:329:in `retrieve' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/provider/parsedfile.rb:282:in `prefetch_target' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/provider/parsedfile.rb:274:in `block in prefetch_all_targets' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/provider/parsedfile.rb:273:in `each' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/provider/parsedfile.rb:273:in `prefetch_all_targets' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/provider/parsedfile.rb:226:in `prefetch' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/transaction.rb:378:in `prefetch' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/transaction.rb:260:in `prefetch_if_necessary' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/transaction.rb:115:in `block in evaluate' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/graph/relationship_graph.rb:120:in `traverse' /opt/puppetlabs/puppet/lib/ruby/vendo
Jira (HI-588) Removing calling_module breaks perfectly valid usage
Title: Message Title Joerg Jaspert created an issue Hiera / HI-588 Removing calling_module breaks perfectly valid usage Issue Type: Bug Assignee: Unassigned Created: 2017/10/19 5:19 AM Priority: Major Reporter: Joerg Jaspert Hi removing the calling_module pseudo variable in favor of "use the module layer" is very short sighted and actively breaks perfectly nice and valid configs, please undo. First off - as long as the hiera thingie runs in compat v3 mode, it should work, no matter what puppet version, as its part of v3. Then, even when using v4 or later, it should work. The module layer is NOT an option to replace what calling_module gave. The module layer is for the module author, which, in many cases, is NOT the one maintaining the local puppet. Using calling_module variable in hiera enables a LOCAL module layer of config option, that is entirely independent of the things that the module author wants to do. My practical example: I do have a 53layer hierarchy here, with widespread use of calling_module included. The biggest user of that are the firewalls and sudo modules, in which, as you may guess, we locally configure the firewall and sudo entities for the machine. Which are highly dependent on our local environment. So nothing at all the module author ever wants (or needs to) resemble. Their hierarchy basically boils down to "nodename, osfamily, common" and is fine for configuring things like executable and config file path entries. Our hierarchy includes tons of layers of local definitions derived from variables (function of machine, network name machine is in, custom facts adapted to our env, etc. pp). This is NOT at all representable with the 3 shallow levels now offered. It does not belong into the module, as its not from the module author, it is not environmen
Jira (PUP-3810) Does not allow $environment in hiera_config variable for no good reason and falls back to non-working path
Title: Message Title Joerg Jaspert commented on PUP-3810 Re: Does not allow $environment in hiera_config variable for no good reason and falls back to non-working path Its definitely not ok to break in such a horrible way with a minor version update. Add Comment This message was sent by Atlassian JIRA (v6.3.10#6340-sha1:7ea293a) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-3810) Does not allow $environment in hiera_config variable for no good reason and falls back to non-working path
Title: Message Title Joerg Jaspert commented on PUP-3810 Re: Does not allow $environment in hiera_config variable for no good reason and falls back to non-working path It may be a singleton, but the setup as I had it worked, and its a no-go to break in a minor version update. Funnily it also worked when I changed hierarchies within environments, but I may have run into some funny sideeffects from $something there (though I did some heavy changes of the hierarchies, using environments to test em before it breaks all systems). I sure can do that by running extra puppet masters for this, but thats somewhat crap when hiera seems to be the only one to demand those extra resources. Anyways, the bad point stays: It should not break like this in a minor version update. Add Comment This message was sent by Atlassian JIRA (v6.3.10#6340-sha1:7ea293a) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-3810) Does not allow $environment in hiera_config variable for no good reason and falls back to non-working path
Title: Message Title Joerg Jaspert created an issue Puppet / PUP-3810 Does not allow $environment in hiera_config variable for no good reason and falls back to non-working path Issue Type: Bug Affects Versions: PUP 3.7.3, PUP 3.7.2, PUP 3.7.1 Assignee: Henrik Lindberg Components: Server Created: 2015/01/06 2:31 AM Environment: Linux (Debian), puppetmaster with passenger Priority: Blocker Reporter: Joerg Jaspert Hi, from 3.7.1 on appearently puppet does no longer allow a setting in puppet.conf, part [master] of hiera_config that looks like Use an environment specific hiera config file hiera_config = $environmentpath/$environment/etc/hiera.yaml Up to, including, 3.7.0 this worked perfectly. The directory expands to /etc/puppetmaster/
