[Zeek-Dev] Zeek and the myricom package plugin
Michael Dopheide
dopheide at es.net
Tue Jul 16 10:07:29 PDT 2019
It builds and works for me against master. Should we change the
bro-pkg/zkg requirement to > 2.0? It should be backwards compatible only
as far as when all the required includes, etc were included in the install
tree. Not sure how far back that change was made.
-Dop
On Tue, Jul 16, 2019 at 11:33 AM Seth Hall <seth at corelight.com> wrote:
> Does this branch look crazy to you at all?
>
> https://github.com/sethhall/bro-myricom/tree/zeek-updates
>
> My plan is to rename the whole project to zeek-myricom and set the alias
> as suggested by Jon once I have some external validation that this
> branch works for more people than just me. :)
>
> .Seth
>
> On 16 Jul 2019, at 10:37, Michael Dopheide wrote:
>
> > Seth,
> >
> > github.com/dopheide-esnet/zeek-myricom contains Jan’s changes as
> > well as
> > removes the enum duplicate if you want to steal those.
> >
> > Dop
> >
> >
> > On Tue, Jul 16, 2019 at 9:29 AM Seth Hall <seth at corelight.com> wrote:
> >
> >> I'll take a look at it.
> >>
> >> .Seth
> >>
> >> On 15 Jul 2019, at 12:32, Michael Dopheide wrote:
> >>
> >>> Updating myricom to build against the install tree looks like it's
> >>> going to
> >>> work and will be much cleaner.
> >>>
> >>> -Dop
> >>>
> >>>
> >>> On Mon, Jul 15, 2019 at 9:46 AM Justin Azoff <justin at corelight.com>
> >>> wrote:
> >>>
> >>>> Speaking of that, you made this commit:
> >>>>
> >>>>
> >>>>
> >>
> https://github.com/J-Gras/bro-af_packet-plugin/commit/5a5d8bb74f162841111b26880137f51683e60ac1
> >>>>
> >>>> which has the new changes(from the skeleton?) that allows it to be
> >>>> built
> >>>> without the full source tree, but the myricom package is still
> >>>> using
> >>>> the
> >>>> old cmake bits.
> >>>>
> >>>> On Mon, Jul 15, 2019 at 9:57 AM Jan Grashöfer
> >>>> <jan.grashoefer at gmail.com>
> >>>> wrote:
> >>>>
> >>>>> So https://github.com/J-Gras/bro-af_packet-plugin/issues/11 isn't
> >>>>> an
> >>>>> issue anymore due to backwards compatible symlinks?
> >>>>>
> >>>>> On 13/07/2019 03:22, Michał Purzyński wrote:
> >>>>>> We just migrated to master with the name change and the afpacket
> >>>>> plugin, so I know the Zeek code is OK.
> >>>>>>
> >>>>>>
> >>>>>>> On Jul 12, 2019, at 5:52 PM, Jon Siwek <jsiwek at corelight.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> On Fri, Jul 12, 2019 at 3:46 PM Michael Dopheide
> >>>>>>>> <dopheide at es.net>
> >>>>> wrote:
> >>>>>>>> Background: We like to run 'master', but with the name change
> >>>>>>>> it
> >>>>> broke too many things and we had to stick to 2.6.2 for the time
> >>>>> being.
> >>>>> Since then, I've started trying to convert our ansible scripts and
> >>>>> prepare
> >>>>> to make the jump. Today I discovered the bro-myricom package
> >>>>> would
> >>>>> fail to
> >>>>> build.
> >>>>>>>>
> >>>>>>>> Has anyone attempted this yet? I can get it to build with a
> >>>>>>>> couple
> >>>>> minor changes:
> >>>>>>>>
> >>>>>>>> src/Myricom.cc
> >>>>>>>> @@ -1,4 +1,4 @@
> >>>>>>>> #include "bro-config.h"
> >>>>>>>> #include "zeek-config.h"
> >>>>>>>>
> >>>>>>>
> >>>>>>> Can you give more info on how to reproduce this one? The master
> >>>>> branch should currently be installing "zeek-config.h" along with a
> >>>>> symlink
> >>>>> to it named "bro-config.h", with the ideal being that people
> >>>>> wouldn't have
> >>>>> to make this change.
> >>>>>>>
> >>>>>>> IIRC, since we changed our default install prefix from
> >>>>>>> /usr/local/bro
> >>>>> to /usr/local/zeek, there's also a bit different logic if we find
> >>>>> someone
> >>>>> is going to install over an old Bro installation that was still at
> >>>>> the old
> >>>>> prefix, so might be good to know if you're installing fresh or
> >>>>> upgrading
> >>>>> from the old version.
> >>>>>>>
> >>>>>>>
> >>>>>>>> tests/Scripts/get-bro-env
> >>>>>>>> @@ -8,7 +8,7 @@ bro=`cat ${base}/../../build/CMakeCache.txt |
> >>>>>>>> grep
> >>>>> BRO_DIST | cut -d = -f 2`
> >>>>>>>> if [ "$1" = "brobase" ]; then
> >>>>>>>> echo ${bro}
> >>>>>>>> elif [ "$1" = "bropath" ]; then
> >>>>>>>> ${bro}/build/bro-path-dev
> >>>>>>>> ${bro}/build/zeek-path-dev
> >>>>>>>>
> >>>>>>>
> >>>>>>> This one just looks like an oversight on our end, we'll need to
> >>>>>>> keep
> >>>>> creating (or symlinking) that "build/bro-path-dev" file.
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Unfortunately, we end up with another problem:
> >>>>>>>> zeek -N
> >>>>>>>> internal error in
> >>>>>>>> /home/zeek/zeek-myricom/build/scripts/./init.bro,
> >>>>> line 37: bad reference count [0]
> >>>>>>>>
> >>>>>>>> Line 37 is just SNF_RSS_IP:
> >>>>>>>> const snf_rss_mode: set[RssField] = {
> >>>>>>>> SNF_RSS_IP,
> >>>>>>>> SNF_RSS_SRC_PORT,
> >>>>>>>> SNF_RSS_DST_PORT
> >>>>>>>> } &redef;
> >>>>>>>
> >>>>>>> This doesn't look related to the Bro-Zeek renaming, but possibly
> >>>>>>> some
> >>>>> enum optimizations we did that are being tickled by what this
> >>>>> plugin
> >>>>> is
> >>>>> doing. Particularly there's an enum being declared/defined twice:
> >>>>>>>
> >>>>>>>
> >>>>>
> >>
> https://github.com/sethhall/bro-myricom/blob/89815d89e0ba6957149521cf99e608c0dc909f6d/src/myricom.bif#L9-L15
> >>>>>>>
> >>>>>>> and
> >>>>>>>
> >>>>>>>
> >>>>>
> >>
> https://github.com/sethhall/bro-myricom/blob/89815d89e0ba6957149521cf99e608c0dc909f6d/scripts/init.bro#L26-L32
> >>>>>>>
> >>>>>>> Possibly old versions of Bro were fine with that happening, but
> >>>>>>> not
> >>>>> anymore. Generally seems odd that we don't explicitly give an
> >>>>> error
> >>>>> message to indicate the same enum being defined in two separate
> >>>>> places.
> >>>>>>>
> >>>>>>> I'll look more into what the proper fix is next week, but if
> >>>>>>> you're
> >>>>> just looking to try to get something working in the meantime, a
> >>>>> workaround
> >>>>> may be to comment out or remove the entire RssField enum
> >>>>> definition
> >>>>> inside
> >>>>> the init.bro script.
> >>>>>>>
> >>>>>>>> Clearly I'm not gonna get lucky with an easy fix. Doing a
> >>>>>>>> simple
> >>>>> search/replace for bro/zeek across the whole tree doesn't seem
> >>>>> viable as
> >>>>> things like bro-bif.h haven't changed names. Has anyone started
> >>>>> digging
> >>>>> into how plugin packages will need to be updated?
> >>>>>>>
> >>>>>>> Generally the idea is to be mostly backward compatible so people
> >>>>> aren't forced to make any changes to external plugins, but looks
> >>>>> like
> >>>>> there's a couple small things we overlooked or had not tested that
> >>>>> we'll
> >>>>> want to fix before the 3.0 release, so thanks for the early
> >>>>> feedback.
> >>>>>>>
> >>>>>>> - Jon
> >>>>>>> _______________________________________________
> >>>>>>> zeek-dev mailing list
> >>>>>>> zeek-dev at zeek.org
> >>>>>>> http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> zeek-dev mailing list
> >>>>>> zeek-dev at zeek.org
> >>>>>> http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev
> >>>>>>
> >>>>> _______________________________________________
> >>>>> zeek-dev mailing list
> >>>>> zeek-dev at zeek.org
> >>>>> http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Justin
> >>>> _______________________________________________
> >>>> zeek-dev mailing list
> >>>> zeek-dev at zeek.org
> >>>> http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev
> >>>>
> >>> _______________________________________________
> >>> zeek-dev mailing list
> >>> zeek-dev at zeek.org
> >>> http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev
> >>
> >> --
> >> Seth Hall * Corelight, Inc * www.corelight.com
> >>
>
> --
> Seth Hall * Corelight, Inc * www.corelight.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.icsi.berkeley.edu/pipermail/zeek-dev/attachments/20190716/561c856b/attachment-0001.html
More information about the zeek-dev
mailing list