later taters! Thanks @trent++ for the RSS suggestion

trent.anderson82 is on the rise! (Karma: 1)

This message was deleted.

Why would a DB query like this take an insanely long time to return (34s using curl) from the puppet server? Is it a stupid query? Most other queries take 1-2 secs.

query=nodes[count()] { deactivated is null and expired is null and facts { name = "osfamily" and value = "Debian" } and facts { name = "operatingsystemmajrelease" and value = "8"} }

Why would a DB query like this take an insanely longtime to return (34s using curl) when asked to the puppet server? Is it a stupid query? Most other queries takes are 1-2 secs.

query=nodes[count()] { deactivated is null and expired is null and facts { name = "osfamily" and value = "Debian" } and facts { name = "operatingsystemmajrelease" and value = "8"} }

Why would a DB query like this take an insanely longtime to return (34s using curl) when asked to the puppet server? Is it a stupid query? Most other queries take 1-2 secs.

query=nodes[count()] { deactivated is null and expired is null and facts { name = "osfamily" and value = "Debian" } and facts { name = "operatingsystemmajrelease" and value = "8"} }

Why would a DB query like this take an insanely long time to return (34s using curl) when asked to the puppet server? Is it a stupid query? Most other queries take 1-2 secs.

query=nodes[count()] { deactivated is null and expired is null and facts { name = "osfamily" and value = "Debian" } and facts { name = "operatingsystemmajrelease" and value = "8"} }

Why would a DB query like this take an insanely long time to return (34s using curl) from the puppet server? Is it a stupid query? Most other queries take 1-2 secs.

query=nodes[count()] { deactivated is null and expired is null and facts { name = "osfamily" and value = "Debian" } and facts { name = "operatingsystemmajrelease" and value = "8"} }

@Viktor Oreshkin has left the channel

Seems a reasonable query... unless maybe you have thousands or tens of thousands of servers and a bunch of different OSes and/or versions

☕ 🧑‍🏫PE Console is about to start up in 15 minutes

\o Good day y’all - console office hour has begun!

If you have any questions/suggestions for anything related to the console, any of the console services (RBAC, Classifier, Activity Service) or the Orchestrator, ask away.

Not sure if this is the right place to ask but our InfoSec team was asking if there is any way to put in safeguards for Tasks and Plans that would prevent people from running them on over X amount of targets without approval from other admins or additional confirmations. For code this can be controlled with branch protection and reviewers for committing code to production but any administrator in the console could deliberately or accidentally issue a command to the entire environment without any safeguards.

A plan could enforce that internally. For tasks, you could create a plan that would take a task to run as input and do similarly. The user experience for the folks running wouldn’t be great as the plan would fail. Depending on exactly why you want to limit the number of targets, there may be better ways to enforce something

you could probably do something similar to what’s outlined here with PDB queries: https://puppet.com/blog/selecting-targets-for-plans-in-puppet-enterprise/

and add a limit to the query

that would be a pretty nice user exp assuming that you could target the hosts you want with a pdb query

I suppose instead of failing the plan if there were more than n targets, you could just truncate the hosts

indeed Next up is 🧑‍🏫Puppet Core Team in 115 hours

I’ll roll that around in my head and see if there’s anything else I can think of that might be useful

yeah we figured there were ways to do it but not any way currently to put in a restriction like that on the entire platform. Workspace One, Intune, SCCM, Crowdstrike, and a lot of other platforms have configurable safeguards like that

so this is mostly around “don’t change everything at once”?

rather than “don’t do things on hosts that you shouldn’t touch”?

More like, don't break everything all at once 😄 examples, Admin issues a destructive or intrusive task but meant to target a subset of systems but instead targeted the entire environment. Would get a warning for final confirmation or a block indicating they cannot run this command on 10,000 systems A malicious actor gains access to an admin account and within seconds, issues a destructive command to the entire environment

gotcha

so what would the expected behavior be for say me setting up a task run and using a query that is

certname ~ *

, just returning up to the limit for the targets?

perhaps

or using the All Nodes nodes group as a target

just trying to think how this would play out with the various ways we have to select targets