I am unable to verify any site or platform since I updated to BOA-2.0.8. I can verify Barracuda Hostmaster, but that is all.

I have seen a few other issues reported that are similar, but they seem to be focused on custom platforms in /data/disk/USER/static. I am unable to verify any platform, including those installed by Octopus. I am unable to verify sites and platforms that were previously verified when BOA-2.0.5 was running.

Seeing previous references to /var/xdrago/usage.sh I ran that. Here is the result:

aegir:/# /var/xdrago/usage.sh
INFO: Removing old permissions-fix-* files...
find: `/data/disk/*/static/*/*/sites/all/permissions-fix-*': No such file or directory
find: `/data/disk/*/static/*/*/*/sites/all/permissions-fix-*': No such file or directory
INFO: Checking BARRACUDA version...
INFO: Version test result: OK

The update to BOA-2.0.8 was performed more than 24 hours ago, but the results are no different after trying again today.

When attempting to verify platforms installed by Octopus I see these fail messages in the log saying:

The drush command '@ provision-verify' could not be found.
Could not find a Drupal settings.php file at ./sites/default/settings.php.

When attempting to verify platforms I installed in static (and after confirming all permissions are correct), I see these messages in the log saying:

Template loaded: /data/disk/USER/.drush/provision/Provision/Config/provision_drushrc.tpl.php
Could not change permissions of /data/disk/USER/static/twitterfeed_2013-04-22/drushrc.php to 644 (chmod to 644 failed on /data/disk/USER/static/PLATFORM_2013-04-22/drushrc.php)
Generated config Platform Drush configuration file
Could not change permissions of /data/disk/USER/static/PLATFORM_2013-04-22/drushrc.php to 444 (chmod to 444 failed on /data/disk/USER/static/PLATFORM_2013-04-22/drushrc.php)

When attempting to verify a site already running before the update, I see this message in the log:

Could not change permissions of /data/disk/USER/static/PLATFORM_2013-01-07/sites/sites.php to 644 (chmod to 644 failed on /data/disk/USER/static/PLATFORM_2013-01-07/sites/sites.php)

Again, just to be clear, all permissions were checked in the custom platform, with everything set to chmod 774 except the sites/files, which is chmod 777.

Related logs:

#2 boa-verify.png265.06 KBJimSmith
Members fund testing for the Drupal project. Drupal Association Learn more


omega8cc’s picture

Component: Drupal Platforms » Aegir Provision
Status: Active » Postponed (maintainer needs more info)

Permissions on drushrc.php files may be correct but ownership is wrong probably. This never happens unless you are overwriting these files as a USER.ftp user, while these files are expected to be *owned* by Aegir system USER user.

I would suggest to follow these steps:

1. Disable cron with service cron stop and wait 2 minutes.
2. Restart mysql server with service mysql restart
3. Enable Drush debugging _DEBUG_MODE=YES both in /root/.barracuda.cnf and /root/.USER.octopus.cnf
4. Run barracuda up-stable and attach full output.
5. Run octopus up-stable USER aegir and attach full output.
6. Run bash /var/xdrago/usage.sh script.

JimSmith’s picture

Version: 6.x-2.x-dev »
Status: Closed (fixed) » Postponed (maintainer needs more info)
265.06 KB

Thank you for the suggestions.

I'm a little unclear what you are saying about overwriting files using USER.ftp. I create new custom platforms as USER.ftp, but to my knowledge nothing was tampered with in the Octopus platforms as USER.ftp.

At any rate, I followed the suggestions, but continue to have the same problems with verifying.

What I'm noticing is it appears that verify runs successfully once then runs again and fails.


Verbose output:

omega8cc’s picture

It looks like you have simply many duplicate platforms *nodes*, probably because you have run another upgrade before Aegir was able to run initial verify on all freshly added platforms, so it created duplicate nodes which causes confusion now.

Please delete all those duplicate "failed" platforms *nodes* (don't use the Delete task!) and then the real platforms will start working properly, maybe after another re-verify.

As for the error related to permissions, what is the result of this command?

ls -la /data/disk/USER/static/twitterfeed_2013-04-22/drushrc.php

JimSmith’s picture

Again, thank you.

I'm trying to recall exactly what happened. Perhaps I did run another upgrade before all of the platforms had verified. Although I'm generally careful about making sure permissions are set correctly before rolling a new platform, I might have failed that when setting up twitterfeed_2013-04-22. And because I presumed permissions were set correctly, when the new platform failed I must have tried fix it without first checking permissions. Again, I don't recall this specifically, but that scenario makes sense.

Anyway, I have deleted the duplicate nodes.

Here is the result you asked for:

aegir:~# ls -la /data/disk/USER/static/twitterfeed_2013-04-22/drushrc.php
-rwxrwxr-x 1 USER.ftp users 354K 2013-04-24 14:34 /data/disk/USER/static/twitterfeed_2013-04-22/drushrc.php*
omega8cc’s picture

Status: Postponed (maintainer needs more info) » Active

OK, thanks. The /var/xdrago/usage.sh script will fix this, but you can also fix this as root:

chown USER /data/disk/USER/static/twitterfeed_2013-04-22/drushrc.php

Note that it should be chown USER and not chown USER.ftp as it is now. The fact that this file is not owned by your Aegir system user is a sign that you have either run some global ownership changes there or the file was overwritten so now is owned by incorrect user.

JimSmith’s picture

Clearly I fumbled the permissions in that platform, though I'm still uncertain how I did it. Just carelessness, I guess. I've created dozens of custom platforms and never run into that before.

Thank you for helping me sort it out.

omega8cc’s picture

Status: Active » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

niccolox’s picture

I had the same problem on a new omega8cc managed self-hosted precise 209 set-up when verifying a new platform based on openoutreach-1

same fix above worked for me, thanks

niccolox’s picture

Version: » 6.x-2.x-dev

did a fresh install on a staging server from HEAD today and have created two platforms using the 8 easy steps process and am getting same error, chown fix works as above. I to have created dozens of platforms before, so not sure what I am missing

niccolox’s picture

I'll create a new ticket for this, but right now, I think its something to do with the fact that I am building sites from platforms rsync'd from BOA

it looks like the rysync unlinking process is keeping old pathes in the drushrc.php and I guess permissions and other issues

        'toolbar' => 
   15        array (
   16:         'filename' => '/data/all/001/panopoly-7.x-1.0-rc4-7.22.1/modules/toolbar/toolbar.module',
   17          'basename' => 'toolbar.module',
   18          'name' => 'toolbar',

I'd really like to be able to develop a workflow that pulls down a codebase from BOA via rsync and then allows me to upload again either as custom static platforms or as managed platforms

anyway. will start a new ticket in morning

niccolox’s picture

Version: » 6.x-2.x-dev
Status: Postponed (maintainer needs more info) » Closed (fixed)

apologies for not getting back to this, in short, I was rync'ing down files from aegir boa, i.e. above #11 and that was causing the issue. thats from memory...