[Zeek-Dev] Zeek and the myricom package plugin
Seth Hall
seth at corelight.com
Tue Jul 16 07:29:24 PDT 2019
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
More information about the zeek-dev
mailing list