Don't recall any basic "project infrastructure" discussions happening
yet for the upcoming replacement/alternative for ZeekControl that we
want to introduce in Zeek 3.2 (roadmap/design links found at ), so
here's starting questions.
# What to Name It ?
Suggestion: `zeekcl`, Zeek (Command-Line) CLlient.
Open to ideas, but will use `zeekcl` below.
# What Programming Language ?
`zeekcl` has different/narrower scope than ZeekControl. It's more
clearly a "client" with sole job of handling requests/responses via
Broker without many (any?) system-level operations/integrations.
Meaning there may be less of an approachability/convenience gap
between C++ versus Python with `zeekcl` than there was with
Also nice if `zeekcl` doesn't require more dependencies beyond what
`zeek` needs since they're expected to be used together.
Is use of Python still desirable for other reasons? Otherwise, I lean
towards `zeekcl` being C++.
For reference/sanity-check in terms of what people expect `zeekcl` to
be: in my testing of the SupervisorControl framework , I had a
sloppy Zeek script implementing the full "client side" (essentially
the majority of what `zeekcl` will do) in ~100 LOC. Most operations
are that simple: send request and display response.
That does mean the third option to consider besides either Python or
C++ is Zeek's scripting language (e.g. `ctl.zeek`), but I don't
suggest that since (1) using a full `zeek` process is way more than we
need and (2) the command-line interface is awkward (`zeek ctl
Supervisor::cmd="status"` versus `zeekcl status`)
# Where's the Source Code Live ?
Past experiences with ZeekControl being in a separate repo than Zeek
are negative in terms of CI/testing: changes in Zeek have broken
ZeekControl, but go uncaught for a while since it is tested
Since common use/maintenance will involve both `zeek` and `zeekcl`,
and also don't expect the later to accrue large amounts of code
deserving of a separate project, I plan to have `zeekcl` code/tests
live inside the main Zeek repo.
Hi, I have abnormal behavior when I use the same script in two different
1. Zeek single thread configuration
2. Zeek configuration with four cores and four workers.
By starting the script in question, in the first mode (zeek on a single
thread) the flow
execution is linear with respect to the code, so the instructions are
executed without any
By starting the script in question, with the second modality (zeek
multithread with four cores and four workers)
the code is started correctly, but at some point workers are seen to be
Is it possible to inhibit the use of code fragments for workers?
Zeek scripts can only be used by Zeek's "manager" or "logger",
so as to prevent "workers" from doing unwanted actions? If yes, is also
possible to make "worker"
able to use some code fragments instead of others ?