zeek / zeek-af_packet-plugin

Plugin providing native AF_Packet support for Zeek.
Other
33 stars 30 forks source link

Zeek 4.0.0 zkg install #24

Closed TOoSmOotH closed 2 years ago

TOoSmOotH commented 3 years ago

Has 4.0.0 support been added yet? Getting the following when trying to install via zkg. I normally compile from scratch but thought I would try zkg so this could be user error on my part. If it hasn't been added yet feel free to close this.

The following packages will be INSTALLED: zeek/j-gras/zeek-af_packet-plugin (2.1.2)

Proceed? [Y/n] Running unit tests for "zeek/j-gras/zeek-af_packet-plugin" Proceed to install anyway? [N/y] error: failed to run tests for zeek/j-gras/zeek-af_packet-plugin: package build_command failed, see log in /opt/zeek/var/lib/zkg/logs/zeek-af_packet-plugin-build.log Installing "zeek/j-gras/zeek-af_packet-plugin"... Failed installing "zeek/j-gras/zeek-af_packet-plugin": package build_command failed, see log in /opt/zeek/var/lib/zkg/logs/zeek-af_packet-plugin-build.log error: incomplete installation, the follow packages failed to be installed: zeek/j-gras/zeek-af_packet-plugin (2.1.2) The command '/bin/sh -c yes | /opt/zeek/bin/zkg install zeek-af_packet-plugin' returned a non-zero code: 1

J-Gras commented 3 years ago

The master branch was updated to support Zeek 4.0. Using zkg the following should work: zkg install zeek-af_packet-plugin --version master

TOoSmOotH commented 3 years ago

Yea it turned out to be kernel headers on the docker container side. In the past for SO I would just compile it and include it in the plugins directory but for 4.0 I am trying to be more compliant with zkg etc. When I try to compile in docker I get the following:

-- Performing Test cxx17_works - Success -- Zeek executable : -- Zeek source : /zeekbuild/zeek-4.0.0 -- Zeek build : /zeekbuild/zeek-4.0.0/build -- Zeek install prefix : /opt/zeek -- Zeek plugin directory: /opt/zeek/lib64/zeek/plugins -- Zeek debug mode : false -- Found KernelHeaders: /usr
-- Kernelheader prefix : /usr -- Configuring done -- Generating done CMake Warning: Manually-specified variables were not used by the project:

ZEEK_DIST

-- Build files have been written to: /zeekbuild/zeek-af_packet-plugin/build make: [build-it] Error 1 (ignored)

SNIP

[ 36%] Building CXX object CMakeFiles/Zeek-AF_Packet.linux-x86_64.dir/src/AF_Packet.cc.o /zeekbuild/zeek-af_packet-plugin/src/AF_Packet.cc:2:10: fatal error: zeek/zeek-config.h: No such file or directory

include "zeek/zeek-config.h"

      ^~~~~~~~~~~~~~~~~~~~

compilation terminated. make[3]: [CMakeFiles/Zeek-AF_Packet.linux-x86_64.dir/src/AF_Packet.cc.o] Error 1 make[3]: Leaving directory `/zeekbuild/zeek-af_packet-plugin/build' make[2]: [CMakeFiles/Zeek-AF_Packet.linux-x86_64.dir/all] Error 2 make[2]: Leaving directory /zeekbuild/zeek-af_packet-plugin/build' make[1]: *** [all] Error 2 make[1]: Leaving directory/zeekbuild/zeek-af_packet-plugin/build' make: *** [build-it] Error 2

TOoSmOotH commented 3 years ago

I forgot to mention that if I use Centos 7 as the build and Centos 7 as the docker guest and they use the same kernel headers it will work properly with zkg. If you try and use say Ubuntu to build the docker it fails because uname -r returns the hosts kernel version.

TOoSmOotH commented 3 years ago

So I was able to get past this by modifying the zkg.meta file and adding --with-kernel=/usr for the configure. It still requires the --version=master as well but builds properly now on any build host under docker. I am not sure what the best default behavior would be.

J-Gras commented 3 years ago

So building for containers is a little bit difficult with respect to zkg, because CMake gets its information from the outer environment as you described. The --with-kernel option is intended for this kind of scenario. However, using zkg there is currently no way to pass this kind of optional arguments when building an installing a plugin. This was recently also discussed on Slack and I opened a corresponding feature request. So for now I hope the workaround of editing zkg.meta works for you.

grigorescu commented 3 years ago

@J-Gras What do you think about falling back to --with-latest-kernel if no kernel headers were found? Seems like a reasonable last-ditch attempt.

J-Gras commented 3 years ago

I like the idea. This may bear some potential for confusion but printing a warning that we fall back to latest kernel could help. So definitely makes sense to me.

J-Gras commented 2 years ago

Turns out we can drop the kernel header dependency completely. Thus, the plugin should now build seamlessly in containers using zkg.