For fun, and to see how well the new build system could work with a packaging system, I built some port files for macports tonight and had a few comments.
*It seems that when "make install" is called in broctl, the broctl-config.sh script is not generated. Maybe "broctl install" just needs to be run as part of the "make install" process?
* Perhaps the "spool" directory for broctl should be moved to "<prefix>/var/spool/bro"? MacPorts gives the following warning messages:
Warning: violation by /opt/local/spool
Warning: broctl violates the layout of the ports-filesystems!
Warning: Please fix or indicate this misbehavior (if it is intended), it will be an error in future releases!
* I wonder if broctl's configuration files should be put into a subdirectory in etc, like <prefix>/etc/broctl/node.cfg, etc.? Right now, if Bro is installed alongside other software you end up with <prefix>/etc/node.cfg which is a little confusing.
*It seems that when "make install" is called in broctl, the
broctl-config.sh script is not generated. Maybe "broctl install"
just needs to be run as part of the "make install" process?
(Jon knows best where/when this is generated.)
* Perhaps the "spool" directory for broctl should be moved to
"<prefix>/var/spool/bro"?
* I wonder if broctl's configuration files should be put into a
subdirectory in etc, like <prefix>/etc/broctl/node.cfg, etc.?
Two issues different issues here: one is what a particular
distribution/port-system/etc. wants, and the other is what we want
to be our default. For the latter, I'd be happy to change the
defaults if we find something more appropiate. For the former,
however, we can't make everybody happy at the same time and thus
should have a way to easily adapt when building packages/ports.
*It seems that when "make install" is called in broctl, the
broctl-config.sh script is not generated. Maybe "broctl install" just
needs to be run as part of the "make install" process?
Yeah, broctl-config.sh should be generated at "broctl install" time. So I think it makes sense for the packager to run that once in order to get a broctl-config.sh that they can include.
I think Jon's right. Without applying any configuration to broctl, it won't work anyway so the "install" command would need to be run after the user does some amount of configuration. What could be worthwhile is to give the user some warning when they go to start Bro if they
a. don't have the generated scripts (broctl-config.sh and the local-nets, etc).
or
b. have changes to their scripts in their site directory that haven't been installed yet.
a. don't have the generated scripts (broctl-config.sh and the local-nets, etc).
Yeah, that makes sense.
b. have changes to their scripts in their site directory that haven't been installed yet.
This likewise but it's quite hard to do for everything that could
potentially change (it's not only the scripts, but also broctl.cfg,
which in turn may set things differnetly so that now new pieces
somewhere else become relevant). I think we can skip this at least
for now.
Maybe for now we could do the minimal check for changes in the site directory or changes to the etc files and giving a warning? Even if that check isn't 100% complete, it will solve a lot of trouble for people.
We could file a ticket to remind ourselves to go back later and see if there are any other situations where we should warn. I just know that myself and the other guys at OSU have run into the "forgot to install" problem multiple times when updating scripts in the site directory.