i ran drush provision install more than 30 times for one site, and started getting an error in the drush output:

String 'testaegirtwelv_32' is too long for user name (should be no longer than 16)

talked it over with mig5, and it is related to the default mysql limit of 16 chars for username. I think the automatic generation of username isn't accounting for having more than 1 digit (more than 9). I guess it would have to just remove more characters from the end of the name to make room for more digits. This seems like a rare bug, but it might effect people hosting many sites.

CommentFileSizeAuthor
#8 provision_improved_mysql_user_name_limit_handling.patch1.96 KBfrankcarey

Comments

anarcat’s picture

anarcat commented
Priority: Critical » Minor

i ran drush provision install more than 30 times for one site, and started getting an error in the drush output

First problem: why the heck would you want to do that?

Second, I don't think this will be a problem that occurs regularly, as even if you're running many many sites, they will have different names and there will be no clashes.

Furthermore, the script degrades quite gracefully: you can just change the site name if you hit that error.

Finally, this doesn't affect aegir, which uses the site_ prefix and will therefore be able to provision 10^11 sites...

anarcat’s picture

anarcat commented

Oh and another issue: this is really only possible if you suffer from #597738: We shouldn't provision install more than once on the same site...

frankcarey’s picture

frankcarey commented

First issue was that I was getting errors from the aegir gui about not being able to email, and that causing the site to fail an install... so I was trying to do it from the command line to pick up some debug info... but the output was not (easily) human readable, so i tried to rerun through sed command.. which took 30 times to try and get it to work :) Not a most common use case, but it might be good to actually run the script multiple times to debug it?

Second: Yes, probably a rare issue, but if you have multiple sites starting with the same words... like calendar.mysite1.com, calendar.mysite2.com you would be making database users like calendarmysite_1 calendarmysite_2... so you could only create 9 sites this way before you run out of characters. Do i have this right?

Finally, this doesn't affect aegir, which uses the site_ prefix and will therefore be able to provision 10^11 sites...

Yes, it seems to me this is wrong because I was only able to make 10 sites before i started getting an error. If script made calendarmysite_1 and then could make calendarmysit_10 and calendarmysi_100 ... all of which have 16 char, then all would be well, but it looks like the script uses 14 char for sitename, 1 for the underscore, and that only leaves 1 character left for a "delta" so only 10^1? Do I have this correct?

frankcarey’s picture

frankcarey commented

oh i think i do remember seeing site_### before in aegir 0.3... and now it seems to be using the actual domain name to make it? did that change?

Anonymous’s picture

Anonymous (not verified) commented

FrankCarey, the site_xxx is the normal behaviour that you *would* see if you were provisioning sites through the frontend as designed.

If you provision a machine from the command line, it is not going to have a site_$nid database name or user, because you aren't actually creating nodes in the Aegir database by which to define an nid from :)

So short story: yes you will run into collisions provisioning sites from the backend only.

And that's why there's a frontend.

frankcarey’s picture

frankcarey commented

mig5: so to clarify.. this is still an issue.. .just a very minor/rare one. A patch implementing the proper padding for this use case would be welcome?

anarcat’s picture

anarcat commented

Patches are always welcome of course. :)

frankcarey’s picture

frankcarey commented
StatusFileSize
new provision_improved_mysql_user_name_limit_handling.patch1.96 KB

here is a patch. I've tested it making 4 sites of the same name www.mysite1234567890.com ( being able to do this is a separate issue)

and here is the new output for each time I did it.

1) mysite1234567890 is available
2) mysite12345678_1 is available
3) mysite12345678_2 is available
4) mysite12345678_3 is available

frankcarey’s picture

frankcarey commented
Status: Active » Needs review
Steven Merrill’s picture

Steven Merrill commented
Status: Needs review » Reviewed & tested by the community

I applied the patch and it worked great.

FWIW, I'm using drush provision to install sites in a Hudson continuous integration setup, so I will reinstall the same site hundreds of times.

+1 to this patch for that reason.

anarcat’s picture

anarcat commented
Status: Reviewed & tested by the community » Needs work 
+  $max_num = pow(10, $mysql_username_limit);

From what I understand, this 10 power 16, which is 10000000000000000. I'm not sure how to put this, but this sounds insane for me. Something close to an infinite loop is not the right way here.

+  $postfix = '';

$postfix is confusing for us people that also deal with mailservers (of which a popular one is named "postfix"). $suffix would be better.

+      drush_log(dt("@option is available", array('@option' => $option)), 'message');

nitpicking: "Database @database is available" would be a better wording, more readable to translators too.

In general, while I'm happy to hear the patch actually works, those issues above need to be fixed before it's committed. Also, I would like to hear testing from someone that actually works with a complete aegir install before this patch is committed.

Thanks for the patch!

This review is powered by Dreditor.

frankcarey’s picture

frankcarey commented

the last 2 string changes sound fine, but I'm wondering what should be done about $maxnum. What I have there is the true limit to the number of possibilities that it could check, of course since it tries each possibility in order, it should only happen if ALL the previous possibilities were already taken, which is just as extreme. So if we put in an arbitrary limit, what do you suggest? The way it was setup before was it would check 100 but that seems too low, so maybe 1000 wouldn't be so terrible? Still I'm not convinced an arbitrary limit is necessary. thoughts?

frankcarey’s picture

frankcarey commented

Another option that might be preferable would be to divide and conquer, but first find the lower and upper bound by doubling since lower numbers are more probable. For example, if the number were 11, we could use the following sequence of guesses to find it: 1, 2, 4, 8, 16, 12, 10, 11. maximum calls would be 2(log_2 K) where K is the first open number. if it was around 10 ^6 then maximum calls would be 40, which is reasonable, but more likely to be less than 14 for numbers less than 128 and 6 for numbers less eight.

adrian’s picture

adrian commented
Status: Needs work » Fixed

This is resolved in head.

We use this now : 

      $suggest[] = sprintf("%s_%d", substr($suggest_base, 0, 16 - strlen( (string) $i) ), $i);

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

volkerk’s picture

volkerk commented
Status: Closed (fixed) » Needs work

Need to cut at 15 chars because an underscore is added in the sprintf.

<?php
      $suggest[] = sprintf("%s_%d", substr($suggest_base, 0, 15 - strlen( (string) $i) ), $i);
?>
adrian’s picture

adrian commented
Status: Needs work » Fixed

i fixed this in the dev-ssl branch which was since merged into master.
thanks,

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

  • Commit aac08b4 on debian, dev-dns, dev-koumbit, dev-log_directory, dev-migrate_aliases, dev-multiserver-install, dev-newhooks, dev-nginx, dev-ports, dev-simplerinstaller, dev-ssl, prod-koumbit, dev-ssl-ip-allocation-refactor, dev-1205458-move_sites_out_of_platforms, 7.x-3.x, dev-subdir-multiserver, 6.x-2.x-backports, dev-helmo-3.x by adrian: 
    A bevy of subtle fixes. Primarily #597750 because we no longer 'do' site...