Definitely something to think about and work towards. One step at a time.
The CMU will eventually need to get reworked and the Postgres database will
need to start becoming more aware of the MySQL databases.
The biggest thing is when I get a customer who is used to Cpanel, they
complain a lot. Especially when it is a real Windows weenie and even more
when all they know is how to do graphics and know nothing about php or
Linux/Unix.
The idea about using the site name in the database name is what I am doing
right now so I support this. One thing though about using Underscores in
the name is that the display in phpMyAdmin handles it kind of funny.
-Regards,
Rashid
On 9/29/08 1:14 PM, "Michael Stauber" <bq (at mark) solarspeed.net> wrote:
> Hi Abdul-Rashid,
>
>> The webapp deal actually randomly generates a username/password and
>> database name. So it is hard to tell what is what.
>
> I'll "borrow" Chris's idea and merge it what I already have: When you create a
> site and/or enable MySQL for it, then it'll suggest a username and database
> name that are easy to match with the site in question.
>
> Example: Site is named www.company.com
>
> Suggested Username: www_company_com
> Suggested Database: www_company_com_db
>
> Before you hit "save" to commit those changes, you can then change it to
> something else if that's more desireable.
>
>> Also, an idea I had too is putting the actual MySQL database under the site
>> directory and drawing a symbolic link to it in the MySQL directory. This
>> way the disk space used will be part of the quota, a site migration would
>> catch the database as well, and it would also be easy to know what
>> databases belong to what sites.
>
> This idea sure has merrits and I see why that would be beneficial.
>
> However, things will then get really tricky if you do a CMU based migration.
> Because then all the symlinks from /var/lib/mysql/ get left behind, although
> the migration will back up and migrate the actual databases in the site
> directory. Likewise, if you do a MySQL restore from a MySQL-dump, the
> symlinks may get broken (not 100% sure about that, have to test it).
>
> Furthermore, as CMU doesn't lock the MySQL databases during a backup (because
> it never needed to do that before), one might end up with corrupted MySQL
> databases in his CMU based export.
>
> If all that can be settled, then yeah, this would be the way to go.