[Zeek-Dev] Zeek and the myricom package plugin

[Michael Dopheide]

>
>
> 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.
>
>
This is a fresh install.  bro-config.h is a symlink in the installed
directory, but I think the issue is that the plugin is building against
bro-dist, the source tree and [bro-dist]/build/bro-config.h doesn't exist.
I can verify this by making that symlink exist.


> This one just looks like an oversight on our end, we'll need to keep
> creating (or symlinking) that "build/bro-path-dev" file.
>

Right on.


> 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.
>

Might give that shot depending how the weekend goes.  Not in a rush, so we
can catch up next week.

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.
>

Wait, are we the only ones that try to run 'master' in production?  :)

Side conversation, what are people's thoughts on how to handle package
transition to zeek?  Using bro-myricom as an example, I made a zeek-myricom
just to help me keep in clear in my head.  Repos could just be renamed, but
I can see situations where that breaks auto-update procedures without some
hand holding.  I haven't looked too closely to see if zkg supports both
bro-pkg and zkg in the 'depends' field for meta data.

-Dop
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.icsi.berkeley.edu/pipermail/zeek-dev/attachments/20190712/7aec2cc3/attachment.html