Remote Administration environment

Acquia provides Remote Administration (RA) clients with an additional RA environment at no additional cost. This environment facilitates the deployment and testing of security updates without disrupting ongoing development in other environments. Updates are deployed based on your RA preferences.

For Acquia Cloud Enterprise clients, the RA environment is hosted on RA-specific shared Acquia servers and will have no impact on development, staging, or production servers. RA environments for Acquia Cloud Professional customers are configured such that they will consume no critical system resources while the website sits idle, and all critical resources remain available to the production website.

Security update testing

Client testing of the initial step (see Security updates) takes place on the RA environment. Clients and Acquia Support can push code to the deployed branch for testing. Testing should take into account that the RA environment may not be configured with the same specs as your Development, Stage or Production environments. This environment will be regularly overwritten by new security updates, and should not be used for any ongoing development, testing, or content creation. It is not possible to deploy code to this environment using the workflow interface.

Databases

Databases copied to the RA environment will only remain as long as a Security Update branch is deployed and undergoing testing.

You can scrub your databases to prevent sensitive data from being copied into the RA environment. For more information about creating scrub scripts to clean any sensitive data, see the Scrubbing a Drupal database environment article on the Acquia Help Center.

Automated database changes

In order to ensure compatibility and testability in the RA Environment, certain changes are made to the copied database using drush. Database level changes on the RA Environment, such as creating new content or disabling modules, have no effect on the code or data deployed to any other environment. The update workflow never copies an RA environment into either the testing or production environments.

If the updated website uses modules dependent upon modules modified by automation, full testing of such functionality will need to take place on another environment. In such cases, the branch can be either deployed to another environment upon request, or such functionality can be tested once the branch has been tagged (step two).

  • Secure Pages and Secure login - These modules are most often coded to point to the Production website, so leaving them enabled often confuses testing. As a result, these modules are disabled using drush when an update branch is deployed to RA. Modules dependent on Secure Pages and Secure Login should be tested on another environment.
  • Stage File Proxy - This module is added and enabled. See below for details.

Subscription-specific database changes

In situations where specific module functionality should be restricted or disabled on the RA Environment, Acquia recommends taking advantage of environment-level variables in the settings.php file that can control functionality for each environment. It is possible to set either an environment-specific functionality using the AH_SITE_ENVIRONMENT variable or a to restrict changes to the non-production environment functionality by using AH_NON_PRODUCTION'. These variables can be used to redirect secure pages for each environment, or set Acquia Search to read-only on the RA Environment, and so on.

Given the unique needs of each website, these variables should be set by the client. Acquia Support is happy to offer suggestions and examples.

Deploy hooks

Hooks that are in the common directory (usually hooks) will run on all environments, including RA. Due to differences between the RA environment and the other environments, these hook scripts occasionally result in unexpected behaviors or task failures, which can cause the RA automated update process to fail.

If you have scripts in the common directory, they can be modified slightly to prevent them from running on the RA environment. The following example includes an if statement to include in the scripts that will allow them to run normally on all environments except for RA:

#!/bin/sh
#
#Standard hook variables here
#

site="$1"
target_env="$2"

if [ "$target_env" != "ra" ]; then
     drush @$site.$target_env updatedb --yes
fi

Alternately, move any hooks located in the common directory to the development, stage and/or production directories instead.

Files and the Stage File Proxy module

Production files are not copied into the RA environment. Instead, the Stage File Proxy module is implemented. The module is added to the repository and enabled on the RA environment only. It has no effect on production environments. This module sends file requests to the production environment and copies the production file in the RA environment. This saves both time and space. Files uploaded by other means, or theme images or CSS using the Drupal file structure rather than a theme folder, will not appear in the RA environment.

Stage File Proxy is incompatible with the following modules:

  • FileField Sources
  • Fast 404 - Adding the following to your website's settings.php file will ensure that Fast 404 does not interfere with the functionality of Stage File Proxy:

    if (!isset($_ENV['AH_SITE_ENVIRONMENT']) || $_ENV['AH_SITE_ENVIRONMENT'] != "ra") fast_404_ext_check();

Stage File Proxy does not support subfolders within your Drupal user files directory. Any images or other files within subfolders will not be displayed correctly in the RA environment.

If you are running these modules, you should deploy the Security Update to a different testing environment as soon as it is available.

Memcache disabled

Memcache is not enabled in the RA environment. It may be enabled in your other environments, but should result in little to no impact to your website(s) when testing in the RA environment. The recommended memcache include statement should already be present in your settings.php file:

if (isset($conf['memcache_servers'])) {
  $conf['cache_backends'][] = './sites/all/modules/memcache/memcache.inc';
  $conf['cache_default_class'] = 'MemCacheDrupal';
  $conf['cache_class_cache_form'] = 'DrupalDatabaseCache';
}

If you are using a different include statement related to memcache in any of your settings.php files, Acquia strongly recommends replacing it with the previous statement and deploying to your production environment. Once the change is deployed to production, websites deployed to the RA environment during step one of the update process will no longer be dependent on memcache while running on that environment.

Domains

The RA environment is provisioned with a single Acquia Cloud subdomain similar to your Development, Stage and Production environments. Additional domains can be added to the RA environment from the Acquia Cloud Domains page. Instructions for adding domains are available at Managing your domains.

Your DNS provider must point your domain names to the IP address of the RA environment to ensure requests for that domain name are directed to the correct location on the RA servers. You can add the domain names to your local hosts file in order to test locally.

Authentication issues

Customers using a Single Sign-On (SSO) solution for Drupal user authentication may encounter issues when signing in to websites on their RA environment that have not been configured with the SSO. Websites using LDAP, SAML, or SimpleSAML solutions can also encounter the same issue.

If your testing in the RA environment is hindered by authentication issues, deploy the update branch to the preferred Testing environment as set in the RA preferences. When creating your update ticket, be sure to request the deployment of update code to an environment other than RA. The RA team will deploy the update branch to your preferred environment and will notify you when you can continue testing.

Contact supportStill need assistance? Contact Acquia Support