comment administrer simplement plusieurs milliers de comptes & databases ?

:salut:

suite à mon post précédent, je voudrais avoir le point de vue du forum sur un quesiton relative à de l'administration "de masse" dirons-nous.

En temps normal, j'administre mon mysql à la ligne de commande ou phpmyadmin, et je gère l'administration des comptes mysql à la main, simplement.

mais qu'est-ce qui se passe si je dois avoir plusieurs milliers de comptes
qui accèdent chacun exclusivement à une database bien précise (et peuvent la détruire/recréer) ?

j'aimerais bien faire ca avec ldap, mais malheureusement ce que j'ai vu là : http://lists.mysql.com/internals/35669

mais laisse supposer que je peux oublier cette idée..

je me trompe ?

comment vs faites pour gérer ce genre de cas simplement ?

MySQL ignore les notions de groupe et de rôle, donc c'est monstrueusement chiant. Une solution simple serait de ne créer que deux utilisateurs, par ex. groupe1@'%' et groupe2@'%'. Tu communiques à tes utilisateurs le mot de passe de leur groupe... ce n'est évidemment pas top en terme de traçabilité...

Une deuxième solution consiste à assortir ceci d'une table de mapping du genre map_comptes(userPHP, pwPHP, userMySQL). Autrement dit, l'utilisateur s'authentifie auprès de l'appli PHP avec un compte perso, et selon ce compte perso, l'appli PHP utilisera l'un ou l'autre des deux comptes MySQL.

Troisième solution, bien connaître la base système mysql, et créer des procs stock qui attribuent des assortiments de privilèges... un exemple se trouve dans l'atelier du chapitre 13 de mon bouquin, si tu arrives à le trouver (en bibliothèque par exemple).

oublions les 2 premiers options qui si elles apportent un petit qqch ne me conviennent pas.

qt à la 3eme, je ne me suis pas bcp plongé dans les tables systemes de mysql, mais fondamentalement ...
si je ne me trompe pas, il y a classiquement 2 sujets

1. l'authentification (vérifier qu'une paire de login/pass est correct)
2. l'authorization (vérifier que le login ok de l'étape 1 a bien accès aux données demandées)

indépendamment de la plateforme, à la console, si je ne m'abuse, lorsqu'on fait un

> mysql -u raoul --password="secret" databasename

c'est mysql en interne qui par la suite regarde dans sa table mysql.user
et à l'instinct je dirais qu'il fait une sorte de
select * from user where user='raoul' and password=hash_mon_password('secret') and host='...'

or précisément, tout ca je veux justement que ca ne soit pas géré vai des tables mysql mais que mysql cherche plutot à se binder sur LDAP à la place (ou alors passe par un PAM qui serait configuré pour utiliser ldap)

en gros que qqpart dans mysql.conf on lui dise qu'il faut utiliser un plugin externe pour la gestion de l'authentification et authorization.

=> or au vu de
1. http://forge.mysql.com/wiki/Pluggabl...icationSupport
2. http://lists.mysql.com/internals/35669

j'ai l'impression qu'il faut que j'oublie cette idée completement ca ne sera pas vraiment dispo en prod avant 2 ans en gros.

donc tout ce qui me vient à l'idée pour que ca ne devienne pas un cauchemar d'administrer chaque compte deux fois (mysql : grant bla bla on truc to user" + ldap : ldapadd -d "uid=user,ou=people,dc=exemple,dc=fr" ....)

1. oublier ldap, ou alors m'en servir de "facade" alors que les comptes et pass seraient stockés dans mysql only => en gros perdre l'interet principal de ldap pour moi

2. me coder un wrapper en perl ou php pour le CRUD des comptes utilsateurs. wrapper qui fait les operation à la fois dans mysql et dans openldap => donc encore du code critique à créer, debugger et maintenir... :(

bref, rien ne me satisfait vraiment.

j'ai raté un truc gros ou quoi ?
je sais pas... à la base j'avais pas l'impression de demander un truc compliqué :aie:

ps: il a l'air effectivement pas facile à se procurer ton buoqun antoun, épuise sur amazon en tt cas.

Oui, tu as raison, il y a deux problèmes et je n'ai parlé que du second (l'autorisation). Pour ce qui est de l'utilisation du LDAP, à ma connaissance ce n'est pas possible, à part effectivement tout encapsuler dans des procs externes...

pour l'instant je préfère oublier cette histoire de
1 compte utilisateur = 1 compte mysql

j'ai la flemme de coder le wrapper qui change les passwords des deux cotés. Au pire on verra plus tard.

finalement à bien y regarder, on se rend compte que le point sensible est l'envoi de backup de base. en effet c'est un mysqldump. Cad que finalement on peut envoyer n'importe quel sql au lieu du dump...

Donc ce que j'ai choisi pour l'instant est d'encrypter ces mysqldump avec une clé symétrique stockée coté server. Comme ca, je suis sur qu'un backup à restaurer n'a pas été modifié par un user.