Zeek renaming: update executable names

[jsiwek]

Things like the bro binary and other tools/scripts like bro-config or bro-cut should be zeekified (I just listed those from memory, should search for others, too).

Seems they can either be symlinks or else a separate script that first emits a deprecation warning before calling out to the actual executable. Depends on what plans are to support the old names... maybe something to consider is that there's may be external scripts/tools that are actually depending on a process name being 'bro'.

[rsmmr]

I'm planing to do the following:

1. Rename executables as proposed below.
2. For each, install a link under the old name pointing to a wrapper script that forwards to the new executable.
3. The wrapper script will also print a deprecation warning if (1) it's running from a tty, and (2) the environment variable ZEEK_IS_BRO remains unset.

I'd ignore any concerns about the process name, that seems hard to anticipate and address.

Does that all sound right? Anything missing from the list below?

bro -> zeek
bro-config -> zeek-config
broctl -> zeekctl
bro-cut -> zeek-cut

No change:
    bifcl
    binpac
    btest
    capstats
    trace-summary
    Anything Broker
    Anything Broccoli (which we should remove for 3.0)

[jsiwek]

Yes, the wrapper script approach was what I was thinking also, but a couple thoughts:

• I'm expecting you maybe have to at least care about fixing BroControl to be aware of the new 'zeek' process name, thought I remember some commands specifically looking for that.

• Renaming broctl -> zeekctl may be awkward if we wanted to later use zeekctl to mean something in the new Supervisor ecosystem, but I guess it's maybe fine and we can instead go with zctl or zktl if later on we need/want something where that kind of name still makes sense.

[sethhall]

Would it make more sense to just make zeek look to see what it was called itself when it started and print the message itself when it starts? Then it's just a symlink from zeek -> bro. .Seth

…

On Apr 2, 2019, at 10:31 AM, Robin Sommer ***@***.***> wrote: I'm planing to do the following: Rename executables as proposed below. For each, install a link under the old name pointing to a wrapper script that forwards to the new executable. The wrapper script will also print a deprecation warning if (1) it's running from a tty, and (2) the environment variable ZEEK_IS_BRO remains unset. I'd ignore any concerns about the process name, that seems hard to anticipate and address. Does that all sound right? Anything missing from the list below? bro -> zeek bro-config -> zeek-config broctl -> zeekctl bro-cut -> zeek-cut No change: bifcl binpac btest capstats trace-summary Anything Broker Anything Broccoli (which we should remove for 3.0) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[rsmmr]

@jsiwek Yeah, BroControl will need some additional care. For its new name, I'd prefer to stick to a predictable renaming scheme for all executables, i.e., sed 's/^bro/zeek/'. And it will probably make sense to find a different name for any new tool anyways.

@sethhall we'll need to do this for the other tools as well, and a single wrapper script seems easier. Any problem with "bro" being a wrapper?

[sethhall]

Not really. At least with the wrapper script, it won't be new code and can be easily removed once the "bro" name is completely deprecated.

[rsmmr]

First stab of this is now in topic/robin/gh-239 in repos zeek, bro-aux, broctl, and zeek-docs. It's probably not perfect yet, but ready for some testing.

For BroControl I went with a pretty comprehensive search-and-replace as it turned out difficult to tease it apart otherwise. I put wrappers for legacy names in place, including for the plugin API. The tests all pass (one exception: command.update, but that's failing on master already for me). I could use some more help testing zeekctl from people more familiar with it. @justin or @dnthayer, could you give it a try and see if you spot anything not working?

[jsiwek]

@rsmmr nice (and thanks, this looks like maybe the most tedious rename yet). I did a quick interactive test of zeekctl (both standalone and cluster) and didn't notice any issues.

Also did a quick skimming review of the changes:

• zeek

  • wrapper script was missing arg forwarding ?

• zeek-aux

  • does the configure skeleton need to fallback on looking for a bro-config if there's no zeek-config, since some may want to still write plugins that are 2.6 compatible ?
  • similarly, need a fallback on looking for bro-path-dev.in ?

• zeekctl

  • some "broke" strings got changed to "zeekke"
  • we'll remove the update command soon, so seems fine if that test fails
  • change broctl repo name to zeekctl (and submodule/dir name within zeek repo) ? We can do this whenever, like on or after merge, just confirming we want that.

[dnthayer]

I found some typos in the changes made in the broctl repo. Should I just push a commit in branch topic/robin/gh-239 in the broctl repo to fix those typos?

Also, not sure if the change "Big Brother" --> "Big Zeekther" was intentional or not (in the MailFrom option).

[rsmmr]

Yes, you can go ahead and push any fixes. "Big Zeekther" was not intentional, and I thought I had fixed that already. At at least one place I replaced it with just "Zeek", sounds like I didn't catch them all. Robin

…

On Tue, May 07, 2019 at 23:06 -0700, Daniel Thayer wrote: I found some typos in the changes made in the broctl repo. Should I just push a commit in branch topic/robin/gh-239 in the broctl repo to fix those typos? Also, not sure if the change "Big Brother" --> "Big Zeekther" was intentional or not (in the MailFrom option). -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #239 (comment)

-- Robin Sommer * Corelight, Inc. * robin@corelight.com * www.corelight.com

[rsmmr]

@dnthayer Thanks for the fixes and improvements.

@jsiwek Fallback on bro-config and bro-path-dev.in for the plugin configure is a good idea. I'll add that. I didn't change the repo name yet to not break stuff, can I leave that to you on merge?

[rsmmr]

Done, I believe this is ready to merge now. Going file PR.

[jsiwek]

This is completed via #363, thanks Robin.