On Thu, Oct 16, 2014 at 11:54 -0700, you wrote:
That makes sense. The next logical question would be, what makes a plugin
special enough to be included the core? I think GeoIP, being legacy like
Robin mentioned, qualifies.
Yeah, as Seth writes, it'll be a fine line. The other thing is
On Oct 17, 2014, at 8:16 AM, Robin Sommer ro...@icir.org wrote:
(2) Select some plugins in bro-plugins that build automatically
with Bro.
(3) Split bro-plugins into two repositories. One set would build
with Bro, the other not. We'd need to decide if both would be
On Fri, Oct 17, 2014 at 15:04 +, you wrote:
Maybe try approach (2) first as it seems simpler, then find out along the way
what improvements are needed.
Yeah, I can see that. I wondering if we could find a mechanism to
automatically hook selected plugins into the Bro build without
On Oct 17, 2014, at 11:14 AM, Robin Sommer ro...@icir.org wrote:
Maybe they'd ship with a configure hook that
the main configure searches all plugins for; or something to that
effect.
What I don't like about this is that eventually these should all be pushed into
external plugins so I feel
I think that is reasonable for some things.
On Oct 16, 2014, at 8:02 AM, Robin Sommer ro...@icir.org wrote:
(unless we decide to
build (some) plugins by default, which currently isn't happening).
--
Adam J. Slagell
Chief Information Security Officer
Assistant Director, Cybersecurity
I think having some plugins distributed and built with Bro is reasonable,
too. As long as functionality and interfaces don't change current users
shouldn't notice a difference.
How eventually moving the plugin to a package manager will affect users is
something else to consider.
-AK
On Oct 16,
+1 that core plugins be built / distributed with bro.
Re: package / plugin management, coming from a Java EE background, one of the
things I don't like about some of the OSGi software (read: highly modular,
plugin-driven) I've worked with is how confusing it can get to track versions
of each
That makes sense. The next logical question would be, what makes a plugin
special enough to be included the core? I think GeoIP, being legacy like
Robin mentioned, qualifies.
-AK
On Oct 16, 2014 9:21 AM, Clark, Gilbert gc355...@ohio.edu wrote:
+1 that core plugins be built / distributed with
On Oct 16, 2014, at 2:54 PM, anthony kasza anthony.ka...@gmail.com wrote:
That makes sense. The next logical question would be, what makes a plugin
special enough to be included the core? I think GeoIP, being legacy like
Robin mentioned, qualifies.
Yep. This is going to just remain
On Oct 14, 2014, at 7:48 PM, anthony kasza anthony.ka...@gmail.com wrote:
From what I can tell, I don't have
geo_location = internal_type(geo_location)-AsRecordType();
in the right location. This line is from the init_net_var() function
from NetVar.cc, which gets called by main.cc.
On Oct 15, 2014, at 10:46 AM, Siwek, Jon jsi...@illinois.edu wrote:
Maybe that can just be completely removed if Bro proper no longer relies on
that type since all the related functionality is now provided by the plugin?
Agreed. Any code related to GeoIP should move into the plugin,
On Oct 15, 2014, at 1:22 PM, anthony kasza anthony.ka...@gmail.com wrote:
What are the general conventions for doing this?
Oh, also: https://www.bro.org/development/howtos/process.html
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
Thanks all. After moving declarations around, nm shows all my expected
symbols to be defined. I'm now receiving internal error in
/usr/local/bro/share/bro/base/init-bare.bro, line 1: internal type
geo_location missing. It seems this error is being caused by the
check on the return value of
contains that symbol?
-Gilbert
From: bro-dev-boun...@bro.org [bro-dev-boun...@bro.org] on behalf of anthony
kasza [anthony.ka...@gmail.com]
Sent: Tuesday, October 07, 2014 12:46 AM
To: Robin Sommer
Cc: bro-dev@bro.org
Subject: Re: [Bro-Dev] Geo Location
On Oct 7, 2014, at 9:36 AM, Clark, Gilbert gc355...@ohio.edu wrote:
A mismatched function definition in .h / implementation in .cc usually causes
this issue for me. Maybe try running the mangled symbol that's reported as
missing through c++filt to see what it really is (if you haven't
I can at least now see why my plugin isn't working as excepted. Thanks
Robin.
-AK
On Oct 5, 2014 8:23 AM, Robin Sommer ro...@icir.org wrote:
On Sun, Oct 05, 2014 at 02:30 -0700, you wrote:
I'm hoping someone has a suggestion or a tip
on troubleshooting the interaction between plugins and
On Sun, Oct 05, 2014 at 23:00 -0700, you wrote:
I can at least now see why my plugin isn't working as excepted.
Great, let me know if it's anything that the plugin documentation
could make more clear.
Robin
--
Robin Sommer * Phone +1 (510) 722-6541 * ro...@icir.org
ICSI/LBNL* Fax
Thanks Robin. Everything on the Writing Bro Plugins page is clear
although the debugging section seems thin to me. Then again, I've have
never compiled Bro with debugging enabled before.
I'm running into issues with my plugin's shared object. Bro is complaining
about an undefined symbol (likely
Hello All,
I recently have been looking at how Bro's plugins work. I was able to
recreate the rot13 functionality from the online documentation and
wanted to do something a little more challenging in hopes of learning
more about plugin development.
On a suggestion from Seth, I've been attempting
On Sun, Oct 05, 2014 at 02:30 -0700, you wrote:
I'm hoping someone has a suggestion or a tip
on troubleshooting the interaction between plugins and the core.
If you haven't yet, try compiling Bro with --enable-debug (and then
recompiling your plugin as well). Then run with -B plugins and see
20 matches
Mail list logo
