provision-import doesn't import client-name, ssl and language settings from alias file [#1530610]

if i have an existing alias that aegir tries to import back again, it will not import the client name as it should.

other settings (e.g. aliases) are imported properly however.

Comment	File	Size	Author
#10	failsafe_default_client.patch	629 bytes	anarcat
#5	restore.php_.txt	3.42 KB	anarcat
#3	restore.php_.txt	2.83 KB	anarcat

Comments

Comment #1

anarcat commented 13 April 2012 at 14:31

Title:

provision-import doesn't respect existing client-name

» provision-import doesn't import client-name, ssl and language settings from alias file

Indeed, only the stuff that is in the drushrc gets imported, so there's actually more to it here.

Comment #2

anarcat commented 13 April 2012 at 14:37

In fact, this could even be in hosting, not provision, after looking at hosting_site.module:333... That function doesn't load the ssl or client settings. The language gets loaded, but there's some weird things going on there ...

Comment #3

anarcat commented 13 April 2012 at 16:34

Status	File	Size
new	restore.php_.txt	2.83 KB

So uh... that was a lot of fun here, restoring a full aegir site from scratch (basically). I had to use a crazy stupid script to restore data from a *backup* of the drush aliases, which I am attaching here for your perusal.

This script will take a backup of your drush aliases and edit the site nodes with the right information for the aliases, language, client_name, redirection and ssl settings.

Comment #4

anarcat commented 13 April 2012 at 18:30

Oh and the above script doesn't really work correctly in 1.7 because of this bug: #1493286: SSL certificates not being created. Fun galore.

Comment #5

anarcat commented 13 April 2012 at 18:41

Status	File	Size
new	restore.php_.txt	3.42 KB

updated version of that hack to deal with ssl, which exhibits the above bug.

Comment #6

Anonymous (not verified) commented 12 June 2012 at 04:11

It seems the act of kicking off an import of a site in the 'post' verify hook of a platform, doesn't load these attributes when it does a node_save. Is that the cause of the issue?


   foreach ($context['sites'] as $url) {
      if (hosting_domain_allowed($url)) {
        // Import any sites that have not been created yet.
        $site = new StdClass();
        $site->type = 'site';
        $site->site_status = HOSTING_SITE_QUEUED;
        $site->import = TRUE;
        $site->title = $url;
        $site->platform = $node->nid;
        $site->client = HOSTING_DEFAULT_CLIENT;
        $site->db_server = HOSTING_DEFAULT_DB_SERVER;
        node_save($site);
        drush_log(dt("Imported existing site !domain", array('!domain' => _hosting_node_link($site->nid))));
      }
      hosting_package_instance_sync($site->nid, $packages['base']);
    }

Note also that the database server is forced to be the HOSTING_DEFAULT_DB_SERVER, which is not ideal: it's quite possible that the site's alias, created by hand earlier, might have a remote database server defined as the db_server attribute. Just stumbled upon this.

The result is that the alias in the backend then gets overwritten with these defaults, setting things like db_server to '@server_localhost', which breaks future migrations etc.

Can we load the relevant attributes from the existing site context at this point?

Comment #7

Anonymous (not verified) commented 12 June 2012 at 05:21

I have worked around it by using drush @hostmaster hosting-import @site, which invokes an install task itself, and then I import the platform, which avoids 'importing' the site because the URL already exists in the frontend. It's not a very sane flow of logic, but it resolves my issue.

Comment #8

anarcat commented 23 October 2012 at 18:42

Note that this is causing #1146014: A user can see sites that don't have a client associated..

Comment #9

anarcat commented 23 October 2012 at 18:48

re #6, I think this is a different issue, which happens when a platform is verified. we are talking about a proper provision-import here, a different thing, although I agree that the code mentionned (in platform/hosting_platform.drush.inc) is problematic.

Comment #10

anarcat commented 25 October 2012 at 20:05

Version:	6.x-1.x-dev	» 6.x-2.x-dev
Status:	Active	» Needs work

Status	File	Size
new	failsafe_default_client.patch	629 bytes

This doesn't fix the problem but makes it a little better (and probably fixes #1146014: A user can see sites that don't have a client associated. altogether).

Testing needed.

Comment #11

ergonlogic

he/him

English

Montréal, Québec 🇨🇦

commented 31 October 2012 at 13:36

The patch attached to #10 does this:

  $site->client = $client->nid ? $client_id : HOSTING_DEFAULT_CLIENT;

But I don't see anywhere in hosting_import_site() where the $client_id variable is set. In fact, it appears as if there's some logic at the beginning of that function that attempts to do the same, no?

  $client = node_load(HOSTING_DEFAULT_CLIENT);

  if ($data['client_name']) {
    $client = hosting_import_client($data['client_name']);
  }

Comment #12

ergonlogic

he/him

English

Montréal, Québec 🇨🇦

commented 31 October 2012 at 14:01

Also, I'm not sure whether I'm replicating this bug properly. Here are the steps I'm taking on a (more or less) fresh Aegir install:

create a new client
create a site owned by that client
backup that site
copy and untar the backup into a new site directory on the same platform
verify the platform (which adds the site-import task automatically)

I've been running drush @hostmaster hosting-task <task_nid> --debug --force so as to see the options passed to the provision-save command. Here's the output of the platform verify (step 5, above); note the errors about undefined variables/properties:

Task starts processing
Backend invoke: php /usr/share/drush/drush.php --backend=2 --root=/var/aegir/platforms/drupal-6.26 --uri= --verbose --debug provision-save '@platform_Drupal626' --context_type=platform --master_url=http://aegir-dev.aegirdev2.local/ --server='@server_master' --web_server='@server_master' --make_working_copy=null 2>&1
php /usr/share/drush/drush.php --backend=2 --root=/var/aegir/platforms/drupal-6.26 --uri= --verbose --debug provision-save '@platform_Drupal626' --context_type=platform --master_url=http://aegir-dev.aegirdev2.local/ --server='@server_master' --web_server='@server_master' --make_working_copy=null 2>&1
Bootstrap to phase 0.
Bootstrap to phase 0.
Found command: provision-save (commandfile=provision)
Loaded alias @server_master from file /var/aegir/.drush/server_master.alias.drushrc.php
Loading apache driver for the http service
Loaded alias @platform_Drupal626 from file /var/aegir/.drush/platform_Drupal626.alias.drushrc.php
Template loaded: /var/aegir/.drush/provision/Provision/Config/Drushrc/provision_drushrc_alias.tpl.php
Changed permissions of /var/aegir/.drush/platform_Drupal626.alias.drushrc.php to 640
Generated config Drush configuration file
Changed permissions of /var/aegir/.drush/platform_Drupal626.alias.drushrc.php to 440
Command dispatch complete
Peak memory usage was 12.84 MB
Loaded alias @platform_Drupal626 from file /var/aegir/.drush/platform_Drupal626.alias.drushrc.php
Backend invoke: php /usr/share/drush/drush.php --backend=2 --verbose --debug @platform_Drupal626 provision-verify 2>&1
php /usr/share/drush/drush.php --backend=2 --verbose --debug @platform_Drupal626 provision-verify 2>&1
Bootstrap to phase 0.
Bootstrap to phase 0.
Found command: provision-verify (commandfile=provision)
Loaded alias @server_master from file /var/aegir/.drush/server_master.alias.drushrc.php
Loading apache driver for the http service
Including /var/aegir/.drush/provision/dns/verify.provision.inc
Including /var/aegir/.drush/provision/platform/backupmigrate/verify.provision.inc
Including /var/aegir/.drush/provision/platform/verify.provision.inc
Drush bootstrap phase : _drush_bootstrap_drupal_root()
Initialized Drupal 6.26 root directory at /var/aegir/platforms/drupal-6.26
Drupal sites directory /var/aegir/platforms/drupal-6.26/sites is writable by the provisioning script
This platform is running drupal 6.26
Found 33 modules in base
Found 6 themes in base
Found install profile default
Template loaded: /var/aegir/.drush/provision/http/Provision/Config/Apache/platform.tpl.php
Generated config platform configuration file
apache on aegir-dev has been restarted
Template loaded: /var/aegir/.drush/provision/Provision/Config/provision_drushrc.tpl.php
Changed permissions of /var/aegir/platforms/drupal-6.26/drushrc.php to 644
Generated config Platform Drush configuration file
Changed permissions of /var/aegir/platforms/drupal-6.26/drushrc.php to 444
Platforms path /var/aegir/platforms exists.
Platforms ownership of /var/aegir/platforms has been changed to aegir.
Platforms permissions of /var/aegir/platforms have been changed to 755.
Platforms path /var/aegir/platforms is writable.
Command dispatch complete
Peak memory usage was 13.66 MB
Undefined variable: site hosting_platform.drush.inc:93
Trying to get property of non-object hosting_platform.drush.inc:93
Undefined variable: site hosting_platform.drush.inc:93
Trying to get property of non-object hosting_platform.drush.inc:93
Undefined variable: site hosting_platform.drush.inc:93
Trying to get property of non-object hosting_platform.drush.inc:93
Undefined variable: site hosting_platform.drush.inc:93
Trying to get property of non-object hosting_platform.drush.inc:93
Undefined variable: site hosting_platform.drush.inc:93
Trying to get property of non-object hosting_platform.drush.inc:93
Undefined property: stdClass::$uid hosting.module:194
Undefined property: stdClass::$site_language hosting_site.nodeapi.inc:144
Undefined property: stdClass::$ip_addresses hosting.ip.inc:43
Undefined property: stdClass::$profile hosting_site.nodeapi.inc:153
Undefined property: stdClass::$verified hosting_site.nodeapi.inc:153
Undefined property: stdClass::$hosting_name hosting_site.nodeapi.inc:155
Undefined property: stdClass::$aliases hosting_alias.module:145
Imported existing site test7.local
Task import was added to the queue. Next queue run is 13:42:04+0000, server time is 13:41:15+0000.
Command dispatch complete
Peak memory usage was 27.48 MB

By the time the site import is run, the client_name has been reset to 'admin', among other things:

Backend invoke: php /usr/share/drush/drush.php --backend=2 --root= --uri=test7.local --verbose --debug provision-save '@test7.local' --context_type=site --master_url=http://aegir-dev.aegirdev2.local/ --aliases=null --redirection=null --db_server='@server_localhost' --platform='@platform_Drupal626' --language=en --client_name=admin 2>&1

Comment #13

omega8cc commented 5 November 2012 at 17:19

Please check if patches posted there:

http://drupal.org/node/1146014#comment-6694336
http://drupal.org/node/1146014#comment-6694378

make any difference in debugging this issue.

They should.

Comment #14

anarcat commented 16 November 2012 at 20:10

It seems my patch isn't fixing the actual issue here, which is about provision-import, not hosting-import. I have nevertheless committed it since it's a good safeguard check for #1146014: A user can see sites that don't have a client associated..

Comment #15

helmo commented 26 February 2016 at 14:36

Issue summary:	View changes
Status:	Needs work	» Closed (outdated)

The 6.x-2.x branch will go EOL along with Drupal this week. So I'm closing
this issue. If it remains a confirmed issue in 7.x-3.x, feel free to re-open,
or better yet, create a new issue referencing this one.

provision-import doesn't import client-name, ssl and language settings from alias file