While trying to debug an issue getting atrium profile to work I tried copying the install task command to prompt.

Running: php /var/aegir/drush/drush.php --root='/var/aegir/atrium-1-0-beta1' 'provision' 'install' 'deftzen.domain.com' --backend

When I run this from the server command prompt the databse that gets created has a much more user friendly name "deftzen" rather than the "site_##" one that gets created by the aegir frontend.

Any chance of changing this to be the default behavior

Comments

Anonymous’s picture

Anonymous (not verified) commented

Been reproducing this from the get-go :) Subscribing!

adrian’s picture

adrian commented
Status: Active » Closed (works as designed)

The issue is the limited amount of characters available for database and user names.

we use site_id to generate the db name where available to avoid possible naming clashes.

you can only have so many wwwmydomain databases before you start treading on other site's namespaces.

also keep in mind that the db name changes over the lifetime of the site.

ie: site_123 becomes site_123_0 after the first migration etc.

To be non destructive we need to do the site_id naming convention.

Anonymous’s picture

Anonymous (not verified) commented

I wouldn't have thought there'd ever be a case of two databases both wwwexamplecom, if the URL is the same, the Site form wouldn't have validated surely :) so I wonder if it'd ever clash?

Thanks for the info though, I didn't know a migration causes a 'revision' increment of the db name (or that a new database was even created). Good to know.

anarcat’s picture

anarcat commented

The issue here is that the database names need to be trimmed to (iirc) 16 characters. So while it is unlikely, it's possible to have a clash between two database names, let's say, drupal-4.7.test.site.example.com and drupal-4.7.test.site.example.org. Those would both resolve to something like drupal47testsitee as a database name.

Basically, this works well for small domain names that do not clash, but it's a recipe for disaster for large sites with lots of domains. Also, it can get very confusing if user A creates www.example.com.evil.com and then user B creates www.example.com. The first database name is going to be wwwexamplecomevi and the second one will be wwwexamplecom. It could be very easy for an operator to confuse the two, and that's an example where the domain name has less than 16 chars. If a domain name has exactly the same number of chars, that attack is even more effective.

So my vote goes to keeping the current scheme. It scales up to 2147483647 sites (or at least 2147483647 nodes on the frontend) which should be plenty for starters (famous last words).

I'm not sure the other naming convention would scale as well. Plus now we get a prefix that distinguishes aegir tables from other tables on a shared database server...

Anonymous’s picture

Anonymous (not verified) commented

Yep, I didn't take into consideration the 16 character limit, potential for clashes there absolutely. And the confusion layer too. No problems for this to stay per design, +1 vote for node-id db names definitely :)

eaton’s picture

eaton commented

Given that the database is only created once, would it be possible to do something as simple as check for $node->custom_db_name during the initial setup process, and use the nid-based system if none is set? Allow other Hostmaster/Aegir plugin modules to implement custom naming conventions?

I understand the need for nids as the default naming scheme, but there are quite a few situations where alternate approaches would cause no problems, and would give a big boost to usefulness for devs coming up to speed on how Aegir works. Thoughts? Objections? Torches and pitchforks?

adrian’s picture

adrian commented

You can pass --db_name to the script to specify the db name, so you can easily implement another naming convention.