Jira (PUP-10627) write public information to puppet_dir/public
Title: Message Title R.I.Pienaar commented on PUP-10627 Re: write public information to puppet_dir/public Yeah, sorry I copied down from Trevor incorrectly, indeed reports should be not be accessible as they hold vast troves of information The whole reason this public directory was even made was due to the request - by many people over the years - to restore last run summary to world readable as it was in the distant past. It was great to see that was done as it solved a security issue for many enabling monitoring as non root. The ability to control file modes in config files is known by very few people ime based on chat history etc now we are back where we started - hard to use defaults for the majority average users. And more confusingly a public directory that holds a non public file Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- 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.369665.1597829487000.33703.1621054500030%40Atlassian.JIRA.
Jira (PUP-10627) write public information to puppet_dir/public
Title: Message Title Scott Cyprus commented on PUP-10627 Re: write public information to puppet_dir/public Josh Cooper Thanks for the quick response. I did see that the original 644 change was caught and changed to 640, which is fine. I was more concerned about the original 644 permission. Fair point about the version being accessible elsewhere, although some of the other info in the file such as failed runs and last_run is a bit sensitive as well. Honestly, I was less concerned about the somewhat-sensitive information in the file, and more concerned with the permissions that the file was given. It's just a bad look, you know? It made me wonder, "What else on my system has similar permissions that I didn't happen to read about in the change logs?" Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- 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.369665.1597829487000.33677.1621036560024%40Atlassian.JIRA.
Jira (PUP-11062) better handling of enable=delayed case for a systemd service
Title: Message Title Josh Cooper commented on PUP-11062 Re: better handling of enable=delayed case for a systemd service The delayed property is missing the required_features part (like we due for mask). That way the property can only be set to that value if the provider supports the feature. Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- 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.399504.162100079.33676.1621035840232%40Atlassian.JIRA.
Jira (PUP-10714) remove "master_used" report parameter in puppet 7
Title: Message Title Josh Cooper commented on PUP-10714 Re: remove "master_used" report parameter in puppet 7 Scott Cyprus The old terminology was deprecated in the 6.x release and removed in 7.0. Also the report_format field in the report schema was updated, so any automation trying to parse the report would know that the master_used field had been removed, see https://github.com/puppetlabs/puppet/commit/ac248dd5b66e7ac1701316b149e0c47af26ab64b. Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- 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.374886.1602655032000.33664.1621034880025%40Atlassian.JIRA.
Jira (PUP-10627) write public information to puppet_dir/public
Title: Message Title Josh Cooper commented on PUP-10627 Re: write public information to puppet_dir/public R.I.Pienaar I think you meant "by default even reports should NOT be accessible? Scott Cyprus The reason for the path change is because the old parent directory /opt/puppetlabs/puppet/cache is not read/executable by other. So in order to make the last_run_summary.yaml readable by monitoring software, you'd have to relax the permissions on the parent cache as well. But that directory can contain sensitive information last_run_report.yaml, so a bigger change was required. The new public directory is read/executable by other, but the last_run_summary.yaml file is not readable, because we are following secure by default practices. If you are an advanced user and want to allow a specific user/group access to the summary file, then it's up to you. I understand the concern around the version number and correlating that with known exploits, but the version number is not a secret. It's literally one command away: $ cat /opt/puppetlabs/puppet/VERSION 7.6.1 and there are about 6 other ways to get the same information. Also know that this feature wasn't "implemented without a second thought." We actually did put a lot of thought into this, but sometimes oversights happen, and we welcome feedback. Add Comment This message was sent by Atlassian Jira
Jira (PDB-4386) Improve performance of catalog inserts/updates (by using an UPSERT)
Title: Message Title Rob Browning updated an issue PuppetDB / PDB-4386 Improve performance of catalog inserts/updates (by using an UPSERT) Change By: Rob Browning Story Points: 3 0 Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- 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.310840.155925674.33624.1621029180113%40Atlassian.JIRA.
Jira (PDB-4386) Improve performance of catalog inserts/updates (by using an UPSERT)
Title: Message Title Rob Browning commented on PDB-4386 Re: Improve performance of catalog inserts/updates (by using an UPSERT) After some investigation, and if our assumptions are correct, we think it's likely to be preferable to continue diffing the catalogs in PDB. One reason is that at the moment PDB CPU is expected to be a notably less constrained resource than postgres since we have the option of running multiple command processors, and trading PDB CPU for a decreased postgres write load is potentially useful. In addition, at least with plain SQL, while we could handle the new/changed rows via upsert, we'd still have to arrange for all the obsolete rows to be deleted. Furthermore, any unchanged rows, at least with the straightforward "on conflict update" solution, would still generate dead tuples (the only upsert that doesn't iirc is "do nothing"). Regarding the original problem, we noticed that the resource queries that were causing concern were likely running more slowly because of VM snapshot IO contention on the host. In any case, whatever we decide in the end, we've taken this opportunity to review some of the other storage code, and identified a number of places where we handle things more efficiently, via upsert, decreasing round trips, etc. cf. PDB-5128 Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- 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
Jira (PUP-10714) remove "master_used" report parameter in puppet 7
Title: Message Title Scott Cyprus commented on PUP-10714 Re: remove "master_used" report parameter in puppet 7 The new terminology "server_used" was marked as resolved on 2020/10/13, and the old terminology "master_used" was completely removed (without deprecation notice) on 2020/10/26. It was mention that you don't think the variable is used anywhere in the product, but what about the humans who read documentation that's still on the internet who do expect that variable to work (maybe somebody wrote a blog post because it actually did work for 13 days)? Do you see how things like this erode trust in the puppet ecosystem? Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- 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.374886.1602655032000.33596.1621027200024%40Atlassian.JIRA.
Jira (PUP-10714) remove "master_used" report parameter in puppet 7
Title: Message Title Scott Cyprus updated an issue Puppet / PUP-10714 remove "master_used" report parameter in puppet 7 Change By: Scott Cyprus Comment: So you decided to break people's builds to arbitrarily change the name of a previously working variable?The new "server_used" terminology was marked as resolved on 2020/10/13 (PUP-10672), and then the old terminology "master_used" was not only deprecated but completely removed on 2020/10/26. Do you see how bad this is? Do you folks care at all anymore? Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- 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.374886.1602655032000.33593.1621026360161%40Atlassian.JIRA.
Jira (PUP-10714) remove "master_used" report parameter in puppet 7
Title: Message Title Scott Cyprus commented on PUP-10714 Re: remove "master_used" report parameter in puppet 7 So you decided to break people's builds to arbitrarily change the name of a previously working variable? The new "server_used" terminology was marked as resolved on 2020/10/13 (PUP-10672), and then the old terminology "master_used" was not only deprecated but completely removed on 2020/10/26. Do you see how bad this is? Do you folks care at all anymore? Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- 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.374886.1602655032000.33592.1621026360115%40Atlassian.JIRA.
Jira (PUP-10627) write public information to puppet_dir/public
Title: Message Title R.I.Pienaar commented on PUP-10627 Re: write public information to puppet_dir/public The file was not executable. It doesn’t indicate what the load of the system is and there are far simpler ways to determine what version of puppet is being run. It holds SIGNIFICANTLY less information than a report - as a response to “by default even reports should be accessible”. You are right which is why they are not. This summary file is not nearly as big a deal as suggested here. And those who are in highly controlled environments are used to tightening things down. This file has a very useful utility - and that is so that monitoring tools monitoring the health of puppet does not need to be run as root. Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- 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.369665.1597829487000.33589.1621025700029%40Atlassian.JIRA.
Jira (PUP-10627) write public information to puppet_dir/public
Title: Message Title Scott Cyprus updated an issue Puppet / PUP-10627 write public information to puppet_dir/public Change By: Scott Cyprus Comment: It's very concerning that this "improvement" request was implemented without a second thought. 755 and 644 on a file that could get someone hacked? People are trusting your software to run on their systems, and careless changes like this erode that trust really quickly. It wasn't a "great catch" by Trevor, it was common sense. Please keep in mind that people use puppet to install software, and that software has an attack surface. If a hacker gains a limited shell on the machine and sees that puppet is running an outdated and vulnerable version then that is an easy way to escalate privileges. Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- 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.369665.1597829487000.33580.1621024500041%40Atlassian.JIRA.
Jira (PUP-10627) write public information to puppet_dir/public
Title: Message Title Scott Cyprus commented on PUP-10627 Re: write public information to puppet_dir/public It's very concerning that this "improvement" request was implemented without a second thought. 755 and 644 on a file that could get someone hacked? People are trusting your software to run on their systems, and careless changes like this erode that trust really quickly. It wasn't a "great catch" by Trevor, it was common sense. Please keep in mind that people use puppet to install software, and that software has an attack surface. If a hacker gains a limited shell on the machine and sees that puppet is running an outdated and vulnerable version then that is an easy way to escalate privileges. Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- 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.369665.1597829487000.33581.1621024500086%40Atlassian.JIRA.
Jira (PUP-10627) write public information to puppet_dir/public
Title: Message Title Scott Cyprus commented on PUP-10627 Re: write public information to puppet_dir/public It's very concerning that this "improvement" request was implemented without a second thought. 755 and 644 on a file that could get someone hacked? People are trusting your software to run on their systems, and careless changes like this erode that trust really quickly. It wasn't a "great catch" by Trevor, it was common sense. Please keep in mind that people use puppet to install software, and that software has an attack surface. If a hacker gains a limited shell on the machine and sees that puppet is running an outdated and vulnerable version then that is an easy way in. Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- 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.369665.1597829487000.33576.1621024380027%40Atlassian.JIRA.
Jira (PUP-3317) Extend Package Source to include HTTP Urls (Windows)
Title: Message Title Paul Were commented on PUP-3317 Re: Extend Package Source to include HTTP Urls (Windows) Josh Cooper I apologize, yes, I was not clear in the request initially. Yes, to support it in EXE packages. Thanks Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- 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.51963.1411137406000.33515.1621018680023%40Atlassian.JIRA.
Jira (PDB-5130) Adjust the updatetime.sql script to handle partitions
Title: Message Title
Zachary Kent created an issue
PuppetDB / PDB-5130
Adjust the updatetime.sql script to handle partitions
Issue Type:
Bug
Assignee:
Unassigned
Created:
2021/05/14 11:56 AM
Priority:
Normal
Reporter:
Zachary Kent
The updatetime.sql script we pulled from the SLV team was written before PDB had partitioned reports and resource-events tables. If we use the script as-is to shift the timestamps for these partitions we'll hit the constraint error shown below. We'll need to update the sql script to account for this issue. It might be sufficient to create the partitions for the days we need to shift the timestamps to ahead of time. This could be difficult to replicate exactly in the sql script because we do this creation on demand here in storage.clj. We should first test that having newer partitions allows the update of timestamps in the reports and resource-events tables to succeed and then figure out the best way to create the newer partitions we'll need. Example error seen when shifting timestamps to a range outside of what's allowed in a partition:
ERROR: new row for relation "reports_20210416z" violates check constraint "reports_20210416z_producer_timestamp_check"
DETAIL: Failing row contains (22, \x62c7899ab6e6219bd2766bd053e4ca9fa8b8b905, 2bce4bec-ce8b-4d36-91d5-e204af508e98, host-4, 3.7.2, 4, a3adc55e-514f-4483-80d3-a258646ced2c, 2021-05-13 15:47:47.293-07, 2021-05-13 15:47:52.293-07, 2021-05-18 12:33:09.63-07, f, 1, 1, null, null, 2021-05-13 15:47:57.293-07, [{"name": "anchor", "value": 0.00046438, "category": "time"}, {"..., [{"file": null, "line": null, "tags": ["notice"], "time": "2015-..., [{"file":
Jira (PUP-11066) optional_param does not set Integer to optional for custom ruby functions
Title: Message Title
Lucy Wyman created an issue
Puppet / PUP-11066
optional_param does not set Integer to optional for custom ruby functions
Issue Type:
Task
Assignee:
Unassigned
Created:
2021/05/14 11:43 AM
Priority:
Normal
Reporter:
Lucy Wyman
With a custom ruby function with the following definition, passing `nil` to Timeout errors: code Puppet::Functions.create_function(:wait, Puppet::Functions::InternalFunction) do dispatch :wait do param 'Variant[Future, Array[Future]]', :futures optional_param 'Integer[1]', :timeout optional_param 'Hash[String[1], Any]', :options return_type 'Array[Boltlib::PlanResult]' end def wait(futures, timeout = nil, options = {}) code Inspecting the types that Puppet expects for the function indicates that the timeout is `PIntegerType`, not optional. With the following definition, the function has the correct signature: code Puppet::Functions.create_function(:wait, Puppet::Functions::InternalFunction) do dispatch :wait do param 'Variant[Future, Array[Future]]', :futures optional_param 'Optional[Integer[1]]', :timeout optional_param 'Hash[String[1], Any]', :options return_type 'Array[Boltlib::PlanResult]' end def wait(futures, timeout = nil, options = {}) code
Add Comment
Jira (PDB-5124) SPIKE - Identify slow queries from PE console
Title: Message Title Austin Blatt assigned an issue to Austin Blatt PuppetDB / PDB-5124 SPIKE - Identify slow queries from PE console Change By: Austin Blatt Assignee: Austin Blatt Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- 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.398239.1620239687000.33382.1621012140085%40Atlassian.JIRA.
Jira (PUP-3317) Extend Package Source to include HTTP Urls (Windows)
Title: Message Title Paul Were commented on PUP-3317 Re: Extend Package Source to include HTTP Urls (Windows) Josh Cooper The request is to support secure URLs i.e. https Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- 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.51963.1411137406000.33357.1621010100087%40Atlassian.JIRA.
Jira (PDB-5129) Upgrade to honeysql >= 1.0.461
Title: Message Title Rob Browning updated an issue PuppetDB / PDB-5129 Upgrade to honeysql >= 1.0.461 Change By: Rob Browning Sprint: HAHA/Grooming Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- 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.399602.1621009309000.3.1621009380027%40Atlassian.JIRA.
Jira (PDB-5129) Upgrade to honeysql >= 1.0.461
Title: Message Title Rob Browning created an issue PuppetDB / PDB-5129 Upgrade to honeysql >= 1.0.461 Issue Type: Task Assignee: Unassigned Created: 2021/05/14 9:21 AM Priority: Normal Reporter: Rob Browning This will require a few changes to pdb, and a clj-parent update. Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97)
Jira (PDB-2590) /sbin/puppetdb ssl-setup breaks file permissions on /etc/puppetdb/conf.d/jetty.ini
Title: Message Title Rob Browning assigned an issue to Rob Browning PuppetDB / PDB-2590 /sbin/puppetdb ssl-setup breaks file permissions on /etc/puppetdb/conf.d/jetty.ini Change By: Rob Browning Assignee: Rob Browning Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- 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.125421.146001330.33309.1621008960345%40Atlassian.JIRA.
Jira (PDB-5128) Decrease round trips and/or upsert to improve command processing
Title: Message Title Rob Browning updated an issue PuppetDB / PDB-5128 Decrease round trips and/or upsert to improve command processing Change By: Rob Browning Sprint: HA 2020-05-19 Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- 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.399505.1621005548000.33219.1621005660034%40Atlassian.JIRA.
Jira (PDB-5128) Decrease round trips and/or upsert to improve command processing
Title: Message Title Rob Browning created an issue PuppetDB / PDB-5128 Decrease round trips and/or upsert to improve command processing Issue Type: Task Assignee: Unassigned Components: PuppetDB Created: 2021/05/14 8:19 AM Priority: Normal Reporter: Rob Browning Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google
Jira (PUP-11062) better handling of enable=delayed case for a systemd service
Title: Message Title
Ciprian Badescu updated an issue
Puppet / PUP-11062
better handling of enable=delayed case for a systemd service
Change By:
Ciprian Badescu
[root@cloud ~]# puppet resource service puppet enable=delayedError: Could not set 'delayed' on enable: undefined method `delayed_start' for Service[puppet](provider=systemd):Puppet::Type::Service::ProviderSystemdError: Could not set 'delayed' on enable: undefined method `delayed_start' for Service[puppet](provider=systemd):Puppet::Type::Service::ProviderSystemdWrapped exception:undefined method `delayed_start' for Service[puppet](provider=systemd):Puppet::Type::Service::ProviderSystemdError: /Service[puppet]/enable: change from 'true' to 'delayed' failed: Could not set 'delayed' on enable: undefined method `delayed_start' for Service[puppet](provider=systemd):Puppet::Type::Service::ProviderSystemdservice { 'puppet': enable => 'true', provider => 'systemd',}
Add Comment
This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97)
--
You
Jira (PUP-11062) better handling of enable=delayed case for a systemd service
Title: Message Title
Ciprian Badescu updated an issue
Puppet / PUP-11062
better handling of enable=delayed case for a systemd service
Change By:
Ciprian Badescu
{code:java} [root@cloud ~]# puppet resource service puppet enable=delayedError: Could not set 'delayed' on enable: undefined method `delayed_start' for Service[puppet](provider=systemd):Puppet::Type::Service::ProviderSystemdError: Could not set 'delayed' on enable: undefined method `delayed_start' for Service[puppet](provider=systemd):Puppet::Type::Service::ProviderSystemdWrapped exception:undefined method `delayed_start' for Service[puppet](provider=systemd):Puppet::Type::Service::ProviderSystemdError: /Service[puppet]/enable: change from 'true' to 'delayed' failed: Could not set 'delayed' on enable: undefined method `delayed_start' for Service[puppet](provider=systemd):Puppet::Type::Service::ProviderSystemdservice { 'puppet': enable => 'true', provider => 'systemd', }{code} Wouldn’t it be nicer if {{enable=>delayed } } resolved to {{enable=>true}} on Linux? That would prevent the user from having to creating extra Puppet logic for this parameter in cross-platform scenarios. If not, the resource should at least return a proper error that {{delayed}} is not supported on Linux. /cc: [~kevin.reeuwijk]
Add Comment
This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97)
Jira (PUP-11062) better handling of enable=delayed case for a systemd service
Title: Message Title Ciprian Badescu created an issue Puppet / PUP-11062 better handling of enable=delayed case for a systemd service Issue Type: Improvement Assignee: Unassigned Created: 2021/05/14 6:59 AM Priority: Normal Reporter: Ciprian Badescu Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- 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
Jira (PDB-5026) Report type filter causes error in subquery
Title: Message Title Oana Tanasoiu assigned an issue to Oana Tanasoiu PuppetDB / PDB-5026 Report type filter causes error in subquery Change By: Oana Tanasoiu Assignee: Oana Tanasoiu Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- 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.387703.1613498155000.33168.1620983040033%40Atlassian.JIRA.
