zeek-dev June 2020

zeek-dev@lists.zeek.org

3 discussions

Zeek Supervisor: designing client and log archival behavior

by Jon Siwek

Looking for feedback on the design/plan for these two Zeek Supervisor components: * https://github.com/zeek/zeek/wiki/Zeek-Supervisor-Client * https://github.com/zeek/zeek/wiki/Zeek-Supervisor-Log-Handling - Jon

5 months

Zeek Supervisor Command-Line Client

by Jon Siwek

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 [1]), 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 ZeekControl. 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 [2], 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 independently. 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. - Jon [1] https://github.com/zeek/zeek/issues/582 [2] https://github.com/zeek/zeek/blob/689a242836092fba7818ba24724b74a7a7902e48/…

5 months

Use zeek scripts only with the "manager" in a cluster configuration

by Davide Robusto

Hi, I have abnormal behavior when I use the same script in two different configurations: 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 Abnormal behavior. 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 performing actions randomly. 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 ?

5 months, 3 weeks

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

zeek-dev June 2020