On Thu, Jun 18, 2020 at 03:32 +0000, Vlad Grigorescu wrote:
As a concrete example, what does a cluster upgrade
The idea is to handle this more like other system services: you'll be
in charge of getting the new Zeek version onto all your systems
yourself, using whatever method you use for other software as well.
For example, if you're installing through a package manager, you'd
just run "update" on all systems. If you're installing from source,
you'll either need to compile on each system, or copy the installation
The underlying assumption is that people will already have a mechanism
in place for administration of their systems, and we shouldn't be
trying to reinvent the wheel, as ZeekControl oddly does. From a
sysadmin perspective, ZeekControl is really doing a lot more right now
that it should be doing; other tools don't work that way. We don't
want it look like an APT anymore (https://github.com/zeek/zeek/issues/259
Today, that means install the new version on the
manager, and then do
`zeekctl deploy`, which copies the files to the nodes and restarts the
cluster. All of that is done without Broker.
There are two parts here: (1) deploying the Zeek installation itself,
and (2) deploying any configuration changes (incl. new Zeek scripts).
For (1), the above applies: we'll rely on standard sysadmin processes
for updating. That means you'd use "zeekcl" to shutdown the cluster
processes, then run "yum update" (or whatever), then use "zeekcl"
again to start things up again. (The Zeek supervisor will be running
already at that point, managaged through systemd or whatever you're
(2) is still a bit up in the air. With 3.2, there won't be any support
for distributing configurations automatically, but we could add that
so that config files/scripts/packages do get copied around over
Broker. Feedback would be appreciated here: What's better, having
zeekcl manage that, or leave it to standard sysadmin process as well?
Reading the script linked in , I notice that zeekcl
would not support
copying files from one node to another?
Correct right now, (2) may or may not change that.
"print" will be supported (roadmap says not in 3.2 yet, but it should
be easy to do, maybe we can get it in still).
"exec" will likely not be supported. We *could* support it, no
technical reason for not doing that over Broker. It just s seems like
another things that's better handled with different tools.
Robin Sommer * Corelight, Inc. * robin(a)corelight.com * www.corelight.com