删除Cassandra用户后在OpsCenter中的操作指引及DSE集群登录故障处理

Let's walk through both your scenarios step by step—since removing a superuser (especially the default cassandra account) can break OpsCenter's connection to your cluster if you don't update the necessary configurations properly.

Scenario 1: What to do in OpsCenter after deleting a Cassandra superuser #

When you delete a superuser that OpsCenter was relying on for cluster access, you need to ensure OpsCenter has a valid, permissioned user to use instead. Here's the process:

• First, create a dedicated OpsCenter user in Cassandra/DSE (if you haven't already). This user needs enough permissions to let OpsCenter monitor and manage the cluster—at minimum, grant SELECT, DESCRIBE, ALTER permissions on keyspaces like system, system_schema, and the OpsCenter-specific opscenter keyspace. If you need full management capabilities, you can assign SUPERUSER (though least-privilege is better for security). Run these CQL commands to set it up:

  CREATE USER opscenter_monitor WITH PASSWORD 'your_secure_password' NOSUPERUSER;
  GRANT SELECT, DESCRIBE, ALTER ON KEYSPACE system TO opscenter_monitor;
  GRANT SELECT, DESCRIBE, ALTER ON KEYSPACE system_schema TO opscenter_monitor;
  GRANT ALL ON KEYSPACE opscenter TO opscenter_monitor;
  

• Update OpsCenter's cluster credentials:
  1. Log into your OpsCenter web console, navigate to the affected cluster, and go to the Cluster Settings page.
  2. Find the Credentials section, replace the old username with your new opscenter_monitor (or whatever you named it) and input the password. Save the changes.
  3. For older OpsCenter versions, you might need to edit the local config files directly:
     • Open /var/lib/opscenter/clusters/<your_cluster_name>/cluster.conf (or /etc/opscenter/clusters/<your_cluster_name>/cluster.conf depending on your setup)
     • Locate the [cassandra] section, update the username and password fields to match your new user, then save the file.
     • Restart the OpsCenter service to apply changes: sudo systemctl restart opscenterd (use sudo service opscenterd restart if you're on an older init system).
• Verify the connection: Check the cluster overview page in OpsCenter to confirm the connection status is green, and that monitoring metrics and management tools are working as expected.

Scenario 2: Fixing OpsCenter when it keeps trying to use the deleted cassandra user #

If you deleted the default cassandra user and OpsCenter is still attempting to use it to log into your DSE cluster, you need to wipe out all traces of the old credentials from OpsCenter's configs:

• First, ensure you have a working superuser in DSE/Cassandra: If you don't have another superuser already, create one immediately via CQL shell (you'll need this to make any necessary cluster changes):

  CREATE USER temp_super WITH PASSWORD 'temp_secure_pass' SUPERUSER;
  

• Update OpsCenter's cluster credentials (again):
  Go back to the Cluster Settings > Credentials page in OpsCenter, double-check that the username is set to your new valid user (not cassandra), save the config, and wait a minute for OpsCenter to reconnect.
• Clean up OpsCenter's local config files:
  If the web console change doesn't stick, manually check these files:
  1. The cluster-specific config: /var/lib/opscenter/clusters/<your_cluster_name>/cluster.conf—make sure the [cassandra] section's username and password aren't set to cassandra.
  2. The global OpsCenter config: /etc/opscenter/opscenterd.conf—look for any default username/password entries under [cassandra] and update them if present.
• Update OpsCenter Agent configs on all nodes:
  If your cluster uses Datastax Agents, they might also be using the old cassandra credentials. On each node:
  1. Open /var/lib/datastax-agent/conf/agent.conf
  2. Find the cassandra_username and cassandra_password lines, replace them with your new user's details.
  3. Restart the agent: sudo systemctl restart datastax-agent
• Check logs to confirm: Head to the Logs section in OpsCenter to verify that the "failed login with user cassandra" errors are gone, and that the cluster connection is stable.

内容的提问来源于stack exchange，提问作者ddd