The deduplication during the script's loading

Zeek
1

Hey!

Credit for discovery of this issue goes to Justin Azoff.

During module loading, Zeek checks the inode number of each script file and silently ignores a file with the same inode as loaded previously.

For example, if

/usr/share/bro/base/frameworks/input/load.bro
/usr/share/bro/base/frameworks/dpd/load.bro

share the same inode (are hardlinked) only the first one will load and the second one will not.

This breaks the workflow for me. The ClearLinux packaging mechanism, by design, hardlinks identical files (if they have identical checksum).

The net result is that a correctly packaged Zeek is left in a non-functioning state after installation.

Justin suggested that I can break hardlinks with rsync, like this

/usr/bin/rsync -aP /usr/share/bro/ /somewhere
/usr/bin/rsync -aP /somewhere /usr/share/bro/

That works - and I have a working Zeek cluster, with af_packet plugin, just by installing a single “network-monitoring-node” bundle.

Do we want to do something about it? Or is this expected? Can we, maybe, make this configurable? Should I live with this workaround?

2

During module loading, Zeek checks the inode number of each script file and silently ignores a file with the same inode as loaded previously.

That's intended/expected.

This breaks the workflow for me. The ClearLinux packaging mechanism, by design, hardlinks identical files (if they have identical checksum).

That's interesting/unfortunate.

Do we want to do something about it? Or is this expected? Can we, maybe, make this configurable? Should I live with this workaround?

IMO, it seems reasonable for us to have an intended file system
structure/layout of the stuff we install, so for a given packaging
system to come in and start changing that without knowing whether the
packaged-software actually relies on it seems like that's their own
fault/problem.

However, if a patch/pull-request were made that provides the same
functionality (prevent loading the same script via alternate, relative
path or symlink) and does not rely on inode, then that would likely be
accepted.

- Jon