Hi,
I just wanted to ask what you think about moving the 3rdparty stuff under src (which at
the moment only contains sqlite) into a separate git submodule?
That way we keep the 3rdparty sources and their change history out of Bro history. SQLite
alone already has more than 140k lines - and I kind of suspect that we might other 3rdparty
sources in the future.
The disadvantage of this approach is, that the bro git repository does no longer contain
all source-files necessary to compile bro. On the other hand - stuff like cmake already is
in submodules - so even though the bro git contains all source files at the moment, you
still cannot compile it without checking out the submodules.
Bernhard
Bernhard Amann created BIT-1048:
-----------------------------------
Summary: merge topic/bernhard/topk
Key: BIT-1048
URL: https://bro-tracker.atlassian.net/browse/BIT-1048
Project: Bro Issue Tracker
Issue Type: Improvement
Components: Bro
Affects Versions: 2.2
Reporter: Bernhard Amann
merge topic/bernhard/topk. The branch should work and is integrated with sumstats. There is a small upcoming interface change - however this will just add new functionality and just change the bifs. For users of sumstats, the integration should not change at all, for others it might take minimal changes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://bro-tracker.atlassian.net/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[ https://bro-tracker.atlassian.net/browse/BIT-1048?page=com.atlassian.jira.p… ]
Bernhard Amann updated BIT-1048:
--------------------------------
Status: Merge Request (was: Open)
> merge topic/bernhard/topk
> -------------------------
>
> Key: BIT-1048
> URL: https://bro-tracker.atlassian.net/browse/BIT-1048
> Project: Bro Issue Tracker
> Issue Type: Improvement
> Components: Bro
> Affects Versions: 2.2
> Reporter: Bernhard Amann
> Labels: sumstats, topk
>
> merge topic/bernhard/topk. The branch should work and is integrated with sumstats. There is a small upcoming interface change - however this will just add new functionality and just change the bifs. For users of sumstats, the integration should not change at all, for others it might take minimal changes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://bro-tracker.atlassian.net/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[ https://bro-tracker.atlassian.net/browse/BIT-1047?page=com.atlassian.jira.p… ]
Bernhard Amann commented on BIT-1047:
-------------------------------------
I always liked the FreeBSD approach to config-files, where they show you a diff between your version and the current version, if you did change the config file.
But that is interactive and probably too much work to be worth it.
> Delete old scripts before installing new ones
> ---------------------------------------------
>
> Key: BIT-1047
> URL: https://bro-tracker.atlassian.net/browse/BIT-1047
> Project: Bro Issue Tracker
> Issue Type: Improvement
> Components: Bro
> Reporter: Robin Sommer
> Fix For: 2.2
>
>
> People keep having problems when they install a new Bro version
> over the installation of an old one because scripts that have disappeared in the new version will keep sticking around from the previous installation.
> We should simply remove the old scripts/base and scripts/policy before installing anything new. People aren't supposed to edit in there so that should be safe.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://bro-tracker.atlassian.net/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[ https://bro-tracker.atlassian.net/browse/BIT-1047?page=com.atlassian.jira.p… ]
Robin Sommer commented on BIT-1047:
-----------------------------------
Agreed, but I don't really see how we could do that for, say,
local.bro or broctl.cfg where we want to give users templates to work
from. Ideas?
> Delete old scripts before installing new ones
> ---------------------------------------------
>
> Key: BIT-1047
> URL: https://bro-tracker.atlassian.net/browse/BIT-1047
> Project: Bro Issue Tracker
> Issue Type: Improvement
> Components: Bro
> Reporter: Robin Sommer
> Fix For: 2.2
>
>
> People keep having problems when they install a new Bro version
> over the installation of an old one because scripts that have disappeared in the new version will keep sticking around from the previous installation.
> We should simply remove the old scripts/base and scripts/policy before installing anything new. People aren't supposed to edit in there so that should be safe.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://bro-tracker.atlassian.net/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[ https://bro-tracker.atlassian.net/browse/BIT-1047?page=com.atlassian.jira.p… ]
Jon Siwek commented on BIT-1047:
--------------------------------
Yeah, I'm not too nervous about deleting previously installed scripts (ones that aren't intended to be user-modified), but I'm thinking that doesn't entirely solve things for the user -- they'll probably still get an error, it's just this time it's something like "in local.bro: can't load X: no such file" which will be more obvious than whatever it was before, but they'll still have to know that means to edit their local.bro to fix the problem.
So I've not got an argument against cleaning up stale scripts, just saying this is a more general thing that can happen with config files that users edit while meanwhile the upstream version of it changes. More clearly indicating such situations at `make install` might help. I'd prefer if everything were designed so configuration/customization weren't done at all by editing installed files in place, rather through additional files that may be created at predetermined locations (but which may override default settings in one of the installed config files).
> Delete old scripts before installing new ones
> ---------------------------------------------
>
> Key: BIT-1047
> URL: https://bro-tracker.atlassian.net/browse/BIT-1047
> Project: Bro Issue Tracker
> Issue Type: Improvement
> Components: Bro
> Reporter: Robin Sommer
> Fix For: 2.2
>
>
> People keep having problems when they install a new Bro version
> over the installation of an old one because scripts that have disappeared in the new version will keep sticking around from the previous installation.
> We should simply remove the old scripts/base and scripts/policy before installing anything new. People aren't supposed to edit in there so that should be safe.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://bro-tracker.atlassian.net/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[ https://bro-tracker.atlassian.net/browse/BIT-1010?page=com.atlassian.jira.p… ]
Robin Sommer commented on BIT-1010:
-----------------------------------
Right that's why I was wondering if {{env:VAR1=1}} would work: i.e., the key would be {{env:VAR1}} hoping the parsers splits simply at the {{=}} and accepts the colon as part of the key.
But not worth discussing further, please file a merge request once ready.
> BroControl plugin for adding environment variables
> --------------------------------------------------
>
> Key: BIT-1010
> URL: https://bro-tracker.atlassian.net/browse/BIT-1010
> Project: Bro Issue Tracker
> Issue Type: Task
> Components: BroControl
> Affects Versions: git/master
> Reporter: Seth Hall
> Assignee: Daniel Thayer
> Fix For: 2.2
>
> Attachments: env_vars.py
>
>
> We should have the ability to add environment variables to Bro at start up time. The option should be available globally in broctl.cfg and per-node in node.cfg. The environments variables should be applied to the process with priority based on how specific the variable is applied (per-node variables defined after global variables so that the per-node variable is used).
> As a name suggestion for the configuration option: env_vars (same name in node.cfg and broctl.cfg).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://bro-tracker.atlassian.net/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[ https://bro-tracker.atlassian.net/browse/BIT-1047?page=com.atlassian.jira.p… ]
Robin Sommer commented on BIT-1047:
-----------------------------------
While I'd answer "yes" to that question, I think it's a different
case: people are supposed to edit these config files and we aren't
touching them (including local.bro). The scripts are different: it's
all "ours" and edits aren't considered safe and hence, I claim, we can
just as well delete them. That argument does extend to some other
stuff as well though, like the new magic database.
> Delete old scripts before installing new ones
> ---------------------------------------------
>
> Key: BIT-1047
> URL: https://bro-tracker.atlassian.net/browse/BIT-1047
> Project: Bro Issue Tracker
> Issue Type: Improvement
> Components: Bro
> Reporter: Robin Sommer
> Fix For: 2.2
>
>
> People keep having problems when they install a new Bro version
> over the installation of an old one because scripts that have disappeared in the new version will keep sticking around from the previous installation.
> We should simply remove the old scripts/base and scripts/policy before installing anything new. People aren't supposed to edit in there so that should be safe.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://bro-tracker.atlassian.net/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Open Fastpath Commits
======================
Commit Component Author Date Summary
----------- ----------- -------------- ---------- ------------------------------------------------------------
edb04e6 [1] bro Bernhard Amann 2013-07-30 fix segfault that could be caused by merging an empty bloom-
[1] edb04e6 https://github.com/bro/bro/commit/edb04e6d8bfe68dddf6968ec37cf39ea3a47feab
[ https://bro-tracker.atlassian.net/browse/BIT-1010?page=com.atlassian.jira.p… ]
Daniel Thayer commented on BIT-1010:
------------------------------------
We are using Python's ConfigParser to read the node.cfg file. It doesn't support the notion
of having multiple instances of a key in the same section (it ignores duplicates). However,
I've just made a change (in branch topic/dnthayer/ticket1010) to make env_vars
stored as a dictionary internally and I've added more error-checking of the user-supplied
list of environment variables, so that should help improve the situation.
Regarding the Myricom plugin, I didn't use "+=" because that would override the user's
values from node.cfg. Instead, I put the plugin's environment variables
at the beginning of the list (so that the user's values can override the
plugin's values). However, env_vars has now been re-implemented as a dictionary,
so hopefully the code is easier to read.
> BroControl plugin for adding environment variables
> --------------------------------------------------
>
> Key: BIT-1010
> URL: https://bro-tracker.atlassian.net/browse/BIT-1010
> Project: Bro Issue Tracker
> Issue Type: Task
> Components: BroControl
> Affects Versions: git/master
> Reporter: Seth Hall
> Assignee: Daniel Thayer
> Fix For: 2.2
>
> Attachments: env_vars.py
>
>
> We should have the ability to add environment variables to Bro at start up time. The option should be available globally in broctl.cfg and per-node in node.cfg. The environments variables should be applied to the process with priority based on how specific the variable is applied (per-node variables defined after global variables so that the per-node variable is used).
> As a name suggestion for the configuration option: env_vars (same name in node.cfg and broctl.cfg).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://bro-tracker.atlassian.net/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira