Will this method work with Octopus? When I run the commands as an Octopus user (o1, for example), some commands don't run as expected. For example, 'provision-save' creates aliases files without 'root' value. hosting-import doesn't work at all.

However, all works great from the interface. Anything I'm missing here? I really would love to automate the deployment process.

Comments

omega8cc’s picture

omega8cc commented

The system user o1 is exactly the same as Aegir standard aegir system user, so it has full rights to manage Aegir backend. Make sure you are switching to this user correctly (exactly as it is required for aegir user elsewhere):

su -s /bin/bash - o1 - note the dash before o1.

Also, BOA is already based on Provision 6.x-2.x branch, which shouldn't, but may make some difference, so any bug reports are welcome, but we will forward them to the Provision queue probably, as there is nothing BOA specific when you are using it with its system user.

drurian’s picture

drurian commented

su -s /bin/bash - o1 - note the dash before o1.

Already doing that.

I've noticed the context files created with through the aegir front end are different:

$aliases['platform'] = array (
  'context_type' => 'platform',
  'server' => '@server_master',
  'web_server' => '@server_master',
  'root' => '/data/disk/o1/static/platform_name',
  'makefile' => '',
);

While from the command line:

$aliases['platform'] = array (
  'context_type' => 'server',
  'server' => '@server_master',
  'remote_host' => 'localhost',
  'aegir_root' => '/data/disk/o1',
  'script_user' => 'o1',
  'ip_addresses' =>
  array (
  ),
  'backup_path' => '/data/disk/o1/backups',
  'config_path' => '/data/disk/o1/config/platform_fd',
  'include_path' => '/data/disk/o1/config/includes',
  'clients_path' => '/data/disk/o1/clients',
  'master_url' => NULL,
  'admin_email' => 'admin@localhost',
);
omega8cc’s picture

omega8cc commented
Project: Octopus » Provision
Version: » 6.x-2.x-dev
Component: User interface » Drush integration

Drush alias for 'context_type' => 'platform', will be always different than 'context_type' => 'server', but if you feel that there are some anomalies, then I will move this issue over to the Provision queue, as I don't see anything BOA specific here.

drurian’s picture

drurian commented

I must have done something wrong. I've tried again and it's working. The only potential issue is when I run

drush @hostmaster hosting-task @platform_myplatform verify

I get

This task is not queued, use --force

Anonymous’s picture

Anonymous (not verified) commented
Status: Active » Postponed (maintainer needs more info)

We'd need to see how you created the platform context with provision-save (the full command) to see how it could possibly have created it as a server alias. I can't reproduce, but it's not impossible that it's a problem with using provision-save from the commandline under 6.x-2.x

sluc23’s picture

sluc23 commented

Hi,

is this still possible to do it?
Run drush provision commands in BOA? I'm using BOA 2.0.5 and when I try to change user from o1.ftp to o1 I've got:

o1.ftp:~$ su -s /bin/bash - o1
*** unknown command: su
omega8cc’s picture

omega8cc commented

@sluc23 You must be logged in as root and not o1.ftp to be able to switch to o1.

sluc23’s picture

sluc23 commented

hi,

yes must logged in as root, makes sense :)

Once ther I'm getting the same error as #4 while executing

drush @hostmaster hosting-task @platform_myplatform verify
This task is not queued, use --force

Any idea how to execute that provision command?

cheers!

omega8cc’s picture

omega8cc commented
Status: Postponed (maintainer needs more info) » Closed (works as designed)

drush @hostmaster hosting-task @platform_myplatform verify --force