auto load ATC config in interactive #1685
Conversation
James-Pickett
changed the title
| @@ -63,6 +65,18 @@ func (s *startupSettingsWriter) setFlags() error { | |||
| } | |||
| updatedFlags["use_tuf_autoupdater"] = "enabled" // Hardcode for backwards compatibility circa v1.5.3 | |||
|
|
|||
| // Set flags will only be called when a flag value changes. The osquery config that contains the atc config | |||
| // comes in via osquery extension. So a new config will not trigger a re-write. | |||
| atcConfig, err := s.extractAutoTableConstructionConfig() | |||
There was a problem hiding this comment.
Is it worth figuring out the plumbing to have this fire when we get a new osquery config? This would likely mean that launcher interactive will not pick up the ATCs until the first launcher start up after getting osq config.
There was a problem hiding this comment.
I'm not sure I understand... Is this only called on startup? Which means the sqlite conf file may lag weeks to months?
There was a problem hiding this comment.
Yes, it's possible. I'm trying to find a clever way to plumb this through .... we could treat config like a flag in knapsack and use it's observer pattern or just find a way to have the extension call startupsettings.OpenWriter when the config updates.
There was a problem hiding this comment.
mmm, that's an interesting thought. If we ever decide we need to restart osquery on a config change, would it leverage that?
There was a problem hiding this comment.
I doubt we would ever leverage that when launcher (daemon) is restarting osquery, since launcher (daemon) can just read the config out of bolt db.
There was a problem hiding this comment.
Right -- that extension would read it from boltdb. But we still need something like that to trigger the restart, don't we?
There was a problem hiding this comment.
I've updated this to have the extension just open the startup settings writer to trigger the write when it gets a new config. I see what you mean about restarting on a new config, as discussed, maybe an issue, but out of scope for this PR.
There was a problem hiding this comment.
Agree it's out of scope for this PR. Mostly mentioning it in case it chanses the direction you want to go in
| @@ -63,6 +65,18 @@ func (s *startupSettingsWriter) setFlags() error { | |||
| } | |||
| updatedFlags["use_tuf_autoupdater"] = "enabled" // Hardcode for backwards compatibility circa v1.5.3 | |||
|
|
|||
| // Set flags will only be called when a flag value changes. The osquery config that contains the atc config | |||
| // comes in via osquery extension. So a new config will not trigger a re-write. | |||
| atcConfig, err := s.extractAutoTableConstructionConfig() | |||
There was a problem hiding this comment.
I'm not sure I understand... Is this only called on startup? Which means the sqlite conf file may lag weeks to months?
| @@ -517,6 +518,18 @@ func (e *Extension) GenerateConfigs(ctx context.Context) (map[string]string, err | |||
| } else { | |||
| // Store good config | |||
| e.knapsack.ConfigStore().Set([]byte(configKey), []byte(config)) | |||
|
|
|||
| // open the start up settings writer just to trigger a write of the config, | |||
| // then we can immediately close it | |||
There was a problem hiding this comment.
I think maybe it would feel cleaner/less easy to introduce bugs in the future if we had a specific function to call to perform the config write, rather than relying on a side effect of OpenWriter...maybe setFlags could be exposed as SyncFlags or something? What do you think?
There was a problem hiding this comment.
how about renaming to WriteSettings and removing from the constructor?
automatically load automatic table configuration from osquery config when running launcher in interactive mode
closes #1683