OpsCenter – Setting up Authentication with Roles and Users

DataStax OpsCenter is a handy tool. However, since it provides the user with a lot of operations that if done accidentally could be very destructive (i.e., truncate table), it is a very good idea that when you install OpCenter, you immediately do three things:

  • Enable Authentication
  • Change the admin password
  • Create user accounts with restricted permissions for different types of roles (i.e., developer, manager, etc.)

DataStax has very thorough documentation on how to enable authentication and setup rolls and users, however I just wanted to make a quick start guide that walks you through these three common steps.

Enable Authentication

To enable authentication you will need to edit the OpsCenter configuration file. Login to your OpsCenter server and edit the config file.

vi /etc/opscenter/opscenterd.conf

In the authentication section of the config file change the setting for “enabled = False” to True.

[athentication]
enabled = True

For the change to take effect you will need to restart the OpsCenter service.

systemctl restart opscenterd

Once the application is back up you will be able to login using the default credentials.

Change the Admin Password

When the application comes back up, you will be able to login using the default admin credentials.

  • Username – admin
  • Password – admin

Go to “admin Change Password“.

Now create a new password for the admin user.

Create a New Role and User

Since the “admin” user has unrestricted permissions, you probably don’t want everyone logging in to OpsCenter with that level of access.

In OpsCenter it has the concept of Roles and Users.

  • Role – Is a defined set of permissions
  • User – Is a login that is mapped to a Role

So for this example let’s create a new role and user account for a developer with a reduced set permissions.

Create Role

To add a new role go to “Settings → Users & Roles“.

Click on “Manage Roles”.

Click on “Add Role”.

Create the new role “Developer“.

Note: You will need to set permissions on a per cluster basis. So you will need to repeat the permissions selection for each cluster.

After saving your changes, you should see a new role called “Developer” on the “Manage Roles” page.

Create User

Now that we have created our new “Developer” role, let’s create a new user from the “Settings → User & Roles” page by clicking the “Add User” button.

Create a new user called “developer” and in the “Role” drop down list make sure to select the role “Developer“.

After clicking “Save” you should see your new “developer” user account.

You will now be able to login with your new “developer” user account.

I hope that helps!

References

Cassandra – Restoring Data from a Backup with OpsCenter

In the last few months we migrated all of our Cassandra clusters from open source Apache Cassandra to DataStax Enterprise Cassandra. As one of the perks of using the DataStax version we also get the Cassandra cluster management tool OpsCenter.

One of the advantages of moving to OpsCenter is we no longer have to use our own custom scripts for managing backups. As part of verifying our new backups we also wanted to run through some data recovery scenarios and make sure we understood how to use the new tools correctly. The following is a simple how to guide for a few common data recovery scenarios that I hope you find useful.

  • Restore Accidentally Deleted Rows While keeping Newly Added Rows
  • Restore Keyspace/Table While Keeping Newly Added Rows
  • Restore Keyspace/Table to a Backup (Dropping All Recent Changes)

Note: At the time of this post, we were using versions:

  • Cassandra DSE – 5.1.17
  • OpsCenter – 6.7.5

Step 1 – Select Backup

Select a Backup to Restore

Services -> Activity -> Restore Backup

Select a backup to restore and click “Next”:

Now it is on step 2 of the restore process where you need to be careful which options you select based on what you would like to do. The following are some common scenarios we tested.

Step 2 – Restore Backup (Scenarios)

Restore Accidentally Deleted Rows While keeping Newly Added Rows

When data is deleted using a DELETE statement in Cassandra, it does not remove the row from an existing SSTable, since they are immutable, instead it writes a Tombstone entry in a new SSTable which stays around for the amount of time defined on the table’s gc_grace_seconds setting. This Tombstone allows the delete to be propagated to all nodes where the row is replicated and also ensures that when an older SSTable storing the row that was deleted is compacted into a new SSTable, the row is removed.

So if you run a restore of a backup, you will notice that even though the deleted rows are in the backup you are restoring, they do not come back. The reason is because Cassandra has a Tombstone entry that is newer than the row being restored so it still knows to mark the row as deleted when it builds it’s index.

The solution is to temporarily set the tombstone grace period on the table to 0 seconds, so it will be ignored, for example:

alter table MY_KEYSPACE_HERE.MY_TABLE_NAME_HERE with gc_grace_seconds = 0;

Then restore the backup for the keyspace you want using the SSTableLoader option:

  • “Use sstableloader”

This will restore the deleted data from the backup into Cassandra without affecting rows added since the backup was taken:

Once the restore task has completed and you can confirm that the accidentally deleted data has been restored, alter the table to set the gc_grace_seconds back to what it was before, for example:

alter MY_KEYSPACE_HERE.MY_TABLE_NAME_HERE with gc_grace_seconds = 864000;

Restore Keyspace/Table While Keeping Newly Added Rows

To restore a backup of a keyspace or table while ensuring rows added since the backup was taken are not lost, you need to ensure you use the SSTableLoader option:

  • “Use sstableloader”

This option will import the data from the backup into the Cassandra cluster, so newly added data will not be affected. 

When running the restore, on the second screen select the “Use sstableloader” option:

Restore Keyspace/Table to a Backup (Dropping All Recent Changes)

If for some reason you need to restore a keyspace or table back to exactly what was in the backup, throwing away any newly added data, on the second screen select the option:

  • “Truncate/delete existing data before restore”.

This option will reset the selected table back to what it was when the backup was taken. This is the default option.

NOTE: Do not use this option unless you are absolutely sure you want to drop newly added data.

I hope you found this useful!

References