Hello everyone,
As part of renaming Bro to Zeek, we are going to change the addresses and
names of all our mailing lists.
The important thing first: this change is going to happen tomorrow
(Thursday), 12/20. The mailing list rename will happen during a system
maintenance window at ICSI (which is hosting the mailing list). Thus the
mailing lists (including the archives) will be unavailable for a few hours
during the day on Thursday. Mails sent to the lists during this time
should be queued and delivered when the system is back up.
The current Bro mailing lists will be renamed as follows:
bro(a)bro.org -> zeek(a)zeek.org
bro-dev(a)bro.org -> zeek-dev(a)zeek.org
bro-commits(a)bro.org -> zeek-commits(a)zeek.org
bro-announce(a)bro.org -> zeek-announce(a)zeek.org
Similarly we will change the mailing list subject tags from Bro to Zeek.
There will be redirects from the old mailing list names to the new ones,
so mails sent to the old addresses will not be lost.
Johanna
I'm working on some scripts where I want to remove every element from a
table in a single shot. In awk, "delete tbl" would do the trick, but Zeek
restricts delete operations to removing single elements. Worse, if I try
iterating over an aggregate to remove elements piece-wise, it doesn't
remove all of them, no doubt because the internal hash table is changing
mid-stream of the "for" loop and thus doesn't visit all of the members.
This means I have to first build up a *separate* vector of all the indexes,
then iterate over that to remove them.
Proposal: extend "delete" so that if applied to a table or a set, it clears
out all of its elements.
This seems straightforward to me, and something that I'll see if I can
find some cycles soon to hack out.
Comments?
Vern
Hello everyone,
as some of you might have noticed, our nightly builds have been broken for
a while. To be more exact since broker was introduced - since this opened
up a few questions on how exactly packaging should be performed.
These problems have now been cleared up and new nightly builds are
available on OBS:
Download URLs: https://software.opensuse.org//download.html?project=network%3Abro&package=…
Package Information: https://build.opensuse.org/package/show/network:bro/bro-nightly
The new builds now link CAF and Broker statically into Bro - so it is no
longer necessary to fiddle with the ld.so.conf or similar.
Builds are now also available for a newer selection of distributions
(again). If your favorite distribution is missing for some reason, let me
know :)
If no one discovers any problems with these build I will do new package
builds of Bro 2.6 using the exact same approach. I only did somewhat
limited testing, but on the few distributions I tried everything worked
fine.
Note that the name of the project on OBS will change to
network:zeek/zeek-nightly at some point in the future - I will send
another followup email once that happens.
Johanna
I've been working on an application that will fire a large volume of events into bro through broker. Basically, I want to fire events into Broker and load balance them across a pool of workers without the need for more than one worker to handle the same event.
I'm having difficulty determining the most right way to accomplish a couple tasks.
I have looked at the implementations of publish_hrw and publish_rr in bro. I could easily implement those features in my application if that is the recommended way to handle this issue.
Unfortunately, that leaves me with another unfortunate problem. I have been unsuccessful in determining how to 'discover' members of a Bro cluster via Broker. Is there a way to do discovery, or do I need to know who the cluster members are and what port they are listening on via a broctl configuration equivalent?
I've read up on cmake variable scope but I can't figure out how to build
bro with static libraries. The bro-bundled caf already has
CAF_BUILD_STATIC_ONLY which I'm pretty sure works but I'm unable to turn
it on when building caf as part of a bro build.
For example I'd like is to optionally (i.e. from a -D argument to cmake
itself) be able to turn on CAF_BUILD_STATIC_ONLY for
aux/broker/3rdparty/caf/CMakeLists.txt but nothing I've tried in the top
level CMakeLists.txt is seen when the caf CMakeLists.txt is being evaluated.
(I'm working on updating the FreeBSD port to 2.6 and can't install
things like libcaf_io.so in /usr/local/lib because they conflict with
libraries potentially installed by the devel/caf port.)
Craig
For some scripting I'm doing, I'm running into the problem that
attributes associated with named types don't get propagated. For
example,
type a: table[count] of count &default = 5;
global c: a;
print c[9];
complains that c[9] isn't set, instead of returning the value 5.
Having dived[*] into this and examined some potential fixes, I've identified
that the problem is that (1) the attribute "&default = 5" in the above
example gets associated with the identifier 'a' rather than with a's type,
and (2) when the parser processes the second line, early in the process 'a'
gets converted to its underlying type, with the attributes lost at that
point since, internally, BroType's do not have attributes.
This is a pain to deal with. If we simply add attributes to BroType's and
for statements like the first line associate the attributes with the type,
then a sequence like:
type a: table[count] of count &default = 5;
type b: a &read_expire = 1 min;
will wind up changing the attributes associated with 'a' even though it
really shouldn't.
I think the right solution for this is to introduce a new BroType called
a NamedType. A NamedType has an identifier, an underlying BroType, and a
set of attributes. When a NamedType is constructed, for its attributes
it combines both the explicit attributes in its declaration (like the
&read_expire for 'b' above) and the implicit (i.e., it inherits/copies the
&default from 'a').
I plan to implement this soon, so please speak up if you have thoughts.
Vern
[*] The dive also exposed some other bugs in attribute processing, which
I'll enter into the tracker shortly.
