> On Sep 19, 2016, at 6:27 PM, Robin Sommer <ro...@icir.org> wrote:
> @Jon: Do you think this would be doable that way?

Yeah, looks viable.

> - I’m not quite sure if the bundle should contain just the packages
>  themselves or further bro-pkg state as well, such as which packages
>  are currently loaded. Right now I’m learning towards saying “just
>  the packages”; that would basically treat bundles just as a
>  transport mechanism to get packages over to another box. The actual
>  Bro machines would still keep control over which packages to
>  actually load, etc.

Yeah, I think that’s generally how it would be also.  Though, maybe since the 
default behavior of the “install” command is to automatically do a subsequent 
“load” it makes sense to automatically do loads after “unbundle” as well.  It 
would then be up to user whether they actually “@load packages” in the target 
machines local.bro or just pick and choose, so they still have complete control 
over loading/unloading.

> - As it is described above, Step 1 would require having a local Bro
>  installation into which packages get installed before they can be
>  bundled up. It would be nice to have a mode where bro-pkg can
>  operate without having a Bro around at all, just downloading
>  packages locally somewhere for bundling them up. I could also see
>  offering an even simpler mode where one simply lists packages to
>  bundle on the command-line: “bro-pkg bundle <pkg1> <pkg2> <pkg3>”.
>  That would be particularly useful with configuration management
>  systems I think.

I think bro-pkg currently works fine even if you don’t have a local Bro 

If you build plugins, you’d need Bro source code, but don’t actually need it 
installed.  Then on the target machine, “unbundle” just unpacks into whatever 
bro-pkg paths are configured for script_dir/plugin_dir.

- Jon

bro-dev mailing list

Reply via email to