Re: [DISCUSS] Donating easy-cass-stress to the project

[Bernardo Botella]

Just found out about this thread.

I do agree, after seeing Jon and Jordan’s talk on this tool, it would be great 
to have it under the project umbrella. Like Alexander, I have also some ideas 
on workflows to contribute, and would love to help maintain it.

Bernardo

> On Oct 8, 2024, at 1:51 PM, Doug Rohrer  wrote:
> 
> Hey folks,
> 
> I just wanted to resurface this conversation, especially after Jon and 
> Jordon’s talk at Community over Code this week. I think there would be some 
> real value in getting easy-cass-lab donated and part of the ecosystem.
> 
> To try to summarize:
> 
> - Jon would like to donate if his active development of the project isn’t 
> negatively affected.
> 
> - It seems a separate repo/subproject is the right way to go rather than 
> bringing it in-tree
> 
> - Several other folks have stepped up to be co-maintainers (thanks!)
> 
> - Some form of IP clearance would need to be done if this were to move 
> forward.
> 
> It seems the major concerns other than IP clearance were taken care of in the 
> thread. Is there an appetite to bring easy-case-stress into the Apache 
> umbrella and, if so, how would we move forward from here?
> 
> Doug Rohrer
> 
>> On May 3, 2024, at 1:16 PM, Alexander DEJANOVSKI  
>> wrote:
>> 
>> 
>> Hi folks,
>> 
>> I'm familiar with the codebase and can help with the maintenance and 
>> evolution.
>> I already have some additional profiles that I can push there which were 
>> never merged in the main branch of tlp-cluster.
>> 
>> I love this tool (I know I'm biased) and hope it gets the attention it 
>> deserves.
>> 
>> Le mar. 30 avr. 2024, 23:17, Jordan West > > a écrit :
>>> I would likely commit to it as well
>>> 
>>> Jordan 
>>> 
>>> On Mon, Apr 29, 2024 at 10:55 David Capwell >> > wrote:
> So: besides Jon, who in the community expects/desires to maintain this 
> going forward? 
 
 I have been maintaining a fork for years, so don’t mind helping maintain 
 this project.
 
> On Apr 28, 2024, at 4:08 AM, Mick Semb Wever  > wrote:
> 
>> A separate subproject like dtest and the Java driver would maybe help 
>> address concerns with introducing a gradle build system and Kotlin.
> 
> 
> 
> Nit, dtest is a separate repository, not a subproject.  The Java driver 
> is one repository to be in the Drivers subproject.  Esoteric maybe, but 
> ASF terminology we need to get right :-) 
> 
> To your actual point (IIUC), it can be a separate repository and not a 
> separate subproject.  This permits it to be kotlin+gradle, while not 
> having the formal subproject procedures.  It still needs 3 responsible 
> committers from the get-go to show sustainability.  Would 
> easy-cass-stress have releases, or always be a codebase users work 
> directly with ?
> 
> Can/Should we first demote cassandra-stress by moving it out to a 
> separate repo ? 
>  ( Can its imports work off non-snapshot dependencies ? )
> It might feel like an extra prerequisite step to introduce, but maybe it 
> helps move the needle forward and make this conversation a bit 
> easier/obvious.
> 
 

Re: [DISCUSS] Donating easy-cass-stress to the project

[Doug Rohrer]

Clarification - there would be some real value in donating easy-cass-stress (as 
the subject says), not lab… The demo was about easy-cass-lab, which uses 
easy-cass-stress.

Thanks,

Doug

> On Oct 8, 2024, at 1:51 PM, Doug Rohrer  wrote:
> 
> Hey folks,
> 
> I just wanted to resurface this conversation, especially after Jon and 
> Jordon’s talk at Community over Code this week. I think there would be some 
> real value in getting easy-cass-lab donated and part of the ecosystem.
> 
> To try to summarize:
> 
> - Jon would like to donate if his active development of the project isn’t 
> negatively affected.
> 
> - It seems a separate repo/subproject is the right way to go rather than 
> bringing it in-tree
> 
> - Several other folks have stepped up to be co-maintainers (thanks!)
> 
> - Some form of IP clearance would need to be done if this were to move 
> forward.
> 
> It seems the major concerns other than IP clearance were taken care of in the 
> thread. Is there an appetite to bring easy-case-stress into the Apache 
> umbrella and, if so, how would we move forward from here?
> 
> Doug Rohrer
> 
>> On May 3, 2024, at 1:16 PM, Alexander DEJANOVSKI  
>> wrote:
>> 
>> 
>> Hi folks,
>> 
>> I'm familiar with the codebase and can help with the maintenance and 
>> evolution.
>> I already have some additional profiles that I can push there which were 
>> never merged in the main branch of tlp-cluster.
>> 
>> I love this tool (I know I'm biased) and hope it gets the attention it 
>> deserves.
>> 
>> Le mar. 30 avr. 2024, 23:17, Jordan West > > a écrit :
>>> I would likely commit to it as well
>>> 
>>> Jordan 
>>> 
>>> On Mon, Apr 29, 2024 at 10:55 David Capwell >> > wrote:
> So: besides Jon, who in the community expects/desires to maintain this 
> going forward? 
 
 I have been maintaining a fork for years, so don’t mind helping maintain 
 this project.
 
> On Apr 28, 2024, at 4:08 AM, Mick Semb Wever  > wrote:
> 
>> A separate subproject like dtest and the Java driver would maybe help 
>> address concerns with introducing a gradle build system and Kotlin.
> 
> 
> 
> Nit, dtest is a separate repository, not a subproject.  The Java driver 
> is one repository to be in the Drivers subproject.  Esoteric maybe, but 
> ASF terminology we need to get right :-) 
> 
> To your actual point (IIUC), it can be a separate repository and not a 
> separate subproject.  This permits it to be kotlin+gradle, while not 
> having the formal subproject procedures.  It still needs 3 responsible 
> committers from the get-go to show sustainability.  Would 
> easy-cass-stress have releases, or always be a codebase users work 
> directly with ?
> 
> Can/Should we first demote cassandra-stress by moving it out to a 
> separate repo ? 
>  ( Can its imports work off non-snapshot dependencies ? )
> It might feel like an extra prerequisite step to introduce, but maybe it 
> helps move the needle forward and make this conversation a bit 
> easier/obvious.
> 
 

Re: 【DISCUSS】The configuration of Commitlog archiving

[guo Maxwell]

Thanks Jon

But should we at least add the ability of dynamic closing to the archive
that Stefan mentioned before ?

Jon Haddad  于2024年9月25日周三 01:16写道：

> I categorize this as Not a Problem.
>
> So far the two main justifications have been operator error and a fairly
> convoluted series of steps to an already compromised database.  I don't
> view either of them as a reason to inconvenience users.
>
> If someone wants to avoid the shell command, what's wrong with CDC?
>
> Jon
>
>
>
>
> On Tue, Sep 24, 2024 at 9:21 AM guo Maxwell  wrote:
>
>> Hello，are there any new updates？🤔
>>
>> guo Maxwell 于2024年9月18日 周三下午4:06写道：
>>
>>> Do you have any new updates  on this DISCUSS ?
>>>
>>> - The reason this pattern is popular is it allows extension of
>>> functionality ahead of the database. Some people copy to a NAS/SAN. Some
>>> people copy to S3. Some people copy to their own object storage that isn’t
>>> s3 compatible. “Compress and move” is super limiting, because “move” varies
>>> remarkably between environments.
>>>
>>> Yes, it is indeed very flexible to use this way, but would it be more
>>> appropriate to decouple the file archiving to heterogeneous storage and
>>> leave it to other systems to handle it specifically? And we only do
>>> compression and copying (file linking like sstable incremental backup)?
>>>
>>>
>>> Štefan Miklošovič  于2024年9月5日周四 04:18写道：
>>>

 On Wed, Sep 4, 2024 at 8:34 PM Jon Haddad  wrote:

> I thought about this a bit over the last few days, and there's
> actually quite a few problems present that would need to be addressed.
>
> *Insecure JMX*
>
> First off - if someone has access to JMX, the entire system is already
> compromised.  A bad actor can mess with the cluster topology, truncate
> tables, and do a ton of other disruptive stuff.  But if we're going to go
> down this path I think we should apply your logic consistently to avoid
> creating a "solution" that has the same "problem" as we do now.  I use
> quotes because I'm not entirely convinced the root cause of the problem is
> enabling some shell access, but I'll entertain it for the sake of the
> discussion.
>
> *Dynamic Configuration and Shell Scripts*
>
> Let's pretend that somehow an open JMX isn't already a *massive*
> security flaw by itself.  Once an attacker has control of a system, the
> next phase of the attack relies on them dynamically changing the
> configuration to point to a different shell script, or to execute 
> arbitrary
> shell scripts.
>
 I agree with the general idea that we don't want this - so in my mind
> the necessary solution here is to disable the ability to change the commit
> log archiving behavior at runtime.
>
> The idea that commit log archiving (and many other config settings)
> would be dynamically configurable is a massive security flaw that should 
> be
> disallowed.  If you want to take this a step further and claim there's a
> flaw with shell scripts in general, I'll even entertain that for a minute,
> but we need to examine if the proposed solution of moving code to Java
> actually solves the problem.
>
> *Dynamic Configuration and Java Code*
>
> Let's say we've removed the ability to use shell scripts, and we've
> gotten people to rewrite their shell code with java code, but we've left
> the dynamic configuration in.  Going back to my original email, I 
> mentioned
> copying commit logs off the node and into an object store.  If someone is
> able to change the parameter dynamically at runtime, they could just as
> easily point to a public S3 bucket and commit logs would be archived there
> which is just as bad as the shell version.  So if we are to convert this
> functionality to Java, we should also be making best practice
> recommendations on what users should and should not do.
>

 I think what you meant here is that if we allowed people to provide a
 pluggable way how stuff is copied over and they would code it up, put that
 JAR on the class path, Cassandra (re)started etc, then someone might
 reconfigure this custom solution in runtime? Yeah, we do not want this. We
 can make it pluggable, but not reconfigurable. To have it pluggable and not
 reconfigurable, then to replace it with something else, an attacker would
 basically need to restart Cassandra with a rogue JAR on the class path. In
 order to do that, I think that at this point it would be beyond any
 salvation and the system is completely compromised anyway.


>
>
> *Apply All Operational Best Practices*
>
> There's been a variety of examples of how a user can further
> compromise a machine once they have JMX, working in tandem with shell
> scripts, but I hope at this point you can see that the issue is
> fundamentally more complex than simply dis

Re: [DISCUSS] Donating easy-cass-stress to the project

[Doug Rohrer]

Hey folks,

I just wanted to resurface this conversation, especially after Jon and Jordon’s 
awesome talk/“live demo" at Community over Code this week. I think there would 
be some real value in getting easy-cass-lab donated and part of the ecosystem.

To try to summarize (please correct me if I’m wrong on any point here):

- Jon would like to donate if his active development of the project isn’t 
negatively affected.

- It seems a separate repo/subproject is the right way to go rather than 
bringing it in-tree

- Several other folks have stepped up to be co-maintainers/committers (thanks!)

- Some form of IP clearance would need to be done if this were to move forward.

It seems the major concerns other than IP clearance were taken care of in the 
thread. Is there an appetite to bring easy-case-stress into the Apache umbrella 
and, if so, how would we move forward from here?

Doug Rohrer


> On May 3, 2024, at 1:14 PM, Alexander DEJANOVSKI  
> wrote:
> 
> Hi folks,
> 
> I'm familiar with the codebase and can help with the maintenance and 
> evolution.
> I already have some additional profiles that I can push there which were 
> never merged in the main branch of tlp-cluster.
> 
> I love this tool (I know I'm biased) and hope it gets the attention it 
> deserves.
> 
> Le mar. 30 avr. 2024, 23:17, Jordan West  > a écrit :
>> I would likely commit to it as well
>> 
>> Jordan 
>> 
>> On Mon, Apr 29, 2024 at 10:55 David Capwell > > wrote:
 So: besides Jon, who in the community expects/desires to maintain this 
 going forward? 
>>> 
>>> I have been maintaining a fork for years, so don’t mind helping maintain 
>>> this project.
>>> 
 On Apr 28, 2024, at 4:08 AM, Mick Semb Wever >>> > wrote:
 
> A separate subproject like dtest and the Java driver would maybe help 
> address concerns with introducing a gradle build system and Kotlin.
 
 
 
 Nit, dtest is a separate repository, not a subproject.  The Java driver is 
 one repository to be in the Drivers subproject.  Esoteric maybe, but ASF 
 terminology we need to get right :-) 
 
 To your actual point (IIUC), it can be a separate repository and not a 
 separate subproject.  This permits it to be kotlin+gradle, while not 
 having the formal subproject procedures.  It still needs 3 responsible 
 committers from the get-go to show sustainability.  Would easy-cass-stress 
 have releases, or always be a codebase users work directly with ?
 
 Can/Should we first demote cassandra-stress by moving it out to a separate 
 repo ? 
  ( Can its imports work off non-snapshot dependencies ? )
 It might feel like an extra prerequisite step to introduce, but maybe it 
 helps move the needle forward and make this conversation a bit 
 easier/obvious.
 
>>> 

Re: [DISCUSS] Donating easy-cass-stress to the project

[Doug Rohrer]

Hey folks,I just wanted to resurface this conversation, especially after Jon and Jordon’s talk at Community over Code this week. I think there would be some real value in getting easy-cass-lab donated and part of the ecosystem.To try to summarize:- Jon would like to donate if his active development of the project isn’t negatively affected.- It seems a separate repo/subproject is the right way to go rather than bringing it in-tree- Several other folks have stepped up to be co-maintainers (thanks!)- Some form of IP clearance would need to be done if this were to move forward.It seems the major concerns other than IP clearance were taken care of in the thread. Is there an appetite to bring easy-case-stress into the Apache umbrella and, if so, how would we move forward from here?Doug RohrerOn May 3, 2024, at 1:16 PM, Alexander DEJANOVSKI  wrote:Hi folks,I'm familiar with the codebase and can help with the maintenance and evolution.I already have some additional profiles that I can push there which were never merged in the main branch of tlp-cluster.I love this tool (I know I'm biased) and hope it gets the attention it deserves.Le mar. 30 avr. 2024, 23:17, Jordan West  a écrit :I would likely commit to it as wellJordan On Mon, Apr 29, 2024 at 10:55 David Capwell  wrote:So: besides Jon, who in the community expects/desires to maintain this going forward? I have been maintaining a fork for years, so don’t mind helping maintain this project.On Apr 28, 2024, at 4:08 AM, Mick Semb Wever  wrote:A separate subproject like dtest and the Java driver would maybe help address concerns with introducing a gradle build system and Kotlin.Nit, dtest is a separate repository, not a subproject.  The Java driver is one repository to be in the Drivers subproject.  Esoteric maybe, but ASF terminology we need to get right :-) To your actual point (IIUC), it can be a separate repository and not a separate subproject.  This permits it to be kotlin+gradle, while not having the formal subproject procedures.  It still needs 3 responsible committers from the get-go to show sustainability.  Would easy-cass-stress have releases, or always be a codebase users work directly with ?Can/Should we first demote cassandra-stress by moving it out to a separate repo ?  ( Can its imports work off non-snapshot dependencies ? )It might feel like an extra prerequisite step to introduce, but maybe it helps move the needle forward and make this conversation a bit easier/obvious.