New Release of ecAudit

[Per Otterström]

We are pleased to announce the release of ecAudit 2.1.0.

The ecAudit plug-in enhance Cassandra 3.x with audit logging functionality. In 
this release we've added support for a high-performance logging backend based 
on Chronicle as well as added new logging parameters and configuration options.

The full list of improvements are:

  *   Make wrapped authorizer backend configurable - #104
  *   Optionally skip values when logging prepared statements - #92
  *   Add support for client port in log messages - #90
  *   Add support for post-logging - #24
  *   Add support for host address in log message - #28
  *   Add support for Chronicle-Queue backend - #62
  *   Add metrics for filtering and logging - #72
  *   Add support for system timestamp in log message - #27
  *   Fix typo of java property for custom audit.yaml path - #59
  *   Build with Cassandra 3.11.4 (only flavor ecaudit_c3.11)
  *   Build with Cassandra 3.0.18 (only flavor ecaudit_c3.0)
  *   Introduce configurable log message format - #55
  *   Make the audit whitelist table a protected resource in Cassandra

This release comes in three flavors (same features, but for different Cassandra 
versions).

ecAudit for Cassandra 3.11.X:
Doc: https://github.com/Ericsson/ecaudit/tree/master
SW: 
https://search.maven.org/search?q=g:com.ericsson.bss.cassandra.ecaudit%20AND%20a:ecaudit_c3.11

ecAudit for Cassandra 3.0.X:
Doc: https://github.com/Ericsson/ecaudit/tree/release/c3.0
SW: 
https://search.maven.org/search?q=g:com.ericsson.bss.cassandra.ecaudit%20AND%20a:ecaudit_c3.0

ecAudit for Cassandra 3.0.11:
Doc: https://github.com/Ericsson/ecaudit/tree/release/c3.0.11
SW: 
https://search.maven.org/search?q=g:com.ericsson.bss.cassandra.ecaudit%20AND%20a:ecaudit_c3.0.11

Feel free to raise a ticket on GitHub if you have a feature request or want to 
contribute. Enjoy!

/The Ericsson team

RE: CassKop : a Cassandra operator for Kubernetes developped by Orange

[Per Otterström]

Thanks for open-sourcing your work! Looks very promising.

/pelle

From: sebastien.allam...@orange.com 
Sent: den 27 maj 2019 08:13
To: user@cassandra.apache.org; attila.wind@swf.technology
Subject: Re: CassKop : a Cassandra operator for Kubernetes developped by Orange

Hello Atilla,

The CassKop project was started a year ago internally at Orange with a small 
team. Discussing with the community we decided to move it to github with an 
open source Apache 2 licence.

The only commit on github don't relate the real project history.

We are really open to cooperate, our goal is to have the better solution for 
production uses.
Sébastien

Le 25 mai 2019 à 11:54, Attila Wind 
mailto:attilaw@swf.technology>> a écrit :

Maybe my understanding is wrong and I am not really a "deployment guru" but it 
looks like to me that

Orange (https://github.com/Orange-OpenSource/cassandra-k8s-operator, 1 
contributor and 1 commit for now on 2019-05-24)
and sky-uk/cassandra-operator (https://github.com/sky-uk/cassandra-operator , 
it's in alpha phase and not recommended in production, 3 contributors, 24 
commits btw 2019.03.25-2019.05.21, 32 Issues)
are developing something I could use in my OWN(!) Kubernetes based solution 
(even on premise if I want or whatever)
They are both open source. Right?

While
Datastax and Instaclustr are commercial players and offer the solution in a 
tightly-coupled way with Cloud only
(I just took a quick look on Instaclustr but could not even figure out pricing 
info for this service... probably I am lame... or not? :-))

So this looks to me a nice competition...
What do I miss?

ps.: maybe Orange and sky-uk/cassandra-operator guys should cooperate..?? 
Others are clearly building business around it

cheers
Attila Wind

http://www.linkedin.com/in/attilaw
Mobile: +36 31 7811355

On 2019. 05. 24. 20:36, John Sanda wrote:
There is also
https://github.com/sky-uk/cassandra-operator

On Fri, May 24, 2019 at 2:34 PM Rahul Singh 
mailto:rahul.xavier.si...@gmail.com>> wrote:
Fantastic! Now there are three teams making k8s operators for C*: Datastax, 
Instaclustr, and now Orange.

rahul.xavier.si...@gmail.com

http://cassandra.link

I'm speaking at #DataStaxAccelerate, the world's premiere #ApacheCassandra 
conference, and I want to see you there! Use my code Singh50 for 50% off your 
registration. www.datastax.com/accelerate


On Fri, May 24, 2019 at 9:07 AM Jean-Armel Luce 
mailto:jaluc...@gmail.com>> wrote:
Hi folks,

We are excited to announce that CassKop, a Cassandra operator for Kubernetes 
developped by Orange teams, is now ready for Beta testing.

CassKop works as a usual K8S controller (reconcile the real state with a 
desired state) and automates the Cassandra operations through JMX. All the 
operations are launched by calling standard K8S APIs (kubectl apply ...) or by 
using a K8S plugin (kubectl casskop ...).

CassKop is developed in GO, based on CoreOS operator-sdk framework.
Main features already available :
- deploying a rack aware cluster (or AZ aware cluster)
- scaling up & down (including cleanups)
- setting and modifying configuration parameters (C* and JVM parameters)
- adding / removing a datacenter in Cassandra (all datacenters must be in the 
same region)
- rebuilding nodes
- removing node or replacing node (in case of hardware failure)
- upgrading C* or Java versions (including upgradesstables)
- monitoring (using Prometheus/Grafana)
- ...

By using local and persistent volumes, it is possible to handle failures or 
stop/start nodes for maintenance operations with no transfer of data between 
nodes.
Moreover, we can deploy cassandra-reaper in K8S and use it for scheduling 
repair sessions.
For now, we can deploy a C* cluster only as a mono-region cluster. We will work 
during the next weeks to be able to deploy a C* cluster as a multi regions 
cluster.

Still in the roadmap :
- Network encryption
- Monitoring (exporting logs and metrics)
- backup & restore
- multi-regions support

We'd be interested to hear you try this and let us know what you think!

Please read the description and installation instructions on 
https://github.com/Orange-OpenSource/cassandra-k8s-operator.
For a quick start, you can also follow this step by step guide : 
https://orange-opensource.github.io/cassandra-k8s-operator/index.html?slides=Slides-CassKop-demo.md#1


The CassKop Team
--

- John

_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete alter

RE: Audit in C*

[Per Otterström]

With ecAudit you can get audit records for login attempts and queries on 
selected ks/tables. Currently there is no way to get audit records for rejected 
attempts/queries _only_, but that’s an interesting feature for future versions.

The plug-in is free to use under the Apache 2.0 license and comes pre-build for 
Cassandra 3.0.x and Cassandra 3.11.x.

/pelle

From: Bobbie Haynes 
Sent: den 13 mars 2019 20:21
To: user@cassandra.apache.org
Subject: Re: Audit in C*

Yes.we are using it and it is very helpful to u so far...!

On Wed, Mar 13, 2019 at 11:38 AM Rahul Singh 
mailto:rahul.xavier.si...@gmail.com>> wrote:
Which version are you referring to?

On Wed, Mar 13, 2019 at 10:28 AM Nitan Kainth 
mailto:nitankai...@gmail.com>> wrote:
Hi,

Anybody have used auditing to find out failed login attempts, or unauthorized 
access tries.

I found ecAudit by Ericsson, is it free to use? Has anybody tried it?

Ref: https://github.com/Ericsson/ecaudit

RE: Repair daily refreshed table

[Per Otterström]

Hi Maxim.

Assuming all your update operations are successful and that you only delete 
data by TTL in that table, then you shouldn’t have to do repairs on it.

You may also consider to lower the gc_grace_seconds value on that table, but 
you should be aware of how this impacts hints and logged batches: 
https://docs.datastax.com/en/cql/3.3/cql/cql_reference/cqlCreateTable.html#tabProp__cqlTableGc_grace_seconds

/pelle

From: Maxim Parkachov 
Sent: den 20 augusti 2018 08:29
To: user@cassandra.apache.org
Subject: Re: Repair daily refreshed table

Hi Raul,

I cannot afford delete and then load as this will create downtime for the 
record, that's why I'm upserting with TTL today()+7days as I mentioted in my 
original question. And at the moment I don't have an issue either with loading 
nor with access times. My question is should I repair such table or not and if 
yes before load or after (or it doesn't matter) ?

Thanks,
Maxim.

On Sun, Aug 19, 2018 at 8:52 AM Rahul Singh 
mailto:rahul.xavier.si...@gmail.com>> wrote:
If you wanted to be certain that all replicas were acknowledging receipt of the 
data, then you could use ALL or EACH_QUORUM ( if you have multiple DCs) but you 
must really want high consistency if you do that.

You should avoid consciously creating tombstones if possible — it ends up 
making reads slower because they need to be accounted for until they are 
compacted / garbage collected out.

Tombstones are created when data is either deleted, or nulled. When marking 
data with a TTL , the actual delete is not done until after the TTL has expired.

When you say you are overwriting, are you deleting and then loading? That’s the 
only way you should see tombstones — or maybe you are setting nulls?

Rahul
On Aug 18, 2018, 11:16 PM -0700, Maxim Parkachov 
mailto:lazy.gop...@gmail.com>>, wrote:
Hi Rahul,

I'm already using LOCAL_QUORUM in batch process and it runs every day. As far 
as I understand, because I'm overwriting whole table with new TTL, process 
creates tons of thumbstones and I'm more concerned with them.

Regards,
Maxim.
On Sun, Aug 19, 2018 at 3:02 AM Rahul Singh 
mailto:rahul.xavier.si...@gmail.com>> wrote:
Are you loading using a batch process? What’s the frequency of the data Ingest 
and does it have to very fast. If not too frequent and can be a little slower, 
you may consider a higher consistency to ensure data is on replicas.

Rahul
On Aug 18, 2018, 2:29 AM -0700, Maxim Parkachov 
mailto:lazy.gop...@gmail.com>>, wrote:
Hi community,

I'm currently puzzled with following challenge. I have a CF with 7 days TTL on 
all rows. Daily there is a process which loads actual data with +7 days TTL. 
Thus records which are not present in last 7 days of load expired. Amount of 
these expired records are very small < 1%. I have daily repair process, which 
take considerable amount of time and resources, and snapshot after that. 
Obviously I'm concerned only with the last loaded data. Basically, my question: 
should I run repair before load, after load or maybe I don't need to repair 
such table at all ?

Regards,
Maxim.