[Bro] BRO and SQL
jmellander at lbl.gov
Mon Oct 29 10:01:10 PDT 2012
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.
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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Bro