Custom platform will not verify

[startinggravity]

Boa info more found here.

I have created a number of fresh installations, first on Linode and then on Digital Ocean. I've attempted to follow every step of the installation process to the letter, but in all cases after a successful installation I have been unable to create and get a new platform to verify.

The verify process fails at this point:

Calling hook drush_provision_drupal_pre_provision_verify We could not find an applicable site for that command. Drush could not bootstrap this platform. Please check the platform directory exists and is readable.

The process I followed is the same as what I have successfully used for years, which is to git clone a repo into the /static directory, then chmod the directories, as described here.

I've run out of ideas of what's causing this. Any suggestions?

[omega8cc]

What is the exact path to the platform, as displayed in Aegir?

Please make sure that the path you have entered is relative and not absolute. This has changed in Aegir 3.x, and while it still shows the base path for custom platforms, it now expects that you will enter only the relative path -- the part after /data/disk/o1/static/

[startinggravity]

I confirmed the platform path is /data/disk/o1/static/.

[EdNett]

I have a fresh install on ovh vps1 on jessie that will not allow new static platform creation, giving the following error: Platform needs to be associated with a webserver. Make sure you have a verified webserver on this Aegir install!

The webserver is verified (nginx_ssl)

boa info more here: https://gist.github.com/EdNett/e0359b75ba05c3d3cd03ab45da430d8c

[omega8cc]

@startinggravity The platform path can't end with /static/ ...

[startinggravity]

I'm sorry. I wasn't clear and didn't mean to say the entire path ended in /static/. I only meant that /data/disk/o1/static was included in the full path.

The full path is /data/disk/o1/static/startinggravity_2016-05-31_D7-43.

[EdNett]

I did another up-stable of both barracuda and octopus (with the only difference removing FMG from the extras list - it was failing anyways) and now I am able to create a static platform and have it verify (by using a makefile). However after one static platform creation, I cannot create another. I receive the same error message as before. This problem still exists for me.

[omega8cc]

Not sure if both reports are related, but we should try to reproduce this, I guess.

[omega8cc]

@startinggravity What is the Drupal core version in use in your custom platforms?

[omega8cc]

@EdNett Can you try to reproduce this after touching this control file?

~/static/control/clear-drush-cache.info

[EdNett]

I touched that control file and the problem still exists. My custom platform is 8.1.2.

[EdNett]

This issue may be related: https://github.com/omega8cc/boa/issues/976

Also, this is a vps from ovh. Is there a test to determine if this type of vps is supported? Thank you. I am testing this on a more modern vps.

[EdNett]

Perhaps also of importance is the fact that I enabled LE ssl for the hostmaster site - and I did it the right way, by removing the control file, NOT by enabling it in the Octopus GUI.

[startinggravity]

I was attempting to build a D7 platform. I have intended to add a D8 platform, but wanted to make sure all was well on D7 first. If you think that I might find different results I can give a try with D8.

I have some other details that are probably not significant, but I will provide them in case I assume that incorrectly.

1. I mentioned that I tried to create new Barracuda/Octopus instances on both Linode and Digital Ocean with the same results. I was initially having problems with the CLI timing out, which had never happened to me when I had built instances before BOA 3.x. Eventually I realized I needed to recapture the screen and not just wait for the emails so that I could answer some questions. This resolved some of my problems, but not the problem of verifying platforms.
2. In one of my attempts to get a working platform I used the Drush makefile method. This is not my preferred workflow, but I was able to get it to work on my first attempt, but failed on a second. This matches @EdNett's results. I did not know at the time that when a makefile is reused the .tmp file has to be cleared. I figured that out later, but I have not attempted since then to create a platform with a makefile.
3. Just to be clear, each time I attempted to created a new instance of BOA I started from a completely fresh VM on Linode or DO. I wanted to be sure I wasn't carrying over mistakes from a previous build.
4. I have not made any changes to enable SSL. Again, I wanted to get an instance and platforms working properly with a clean installation first before making adjustments like that.

[EdNett]

I no longer have this issue now.

I had added i18n, l10n_update and variable contrib modules to /data/disk/o1/aegir/distro/002/profiles/hostmaster/modules/contrib

and I did chown and chmod them recursively. However, I find that after disabling them, I am able to add platforms and sites, including 8.1.2. I apologize for wasting anyone's time, and I wonder if it was just one submodule of i18n, for example that might have caused this?

[omega8cc]

@startinggravity -- We have tried to reproduce the problem, and we couldn't. It just works with all distros we have tried as custom platforms in static:

opigno_lms-7.x-1.22 openatrium-7.x-2.63 panopoly-7.x-1.35 commerce_kickstart-7.x-2.37 drupal-8.1.2 restaurant-7.x-1.11

There must be something in the codebase you are trying to use, which is not compatible with either Drush 8, PHP version used, or both.

[omega8cc]

Here is a proof:

[omega8cc]

And here with opigno_lms site installed:

[startinggravity]

I cloned D7.43 directly from d.o. into static and followed standard permission changes. This time I was able to set up a platform with no problem at all, so yes, it does seem like there is something odd about my other sites.

The repos I tested initially had been used on another installation of BOA. I'm not quite sure what is going on and will have to investigate this. At any rate, my test tonight repeats the results of your tests.

Following my successful installation, however, I attempted to delete the platform. No sites had been created with it, but the attempt to delete it failed.

Calling hook drush_provision_drupal_provision_delete.
-
Deleting /data/disk/o1/static/drupal-7-43/profiles/standard/standard.profile file failed.
-
Deleting /data/disk/o1/static/drupal-7-43/profiles/standard/translations/README.txt file failed.
-
Deleting /data/disk/o1/static/drupal-7-43/profiles/standard/translations directory failed.

... etc., etc.

As before, the fail responses come right after a call to Drush. Any thoughts on this?

[omega8cc]

I can't reproduce this, either:

Can you check permissions and ownership on your custom platform before trying to delete it? Everything should be group writable, but the server will set correct permissions for you only once you upload the codebase via SFTP or FTPS.

It is explained at: https://omega8.cc/are-there-any-specific-good-habits-to-learn-116

If you download the codebase on command line (with wget, curl, drush make, git etc.) then you must chmod entire platform codebase to make it group writable, or otherwise Aegir system user will not be able to write/delete everything properly -- unless you will wait for the daily maintenance and you have _PERMISSIONS_FIX=YES

Example:

find static/platform/foo -type d -exec chmod 0775 {} \; find static/platform/foo -type f -exec chmod 0664 {} \;

[omega8cc]

Note: the find command is not available in limited shell. You need to run it as root or system user. Otherwise just chmod -R 775 static/platform/foo

[startinggravity]

I think I found the problem, or at least part of the problem. Previously, the documentation said:

Now, the only thing you should remember about (but only when you run drush make on command line) is to set group writable permissions for platform’s root directory, plus its sites and core modules subdirectories with commands: 'chmod 775 ~/static/foo-bar' plus 'chmod -R 775 ~/static/foo-bar/sites' and 'chmod 775 ~/static/foo-bar/modules'.

It now says:

Now, the only thing you should remember about (but only when you run drush make on command line or you have downloaded your platform codebase with wget, curl or git) is to set group writable permissions: 'chmod -R 775 ~/static/foo-bar'.

I'm not sure when that was changed, but I have always followed the previous instructions.

[omega8cc]

@startinggravity -- we have updated this today, after realizing that these permissions are not sufficient if you have created a codebase with some other method than SFTP/FTPS upload. The only remaining question is why it somehow worked for you in the past. You should always experience the same problem with codebase created via wget, curl, drush make or git download on command line.