[Bro-Dev] Broctl installation process clean up

Robin Sommer robin at icir.org
Sun Nov 7 20:57:36 PST 2010

> https://wiki.ncsa.illinois.edu/display/BROWATERS/CMake+Porting+Progress#CMakePortingProgress-BroctlTasks%2FNotes

Very nice, good job! That all sounds good. A few more comments

On Sat, Nov 06, 2010 at 20:34 -0500, you wrote:

> As part of the CMake porting process, I think it makes sense to
> clean up Broctl's initial installation process,

Yes, definitly.

> I propose that we let CMake take care of the dependency checking
> (other Bro components need to be installed first)

I agree. One reason for the current installation is to essentially 
get around the fact that there's no coherent way of installing all
the pieces easily, and broctl's install tries to hide that as good
as it can and just assembles what it needs.

>  and initial installation of the Broctl files while `broctl install`
>  would still be responsible for generating scripts from templates,
>  updating to new version of .cfg and site policy files, and syncing
>  to worker nodes (at least I think that's a summary of what broctl
>  does).

That sounds good. The one additional thing we should think about
(per earlier mails) is getting rid of generating scripts from
templates. How much work do you think would it be to adapt the
installation to (1) generate a single shell script, say
broctl-config.sh[1], with all (relevant) configure options; and (2)
use static versions for all the helper scripts which then source
broctl-config.sh before doing anything else. That way, we should be
able to get rid of (nearly?) all the Target/TargetDev entries in
BroControl/install.py, leaving them to CMake instead. I'm thinking
we need to do that anyway eventually, and doing so later would then
again require to work on the installation.

[1] Ideally, this would be generated on a per-system basis, so that
nodes can be configured differently. However, that might turn out to
be a bit tricky and I'm fine leaving that out for now. 

> The specific functionality that would be lost is `broctl install
> --make` (used by current Makefile)

No problem. 

>  and also the DevMode=1 feature that seems to basically turn `broctl
>  install` into a `broctl install --make` in order to update the
>  files from the distribution source.

That's ready to go anyway, it's mainly a relict from broctl's first

> Good plan or bad plan?

Excellent plan!

> The policy files into $broctl_prefix/share/bro ?

Better into a subdirectory of that, to keep them seperate from

One more thing: some easy way to change the default paths where the
various broctl pieces go would be nice; seems distributions will
need that (also, if it makes sense to change any of the default
paths generally (for broctl, or also Bro itself), now would be the
right time for that as well). 


Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org
ICSI/LBNL    * Fax   +1 (510) 666-2956 *   www.icir.org

More information about the bro-dev mailing list