[Intelmq-dev] Proposal - IntelMQ with Run Modes & Process Management

[Bernhard Reiter]

Hi,

Am Donnerstag 27 April 2017 14:16:33 schrieb Sascha Wilde:
> Even if systemd turns out to be a good choice, I'd vote against making
> it a hard dependency.  The reasons are very much the same Bernhard
> stated him self in an earlier post: it would make IntelMQ a Linux only
> product, which would be a shame given the overall open and portable
> design of it.

keeping it more portable only makes sense if there are people trying to run 
and helping to maintain intelmq on a non GNU/Linux platform. Otherwise it is 
just extra work and code that gets never executed. And it would be readded 
later again if a maintainer comes up.

Otherwise I'd like to see what systemd actually brings to the table. If it 
does add much, it may just be considered the less attractive solution and 
should not be used at all. (Except for starting the top-level intelmq-system, 
whatever it is.)

[..] 

> > Sooner or later I guess intelmq will need this kind of "flow control" to
> > be able to fulfill its promise of providing a fast and fully automatable
> > system. So it may become interesting to you at certat as well. :)

> currently the problems we are observing 
> are quite fundamental and don't need overly clever solutions.  I'd like
> to point to the proposal Bernard Herzog made in issue 709 last year:
> https://github.com/certtools/intelmq/issues/709
> it outlines a rather simple solution to much of the resource problems,
> and demonstrates how to build solutions that don't depend on an higher
> level service, with in depth knowledge of the bots interactions.

Thanks for reminding about Bernhard Herzog's proposal.
This again shows me that we need an overview of the problems we want to solve,
before we can evaluate the different ways of solving them.

Regards,
Bernhard

-- 
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.cert.at/pipermail/intelmq-dev/attachments/20170428/32c679b6/attachment.sig>