I have been thinking and trying different things but for now, it appears that if we are to share policies around, there is no easy way to be able to distribute input-files along with policy files.
Basically, right now I use
redef Scan::whitelist_ip_file = "/usr/local/bro/feeds/ip-whitelist.scan" ;
and then expect everyone to edit path as their setup demands it and place accompanying sample file in the directory or create one for themselves - this all introduces errors as well as slows down deployment.
Is there a way I can use relative paths instead of absolute paths for input-framework digestion. At present a new-heuristics dir can have __load__.bro with all policies but input-framework won't read files relative to that directory or where it is placed.
redef Scan::whitelist_ip_file = "../feeds/ip-whitelist.scan" ;
Something similar to __load__.bro model
Also, one question I have is should all input-files go to a 'standard' feeds/input dir in bro or be scattered around along with their accompanied bro policies (ie in individual directories )
Something to think about as with more and more reliance on input-framework i think there is a need for 'standardization' on where to put input-files and how to easily find and read them.
Aashish
Bro's current Broker framework has a few pretty inelegant API parts
because Bro's scripting language doesn't support some of its
operations well currently. I've put some thoughts together on
potential language extensions to improve the situation and come to a
nicer Broker framework API:
https://www.bro.org/development/projects/broker-lang-ext.html
Feedback welcome, this is just a first draft.
Robin
--
Robin Sommer * ICSI/LBNL * robin(a)icir.org * www.icir.org/robin
So if we have compresscmd unset then archive-log script does a copy:
archive-log: nice cp $file_name "$dest"
Any reason why it doesn't do move instead ?
I propose changing cp to mv
Aashish
Hi,
In BIT-313 "DPD: ProtocolConfirmation, ProtocolViolation revamp", there is a link to a discussion about "violation-confirmation".
Unfortunately, I could not access this paper (broken link ?)
As the ticket also says "ask bro-dev@... if you want access to the above website", I'm asking :-)
Could I get a link to or a copy of the "violation-confirmation" discussion ?
Thank you.
François
Hello,
I have a package where I provide a sample configuration file for people to redef according to their needs and specifics.
Now everytime when they upgrade the package, I risk over writing their modified config file.
SO I decided to call the config file scan-config.bro.orig but then I am running into issues of which one to load and how to determine the presence of an already existing scan-config.bro in __load__.bro
The idea of asking uses to redef outside package directory might be cumbersome for unfamiliar users.
Any thoughts ?
Aashish
Playing with Bro packages and bundles, there's one thing where I ended
up a bit confused and that's the meta data. We have two places right
now that store meta data about a package: there's the central set
stored with the package source (bro-pkg.index), and then there's the
set coming with the package itself (bro-pkg.meta). However, I'm a bit
lost what goes where, and which information should remain accessible
once things are bundled up.
Seems bro-pkg.meta generally has "description" and "tags" at least.
However, that information seems lost once I bundle a package up and
don't have access to the index repository anymore. There doesn't seem
to be an expectation that bro-pkg.meta would have similar information,
so there's nothing there to fill the gap.
Then, bro-pkg.meta has a "version" field (the docs show that as the
one field to put in there). I believe that version isn't really used
anywhere other than showing it as part of the meta data output in
"info". In Python it also maps to PackageInfo.metadata_version. But
then there's also PackageStatus.current_version, which is from git
(although I'm not sure how I would actually set that; is it just any
tag?).
Once packages go through bundle/unbundle I cannot run "info" when I'm
offline, and hence I don't get some of the information anymore (same
from Python with PackageInfo I believe)
Ideally, what I'd like to have is a single interface (speaking in
Python API terms) for a package that gives me all the meta-data
consistently, pulling it out from where's it's stored and maintaining
it when bundling. For things like "description", "tags", it could pull
them out of bro-pkg.index by default, and maybe override them from
bro-pkg.meta if they are defined there (so that one can set them even
if there's no package source to begin with). And bundles would then
carry the information through, probably inside their manifest. For
version information, bro-pkg could start with the git branch/tag but
override it with values from bro-pkg.index and bro-pkg.meta if defined
there. That way people could choose how to do their versioning. The
API would just offer a single version() doing the right thing, and
"bro-pkg info" would show that.
Does this make sense? I'm not quite sure about the reasons for the
current structure, I'm mostly thinking from the perspective of
information about the package I'd like to have access to easily, and
where it's coming from.
Robin
--
Robin Sommer * ICSI/LBNL * robin(a)icir.org * www.icir.org/robin
In BIT-1763, Johanna asks for a way to mark commits for a point
release (assuming we do one). Let's do this: set the "fix version" of
the ticket to include 2.5.1 and add the commit hash for the fix to the
notes. Then we can later search for these and cherry-pick. (We'll
still close the ticket once fixed in master to avoid confusion.)
Robin
--
Robin Sommer * ICSI/LBNL * robin(a)icir.org * www.icir.org/robin
I have noticed that at times my proxies are spending way too much CPU (100% for extended duration) in tree operations which include inserts and tree_balance_after_insert. Anyone has any pointers to what might be going on proxies ?
Aashish
I have noticed that sometimes (more often than not), not all workers see a manager2worker event or likewise not all workers report a worker2manager event on manager - missing as high as 10% of the events and as little as 1% of such events are 'missing' ie don't show up.
This is puzzling since I am not sure why/where bottleneck is or what might cause the disappreance.
Is there a way to assure that these events are movig data as expected ?
Thanks,
Aashish
Could folks take a look at NEWS and see what's missing?
Couple of things I think we should add at least:
- Document the cluster framework's new logger node, with an
example how to use it.
- Document the recent intel framework updates.
- Add BroControl news/changes.
Any takers for these?
Robin
--
Robin Sommer * ICSI/LBNL * robin(a)icir.org * www.icir.org/robin