I've seen very little feedback from the Bro 2.6 beta that was posted recently. I'm wondering how many people have tried it and if there is any feedback about it?
Thanks!
.Seth
I can report bro "version 2.6-beta2-3" built and started on 9/21/2018
on FreeBSD 11.2-RELEASE-p2 is still working...no issues for me (no
plugins/packages)
Adding to the data points and hopefully confidence of people who may be waiting…
ESnet is running dev/2.7 (which includes all of the 2.6 changes) in production with no issues. CentOS 7 and MyricomSNF.
-Dop
Working great for us. We've had to rewrite some scripts and such, but otherwise, no issues. __
Thanks for your good (hard) work!
Working great for us. We've had to rewrite some scripts and such, but otherwise, no issues. __
Any comments about what scripts you had to rewrite or the reasons for why they needed rewritten?
Thanks for your good (hard) work!
I can't take much credit for this release. I had remarkably little code it, but I think it's a pretty nice release! A ton of work over multiple years has gone into it.
.Seth
So, I tried running this on FreeBSD 10.3-STABLE and I see the following, builds
fine but when trying to run:
$ ./broctl install
Error: running "bro -v" failed with output:
Undefined symbol "_ZN6broker5topic8reservedE" referenced from COPY relocation in /home/bro/master/bin/bro
I do see that bro builds against its own libcaf:
$ ldd ./bro
./bro:
libpcap.so.1 => /usr/local/opt/snf/lib/libpcap.so.1 (0x400ef1000)
libssl.so.9 => /usr/local/lib/libssl.so.9 (0x40113a000)
libcrypto.so.9 => /usr/local/lib/libcrypto.so.9 (0x401400000)
libz.so.6 => /lib/libz.so.6 (0x401852000)
libbroker.so.0 => /usr/local/lib/libbroker.so.0 (0x401c00000)
libcaf_core.so.0.16.0 => /home/bro/master/lib/libcaf_core.so.0.16.0 (0x402200000)
libcaf_io.so.0.16.0 => /home/bro/master/lib/libcaf_io.so.0.16.0 (0x402800000)
libcaf_openssl.so.0.16.0 => /home/bro/master/lib/libcaf_openssl.so.0.16.0 (0x402c86000)
libc++.so.1 => /usr/local/lib/libc++.so.1 (0x402ee0000)
libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x4031a0000)
libm.so.5 => /lib/libm.so.5 (0x4033bd000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4035e6000)
libthr.so.3 => /lib/libthr.so.3 (0x4037f4000)
libc.so.7 => /lib/libc.so.7 (0x403a18000)
libsnf.so.0 => /usr/local/opt/snf/lib/libsnf.so.0 (0x403dc6000)
libcaf_core.so.0.14.1 => /usr/local/lib/libcaf_core.so.0.14.1 (0x403fd6000)
libcaf_io.so.0.14.1 => /usr/local/lib/libcaf_io.so.0.14.1 (0x4042c4000)
libcxxrt.so => /usr/local/lib/libcxxrt.so (0x404574000)
librt.so.1 => /usr/lib/librt.so.1 (0x404790000)
Aashish
libcaf_core.so.0.16.0 => /home/bro/master/lib/libcaf_core.so.0.16.0 (0x402200000)
libcaf_io.so.0.16.0 => /home/bro/master/lib/libcaf_io.so.0.16.0 (0x402800000)
..
libcaf_core.so.0.14.1 => /usr/local/lib/libcaf_core.so.0.14.1 (0x403fd6000)
libcaf_io.so.0.14.1 => /usr/local/lib/libcaf_io.so.0.14.1 (0x4042c4000)
Looks like you have an older version of caf installed in /usr/local that may be conflicting with things.
I helped someone on IRC with a similar problem and removing any old caf libraries and header files in /usr/local fixed things.
I had that issue where I had to remove the OS installed libcaf on FreeBSD.
I'll get back to you on script rewrites.
> Working great for us. We've had to rewrite some scripts and such, but
> otherwise, no issues. __
Any comments about what scripts you had to rewrite or the reasons for
why they needed rewritten?
> Thanks for your good (hard) work!
I can't take much credit for this release. I had remarkably little code
it, but I think it's a pretty nice release! A ton of work over multiple
years has gone into it.
.Seth
Hm, that makes me wonder if we should do something like set an RPATH to make sure the correct libcaf is used.
Jon, does that make sense? It seems that this problem will only come up more frequently as caf is packaged by more systems.
.Seth
I am not sure that that will help - setting an rpath in packaged binaries is typically at least discouraged. We actually also don’t do it in the packages that we do (or will) ship.
For example, see https://wiki.debian.org/RpathIssue, https://www.debian.org/doc/manuals/maint-guide/advanced.en.html, https://fedoraproject.org/wiki/Packaging_tricks#Acceptable_use_of_rpath (rpmlint raises it as an error; it can be considered ok in fedora for internal libraries), https://en.opensuse.org/openSUSE:Packaging_checks (this seems to outright prohibit its use).
But - perhaps we should recognize such situations and refuse to compile/warn users that they mightt have to re-set their dynamic link paths?
Johanna
An RPATH is already set by default (regardless of platform):
$ readelf -d /usr/local/bro/bin/bro | grep RPATH
0x000000000000000f (RPATH) Library rpath: [/usr/local/bro/lib]
$ readelf -d /usr/local/bro/lib/libbroker.so | grep RPATH
0x000000000000000f (RPATH) Library rpath: [/usr/local/bro/lib]
$ freebsd-version
10.3-RELEASE-p29
I tried reproducing the problem by faking it out with CAF libs
installed in /usr/local:
$ ls /usr/local/lib/libcaf_*
/usr/local/lib/libcaf_core.so
/usr/local/lib/libcaf_core.so.0.15.3
/usr/local/lib/libcaf_io.so
/usr/local/lib/libcaf_io.so.0.15.3
But that still works fine for me:
$ /usr/bin/ldd /usr/local/bro/bin/bro
/usr/local/bro/bin/bro:
libpcap.so.8 => /lib/libpcap.so.8 (0x80162b000)
libssl.so.7 => /usr/lib/libssl.so.7 (0x801870000)
libcrypto.so.7 => /lib/libcrypto.so.7 (0x801adc000)
libz.so.6 => /lib/libz.so.6 (0x801ed1000)
libbroker.so.0 => /usr/local/bro/lib/libbroker.so.0 (0x802200000)
libthr.so.3 => /lib/libthr.so.3 (0x802e71000)
libcaf_core.so.0.16.0 => /usr/local/bro/lib/libcaf_core.so.0.16.0 (0x803200000)
libcaf_io.so.0.16.0 => /usr/local/bro/lib/libcaf_io.so.0.16.0 (0x803c00000)
libcaf_openssl.so.0.16.0 =>
/usr/local/bro/lib/libcaf_openssl.so.0.16.0 (0x80453e000)
libc++.so.1 => /usr/lib/libc++.so.1 (0x804844000)
libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x804b03000)
libm.so.5 => /lib/libm.so.5 (0x804d20000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x804f49000)
libc.so.7 => /lib/libc.so.7 (0x805157000)
So not sure why Aashish or others had problems with alternate CAF installations.
- Jon
For local installs where we only ever intend to load libraries that
were a part of the same build, it seems reasonable to have an RPATH.
For binary packages, I agree that it's not as good an idea, and that's
what the `configure --binary-package` flag was meant to help with: it
disables setting of RPATH instead of doing what normally happens in
cmake/SetupRPATH.cmake
- Jon