nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Witt <joe.w...@gmail.com>
Subject Re: Having the ability to disable controlling mechanism for agents
Date Wed, 27 Sep 2017 01:10:06 GMT
I think it is worth making it configurable.  There may be cases where
they are so bandwidth constrained, for example, that they don't want
to spend any bits on sending back heartbeats. In the case heartbeats
are not sent back then we lose information about which commands have
been received.  Though through provenance or data tagging we could
still store flow version information as an in-band.  In general we
should ideally have multiple paths to acquire critical information.

On Tue, Sep 26, 2017 at 4:32 PM, Aldrin Piri <aldrinpiri@gmail.com> wrote:
> My feel is that there should be a way to enable/disable C2 as the user sees
> fit.
>
> There may be other implementations that take their own approach but I can
> see many users taking the one that is currently in the codebase as it may
> cover the majority of their needs.  I could imagine that some would be
> averse to having that functionality "always on" but would still appreciate
> the option of the capability when they wanted to dig in after the fact and
> are okay with a config change (and restart if needed).
>
> On Tue, Sep 26, 2017 at 9:28 AM, Marc <phrocker@apache.org> wrote:
>
>> Good Morning/Afternoon/Evening Everyone,
>>
>>    A pull request exists to introduce some very limited command and control
>> capabilities. In it one of the developers questioned why we were attempting
>> to send a heartbeat to a command and control server when it was not
>> configured. That's a very valid point.  By design we have a C2 agent that
>> uses a protocol to transmit/receive messages and/or commands. If the
>> protocol isn't configured we're effectively neutered, but we still have the
>> ability to have local control through scripts or executables, so I would
>> like to see C2 a permanent aspect of the MINIFi CPP agent that we have.
>>
>>    If protocol endpoints aren't configured as the reviewer noted we
>> shouldn't be attempting them, so that point is settled ( as in he is
>> correct ), but the penultimate question is whether or not we should allow
>> C2 to be disabled by design. Should this feature be pluggable to the agent?
>> My initial design was that it should not since allowing command and control
>> to be disabled appeared antithetical with its intent; however, I'd love to
>> hear other input as I may be entirely off base ( sometimes I'm not even on
>> the right ball field!).
>>
>>   Given the previous sentiment that a C2 agent could be controlled locally,
>> and the capabilities can be used for localized debug/control, should we
>> ever allow C2 to disabled from the default agent? I acknowledge that others
>> may build their own agents without command and control capabilities, so I
>> can only ask this question in regards to the agent that we are building and
>> including into the Apache MiNiFi CPP project.
>>
>>   TL;DR : Should we allow C2 capabilities to be disabled?
>>
>>
>>   Thank for your time and consideration,
>>   Marc
>>

Mime
View raw message