From seth at corelight.com Wed Dec 5 06:45:45 2018 From: seth at corelight.com (Seth Hall) Date: Wed, 05 Dec 2018 09:45:45 -0500 Subject: [Bro-Dev] attributes & named types In-Reply-To: <20181105164014.GC80620@corelight.com> References: <201811032114.wA3LEGEm019479@fruitcake.ICSI.Berkeley.EDU> <20181105164014.GC80620@corelight.com> Message-ID: On 5 Nov 2018, at 11:40, Robin Sommer wrote: > I like the "&log=T|F" syntax to control this more directly, as long as > "&log" remains being equivalent to "&log=T". Oh, I like that too and it dovetails very nicely with the existing syntax. I remember those discussions we had about &log back then and I remember being the one that pushed for it but even then I didn't feel particularly comfortable with it (as I recall you feeling). .Seth -- Seth Hall * Corelight, Inc * www.corelight.com From leres at ee.lbl.gov Wed Dec 5 19:03:06 2018 From: leres at ee.lbl.gov (Craig Leres) Date: Wed, 5 Dec 2018 19:03:06 -0800 Subject: [Bro-Dev] Building bro 2.6 with static broker/caf libraries Message-ID: I've read up on cmake variable scope but I can't figure out how to build bro with static libraries. The bro-bundled caf already has CAF_BUILD_STATIC_ONLY which I'm pretty sure works but I'm unable to turn it on when building caf as part of a bro build. For example I'd like is to optionally (i.e. from a -D argument to cmake itself) be able to turn on CAF_BUILD_STATIC_ONLY for aux/broker/3rdparty/caf/CMakeLists.txt but nothing I've tried in the top level CMakeLists.txt is seen when the caf CMakeLists.txt is being evaluated. (I'm working on updating the FreeBSD port to 2.6 and can't install things like libcaf_io.so in /usr/local/lib because they conflict with libraries potentially installed by the devel/caf port.) Craig From seth at corelight.com Thu Dec 6 05:53:05 2018 From: seth at corelight.com (Seth Hall) Date: Thu, 06 Dec 2018 08:53:05 -0500 Subject: [Bro-Dev] Building bro 2.6 with static broker/caf libraries In-Reply-To: References: Message-ID: <0BD9C77C-30E2-433B-B65F-E4B7BF3F9AD4@corelight.com> Johanna has been working on this recently. We may end up needing to do a minor release update just to fix this because it appears that it's going to be a bit of a packaging problem on a number of OSs and distros otherwise. .Seth On 5 Dec 2018, at 22:03, Craig Leres wrote: > I've read up on cmake variable scope but I can't figure out how to > build > bro with static libraries. The bro-bundled caf already has > CAF_BUILD_STATIC_ONLY which I'm pretty sure works but I'm unable to > turn > it on when building caf as part of a bro build. > > For example I'd like is to optionally (i.e. from a -D argument to > cmake > itself) be able to turn on CAF_BUILD_STATIC_ONLY for > aux/broker/3rdparty/caf/CMakeLists.txt but nothing I've tried in the > top > level CMakeLists.txt is seen when the caf CMakeLists.txt is being > evaluated. > > (I'm working on updating the FreeBSD port to 2.6 and can't install > things like libcaf_io.so in /usr/local/lib because they conflict with > libraries potentially installed by the devel/caf port.) > > Craig > _______________________________________________ > bro-dev mailing list > bro-dev at bro.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev -- Seth Hall * Corelight, Inc * www.corelight.com From robin at corelight.com Thu Dec 6 06:59:31 2018 From: robin at corelight.com (Robin Sommer) Date: Thu, 6 Dec 2018 06:59:31 -0800 Subject: [Bro-Dev] Building bro 2.6 with static broker/caf libraries In-Reply-To: References: Message-ID: <20181206145931.GC71146@corelight.com> On Wed, Dec 05, 2018 at 19:03 -0800, Craig Leres wrote: > (I'm working on updating the FreeBSD port to 2.6 and can't install > things like libcaf_io.so in /usr/local/lib because they conflict with > libraries potentially installed by the devel/caf port.) What's the version of the CAF port? If it's recent, Bro should be able to link against that. Robin -- Robin Sommer * Corelight, Inc. * robin at corelight.com * www.corelight.com From johanna at icir.org Thu Dec 6 07:01:25 2018 From: johanna at icir.org (Johanna Amann) Date: Thu, 6 Dec 2018 07:01:25 -0800 Subject: [Bro-Dev] Building bro 2.6 with static broker/caf libraries In-Reply-To: References: Message-ID: <20181206150114.hjt6s3ezowsepnn7@Tranquility.local> Hi Craig, I actually recently started working on this, however I am did not quite look at what you want. There already is a branch called topic/johanna/static, which now makes --build-static(-only) work for broker whan CAF is built statically - it does not yet pass the static flags through to broker; I actually wanted to take a look at that today. I will let you know when I make progress there :) Johanna On Wed, Dec 05, 2018 at 07:03:06PM -0800, Craig Leres wrote: > I've read up on cmake variable scope but I can't figure out how to build > bro with static libraries. The bro-bundled caf already has > CAF_BUILD_STATIC_ONLY which I'm pretty sure works but I'm unable to turn > it on when building caf as part of a bro build. > > For example I'd like is to optionally (i.e. from a -D argument to cmake > itself) be able to turn on CAF_BUILD_STATIC_ONLY for > aux/broker/3rdparty/caf/CMakeLists.txt but nothing I've tried in the top > level CMakeLists.txt is seen when the caf CMakeLists.txt is being evaluated. > > (I'm working on updating the FreeBSD port to 2.6 and can't install > things like libcaf_io.so in /usr/local/lib because they conflict with > libraries potentially installed by the devel/caf port.) > > Craig > _______________________________________________ > bro-dev mailing list > bro-dev at bro.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev > From hosom at battelle.org Thu Dec 6 09:09:02 2018 From: hosom at battelle.org (Hosom, Stephen M) Date: Thu, 6 Dec 2018 17:09:02 +0000 Subject: [Bro-Dev] Broker cluster discovery and load balancing Message-ID: I've been working on an application that will fire a large volume of events into bro through broker. Basically, I want to fire events into Broker and load balance them across a pool of workers without the need for more than one worker to handle the same event. I'm having difficulty determining the most right way to accomplish a couple tasks. I have looked at the implementations of publish_hrw and publish_rr in bro. I could easily implement those features in my application if that is the recommended way to handle this issue. Unfortunately, that leaves me with another unfortunate problem. I have been unsuccessful in determining how to 'discover' members of a Bro cluster via Broker. Is there a way to do discovery, or do I need to know who the cluster members are and what port they are listening on via a broctl configuration equivalent? From johanna at icir.org Thu Dec 6 10:25:50 2018 From: johanna at icir.org (Johanna Amann) Date: Thu, 6 Dec 2018 10:25:50 -0800 Subject: [Bro-Dev] Building bro 2.6 with static broker/caf libraries In-Reply-To: <20181206150114.hjt6s3ezowsepnn7@Tranquility.local> References: <20181206150114.hjt6s3ezowsepnn7@Tranquility.local> Message-ID: <20181206182550.o6c3cxprmjduayp7@Trafalgar.local> Hi Craig, I pushed another commit to the branch that passes --build-static-only through to CAF; if you just want the patch for that it is available at https://github.com/zeek/broker/commit/bf03a4246113c72d10530cc0c2729a3fa6f0b046. (Note that repositories are currently being migrated; if you pull it from somewhere make sure that you actually have that commit in the branch) Johanna On Thu, Dec 06, 2018 at 07:01:25AM -0800, Johanna Amann wrote: > Hi Craig, > > I actually recently started working on this, however I am did not quite > look at what you want. > > There already is a branch called topic/johanna/static, which now makes > --build-static(-only) work for broker whan CAF is built statically - it > does not yet pass the static flags through to broker; I actually wanted to > take a look at that today. > > I will let you know when I make progress there :) > > Johanna > > On Wed, Dec 05, 2018 at 07:03:06PM -0800, Craig Leres wrote: > > I've read up on cmake variable scope but I can't figure out how to build > > bro with static libraries. The bro-bundled caf already has > > CAF_BUILD_STATIC_ONLY which I'm pretty sure works but I'm unable to turn > > it on when building caf as part of a bro build. > > > > For example I'd like is to optionally (i.e. from a -D argument to cmake > > itself) be able to turn on CAF_BUILD_STATIC_ONLY for > > aux/broker/3rdparty/caf/CMakeLists.txt but nothing I've tried in the top > > level CMakeLists.txt is seen when the caf CMakeLists.txt is being evaluated. > > > > (I'm working on updating the FreeBSD port to 2.6 and can't install > > things like libcaf_io.so in /usr/local/lib because they conflict with > > libraries potentially installed by the devel/caf port.) > > > > Craig > > _______________________________________________ > > bro-dev mailing list > > bro-dev at bro.org > > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev > > > _______________________________________________ > bro-dev mailing list > bro-dev at bro.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev > From p.antoine at catenacyber.fr Thu Dec 6 11:15:06 2018 From: p.antoine at catenacyber.fr (Philippe Antoine) Date: Thu, 6 Dec 2018 20:15:06 +0100 Subject: [Bro-Dev] Building bro 2.6 with static broker/caf libraries In-Reply-To: <20181206182550.o6c3cxprmjduayp7@Trafalgar.local> References: <20181206150114.hjt6s3ezowsepnn7@Tranquility.local> <20181206182550.o6c3cxprmjduayp7@Trafalgar.local> Message-ID: In case it is helpful, here is the script I used to build all static bro (without any shared libraries) ``` cd bro mkdir buildcaf cd buildcaf cmake -DCAF_NO_UNIT_TESTS=1 -DCAF_NO_EXAMPLES=1 -DCAF_BUILD_STATIC_ONLY=1 ../aux/broker/3rdparty/caf/ make make install || true cd .. mkdir build cd build cmake -DDISABLE_PYTHON_BINDINGS=1 -DENABLE_STATIC_ONLY=1 -DCAF_ROOT_DIR=../buildcaf .. make make install ``` It needed also a small patch to bro, which comes afterwards ``` diff --git a/CMakeLists.txt b/CMakeLists.txt index 452f2834c..c8039f8da 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -268,7 +268,11 @@ install(DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/cmake DESTINATION share/bro ## Recurse on sub-directories add_subdirectory(aux/broker) -set(brodeps ${brodeps} broker) +if (ENABLE_STATIC_ONLY) + set(brodeps ${brodeps} broker_static) +else () + set(brodeps ${brodeps} broker) +endif () include_directories(BEFORE ${CMAKE_CURRENT_SOURCE_DIR}/aux/broker ${CMAKE_CURRENT_BINARY_DIR}/aux/broker) include_directories(BEFORE ${CAF_INCLUDE_DIR_CORE}) ``` > Le 6 d?c. 2018 ? 19:25, Johanna Amann a ?crit : > > Hi Craig, > > I pushed another commit to the branch that passes --build-static-only through > to CAF; if you just want the patch for that it is available at > https://github.com/zeek/broker/commit/bf03a4246113c72d10530cc0c2729a3fa6f0b046. > > (Note that repositories are currently being migrated; if you pull it from > somewhere make sure that you actually have that commit in the branch) > > Johanna > > On Thu, Dec 06, 2018 at 07:01:25AM -0800, Johanna Amann wrote: >> Hi Craig, >> >> I actually recently started working on this, however I am did not quite >> look at what you want. >> >> There already is a branch called topic/johanna/static, which now makes >> --build-static(-only) work for broker whan CAF is built statically - it >> does not yet pass the static flags through to broker; I actually wanted to >> take a look at that today. >> >> I will let you know when I make progress there :) >> >> Johanna >> >> On Wed, Dec 05, 2018 at 07:03:06PM -0800, Craig Leres wrote: >>> I've read up on cmake variable scope but I can't figure out how to build >>> bro with static libraries. The bro-bundled caf already has >>> CAF_BUILD_STATIC_ONLY which I'm pretty sure works but I'm unable to turn >>> it on when building caf as part of a bro build. >>> >>> For example I'd like is to optionally (i.e. from a -D argument to cmake >>> itself) be able to turn on CAF_BUILD_STATIC_ONLY for >>> aux/broker/3rdparty/caf/CMakeLists.txt but nothing I've tried in the top >>> level CMakeLists.txt is seen when the caf CMakeLists.txt is being evaluated. >>> >>> (I'm working on updating the FreeBSD port to 2.6 and can't install >>> things like libcaf_io.so in /usr/local/lib because they conflict with >>> libraries potentially installed by the devel/caf port.) >>> >>> Craig >>> _______________________________________________ >>> bro-dev mailing list >>> bro-dev at bro.org >>> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev >>> >> _______________________________________________ >> bro-dev mailing list >> bro-dev at bro.org >> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev >> > _______________________________________________ > bro-dev mailing list > bro-dev at bro.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20181206/60e57617/attachment-0001.html From johanna at icir.org Thu Dec 6 11:55:12 2018 From: johanna at icir.org (Johanna Amann) Date: Thu, 6 Dec 2018 11:55:12 -0800 Subject: [Bro-Dev] Building bro 2.6 with static broker/caf libraries In-Reply-To: <20181206182550.o6c3cxprmjduayp7@Trafalgar.local> References: <20181206150114.hjt6s3ezowsepnn7@Tranquility.local> <20181206182550.o6c3cxprmjduayp7@Trafalgar.local> Message-ID: <20181206195512.iyynwjmkwrozkqzq@Trafalgar.local> FYI - there now also is a topic/johanna/static branch in the base repository, which adds a --enable-static-broker flag that automatically builds/links static broker/caf against Bro. Pull request in https://github.com/zeek/zeek/pull/224. Johanna On Thu, Dec 06, 2018 at 10:25:50AM -0800, Johanna Amann wrote: > Hi Craig, > > I pushed another commit to the branch that passes --build-static-only through > to CAF; if you just want the patch for that it is available at > https://github.com/zeek/broker/commit/bf03a4246113c72d10530cc0c2729a3fa6f0b046. > > (Note that repositories are currently being migrated; if you pull it from > somewhere make sure that you actually have that commit in the branch) > > Johanna > > On Thu, Dec 06, 2018 at 07:01:25AM -0800, Johanna Amann wrote: > > Hi Craig, > > > > I actually recently started working on this, however I am did not quite > > look at what you want. > > > > There already is a branch called topic/johanna/static, which now makes > > --build-static(-only) work for broker whan CAF is built statically - it > > does not yet pass the static flags through to broker; I actually wanted to > > take a look at that today. > > > > I will let you know when I make progress there :) > > > > Johanna > > > > On Wed, Dec 05, 2018 at 07:03:06PM -0800, Craig Leres wrote: > > > I've read up on cmake variable scope but I can't figure out how to build > > > bro with static libraries. The bro-bundled caf already has > > > CAF_BUILD_STATIC_ONLY which I'm pretty sure works but I'm unable to turn > > > it on when building caf as part of a bro build. > > > > > > For example I'd like is to optionally (i.e. from a -D argument to cmake > > > itself) be able to turn on CAF_BUILD_STATIC_ONLY for > > > aux/broker/3rdparty/caf/CMakeLists.txt but nothing I've tried in the top > > > level CMakeLists.txt is seen when the caf CMakeLists.txt is being evaluated. > > > > > > (I'm working on updating the FreeBSD port to 2.6 and can't install > > > things like libcaf_io.so in /usr/local/lib because they conflict with > > > libraries potentially installed by the devel/caf port.) > > > > > > Craig > > > _______________________________________________ > > > bro-dev mailing list > > > bro-dev at bro.org > > > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev > > > > > _______________________________________________ > > bro-dev mailing list > > bro-dev at bro.org > > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev > > > _______________________________________________ > bro-dev mailing list > bro-dev at bro.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev > From jsiwek at corelight.com Thu Dec 6 12:50:50 2018 From: jsiwek at corelight.com (Jon Siwek) Date: Thu, 6 Dec 2018 14:50:50 -0600 Subject: [Bro-Dev] Broker cluster discovery and load balancing In-Reply-To: References: Message-ID: On Thu, Dec 6, 2018 at 11:16 AM Hosom, Stephen M wrote: > I have looked at the implementations of publish_hrw and publish_rr in bro. I could easily implement those features in my application if that is the recommended way to handle this issue. There's been some ideas on pushing loading balancing mechanisms into broker itself, but I doubt that's something that will get done in the near term. Explicitly implementing HRW or Round-Robin load balancing in your application is definitely one way to handle things for now. > Unfortunately, that leaves me with another unfortunate problem. I have been unsuccessful in determining how to 'discover' members of a Bro cluster via Broker. Is there a way to do discovery, or do I need to know who the cluster members are and what port they are listening on via a broctl configuration equivalent? At the moment, the cluster configuration is defined by the Cluster::nodes table that gets auto-generated by broctl into cluster-layout.bro. Does that table have all the info you need? You still might need a well-known node to connect your broker application (e.g. manager) to, but then you should be able to send back the information you need from that table (e.g. here's the list of worker ip/port pairs). - Jon From vern at corelight.com Thu Dec 6 14:02:40 2018 From: vern at corelight.com (Vern Paxson) Date: Thu, 06 Dec 2018 14:02:40 -0800 Subject: [Bro-Dev] "delete" of entire tables/sets Message-ID: <20181206220240.0E6F12C6D02@rock.ICSI.Berkeley.EDU> I'm working on some scripts where I want to remove every element from a table in a single shot. In awk, "delete tbl" would do the trick, but Zeek restricts delete operations to removing single elements. Worse, if I try iterating over an aggregate to remove elements piece-wise, it doesn't remove all of them, no doubt because the internal hash table is changing mid-stream of the "for" loop and thus doesn't visit all of the members. This means I have to first build up a *separate* vector of all the indexes, then iterate over that to remove them. Proposal: extend "delete" so that if applied to a table or a set, it clears out all of its elements. This seems straightforward to me, and something that I'll see if I can find some cycles soon to hack out. Comments? Vern From jsiwek at corelight.com Thu Dec 6 14:37:11 2018 From: jsiwek at corelight.com (Jon Siwek) Date: Thu, 6 Dec 2018 16:37:11 -0600 Subject: [Bro-Dev] "delete" of entire tables/sets In-Reply-To: <20181206220240.0E6F12C6D02@rock.ICSI.Berkeley.EDU> References: <20181206220240.0E6F12C6D02@rock.ICSI.Berkeley.EDU> Message-ID: On Thu, Dec 6, 2018 at 4:09 PM Vern Paxson wrote: > This means I have to first build up a *separate* vector of all the indexes, > then iterate over that to remove them. I guess re-assigning a new, empty table to the variable could be analogous to deleting all entries and also avoids the iterator invalidation problem ? > Proposal: extend "delete" so that if applied to a table or a set, it clears > out all of its elements. But yeah, that also seems clearer to me at first thought. - Jon From vern at corelight.com Thu Dec 6 15:11:25 2018 From: vern at corelight.com (Vern Paxson) Date: Thu, 06 Dec 2018 15:11:25 -0800 Subject: [Bro-Dev] "delete" of entire tables/sets In-Reply-To: (Thu, 06 Dec 2018 16:37:11 CST). Message-ID: <20181206231125.24F102C6ED6@rock.ICSI.Berkeley.EDU> > I guess re-assigning a new, empty table to the variable could be > analogous to deleting all entries and also avoids the iterator > invalidation problem ? Hah!, yeah, that's certainly a simple way to do it. Maybe I'll change my hacking for now to just be adding this observation to the "delete" documentation :-). Vern From jmellander at lbl.gov Thu Dec 6 16:07:24 2018 From: jmellander at lbl.gov (Jim Mellander) Date: Thu, 6 Dec 2018 16:07:24 -0800 Subject: [Bro-Dev] "delete" of entire tables/sets In-Reply-To: <20181206231125.24F102C6ED6@rock.ICSI.Berkeley.EDU> References: <20181206231125.24F102C6ED6@rock.ICSI.Berkeley.EDU> Message-ID: I believe the clear_table() function still exists in zeek, as well... On Thu, Dec 6, 2018 at 3:12 PM Vern Paxson wrote: > > I guess re-assigning a new, empty table to the variable could be > > analogous to deleting all entries and also avoids the iterator > > invalidation problem ? > > Hah!, yeah, that's certainly a simple way to do it. Maybe I'll > change my hacking for now to just be adding this observation to > the "delete" documentation :-). > > Vern > _______________________________________________ > bro-dev mailing list > bro-dev at bro.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20181206/27ee1bf3/attachment.html From vern at corelight.com Thu Dec 6 16:17:20 2018 From: vern at corelight.com (Vern Paxson) Date: Thu, 06 Dec 2018 16:17:20 -0800 Subject: [Bro-Dev] "delete" of entire tables/sets In-Reply-To: (Thu, 06 Dec 2018 16:07:24 PST). Message-ID: <20181207001720.3929E2C7049@rock.ICSI.Berkeley.EDU> > I believe the clear_table() function still exists in zeek, as well... Hah^2! Yeah, it does. Well, glad I consulted the list before diving into some hacking :-P. Vern From johanna at icir.org Thu Dec 13 14:22:05 2018 From: johanna at icir.org (Johanna Amann) Date: Thu, 13 Dec 2018 14:22:05 -0800 Subject: [Bro-Dev] New nightly builds and Bro build testing Message-ID: <20181213222205.kmn6jz75oaiwogt4@user159.sys.ICSI.Berkeley.EDU> Hello everyone, as some of you might have noticed, our nightly builds have been broken for a while. To be more exact since broker was introduced - since this opened up a few questions on how exactly packaging should be performed. These problems have now been cleared up and new nightly builds are available on OBS: Download URLs: https://software.opensuse.org//download.html?project=network%3Abro&package=bro-nightly Package Information: https://build.opensuse.org/package/show/network:bro/bro-nightly The new builds now link CAF and Broker statically into Bro - so it is no longer necessary to fiddle with the ld.so.conf or similar. Builds are now also available for a newer selection of distributions (again). If your favorite distribution is missing for some reason, let me know :) If no one discovers any problems with these build I will do new package builds of Bro 2.6 using the exact same approach. I only did somewhat limited testing, but on the few distributions I tried everything worked fine. Note that the name of the project on OBS will change to network:zeek/zeek-nightly at some point in the future - I will send another followup email once that happens. Johanna From jmellander at lbl.gov Tue Dec 18 11:29:17 2018 From: jmellander at lbl.gov (Jim Mellander) Date: Tue, 18 Dec 2018 11:29:17 -0800 Subject: [Bro-Dev] "delete" of entire tables/sets In-Reply-To: <20181207001720.3929E2C7049@rock.ICSI.Berkeley.EDU> References: <20181207001720.3929E2C7049@rock.ICSI.Berkeley.EDU> Message-ID: To satisfy my curiosity and to provide further info for anyone viewing list archives, I benchmarked assigning a new table() vs. running clear_table() on tables of various sizes & complexities. Assigning a new table() was clearly the winner by a huge margin. It should be noted that these two methods are not completely equivalent. I run a script where a current table is periodically moved to an old table, and the current table cleared for further use. So, with A & B being tables of the same type: B = A; A = table(); works as intended, as B now contains the prior contents of A, and A is a new empty table. B = A; clear_table(A); clears both, as they both point to the same table. On Thu, Dec 6, 2018 at 4:17 PM Vern Paxson wrote: > > I believe the clear_table() function still exists in zeek, as well... > > Hah^2! Yeah, it does. Well, glad I consulted the list before diving into > some hacking :-P. > > Vern > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20181218/66017dfc/attachment.html From johanna at icir.org Wed Dec 19 04:38:42 2018 From: johanna at icir.org (Johanna Amann) Date: Wed, 19 Dec 2018 13:38:42 +0100 Subject: [Bro-Dev] Zeek mailing list renaming and outage Message-ID: <20181219123842.eizalnmhjjwdm5tp@Tranquility.fritz.box> Hello everyone, As part of renaming Bro to Zeek, we are going to change the addresses and names of all our mailing lists. The important thing first: this change is going to happen tomorrow (Thursday), 12/20. The mailing list rename will happen during a system maintenance window at ICSI (which is hosting the mailing list). Thus the mailing lists (including the archives) will be unavailable for a few hours during the day on Thursday. Mails sent to the lists during this time should be queued and delivered when the system is back up. The current Bro mailing lists will be renamed as follows: bro at bro.org -> zeek at zeek.org bro-dev at bro.org -> zeek-dev at zeek.org bro-commits at bro.org -> zeek-commits at zeek.org bro-announce at bro.org -> zeek-announce at zeek.org Similarly we will change the mailing list subject tags from Bro to Zeek. There will be redirects from the old mailing list names to the new ones, so mails sent to the old addresses will not be lost. Johanna