[BlueOnyx:00214] Re: Third party software

[Michael Stauber]

Hi Stephanie,

> But the answer is soooo simple! Change the protection on the directory
> holding the mySQL files within the site root to be 700 with the group s bit
> still set. With the ownership as mysql.sitexxx the site admin will not be
> able to change the contents of the directory, the files created will count
> toward the site quota, and with the group 's' bit set the group ownership
> of files created within the directory will be sitexxx as well.

Correct, but then we would still have the MySQL database files somewhere under 
the site root (or in a subdirectory there). Which means we need symbolic 
links in the real MySQL database directory to point to where the databases 
then really are. If possible I'd like to avoid that. But then we're back in 
the same boat that a siteAdmin can delete the database files. Catch-22. 

> Does it matter that the files are within the site root if CMU export knows
> how to do a mysqldump?

CMU doesn't know how to do a MySQL-dump. Yet. However, now that we have the 
MySQL "root" access details stored in CODB (and also the info which sites 
have which MySQL databases) we can "teach" CMU to also do MySQL-dumps. Should 
be fairly simple.

> Options for mysqldump can eliminate the drop 
> database/tables from the backup. Using the gui based functions to create
> the databases on import, then executing the output from the mysqldump, the
> database should be back and setup as one might expect with a CMU import.
> Does this sound reasonable, logically separating the database creation from
> the data/table restore?

Yeah, sounds good. Let me roll those thoughts in my head for a few days for 
refinement and I'll see to it that it's put into code.

-- 
With best regards

Michael Stauber