Cela peut vous paraître curieux si vous êtes nouveau dans le domaine du NoSQL mais, dans ce secteur (et c’est une autre raison de faire pleurer les DBA du relationnel), la connexion par mot de passe et les limitations des accès vers les objets sont optionnelles. Ou payantes. Ou les deux.
Nous allons voir comment activer ces deux options (insérer ici des sanglots étouffés) et signaler quelques problèmes rencontrés, afin de vous éviter de perdre du temps.
Préparation
Bien Équipé, L’homme Pugnace Affronte La Situation (allégorie)
…car nous pensons qu’il vaut mieux éviter les ennuis que de savoir comment en sortir : si vous activez l’authentification, il faut que le facteur de réplication (RF) du keyspace « system » soit égal au nombre de nœuds dans chacun des datacenters existant. En effet, par défaut, celui-ci est égal à 1. Cela signifie qu’à chaque connexion, la requête de validation a une bonne chance d’être routée vers le seul nœud qui possède l’information. D’où perte de temps, dégradation des performances et risque de timeout.
Et vous pouvez oublier la résilience du service car si le nœud possédant l’information est arrêté, les connexions utilisateurs sont impossibles. C’est traître, d’autant que si votre cluster est de petite taille (exemple: 2 ou 3 membres), vous avez des chances pour que cela fonctionne 66% ou 33% du temps. Corollaire : à chaque modification définitive dans la topologie (ajout ou suppression), il faudra modifier ce facteur pour qu’il corresponde au nouveau nombre de nœuds.
Vous avez aussi la configuration des clients à prendre à compte. Vous pouvez préparer l’activation en mettant les logins/mot de passes dans les chaînes de connexion: ils seront ignorés tant que la configuration Cassandra n’aura pas été rechargée.
Passons maintenant à la configuration. Détendez-vous, c’est simple
Configuration
Les exemples sont données pour Cassandra v2.1. Nous n’avons pas suffisamment testé la v3 pour lister tous les changements. Nous vous ferons un article là-dessus plus tard car ils sont nombreux. Le seul élément que nous avons rencontré est que la commande « CREATE USER » est marquée comme étant bientôt obsolète (« deprecated »)… depuis la 2.2. Nous avons un poil de retard.
Dans cassandra.yaml, il n’y a que deux paramètres à changer :
authenticator: AllowAllAuthenticator authorizer: AllowAllAuthorizer
A remplacer par
authenticator: PasswordAuthenticator authorizer: CassandraAuthorizer
Pour info, un autre paramètre peut avoir son importance selon votre fonctionnement (par exemple: cluster hybride local/cloud, où se ré-identifier est coûteux) : « permissions_validity_in_ms ». Défaut: 2 secondes.
Préparer la configuration de chaque nœud. Lorsque c’est fait, redémarrez les nœuds en rolling restart (en français: « l’un après l’autre après l’autre… ». Ce n’est pas une coquille). Un shell distribué type dsh simplifie l’opération. Ou le script dbSQWare « sqwcas_RollingRestart.ksh », installé par son module Cassandra.
Si tout s’est correctement déroulé, vous devez voir dans le log ce message :
INFO [NonPeriodicTasks:1] 2017-02-23 14:16:31,491 PasswordAuthenticator.java:225 - PasswordAuthenticator created default user 'cassandra' INFO [NonPeriodicTasks:1] 2017-02-23 14:16:31,662 Auth.java:236 - Created default superuser 'cassandra'
Utilisation
Le compte administrateur par défaut est « cassandra », mot de passe « cassandra ».
Il est conseillé de le changer. Mieux: il est conseillé de créer un autre compte administrateur et de supprimer celui-ci.
Exemple :
CREATE USER IF NOT EXISTS mighty_root WITH PASSWORD 'mroot' superuser;
Exemple de connexion avec cqlsh:
cqlsh -u mighty_root -p mroot host_name host_port
Une fois que vous avez la certitude que tout fonctionne comme prévu, vous pouvez créer dans le $HOME du propriétaire de Cassandra un dossier caché « .cassandra » dans lequel vous stockerez un fichier de configuration personnel, « cqlshrc ». Ci-dessous, un exemple de ce fichier.
$ cat .cassandra/cqlshrc [authentication] username = nom_du_compte password = mot_de_passe [connection] hostname = host_name port = 9042 [ui] color = on completekey = tab
Un simple « cqlsh » doit fonctionner.
Dernière information : pour vérifier les utilisateurs créés, vous pouvez regarder dans la table system.users ou tout simplement demander en CQL « list users; ».
Si vous utilisez Datastax DevCenter pour vous connecter, il faut ajouter les informations dans les propriétés de la connexion : clic-droit sur son nom puis « propriétés », cliquer sur « basique » pour qu’apparaisse « avancée » et là vous pouvez entrer les informations.
Fier De Son Labeur, L’employé Reçoit Sa Récompense (archive, collection privée)
Vous voilà paré à faire face aux multiples ennuis qui ne manqueront pas de surgir.
Erreurs rencontrées
- Si vous rencontrez l’erreur:
Unauthorized: code=2100 message="You have to be logged in and not anonymous to perform this request"
C’est que l’authentification par mot de passe n’est pas active. Vérifiez votre configuration.
- Si vous rencontrez celle-ci:
</li> </ul> WARN NonPeriodicTasks:1 2017-02-23 14:13:48,782 PasswordAuthenticator.java:230 - PasswordAuthenticator skipped default user setup: some nodes were not ready
C’est que certains nœuds sont injoignables. Leur redémarrage n’est pas terminé ou bien une erreur les en empêche (une coquille dans la configuration, par exemple).
- Autre erreur, texte en français car reçu par le client:
"seul un superuser peut créer un superuser"
… alors même que vous êtes connecté en « cassandra ». Cela se produit lorsque l’authentification n’est pas configurée sur tous les nœuds.
Des problèmes ? des questions ? Exprimez-vous ! Les commentaires sont ouverts. Coquilles et fautes de grammaires sont notre lot quotidien : signalez-les nous à m.capello@dbsqware.com
Crédit photos: Wellcome images, CC BY 4.