[Bro] BRO and SQL

Jim Mellander jmellander at lbl.gov
Mon Oct 29 10:01:10 PDT 2012

Thanks Jon,

That should help with what I'm contemplating.  If would be really cool if
there was a generational attribute (probably just a value that is
incremented on update) on tables, so that the event could sense which table
had, in fact, been changed.  Thats just a wishlist item, as I don't have
any significant use cases for such functionality.

Thanks again,


On Mon, Oct 29, 2012 at 8:03 AM, Siwek, Jonathan Luke
<jsiwek at illinois.edu>wrote:

> > Seth's information on "broctl update", reproduced below has proven
> useful to us when changing const variables (sounds like a contradiction!),
> such as maintanance of whitelists or blacklists, without restarting bro.
>  I've been thinking about some use cases of redef'ing consts, where I would
> like to cook the data in the consts.  This I typically do with a bro_init
> event handler when bro starts up.  Is there some way to trigger an event
> when these updates occur, so that the updated variable can be recooked?
> A general event called "Control::configuration_update" gets queued when a
> nodes configuration gets changed by e.g. `broctl update`.  So handling that
> I think should be an indication that the node's redef'able consts may have
> changed.  Maybe that will work for what you want to do?
>     Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20121029/50b939ca/attachment.html 

More information about the Bro mailing list