[Intelmq-dev] Packaging Strategy for Bots with dependencies

j.onderka at nbu.cz j.onderka at nbu.cz
Fri Jul 1 11:57:42 CEST 2016


Hello,

for adding own bots to IntelMQ, I am using b) type of solution. Every 
BOT class contains Meta class, which include BOT type, name, 
description, default parameters and new harmonization fields. Then BOT 
is registered by setuptools entry_points functionality, so IntelMQ can 
generate the list of all BOTS.

You can find the example of implementation in 
https://gist.github.com/ondj/93d7d0e12fa07fe8205b24d76f258d46

Thet disadvantage of this solution is that for example default 
`collector_http` BOT has in current BOTS file multiple definitions for 
different services.

I am glad if you find an inspiration in my solution.

Best,
Jakub

Dne 2016-06-30 17:55, Bernhard Reiter napsal:
> Am Mittwoch, 20. April 2016 11:55:59 schrieb L. Aaron Kaplan:
>> > Aren't we running into the same issue as with the BOTS file? If
>> 
>> The BOTS file is simply a template of which bots exist in general.
>> It is mainly used for the intelmq-manager to display which ones could 
>> get
>> selected. And which parameters they have.
> 
> In order to get this moving, I propose to tackle it in small steps.
> 
> What about implementing a solution for the contents of BOTS first?
> We keep the logic of etc/defaults.conf and etc/runtime.conf for this 
> step.
> So no hiearchical configuration (for now) and then we take it from 
> there.
> 
> Thinking about how to solve the BOTS file first:
> a) (proposed by Dusting)  bots.d/ directory solution,
>     means adding and removing filenames.
> b) adding an initialisation function to each module which
>     returns the necessary information
> c) write a small packaging helper that adds/removes sections
>     from BOTS
> 
> Some thoughts (being still new to the code base):
> b) seems attractive to me, because it keeps information
>     close to where it is maintainted. Its main drawback probably is
>     that is the largest change. Are there other drawbacks?
> c) has the drawback of requiring running code during (de)installation.
>    And it does not add much over a).
> 
> Best,
> Bernhard
> _______________________________________________
> Intelmq-dev mailing list
> Intelmq-dev at lists.cert.at
> http://lists.cert.at/cgi-bin/mailman/listinfo/intelmq-dev


More information about the Intelmq-dev mailing list