With a unprivileges mysql user:

$ drush @imc si 
You are about to DROP your 'imc' database and then CREATE a new one. Do you want to continue? (y/n): y
ERROR 1044 (42000) at line 1: Access denied for user 'imc'@'localhost' to database 'imc'
No tables to drop.  

if I pass --debug then mysql is invoked with -v and there's an extra failure because the sql query is included in the output:

jonhattan@jengibre:~$ mysql -v imc
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 2367
Server version: 5.1.49-3 (Debian)

mysql> show tables;
--------------
show tables
--------------

Empty set (0.00 sec)

so it will do

Calling db_query(DROP TABLE SHOW TABLES, --------------, )

also in this case for --debug we obtain an extra bug:

call_user_func_array() expects parameter 1 to be a valid callback, function 'db_query' not found or invalid        [warning]
function name drush.inc:1159 [2.48 sec, 7.35 MB]

It seems db_query is not available in DRUSH_BOOTSTRAP_DRUPAL_SITE stage.

other thing I'm seeing is that drush @alias si doesn't work, because of @alias. It doesn't mather the cwd. I've also tried using drush_shell_cd_and_exec() in site_install_6.inc with no luck.

Comments

jonhattan’s picture

I'll try to reorganize above report:

1/ drush @alias si doesn't work *for d6* because of the alias (it doesn't matter the cwd --in $drupal_root or out). I've succesfully run the same command for d7.
2/ mysql -v is inadequate if you plan to parse its result.
3/ db_query() is called by drush_sql_drop() and is not available before DRUSH_BOOTSTRAP_DRUPAL_DATABASE

greg.1.anderson’s picture

I'm not going to have time to work on this today after all. :(

I'll be back online Sunday night. Ship drush-4 w/out this or wait for me or do this for me -- any is okay with me.

My thoughts:

1. Don't know why
2. We should add drush_get_option('sql-verbose') and not make sql produce verbose output just because -v is on. This should be passed as a param to sql execute, so functions that call sql query programatically can have 'verbose' turned off.
3. We should be able to call sql-drop via backend invoke so that it will bootstrap to the DATABASE level.

moshe weitzman’s picture

2. sounds good.
3. Lets take a little more time to do what we originally wanted which is to make sql-drop work without any bootstrap.

moshe weitzman’s picture

2. I just fixed this by removing verbose from mysql and postgres calls. It didn't actually help us.

moshe weitzman’s picture

1. I can't reproduce this. I just tried on another local site. Are you using a remote site? Are you sure that its drush is up to date? Please post a full --debug log.

moshe weitzman’s picture

Status: Active » Fixed

3. Fixed. Now using _drush_sql_query() instead of db_query().

moshe weitzman’s picture

Status: Fixed » Postponed (maintainer needs more info)

I should note that I didn't implement my suggestion to make sql-drop a pure bash operation since thats a bigger change that we should do in Drush 5.

At this point, we need confirmation that the alias technique works or fails. after these changes. And a full debug log.

jonhattan’s picture

Assigned: greg.1.anderson » Unassigned
Status: Postponed (maintainer needs more info) » Active
StatusFileSize
new1.03 KB

My alias is:

$aliases['imc'] = array (
  'root' => '/var/www/imc',
  'uri' => 'http://imc',
  'databases' => 
  array (
    'default' => 
    array (
      'default' => 
      array (
        'driver' => 'mysql',
        'username' => 'root',
        'port' => '',
        'host' => 'localhost',
        'database' => 'drupal_imc',
      ),
    ),
  ),
);

and the original site was installed at sites/default. There's no multisite environment. So I run drush @imc si.

The first chunk of code to be run through php -r in site_install_6.inc is:

Executing: php -r 'error_reporting(E_ERROR);$_GET=array("profile"=>"default", "locale"=>"en", "id"=>"1"); $_REQUEST=&$_GET;define("DRUSH_SITE_INSTALL6", TRUE);$_SERVER["SERVER_SOFTWARE"] = NULL;$_SERVER["SCRIPT_NAME"] = "/install.php";$_SERVER["HTTP_HOST"] = "http://imc";$_SERVER["REMOTE_ADDR"] = "127.0.0.1";function _cli_cookie_print(){print(serialize(array(session_name()=>session_id())));}
register_shutdown_function("_cli_cookie_print"); include("/var/www/imc/install.php");'
  a:1:{s:9:"PHPSESSID";s:0:"";}

The difference when running si from the drupal root is that $_SERVER["HTTP_HOST"] = "http://imc" is always the same as --sites-subdir, and without http://.

Attached a patch that fix this situation and doesn't seem to break other scenarios.

btw here's the debug output:

jonhattan@jengibre:~$ drush @imc si --debug
You are about to DROP your 'imc' database and then CREATE a new one. Do you want to continue? (y/n): y
Sites directory sites/default already exists - proceeding. [4.36 sec, 7.34 MB]                                        [notice]
Calling system(mysql --database=information_schema --host=localhost --user=root --password=root  < /tmp/phpNWhEML);
Executing: php -r 'error_reporting(E_ERROR);$_GET=array("profile"=>"default", "locale"=>"en", "id"=>"1"); $_REQUEST=&$_GET;define("DRUSH_SITE_INSTALL6", TRUE);$_SERVER["SERVER_SOFTWARE"] = NULL;$_SERVER["SCRIPT_NAME"] = "/install.php";$_SERVER["HTTP_HOST"] = "http://imc";$_SERVER["REMOTE_ADDR"] = "127.0.0.1";function _cli_cookie_print(){print(serialize(array(session_name()=>session_id())));}
register_shutdown_function("_cli_cookie_print"); include("/var/www/imc/install.php");'
  a:1:{s:9:"PHPSESSID";s:0:"";}
Executing: php -r '$_GET=array("profile"=>"default", "locale"=>"en", "id"=>"1"); $_REQUEST=&$_GET;define("DRUSH_SITE_INSTALL6", TRUE);$_SERVER["SERVER_SOFTWARE"] = NULL;$_SERVER["SCRIPT_NAME"] = "/install.php";$_SERVER["HTTP_HOST"] = "http://imc";$_SERVER["REMOTE_ADDR"] = "127.0.0.1";$_COOKIE=unserialize("a:1:{s:9:\"PHPSESSID\";s:0:\"\";}"); $_GET["op"]="start"; include("/var/www/imc/install.php");'
Executing: php -r '$_GET=array("profile"=>"default", "locale"=>"en", "id"=>"1"); $_REQUEST=&$_GET;define("DRUSH_SITE_INSTALL6", TRUE);$_SERVER["SERVER_SOFTWARE"] = NULL;$_SERVER["SCRIPT_NAME"] = "/install.php";$_SERVER["HTTP_HOST"] = "http://imc";$_SERVER["REMOTE_ADDR"] = "127.0.0.1";$_COOKIE=unserialize("a:1:{s:9:\"PHPSESSID\";s:0:\"\";}"); $_GET["op"]="do_nojs"; include("/var/www/imc/install.php");'
Executing: php -r '$_GET=array("profile"=>"default", "locale"=>"en", "id"=>"1"); $_REQUEST=&$_GET;define("DRUSH_SITE_INSTALL6", TRUE);$_SERVER["SERVER_SOFTWARE"] = NULL;$_SERVER["SCRIPT_NAME"] = "/install.php";$_SERVER["HTTP_HOST"] = "http://imc";$_SERVER["REMOTE_ADDR"] = "127.0.0.1";$_COOKIE=unserialize("a:1:{s:9:\"PHPSESSID\";s:0:\"\";}"); $_GET["op"]="finished"; include("/var/www/imc/install.php");'
Executing: php -r '$_GET=array("profile"=>"default", "locale"=>"en", "id"=>"1"); $_REQUEST=&$_GET;define("DRUSH_SITE_INSTALL6", TRUE);$_SERVER["SERVER_SOFTWARE"] = NULL;$_SERVER["SCRIPT_NAME"] = "/install.php";$_SERVER["HTTP_HOST"] = "http://imc";$_SERVER["REMOTE_ADDR"] = "127.0.0.1";$_COOKIE=unserialize("a:1:{s:9:\"PHPSESSID\";s:0:\"\";}");
  $_POST = array (
    "site_name" => "Site-Install", 
    "site_mail" => "admin@example.com", 
    "account" => array (
      "name" => "admin",
      "mail" => "admin@example.com",
      "pass" => array (
        "pass1" => "admin",
        "pass2" => "admin"
      )
    ),
    "date_default_timezone"=>"0", 
    "clean_url"=>1,
    "form_id"=>"install_configure_form", 
    "update_status_module" => array("1"=>"1")
  );
  include("/var/www/imc/install.php");'
Command dispatch complete [4.94 sec, 7.35 MB]                                                                         [notice]
 Timer  Cum (sec)  Count  Avg (msec) 
 page   4.381      1      4381.43    

Peak memory usage was 7.4 MB [4.95 sec, 7.35 MB]                                                                      [memory]

Although it doesn't mark an error it doesn't install the site at all.

jonhattan’s picture

Status: Active » Needs review
moshe weitzman’s picture

Title: site-install fails for d6 » site-install fails for d6 when using a site alias
Status: Needs review » Needs work

I could reproduce this problem but it is solved by passing --sites-subdir. That option is mandatory for new installs. I don't think we need the latest patch as it complicates site-install for existing sites (they would also be required to pass --sites-subdir).

Please confirm that passing --sites-subdir fixes the problem. If desired, you may put it into drushrc.

jonhattan’s picture

Status: Needs work » Needs review
StatusFileSize
new1020 bytes

The problem here has introduced by me in #1004476: site-install doesn't work for d6 when installing in a subdir. HTTP_HOST should not include the protocol part. drupal_valid_http_host() in conf_init() was killing the installation process.

moshe weitzman’s picture

Status: Needs review » Reviewed & tested by the community

Nice detective work.

moshe weitzman’s picture

Status: Reviewed & tested by the community » Fixed

committed. thanks.

Status: Fixed » Closed (fixed)

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

moshe weitzman’s picture

Assigned: Unassigned » jonhattan
Priority: Normal » Minor
Status: Closed (fixed) » Active

I'm seeing a problem with the most recent fix here. If you use a mixed case name for your sites-subdir, it gets automatically lowercased when reading out of $_SERVER['HTTP_HOST']. Not sure if that always happens or just on some configurations of PHP. So, the HTTP_HOST that we set is wrong and Drupal tries to install to sites/default instead of sites/mixedCase (for example).

using PHP 5.2.10-2ubuntu6.7 with Suhosin-Patch 0.9.7 (cli) (built: Jan 12 2011 17:56:07)

jonhattan’s picture

StatusFileSize
new1.85 KB

I'm not able to install a site at sites/mixedCase site even via web. mixedCase is supposed to be a domain name and they're case insensitive. I see my browser and apache lowercasing it.

With attached patch we force to assign mixedCase to HTTP_HOST, and also pass the failure to drupal internals. No possible fix IMO.

In the log:

Executing: php -r 'error_reporting(E_ERROR);$_GET=array("profile"=>"default", "locale"=>"en", "id"=>"1"); $_REQUEST=&$_GET;def
ine("DRUSH_SITE_INSTALL6", TRUE);$_SERVER["SERVER_SOFTWARE"] = NULL;$_SERVER["SCRIPT_NAME"] = "/install.php";$_SERVER["HTTP_HO
ST"] = "mixedCase";$_SERVER["REMOTE_ADDR"] = "127.0.0.1";function _cli_cookie_print(){print(serialize(array(session_name()=>se
ssion_id())));}

....

        <div id="center"><div id="squeeze"><div class="right-corner"><div class="left-corner">
            <h2>Requirements problem</h2>                    <h3>The following error must be resolved before you can continue the installation process:</h3><div class="messages error">
  The Drupal installer requires that you create a settings file as part of the installation process.
  <ol>
  <li>Copy the <em>./sites/default/default.settings.php</em> file to <em>./sites/default/settings.php</em>.</li>
moshe weitzman’s picture

Status: Active » Reviewed & tested by the community

OK. Feel free to commit the patch if you think it is helpful. Otherwise, lets move this back to fixed.

jonhattan’s picture

Status: Reviewed & tested by the community » Fixed

The patch is syntactically precise in the usage of 'uri' (by respecting http://) so commited. Also implemented a validation callback to force lowercase sites-subdir.

http://drupal.org/cvs?commit=495602

jonhattan’s picture

Version: » All-versions-4.x-dev
Assigned: jonhattan » msonnabaum
Status: Fixed » Patch (to be ported)
StatusFileSize
new3.17 KB

Backport #18 worth it to reduce some possible bug reporting. Attached the complete patch.

msonnabaum’s picture

Status: Patch (to be ported) » Fixed

Thanks jonhattan. Committed.

http://drupal.org/cvs?commit=496840

Status: Fixed » Closed (fixed)

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