Aegir Platform DrupalCommerce

Как говриться "А ларчик просто открывался". 

Продолжая тему Aegir панели и  хостинга Drupal, решил добавить  в свой развернутый вариант Aegir  еще одну Платформу, и не простоую платформу аплатформу электронной коммерции DrupalCommerce. 

Основываясь на опыте  добавления  сборки Agov (Сайт для  автралийского правительстава) которое подключилось  очень даже  легко, сделал вывод, что  DrupalCommerce подключится так же быстро и сайт  на основании нее создатся так же без проблем. Но не тут-то было. 

Но давайте все по порядку.

Первое, что необходимо сделать  это   в директорию  "Platforms" скачать  распакованую  сборку. В нашем случае это Commerce

На втором шаге заходим в панел управления и  добавляем   путь  до  добавлемой платформы  (достаточно добавить  только  название папки, путь  до нее  лучше не менять)

После чего наступает так называемая проверка  "Verifi", на которой ситсема проверяет целостность пакетов и  чего-то еще.

Спустя некоторое время система отрапартует, что все хорошо или наоборот. Мы рассматриваем певый вариант, так как второй очень специфичен. 

Соответветственно наступает третий шаг, добавления сайта  на базе  установленной платформы. Кликаем на  "Add Site" заполняем имя домена DNS-записи коорого "смотрят на  наш сервер, выбираем в блоке "Install profile" название  профиля в сборке, выбираем нашу добавленую платформу, сервер базы данных, есл необходимо алиасы домена и нажимаем  SAVE. Ждем некоторое время, и наслаждаемся свеже установленным Drupal Commerce. 

Однако, не всегда все проходит очень гладко. В течение недели я боролся с непонятной  проблемой невозможности  установки данной платформы, правильнее сказать , не мог создать сайт на  базе нее, постоянно  получалась  неизвестная ошибка.

Как всегда  выход нашелся чисто случайно и ларчик прост открывался. 

Оказывается в демонстрационом контенте данной сборки присутсвует  подключение к сторонней  платежной системе (она  прописана по умолчанию  и активируется), в свою очередь это требует, Внимание, барабанная дробь, модуля PHP - CURL. Когда данный модуль был проинсталтирован то все сразу  же  заработало.

Надо  сказать, что  изначальный поиск по  ошибке "Инсталяция потерпела неудачу" приводила на  друпал орг, на комьюнити  aegir, но как таковых ответа на  поставленный  вопрос (вменяемы) никто не давал, все ссылалсь на права фаловой  системы, недостаток оперативной памяти или процессорный лимит, но ка коказалось все гораждо проще всего лишь необходимо было вчитаться в список ошибок и разглядть  ошибку с использование (отсутвием) данного модуля. Заием проинтсалировать и повторить процесс

аываывавыаываыв

Saturday, 2014, October 25 - 19:30

07:00pm

Tuesday, 2014, November 25 - 19:00 to Thursday, 2014, December 25 - 19:00

07:00pm

Importing a single site manually

If you already have a platform setup on Aegir with EXACTLY the same codebase as your existing site, then you don't need to transfer the entire old codebase - you can just transfer the sites/example.com directory. However, you also need to make sure any dependencies on contrib modules that your site has, are covered on the codebase or Platform that you're importing it into.

In general it may be considered safer/less prone to confusing errors to transfer the entire old codebase into Aegir as a whole Platform, whereby the site will be imported automatically under that Platform. You can then migrate it in Aegir to one of your existing Platforms later. See importing from a complete Drupal platform for this method.

Also, it is much faster to just "deploy" an Aegir backup than go through the manual procedure here, so you should generally follow that procedure instead of the one defined here unless you have a very hairy setup.

To transer a site manually into Aegir, those are the steps you should follow:

1. Create the site database, user and directory

In order to import the site, you need to create a database and database user for the site, along with a directory in the platform.

The simplest way to do this is to create an empty site in the right platform and overwrite it. Through the commandline:

 

drush provision-save @example.com --context_type=site --platform=@platform_d6 --uri=example.com --db_server=@server_localhost --client_name=admin
drush provision-install @example.com

 

Through the UI, this can be done simply by creating a site in Create content.

If this is not working for some reason, you can create the mysql user and database manually using the following:

 

GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER, LOCK TABLES, CREATE TEMPORARY TABLES ONdatabasename.* TO 'databaseuser'@'localhost' IDENTIFIED BY 'password';
CREATE DATABASE databasename;

 

2. Transfer the files

You need to copy the sites/example.com directory from your old server to the new Aegir server.

To do this, first create a tarball of the site on the old server. Within the sites/example.com directory type:

 

tar -zcvf example.com.tar.gz .

 

Then, on the Aegir server, you can create a directory for it in the codebase (platform) you want to put it under:

 

cd /var/aegir/platforms/drupal-X.Y/sites
mkdir example.com
cd example.com
wget http://example.com/example.com.tar.gz
tar
 -zxvf example.com.tar.gz ./files ./modules ./libraries ./themes

 

Instead of using wget you could of course use SCP or FTP to transfer the tarball onto the Aegir server.

In the above we assume that you have created an empty site as directed above, if not, you will also need to extract the settings.php file, so that last command should instead be simply:

 

tar -zxvf example.com.tar.gz

 

Then you will need to modify the settings.php file to follow the user and database created in the first step. Again, this is not necessary if you let Aegir create the site for you.

Once the file is unpacked, check the ownership and group of each file by using ls -al. It should be either 'aegir:aegir' or 'aegir:www-data'. Change it if necessary. In particular, files that may have been uploaded on your site via modules like imagecache, upload, Profile pics etc, may need to have their ownership changed:

 

sudo chown -R aegir:www-data $platform/sites/*/files

 

3. Transfer the Database

Make a backup of the database on your old server (Backup and Migrate module is good for this, or you can use phpmyadmin or your favourite MySQL management tool. It's a good idea to truncate the cache, search and watchdog tables first to reduce the size of the database. The "Backup and Migrate" module does this for you.

If you are importing a site from a previous Aegir installation somewhere, such as from a backup tarball, the database.sql will already be within the tarball you unpacked. You can use this to import into a new database on your new server.

You can import the database with drush using the following command:

 

drush @example.com sqlc < database.sql

 

4. Verify In Aegir

In the Aegir web interface click on the name of the platform you have added your site to. You can access the list of platforms via the 'Platforms' tab in the primary links menu.

Execute a new Verify task on this platform via the 'Verify' button in the task list.

Aegir will now re-verify the platform. In the process of this, it will discover your new site and spawn a new 'Import' task for the site.

Once it's done this (it may take a couple of cron runs to dispatch these tasks in the queue) the tasks should turn green (if not, see 'Troubleshooting' below).

At this point, presuming you have updated DNS or are overriding DNS via an entry in your /etc/hosts file to access the site via the new Aegir server, you can visit the site in a browser and check around to see that it has worked. Pay particular attention to any links in node content that pointed to paths referencing /sites/community.aegirproject.org if your site was not part of a multisite setup. (Drupal has a habit of storing these paths in the database, or they may have been hard-coded into nodes by users).

Aegir will not go through all your database and update all URLs, so some images or links may be broken. This will need to be done manually. Aegir does attempt to update paths stored in tables such as 'files' though.

It's a good idea to clear the caches, and you may need to get imagecache to rebuild its thumbnails if you use it.

Importing a complete Drupal platform

 

  1. 1.Transfer the codebase
  2. 2.Transfer the Database
  3. 3.Setup Platform in Aegir
  4. 4.Import and Verify Sites In Aegir
  5. 5.Migrate To Another Platform
  6. 6.Troubleshooting

This way of importing sites is often considered the safest whereby you transfer across an entire codebase containing Drupal core, and define it as a Platform first. This makes sure you bring any dependencies, contrib modules etc, in exactly the same version and configuration that is referenced in the database for the site.

1. Transfer the codebase

Create a tarball of the codebase on the old server. Within the drupal root directory type: tar -zcvf example.com.tar.gz * .htaccess

Note that we have to specify including the .htaccess because it isn't picked up by the * wildcard due to being prefixed with a full stop. It is important to bring along the .htaccess for a platform so that Aegir can consider these settings when it generates Apache configuration for this platform.

Then, on the new server you can create a directory for it in the codebase you want to put it under:

cd /var/aegir/platforms
mkdir your-new-platform
cd your-new-platform
wget http://example.com/example.com.tar.gz
tar
 -zxvf example.com.tar.gz

 

Instead of using wget you could of course use SCP or FTP to transfer the tarball onto the Aegir server.

Once the file is unpacked, check the ownership and group of each file by using ls -al. It should be either 'aegir:aegir' or 'aegir:www-data'. Change it if necessary. We have to assume you have basic knowledge of Linux and POSIX permissions - we can't be responsible for teaching you sysadmin skills :)

In particular, files that may have been uploaded on your site via modules like imagecache, upload, Profile pics etc, may need to have their ownership changed: sudo chown -R aegir $platform/sites/*/files

If your site previously resided in sites/defau1t you need to move it because Aegir ignores the default directory (it has no way of understanding what URL this would be accessed by, so it is impossible to 'manage' it). Each site needs its own directory with the correct domain in typical Drupal multisite design:

 

mv sites/defau1t sites/example.com

 

If you do this, you may need to also update your filepath's stored in the files table by running the following query on your database:

UPDATE files SET filepath = REPLACE(filepath, 'sites/defau1t', 'sites/example.com');

 

There are many other places in the database that can suffer the same problem, the node_revisions table for example. If you have phpMyAdmin available you can easily search the entire database for 'sites/defau1t'. Select the database, then click the Search tab. Once you know which tables are affected you can run a variation of the above query to correct these records.

2. Transfer the Database

Note: This step is not necessary if you are moving your site from one directory on your server (e.g., /var/www/html) to a newly created Aegir directory on the same server (e.g., /var/aegir).

Make a backup of the database on your old server (Backup and Migrate module is good for this, or you can use phpmyadmin or your favourite MySQL management tool. It's a good idea to truncate the cache, search and watchdog tables first to reduce the size of the database (Backup and Migrate does this for you).

Aegir does not provide support for importing databases with prefixed tables so it is best to remove prefixes form the database. However, there is work to bring this support in (http://drupal.org/node/483346) and a solution if you want to keep prefixes on your tables (http://drupal.org/node/483346#comment-3113516)

Unlike traditional Drupal projects the database settings cannot be found in settings.php. The database credentials are stored in the Apache vhost config of the associated site. This is a security measure implemented by the Aegir project.

In the vhost directory on your old server, /var/aegir/config/server_master/apache/vhost.d/, is a vhost file for every site on your server. The contents of the file can be displayed in your terminal with the command cat thenameofthefile. At the top of the file you will find the credentials needed to create a database on the new server.

On your new server, manually create a new database and upload the .sql file from your backup.

Then create the mysql user that your site accesses the database as, and grant it all permissions on that database except 'GRANT'.

Connect to the database on the old server: mysql -u root -p

Create the new database: create database yourdatabasename

Add the user: CREATE USER 'yourdatabaseuser'@'localhost' identified by 'youruserpassword';

Give the necessary privileges: GRANT ALL PRIVILEGES ON yourdatabasename.* TO 'yourdatabaseuser'@'localhost';

Import the database: mysql -u yourdatabaseuser -p -h localhost yourdatabasename < thenameofthedatabase.sql

3. Setup Platform in Aegir

In the Aegir web interface click on 'Create Content' and 'Platform'. This step is often easiest when using the admin-menu on the top of your screen.

Enter the name you want to use for the platform (eg 'My Platform import'), and the path to the platform on the server (eg '/var/aegir/platforms/your-new-platform')

Click Save to submit the form, and Aegir will spawn a Verify task for this platform into the queue.

Once the task is complete this the task should turn green (click through to the homepage to refesh and check. If not, see 'Troubleshooting' below).

4. Import and Verify Sites In Aegir

Upon completion of the above Platform verification task, Aegir will discover your new site and spawn a new 'Import' task for the site.

Once it's done this (it may take a couple of cron runs to dispatch these tasks in the queue) the tasks should turn green (if not, see 'Troubleshooting' below).

At this point, presuming you have updated DNS or are overriding DNS via an entry in your /etc/hosts file to access the site via the new Aegir server, you can visit site in a browser and check around to see that it has worked. Pay particular attention to any links in node content that pointed to paths referencing /sites/community.aegirproject.org if your site was not part of a multisite setup. (Drupal has a habit of storing these paths in the database, or they may have been hard-coded into nodes by users).

It's a good idea to clear the caches, and you may need to get imagecache to rebuild its thumbnails if you use it.

5. Migrate To Another Platform

Now that you have your sites under Aegir's control you can take advantage of its power, and easily migrate them to another platform. In the event that your sites were on old versions of Drupal core and a new one is available and present as another Platform on your Aegir server, you can use the Migrate process to upgrade those sites onto the new core.

For details on how to Migrate sites, consult the Migrate documentation.

6. Troubleshooting

For those who are migrating existing sites that live with their files in the sites/community.aegirproject.org folder, things can get tricky. However, you can follow this tutorial and successfully get things moved over rather easily.

Manage your Aegir system from the command-line

As you probably know if you've been using it for a while, Aegir is generally considered to have two hemispheres: one is Hostmaster / Hosting, the install profile and module set that make up the web-based Aegir frontend control panel.

Hostmaster installs your site and provides the dispatcher to run the queues on your system. Hosting and its submodules provide all the functionality that lets you add site and platform nodes and kick off tasks on them (such as Migrate, Clone etc), from a web browser.

The other hemisphere is Provision, which is the 'backend' and guts of the Aegir system. It's essentially a large extension module to Drushthat actually performs all the tasks sent into the queue. This component is what installs sites, moves them around, deletes them, creates the VirtualHost configurations and databases and so on.

So really, the Hosting frontend exists simply to provide a convenient method of placing tasks (say, 'hosting-task install @site' into the queue, which hostmaster 'dispatches' and hands to Provision in the form of a Drush command (drush @site provision-install').

In the old Drush 2.x days, we used to have pass a whole bunch of arguments for tasks so that Provision knew what site to operate on and its various components (what platform it was on, etc). These days thanks to Drush 3, we make heavy use of Drush Aliases, which are essentially little registry configs per each object, such as a site, platform or server, that can be loaded in one go with all attributes on-hand ready to use by Drush.

You can see these Drush aliases in your /var/aegir/.drush/ directory. They are the files that end in .alias.drushrc.php

Drush provides you with the command 'drush site-alias' or 'drush sa' to also view what aliases are able to be loaded in the system.

The presence of a Drush alias per object makes things really interesting in Aegir if you want to drive this whole system from the command-line as opposed to use the frontend.

Now, why would you want to do that? Well, think like a sysadmin: by being able to drive a system from a command line, that means you ought to be able to go some ways to automating that system, resulting in less effort, faster turnaround, automated turn-key services.. giving birth to Skynet.. well, the list goes on and on :)

In this tutorial, I'm going to show you how to create two separate Drupal platforms (codebases), install a site on one platform, and migrate (upgrade) that site between the two platforms - all from the command line.

Users who want to skip ahead and learn how to automate processes like this using fancy tools like Jenkins, Fabric or Capistrano: I highly recommend you read my article and watch my screencast on Zero-touch Drupal deployment with Jenkins, Aegir, Git, Fabric and Drush.

Step 1: Build your platforms

Sites in Aegir have to exist on top of (or within, whatever analogy you prefer) a platform. A platform is simply a Drupal codebase - this can be vanilla Drupal, Pressflow, or a custom packaged Distribution such as OpenAtrium or your own awesome forked version of Drupal that has no bugs (right?).

I'll be assuming you have got Aegir already installed but haven't set up any platforms. Let's add some platforms now from the command line, using a Drush Makefile.

Become the aegir user if you haven't already: su -s /bin/bash aegir

Create a directory called 'makefiles'

mkdir ~/makefiles

Create a file in this directory called 'drupal-6.22.make' that contains this:


 
api = 2

core = 6.x
projects[drupal][type] = "core"
projects[drupal][download][type] = "get"
projects[drupal][download][url] = "http://ftp.drupal.org/files/projects/drupal-6.22.tar.gz"

Make another makefile for Drupal 7 called 'drupal-7.9.make':


 
api = 2

core = 7.x
projects[drupal][type] = "core"
projects[drupal][download][type] = "get"
projects[drupal][download][url] = "http://ftp.drupal.org/files/projects/drupal-7.9.tar.gz"

Step 2: Generate Drush Aliases for your platforms

The next thing we can do is generate a Drush alias that defines each platform. To do that, you use the Drush (Provision) command 'provision-save', with appropriate arguments likeso:

drush --root='/var/aegir/platforms/drupal-6.22' provision-save '@platform_drupal622' --context_type='platform' --makefile='/var/aegir/makefiles/drupal-6.22.make'

Now you should see a new file in /var/aegir/.drush/ called platform_drupal622.alias.drushrc.php. It should look like this:

$aliases['platform_drupal622'] = array (
  'context_type' => 'platform',
  'server' => '@server_master',
  'web_server' => '@server_master',
  'root' => '/var/aegir/platforms/drupal-6.22',
  'makefile' => '/var/aegir/makefiles/drupal-6.22.make',
);

Repeat the procedure to save an alias for your Drupal 7.9 platform.

drush --root='/var/aegir/platforms/drupal-7.9' provision-save '@platform_drupal79' --context_type='platform' --makefile='/var/aegir/makefiles/drupal-7.9.make'

Step 3: Verify (and build) your platforms

Now, obviously this has not built the platform - we haven't executed Drush make or ended up with actual codebases on our filesystem yet. But because we made makefiles and referenced them in our Drush aliases, Aegir is smart enough to go right ahead and build the platforms for us when we Verify these platforms.

drush @platform_drupal622 provision-verify

Because this invokes Drush Make as the codebase doesn't exist, you should see something like


 
drupal downloaded from http://ftp.drupal.org/files/projects/drupal-6.22.tar.gz.      [ok]

Rinse and repeat for Drupal 7!

drush @platform_drupal79 provision-verify

Step 4: (Optional) - Import the changes into the Hostmaster frontend

You have a choice now: if you *do* expect that you want to use the frontend web interface to manage this platform and sites on it, in future, then you probably want to import this new platform into the Aegir frontend. It's important to remember that so far, we have operated entirely from the command line: if you visit your Aegir web interface, no Drupal 6 or Drupal 7 platforms exist there yet.

If you ever want to install or manage sites on these platforms from the web interface, you will need to import this platform into Aegir. Fortunately, Aegir provides a magic command that lets you 'refresh' the frontend with information gleaned from the backend. This includes importing new platforms and sites as nodes, if the Drush alias exists for those objects.

drush @hostmaster hosting-import @platform_drupal622

There'll be no output here. If you watch your Aegir frontend, you'll see a new 'Verify drupal622' task added to the queue, and your Platform node will now exist too. Magic!

As always: if you're doing this, repeat with the Drupal 7 platform:

drush @hostmaster hosting-import @platform_drupal79

Step 5: Save a Drush alias for a new site

We have our platforms now, but no sites. Let's repeat the pattern of this process but for a site. Because a site is an object in Aegir, just like a Platform, we need to define a Drush alias for it before we can do anything clever with it.

drush provision-save '@test.example.com' --context_type='site' --uri='test.example.com' --platform='@platform_drupal622' --server='@server_master' --db_server='@server_localhost' --profile='default' --client_name='admin'

Note these options: we define the *type* of alias as a site (as opposed to a platform). We also link this site to the Drupal 6.22 platform using its alias name. We then go ahead and define the 'server' (this is the HTTP component, by default '@server_master' on a standalone Aegir system), the db_server (the MySQL component, which by default is '@server_localhost' on a standalone Aegir system), the install profile and so on.

Your Drush alias in /var/aegir/.drush/ should look something like this:

$aliases['test.example.com'] = array (
  'context_type' => 'site',
  'platform' => '@platform_drupal622',
  'server' => '@server_master',
  'db_server' => '@server_localhost',
  'uri' => 'test.example.com',
  'root' => '/var/aegir/platforms/drupal-6.22',
  'site_path' => '/var/aegir/platforms/drupal-6.22/sites/test.example.com',
  'site_enabled' => true,
  'language' => 'en',
  'client_name' => 'admin',
  'aliases' => 
  array (
  ),
  'redirection' => false,
  'cron_key' => '',
  'profile' => 'default',
);

Note the various other options for saving Drush aliases in Aegir. You can see all options by running 'drush help provision-save' too.

Step 6: Install your site

In just the same fashion that we saved an alias for our platform, then ran 'provision-verify' to build it, we'll do the same with our site; except that we use 'provision-install' for sites.

drush @test.example.com provision-install

Step 7: (Optional) - import your site in to the frontend

Again, if you elected to maintain management of the site and platforms in the Aegir frontend for later, you will want to import this site into the frontend now.

Importing the site is a bit different: Aegir will think it needs to 'install' the site even though we've already installed it. To work around this, simply execute a 'Verify' of the platform this site sits on, via the frontend. This will invoke a proper import of the site. (This probably needs to be improved in a future version of Aegir itself so we don't have to jump through such a hoop)

drush @hostmaster hosting-task @platform_drupal622 verify

This will automatically discover the site and spawn an 'Import' task for the frontend to import this site.

Step 8: Migrate (upgrade) your site between Drupal 6 to Drupal 7

I'm going to presume you've saved your Drupal 7 alias, ran provision-verify to build the actual codebase, and optionally imported that platform into the frontend with hosting-import.

Now let's migrate our site from the command-line, from the Drupal 6 to Drupal 7 platform. This is analogous to 'upgrading' the site between releases, because the migration process in Aegir puts the site on the new codebase and then runs drush updatedb (equivalent of running update.php) to apply database updates.

drush @test.example.com provision-migrate @platform_drupal79

Because this example is a rather dramatic one (a jump between core versions!) you'll see a lot of activity eventually occur, whilst a lot of database updates take place. You can, obviously, use this procedure simply to apply small module upgrades within the one version of Drupal core.

It is highly recommended, in fact, to use this 'migrate between platforms' workflow for applying *any* code/database changes to your site, because you can take advantage of the Aegir ability to detect a failed update and 'roll back' automatically to the original version. See otherarticles on best practices for Aegir site update workflows.

Your site is now a Drupal 7 site!

Step 9: (Optional) - refresh the frontend with the migration change

Once again: the frontend doesn't know that you migrated the site between the two platforms directly from the commandline. If you want the frontend to be notified of this change, run the following:

drush @hostmaster hosting-import @test.example.com

You'll note that the site's 'platform' in the frontend is now drupal79 instead of drupal622.

Step 10: Fix the site's alias to use default profile

Now, we incidentally have an obscure bug here which resets the profile to 'N/A' in the frontend: this is because the migration retained the 'default' profile in the alias instead of switching it to 'standard', the new default profile in Drupal 7. To fix this, we need to re-save the Drush alias with the updated details:

drush provision-save '@test.example.com' --context_type='site' --uri='test.example.com' --platform='@platform_drupal79' --server='@server_master' --db_server='@server_localhost' --profile='standard' --client_name='admin'

Now re-verify the site (updates the defined profile in the site's settings.php:

drush @test.example.com provision-verify

And if you are keeping the frontend up to date, run:

drush @hostmaster hosting-task @test.example.com verify

... and you should see the profile is now 'Standard' in the site listing in the frontend.

This should not be necessary if you are simply migrating between point releases within the same version of core, or even migrating between the same version of core but applying upgrades of specific contrib or custom modules.

Deleting sites

Note that you can run drush @test.example.com provision-delete to delete the site from the system. Currently, however, we don't have a mechanism in place for reflecting that change in the frontend via hosting-import - but hopefully we will soon. See this ticket

Programatically add aliases

This is an edit 24 hours after I posted this: someone on IRC asked 'can you programatically add URL aliases to a site'? And the answer is, yes you can :)

Make sure you have the Site Aliasing feature enabled in /admin/hosting/features, then, (in this example, assuming your site already existed and was in the Aegir frontend) simply re-save your Drush alias for the site, passing a comma-delimited list of aliases as an argument:


 
drush provision-save '@mig3.test.dev' --context_type='site' --uri='mig3.test.dev' --platform='@platform_drupal622' --server='@server_master' --db_server='@server_localhost' --profile='default' --client_name='admin' --aliases='www.mig3.test.dev, test.dev'

Check your alias file in ~/.drush/ and you should see an array of aliases listed now:


 
$aliases['mig3.test.dev'] = array (
  'context_type' => 'site',
 (snip for readability)
  'aliases' =>
  array (
    0 => 'www.mig3.test.dev',
    1 => ' test.dev',
  ),

Now run

drush @mig3.test.dev provision-verify

, which will rewrite your Apache vhost to include these aliases as ServerAlias parameters and will restart Apache to make those aliases active.

Finally: your site node in the frontend still doesn't show any aliases, as discussed several times in this post. To refresh the frontend and see those aliases listed, run the magic hosting-import command:

drush @hostmaster hosting-import @mig3.test.dev

And now your aliases will be visible in the site node!

Other commands

There are other commands available in Provision, including the ability to reset the one-time login URL for an administrator on a site, cloning sites, and so on. Use 'drush help' as the aegir user to view the various provision commands, and use 'drush help provision-(command)' to get more detailed instructions on syntax.

Remote servers (multiserver)

Aegir supports multiple 'server' entities. These servers have 'services' such as 'Web' or 'Database', and 'service types' which are implementations of that service, such as 'Apache' or 'MySQL'.

Some previous experience in the configuration of Apache and MySQL will help if you want to use remote servers with Aegir. If you haven't had any experience in setting up and maintaining Apache or MySQL before you might want get familiar with the basic concepts first.

Table of Contents [hide]

 

  1. 1.Remote web servers
    1. 1.1.System dependencies
    2. 1.2.Aegir user
    3. 1.3.Web server configuration
    4. 1.4.Sudoers
    5. 1.5.Login shell
    6. 1.6.MySQL access
    7. 1.7.SSH keys
    8. 1.8.Verify the server

1. Remote web servers

1.1. System dependencies

On the remote server, install these packages

 

  apt-get install rsync apache2 php5 php5-cli php5-mysql postfix mysql-client sudo

 

1.2. Aegir user

Any number of remote web servers may be configured. The remote server needs an aegir user created on the system.

 

adduser --system --group --home /var/aegir aegir
adduser aegir www-data    #make aegir a user of group www-data

 

1.3. Web server configuration

You'll also need to prepare the web server in the same way you did for the master Aegir server during installation:

 

a2enmod rewrite
ln -s /var/aegir/config/apache.conf /etc/apache2/conf.d/aegir.conf

 

Don't restart Apache even when it prompts you. This will be done by the Verify task you'll spawn for the server from the Aegir frontend later.

1.4. Sudoers

Add the aegir user to sudoers so it can restart Apache.

 

  aegir ALL=NOPASSWD: /usr/sbin/apache2ctl

 

1.5. Login shell

The remote aegir user will also need a login shell, which can be modified using the chsh command.

 

  chsh -s /bin/sh aegir

 

1.6. MySQL access

Aegir connects directly to the remote server's MySQL to create databases and users. Therefore, you need to log into MySQL in the remote server as root and create a user with the following command:

GRANT ALL PRIVILEGES ON *.* TO root@aegir_server_IP IDENTIFIED BY 'some_pass' WITH GRANT OPTION;
FLUSH PRIVILEGES;

 

Note the comment about "bind-address = 127.0.0.1" on http://community.aegirproject.org/installing/manual#Database_configuration

When the server is being verified, Aegir will attempt to create a database and grant privileges to a user for that database. If any of these two fails, verify that your MySQL configuration is correct and that there is no firewall blocking your MySQL port.

You can confirm that MySQL is configured correctly on the remote server by manually connecting from the command line on your Aegir machine:

 

[aegir@aegir_box:~]$ mysql -h <mysql_server_IP> -u root -p

 

If your MySql database is running on the same server as the Aegir master and is configured with the name "localhost", you may run an issue where the remote web server tries to access MySql via a local socket rather than the hostname. To resolve this, just change the server hostname for the MySql server in Aegir from "localhost" to the hostname of the server.

1.7. SSH keys

SSH public/private keys should be set up so the main Aegir server's aegir user can access remote web aegir users with no passwords required.

Example: on main Aegir server:

 

ssh-keygen -t rsa
(follow prompts)

 

Do not use a passphrase when you create your key. Simply press Enter to leave the passphrase blank. Otherwise, SSH will insist that you enter the passphrase everytime you try to SSH using the key. We don't want SSH to present any prompts.

Put the public key's contents into /var/aegir/.ssh/authorized_keys on the remote web server. The easiest way to do this is to use the ssh-copy-id command.

You should manually login for the first time from your Aegir master server to your remote server as the aegir user, so that the remote web server is added to the known_hosts file in /var/aegir/.ssh on your Aegir master server. Verifying the remote webserver will fail until this has been done.

You can confirm that SSH is set up correctly by manually connecting from your aegirmaster server to your remote server as aegir@ user to aegir@ user:

[aegir@aegirmaster:~]$ ssh aegir@<remoteserver>
This should directly log you into the remote shell command line without any additional keys pressed.
[...]
[aegir@<remoteserver>:~]$

 

There are many, many tutorials online for setting up ssh keys, and various mistakes can be made by inexperienced users such as permissions etc. Aegir isn't a 'Linux beginner's practice tool', so setting these up is really out of the scope of this document and users are encouraged to research this on their own. (For Ubuntu, see this article).

If you have followed the instructions above, and your SSH connection gets closed immediately after you try to connect to the remote server as the aegir user, you may not have given the aegir user a shell correctly. Check the /etc/passwd file on the remote server to make sure that the aegir user has a shell.

1.8. Verify the server

Now you can add a new server node in Aegir, set the hostname and/or IP and set the service type to be 'Apache' (or Apache_SSL if this site is to handle SSL sites).

A verify task will be spawned and added to the Task queue ready for dispatching. During a server verification task, various configurations will be set on the Aegir master server and also synced to the remote web server, restarting Apache.

Now when you add a new Platform node in Aegir, you have the option of setting which web server to host it on. If you are not using a makefile but are downloading a platform manually, you must still do this on the main Aegir server. The contents will then be synced across to the web server.

You don't choose a web server when installing a new site. Because a site depends on a platform, its web server is implied by which platform has been chosen. In other words, all sites on a platform are hosted on the same server. You cannot host two sites on the same platform on different servers.

Платные услуги

Я готов предложить Вам следующие услуги:

Создание сайтов (от 10 000 руб.)

Создание блогов (от 10 000 руб.)

Создание интернет-магазинов (от 30 000 руб.)

Создание досок объявлений (от 10 000 руб.)

Разработка скриптов под ваши нужды (от 1000 руб.)

Удаление вирусов с сайта (от 1000 руб.)

Работаю я в основном со следующими движками: Drupal Joomla WordPress

Если у Вас есть, какая то другая задача, обращайтесь, возможно, я смогу Вам помочь с её реализацией.

Со мной можно связаться следующим образом:

E-mail: pac.am@ya.ru

Разворачиваем Aegir - свой Drupal хостинг с панелью

Разворачиваем Aegir - свой Drupal хостинг с панелью

Pages

Subscribe to Front page feed
Яндекс.Метрика