Thanks so much for the long and detailed reply! I am not quite sure which of the many options you suggested I would go for, but I will keep the list posted on what I end up doing. I guess I will play with all your options a little bit, and figure out what works for me. <br>
<br>Thanks,<br>Jayanth<br><br><div class="gmail_quote">On Wed, May 14, 2008 at 5:30 PM, Robin Sommer &lt;<a href="mailto:robin@icir.org">robin@icir.org</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
(Late reply, sorry.)<br>
<div class="Ih2E3d"><br>
On Fri, May 02, 2008 at 09:30 -0700, you wrote:<br>
<br>
&gt; I have a question about sending scripts from one Bro to a second one, and<br>
&gt; having the second one install the script at run-time, and I was wondering<br>
&gt; how it would be done. Any help appreciated! Details below.<br>
<br>
</div>This requires a longer answer ...<br>
<br>
We don&#39;t have any prepackaged functionality at the moment to simply<br>
do a &quot;send everything and install&quot;.<br>
<br>
What we have are two things:<br>
<br>
(a) a built-in function send_id() which will send a particular<br>
 &nbsp; &nbsp;script-level ID to the remote end, which will install it. That<br>
 &nbsp; &nbsp;includes variables but also event handlers, script functions,<br>
 &nbsp; &nbsp;etc. By sending all global IDs successively, one will eventually<br>
 &nbsp; &nbsp;have sent the whole configuration. (However, that would be best<br>
 &nbsp; &nbsp;done in C++ code by writing a new built-in function).<br>
<br>
(b) If it doesn&#39;t need to be network communication, there&#39;s the<br>
 &nbsp; &nbsp;command-line option &quot;--dump-config&quot; that puts the whole<br>
 &nbsp; &nbsp;configuration into a binary file, which can then be picked up by<br>
 &nbsp; &nbsp;another instance dynamically (by copying the file into the<br>
 &nbsp; &nbsp;.state directory of the target Bro). Internally, dump-config<br>
 &nbsp; &nbsp;essentially does just what I sketched above in (a): iterating<br>
 &nbsp; &nbsp;through all IDs and serializing them.<br>
<br>
So much for the theory. Now the practical part: I think this whole<br>
set of functionality hasn&#39;t been used by anybody in a long time.<br>
Because of Bro&#39;s internal structure, replacing policy scripts at<br>
run-time is actually pretty tricky and I wouldn&#39;t want to bet much<br>
money that when you try --dump-config, it will &quot;just work&quot;. It did<br>
seem to work well with tests done while implementing all this stuff,<br>
yet I think it has never been exercised very much and the problems<br>
are subtle here.<br>
<br>
So, depending on what exactly you need, I&#39;d suggest something<br>
different, which is what the Bro cluster is doing:<br>
<br>
(1) many policy changes are limited to fine-tuning, e.g., changing<br>
 &nbsp; &nbsp;the value of some configuration paramemter, like extending a<br>
 &nbsp; &nbsp;regexp to match more activity, or changing some detection<br>
 &nbsp; &nbsp;threshold. Sending just values of script variables works<br>
 &nbsp; &nbsp;actually pretty well and the Bro cluster limits online updates<br>
 &nbsp; &nbsp;to such cases: all variables which are declared as &amp;redef can be<br>
 &nbsp; &nbsp;updated dynamically from remote. This is implemented by the<br>
 &nbsp; &nbsp;script aux/cluster/policy/send-config.bro in my branch.<br>
<br>
(2) another typical policy change is enabling/disabling a certain<br>
 &nbsp; &nbsp;kind of analysis (such as now loading the HTTP analyzer, or<br>
 &nbsp; &nbsp;disabling scan detection). My branch has some code to enable<br>
 &nbsp; &nbsp;this from remote by grouping related events into &quot;event groups&quot;<br>
 &nbsp; &nbsp;and then allowing to enable/disable event groups remotely. So<br>
 &nbsp; &nbsp;this can also be done during run-time.<br>
<br>
(3) finally, for everyting else (like adding new script code, or<br>
 &nbsp; &nbsp;changing an existing handler) Bro needs to be reinstarted. The<br>
 &nbsp; &nbsp;impact of that is mitigated by using persistent state so<br>
 &nbsp; &nbsp;that at least the most important state information is kept<br>
 &nbsp; &nbsp;across restarts.<br>
<br>
<br>
Any questions? :-)<br>
<br>
Robin<br>
<font color="#888888"><br>
<br>
--<br>
Robin Sommer * Phone +1 (510) 666-2886 * <a href="mailto:robin@icir.org">robin@icir.org</a><br>
ICSI/LBNL &nbsp; &nbsp;* Fax &nbsp; +1 (510) 666-2956 * &nbsp; <a href="http://www.icir.org" target="_blank">www.icir.org</a><br>
</font></blockquote></div><br>