672
Comment:
|
5360
spam
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
= DaemonAdmin/MySQL = | Because we wanted to have version 5 of MySQL running on our stable server, we used the [[http://dotdeb.org]] package. For this reason there should be mirrors from dotdeb.org listed in the file ''/etc/apt/sources.list'' on deleuze. |
Line 3: | Line 3: |
Because we wanted to have version 5 of MySQL running on our stable server, we used the [http://dotdeb.org] package. For this reason there should be mirrors from dotdeb.org listed in the file ''/etc/apt/sources.list'' on deleuze. == Configuration details == |
= Configuration details = |
Line 9: | Line 7: |
== Progress == | = Progress = |
Line 13: | Line 11: |
== Testing == | = To Do = The new dbtool implemented as part of DomTool can now be used to create MySQL users and databases and the associated AFS directories. We still need to figure out how to allow users to drop tables from their databases without letting them drop the databases themselves. Since users retain permissions on a database even after it's dropped, the user could drop his database and recreate it on the partition where /var/lib/mysql lives, instead of in AFS. We also need to work out exactly what hostname mask to use in creating users and granting them privileges. ''' Bugzilla says this isn't an issue anymore. dbtool runs mysql-fixperms now right? Or must a user tell dbtool to do this? -- RyanMikulovsky ''' '''No, dbtool doesn't run mysql-fixperms. We would never have created that script if it were possible to set up a database ahead of time so that these problems wouldn't apply to it. mysql-fixperms needs to do things to particular tables, and dbtool isn't run on table creation. --AdamChlipala''' = Steps to perform = == Logical steps == 1. Create user's database volume in AFS, if one isn't there already 1. Create directory structure with proper permission within the AFS volume (the sole existence of the directory is enough for MySQL to consider it a database, even if just an empty one). NOTE: If we stick to existing behavior on fyodor, requested database name should be prefixed with USERNAME_ . 1. Create a symbolic link in /var/lib/mysql/ that points to the database 1. Grant the user rights on the new DB And, in terms of command line, the steps are: == Initialize DB space for any DB == You need to perform this as any user who has AFS admin permissions: 1. $dir = /afs/hcoop.net/common/.databases/'''USERNAME''' '''If vos examine db.USER says there's no volume created:''' 1. vos create -server afs -partition a -name db.'''USERNAME''' -maxquota 5000 '''If db.USER volume is there, but $dir is not present (volume isn't mounted):''' 1. fs mkmount -dir /afs/hcoop.net/common/.databases/'''USERNAME''' -vol db.'''USERNAME''' -rw 1. vos release common.databases '''And this can be done always:''' 1. fs setacl -dir $dir -acl databases l 1. fs setacl -dir $dir -acl system:backup rl == Database creation routine when the db space has been initialized == You need to perform this as any user who has AFS admin permissions: 1. $dir = /afs/hcoop.net/common/databases/'''USERNAME'''/mysql 1. mkdir -p $dir 1. fs setacl -dir $dir -acl mysql lid 1. fs setacl -dir $dir -acl databases none # (keep out other databases, just in case) 1. fs setacl -dir $dir -acl system:backup rl # (should be inherited from parent dir) 1. sudo mkdir $dir/'''DBNAME''' || exit # (Must not exist) 1. sudo chown mysql:mysql $dir/'''DBNAME''' 1. sudo chmod 770 $dir/'''DBNAME''' # (Just for visual impression) 1. sudo ln -sf $dir/'''DBNAME''' /var/lib/mysql/'''DBNAME''' 1. fs setacl -dir $dir/'''DBNAME'''/ -acl mysql all Now, about users and granting permissions to the database, I would like to see users being able create new users and passwords and their privileges (to their databases) themselves. This would allow fine-grained tuning of what service uses which DB username/pw, and what access rights it has. Maybe a list of users/passwords, or an appropriate support ticket would be cool. So anyway, the procedure for creating a user and giving privileges, executed on behalf of the admin user (domtool2), which can be specified as '''sudo -H mysql -e "<COMMAND HERE>" mysql''': 1. CREATE USER ''''USERNAME''''@''''HOSTNAME'''' IDENTIFIED BY ''''PASSWORD''''; 1. GRANT SELECT,INSERT,UPDATE,DELETE,INDEX,ALTER,CREATE VIEW,SHOW VIEW,GRANT OPTION ON '''DBNAME.*''' TO '''USERNAME'''@'%.hcoop.net'; 1. FLUSH PRIVILEGES; (Thing to note here: Wildcard '%' can be used in hostname part, for things like '%.hcoop.net'.) There are two other things related to users, one is changing password and the other is deleting users. These simply map to mysql SET PASSWORD and DROP USER commands, if you go to implement them. And one last thing; mysql is listening both on localhost and network interfaces (deleuze external IP). Maybe we want to restrict it to run on just one of them. Or if not, if it will run on both, then the access rule ( USERNAME@'%.hcoop.net' ) has to be duplicated in a way (for USERNAME@localhost), OR the users will always have to specify mysql host "deleuze" instead of "localhost". Another solution to this is that we don't try to be clever at all, but simply let users make sure the hostname part in their support ticket will match the interface they'll be using to connect. |
Because we wanted to have version 5 of MySQL running on our stable server, we used the http://dotdeb.org package. For this reason there should be mirrors from dotdeb.org listed in the file /etc/apt/sources.list on deleuze.
1. Configuration details
my.cnf file modified to leave a port open over the network, default is local pipe only.
2. Progress
As of Sat Jan 6 12:29:23 EST 2007, the MySQL 5.0 daemon and client libraries have been installed on deleuze. I also installed the mysql-common and mysql-client 5.0 packages on mire which should will allow for users to connect back to the main DB server.
3. To Do
The new dbtool implemented as part of DomTool can now be used to create MySQL users and databases and the associated AFS directories. We still need to figure out how to allow users to drop tables from their databases without letting them drop the databases themselves. Since users retain permissions on a database even after it's dropped, the user could drop his database and recreate it on the partition where /var/lib/mysql lives, instead of in AFS.
We also need to work out exactly what hostname mask to use in creating users and granting them privileges.
Bugzilla says this isn't an issue anymore. dbtool runs mysql-fixperms now right? Or must a user tell dbtool to do this? -- RyanMikulovsky
No, dbtool doesn't run mysql-fixperms. We would never have created that script if it were possible to set up a database ahead of time so that these problems wouldn't apply to it. mysql-fixperms needs to do things to particular tables, and dbtool isn't run on table creation. --AdamChlipala
4. Steps to perform
4.1. Logical steps
- Create user's database volume in AFS, if one isn't there already
- Create directory structure with proper permission within the AFS volume (the sole existence of the directory is enough for MySQL to consider it a database, even if just an empty one). NOTE: If we stick to existing behavior on fyodor, requested database name should be prefixed with USERNAME_ .
- Create a symbolic link in /var/lib/mysql/ that points to the database
- Grant the user rights on the new DB
And, in terms of command line, the steps are:
4.2. Initialize DB space for any DB
You need to perform this as any user who has AFS admin permissions:
$dir = /afs/hcoop.net/common/.databases/USERNAME
If vos examine db.USER says there's no volume created:
vos create -server afs -partition a -name db.USERNAME -maxquota 5000
If db.USER volume is there, but $dir is not present (volume isn't mounted):
fs mkmount -dir /afs/hcoop.net/common/.databases/USERNAME -vol db.USERNAME -rw
- vos release common.databases
And this can be done always:
- fs setacl -dir $dir -acl databases l
- fs setacl -dir $dir -acl system:backup rl
4.3. Database creation routine when the db space has been initialized
You need to perform this as any user who has AFS admin permissions:
$dir = /afs/hcoop.net/common/databases/USERNAME/mysql
- mkdir -p $dir
- fs setacl -dir $dir -acl mysql lid
- fs setacl -dir $dir -acl databases none # (keep out other databases, just in case)
- fs setacl -dir $dir -acl system:backup rl # (should be inherited from parent dir)
sudo mkdir $dir/DBNAME || exit # (Must not exist)
sudo chown mysql:mysql $dir/DBNAME
sudo chmod 770 $dir/DBNAME # (Just for visual impression)
sudo ln -sf $dir/DBNAME /var/lib/mysql/DBNAME
fs setacl -dir $dir/DBNAME/ -acl mysql all
Now, about users and granting permissions to the database, I would like to see users being able create new users and passwords and their privileges (to their databases) themselves. This would allow fine-grained tuning of what service uses which DB username/pw, and what access rights it has. Maybe a list of users/passwords, or an appropriate support ticket would be cool.
So anyway, the procedure for creating a user and giving privileges, executed on behalf of the admin user (domtool2), which can be specified as sudo -H mysql -e "<COMMAND HERE>" mysql:
CREATE USER 'USERNAME'@'HOSTNAME' IDENTIFIED BY 'PASSWORD';
GRANT SELECT,INSERT,UPDATE,DELETE,INDEX,ALTER,CREATE VIEW,SHOW VIEW,GRANT OPTION ON DBNAME.* TO USERNAME@'%.hcoop.net';
- FLUSH PRIVILEGES;
(Thing to note here: Wildcard '%' can be used in hostname part, for things like '%.hcoop.net'.)
There are two other things related to users, one is changing password and the other is deleting users. These simply map to mysql SET PASSWORD and DROP USER commands, if you go to implement them.
And one last thing; mysql is listening both on localhost and network interfaces (deleuze external IP). Maybe we want to restrict it to run on just one of them. Or if not, if it will run on both, then the access rule ( USERNAME@'%.hcoop.net' ) has to be duplicated in a way (for USERNAME@localhost), OR the users will always have to specify mysql host "deleuze" instead of "localhost". Another solution to this is that we don't try to be clever at all, but simply let users make sure the hostname part in their support ticket will match the interface they'll be using to connect.