You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When rolling new changes to the osquery configuration of nodes, it would be a good idea to implement a system to shard the configuration so it will not get to all the nodes at once.
The text was updated successfully, but these errors were encountered:
@javuto While this issue is somewhat old, it's still very relevant.
From the code base of OSctrl, it does seem like it's supported, however i haven't tested it out.
While the shard functionality of OSQuery is nice, because it's built into OSQuery, it will still be sent to all hosts as OSCtrl sends down same config to all hosts inside the environment.
There may be value in targeting specific hosts (e.g. by name or tags) to receive certain configs. But yeah, haven't explored the use case too much honestly. Was just wondering what your thoughts are?
@martinjaegerdk I agree 100%, that is the reason I have left this issue open, because at some point I would like to have this implemented. Currently the configuration applies to the whole environment and once changes are made, it will be served to all the nodes enrolled in the environment. What do you think has more value:
The environment configuration editor provides a template but each node configuration can be customized.
Tags can be used to group the configuration so different nodes get different osquery configuration.
The configuration is determined per environment, but you can enable an option to distribute it using random sharding amongst all nodes members in that environment.
When rolling new changes to the osquery configuration of nodes, it would be a good idea to implement a system to shard the configuration so it will not get to all the nodes at once.
The text was updated successfully, but these errors were encountered: