Closed philrz closed 3 years ago
Thanks a bunch Phil, lots of useful detail here! From the error messages this looks like the problem described here, i.e. a platform-internal ordering problem in the resolution of math.h. That would mean it's certainly not a Community ID problem and arguably also not a Zeek one. But ... this makes it pretty intriguing that your Zeek-bundled zkg doesn't have this problem... I would have assumed this to make zero difference as far as running the package's build_command
is concerned. So there's something interesting going on here. I'll dig in and follow up.
I tweaked the actions so they dump the generated CMakeCache.txt files out of the package build directory zkg produces in its internal state. There's a pretty suspicious difference in the include folders produced via zeek-config --include_dir
. For the succeeding build:
BRO_CONFIG_INCLUDE_DIR:PATH=/usr/local/zeek/include:/usr/local/zeek/include/zeek:/Applications/Xcode_12.4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/usr/include:/Applications/Xcode_12.4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/usr/include:/usr/local/opt/openssl/include::
For the brew-based, failing one:
BRO_CONFIG_INCLUDE_DIR:PATH=/usr/local/Cellar/zeek/4.0.0/include:/usr/local/Cellar/zeek/4.0.0/include/zeek:/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include:/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include:/usr/local/opt/openssl@1.1/include::
I.e., different SDKs, which matches the diagnosis in the link above.
More tomorrow...
zeek/zeek#1368 looks related too, though the focus there was CirrusCI.
It looks like the root discrepancy between the brew-based install and the full build is indeed that in the Homebrew install zeek-config --include_dir
lists /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include
for some system headers Zeek requires, whereas in the local build it ends up being /Applications/Xcode_12.4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/usr/include
.
A crude workaround if you want to keep using the Homebrew workflow right now is therefore to swap out these paths in zeek-config via something like this:
diff --git a/.github/workflows/runtest.yaml b/.github/workflows/runtest.yaml
index a98eb24..4557e0e 100644
--- a/.github/workflows/runtest.yaml
+++ b/.github/workflows/runtest.yaml
@@ -8,7 +8,9 @@ jobs:
runs-on: macos-10.15
steps:
- name: Install Zeek via brew
- run: brew install zeek
+ run: |
+ brew install zeek
+ sed -i '' "s|$(xcrun --show-sdk-path)|$(xcodebuild -sdk macosx -version | grep '^Path:' | cut -d' ' -f2)|" $(brew --cellar)/zeek/4.0.0/bin/zeek-config
- name: Install/setup Zeek Package Manager
run: |
sudo pip3 install zkg
I cobbled together a few commands here that seem better than literally spelling out paths subject to change, but it's clearly a hack. I suspect the true fix will be to our MacDependencyPaths
CMake module over in Zeek, for which I'll now create a ticket.
This is the second case in the past weeks where it would have been handy to alter the paths that zeek-config
reports after installation, for external reasons — the other was a DESTDIR-style FreeBSD override for a Zeek install staged in an alternative location.
I'm pleased to report that with the guidance from @ckreibich and patch suggestions from @bbannier, I've managed to get https://github.com/Homebrew/homebrew-core/pull/74932 merged to address the original symptom described at this issue. Now that the Homebrew formula is updated, here's verification steps on a scratch macOS running on GitHub Actions that shows it's now working:
$ brew update
$ brew install zeek
$ sudo pip3 install zkg
$ sudo zkg autoconfig
$ sudo zkg install --force https://github.com/corelight/zeek-community-id
$ wget https://archive.wrccdc.org/pcaps/2018/wrccdc.2018-03-23.010014000000000.pcap.gz
$ gunzip wrccdc.2018-03-23.010014000000000.pcap.gz
$ zeek -C -r wrccdc.2018-03-23.010014000000000.pcap --exec "@load packages" local
$ cat conn.log | zeek-cut community_id | head -1
1:Ok4Im3EoUdvUUsMuVAIMNfYoKfg=
Since I was the one who originally opened this issue, I'll go ahead and close it now. Thanks to everyone for their help! It's good knowing I can point users at Homebrew-installed binary Zeek and know they can use the Community ID package. It's become very useful in the Brim experience since it's essential for joining Zeek and Suricata data.
Thank you for all your work here, Phil! :+1:
I originally stumbled onto this problem on my Mac laptop running macOS Big Sur (11.2), but as I get into below, I've reproduced it on GitHub Actions runners using macOS 10.15 as well. I figure using Actions makes it easier for others to acquire & run this on "scratch" macOS instances.
Starting from a fresh macOS host, the steps & failure log in a nutshell:
For GitHub Actions Workflow that reproduces this problem, see this repo:
https://github.com/philrz/zeek-macos-brew-cid-fail
The Actions Workflow file that repeats the steps above to show the failure is at:
https://github.com/philrz/zeek-macos-brew-cid-fail/blob/main/.github/workflows/runtest.yaml
I've confirmed via a separate set of runs that I do not have this problem if I compile Zeek v4.0.0 from source and use its built-in
zkg
. A repo that runs those steps successfully as a GitHub Actions workflow, for comparison:https://github.com/philrz/zeek-macos-compiled-cid-success
https://github.com/philrz/zeek-macos-compiled-cid-success/blob/main/.github/workflows/runtest.yaml