-
Notifications
You must be signed in to change notification settings - Fork 3
OHAI Remote Targeting Current State
09:17 How goes the day?
09:18 So given we can’t add flags yet in an input, once I hit the lifecycle of the reporter plug-in, is the train connection still active to the endpoint or has that been closed already? I couldn’t find it in the developer docs or if it did exist how to reference it or use it
cwolfe
09:30
inspec.backend.backend
09:30 it should still be active
09:30 Hrm, though that may only be available in the rsource DSL
aaronlippold
09:31
Ok. And that should use the standard chef config, so i should be able to lift the code from chef client to establish the connection to ohai?
09:31 Yes, when I pry'd in it didn't seem to be avalible
09:32 backend did not seem to be there
09:32 I am using this as a reference - https://github.com/chef/chef/blob/7558c414030d082194d0d2b5f74279ce151517e9/lib/chef/client.rb#L574-L609 (edited)
09:33 I know I may have to mess a bit with the connection to setup the connection
09:34 Do you think this make more sense as a core plugin?
09:43 I can try to pry in again at the reporter phase and see if backend is there
09:43 What's the trick to bundle exec ... with my plugin so I don't have to rebuild and reinstall it to test?
09:43 Like I would with inspec core
10:19 To ease plugin development, install your plugin using path
10:20 bundle exec plugin install ../path/to/inspec-myplugin/lib/inspec-myplugin.rb
10:20 ahh I see --- cool
10:21 https://github.com/mitre/inspec-reporter-json-hdf/pull/21
10:21 is what I am working on
10:21 So the backend,,, is it only in the Resources DSL
10:22 it is certainly there, but may be accessible otherwise
10:22 looking
10:23 I almost feel like this is a two part solution: a core cli plugin that collects the data and adds to run_data update of reporter plugins to use the new data This was our original thought if I recall, the only reason we would need to add flags to Thor would be to --disable-ohai and --ohai-plugins= which would override the default filter in (1)
10:24 And if you have a preference in how you would want run_data updated and where in the structure - please let me know
10:26 If you like, I can see if I can get this working in my PR above by layering this into the reporter plugin, then I can refactor to make it a core plugin in main and submit a PR. Just let me know what you think makes the most sense
10:27 When is 5x coming out by the way ... are you saving it for ChefConf again?
10:29 No, it's scheduled to be a surprise. But soon.
10:29 LOL -- ok then -- we wait with baited anticipation
10:30 I found where the resource gets its backend hook, I don't think that can be used - https://github.com/inspec/inspec/blob/a658bac10d4e8bf4401e214a215d4b08e7d42305/lib/inspec/resource.rb#L239
10:31 Can't be used in a reporter plugin you mean
10:32 Right, not reachable from there
10:32 makes sense actually I expected that - if I could it would be a hack
10:32 Might be able to reach another reference to backend another way
10:33 Any idea on what that could be?
10:37 If I am thinking about this correctly - and correct me - what we are really doing here is either a cli-plugin that is adding adding a mixin to the transport data object to collect init data and then just passing that to run_data right before we build out the control data. Could the collection part be a train plugin that is just a couple of mixin's that amends this data? (edited)
10:39 Not really. train plugins are loaded 1:1 with the transport. So if you choose -t ssh://, only the train-ssh transport is supposed to get loaded.
10:40 That may be broken.
10:40 Bummer, I was hoping I could just add a mixin to all transports to add the collection of data 10:40 Which is I think what folks would expect
10:41 Likewise a reporter plugin is only loaded if it is used as output
10:41 What's is broken that only one transport plugin is loaded?
10:41 Yup, only load what you use, that makes sense
10:42 No, I meant we may be loading all train plugins but only using the requested one, which I would consider broken
10:42 so don't rely on it , we might fix it
10:43 (I'm not sure about that)
10:43 So what do you think the best plan of attack is?
10:43 I can't do it in the reporter plugin
10:44 And it doesn't make sense to make a whole new transport (edited)
10:44 as I want to collect on all transport
10:45 No easy way forward that I see. Maybe make a new plugin type, CLI option, which isn't easy because CLI option handling is a huge mess now, and add it as a CLI option plugin.
10:46 Or drop the plugin idea and just do it as a CLI option directly, no plugin, and then use the data if available in your reporter.
10:46 So a direct PR to inspec-core is the only way at the moment
10:47 one way or the other, as far as I see * aaronlippold
10:47 I assume you guys would like this and support the idea
10:47 I like it but I don't control the priorities, Lokesh does
10:47 From a business perspective this solves a huge gap. inventory which agencies have a big problem with (edited) 10:49 OK. I think I can sell it, it is a requirement for DOD, Fed, etc and VMWare needs it for their integration of inspec into their products which is going well
10:49 SOunds good
10:50 did we add --passthrough as a cli option yet
10:50 or is it still locked to inspec.config at the moment
10:52 Does not appear to be a CLI option
10:53 How much time to I have to get these PRs in before the first release of 5.x
10:55 I can't really answer that, but don't count on it
10:55 Ok. I will add that to the list as well -- would you want --passthrough on the cli replace the data in .config file or merge - I would think its a merge function
10:55 OK. So soon is what your say ... got it
10:55 lol
10:55 thanks
10:57 The Config class handles all the merging - it does too much, probably. https://github.com/inspec/inspec/blob/a658bac10d4e8bf4401e214a215d4b08e7d42305/lib/inspec/config.rb#L437
10:57 You just need to define a CLI option.
11:00 Ok. We will start working on a direct PR for the ohai stuff, I will add passthrough to the todo list.
Also, you said if we were to add data elements to the core JSON reporter you want them as top-level elements so they are not breaking changes with the current tools.
What is on my longer-term list at the moment is:
- target { basic ohai data about trarget + ec2 | docker | k8s | if ohai has it and we are on that kind of target }
- add cli passthrough for run-time info - already a top level element
- attestation - (sister to waiver but does pass|fail vs 'skip` ) - I would like to just borrow from the waiver code given they are almost the same thing just setting control status to the 'other states'
Thanks for the time today
Glad to help