Fatal error: Class 'Provision_Service_http_https' not found in /var/aegir/hostmaster-7.x-3.144/sites/myaegir.com/modules/hosting_https/submodules/apache_https/drush/Provision/Service/http/https/apache.php on line 11

doing a grep I found:

drush/Provision/Service/http/https.php:13:class Provision_Service_http_https extends Provision_Service_http_public {
submodules/nginx_https/drush/Provision/Service/http/https/nginx.php:11:class Provision_Service_http_https_nginx extends Provision_Service_http_https {
submodules/apache_https/drush/Provision/Service/http/https/apache.php:11:class Provision_Service_http_https_apache extends Provision_Service_http_https {

I use these instructions to install drush.phar, https://github.com/drush-ops/drush-launcher

Is drush.phar not able to pick up the contents of the drush directory in hosting_https?

Comments

SocialNicheGuru created an issue. See original summary.

socialnicheguru’s picture

Status: Active » Closed (works as designed)

This was a misconfiguration of drush.

I used composer require drush/drush 8.x in the aegir directory and the sites/aegir directory.

Milestech’s picture

I'm getting this same error, except I have limited ability to figure out what is going wrong on my own. And I don't really understand the comment/solution above.

For context: Today I upgraded aegir from 3.10 to 3.14 via debian package update/upgrade, that seemingly went ok, I did have to apply a patch to pause the task queue, as the upgrade was getting stuck halfway. Once I did that it finished ok. Site status all looked good at that point, new host verified.

Then I noticed the changes mentioned in the release notes for 3.14 about switching LE HTTPS to the new 'in core' version (I had some sites using LE). I was about to finish that process (I think) when I noticed the server wasn't verifying, in fact any verification tasks I started stalled. I next noticed that drush was letting me know the above error. I presume that is preventing anything else from happening.

As I said, I'm operating at the limit of my aegir/drush/drupal/linux abilities here. I might be missing something obvious to most people hanging around these pages. Thanks.

fenstrat’s picture

@Milestech sounds like you could have an old version of https://www.drupal.org/project/hosting_https floating around (you indicated you used LE before). It's likely in sites/all or sites/your-aegir-site.com. If it's there remove it and make sure only the one that comes with Aegir core from 3.14 (it'll probably be in /var/aegir/hostmaster-7.x-3.144/profiles/hostmaster/modules/aegir/hosting_https).

Milestech’s picture

Thanks, I did find the other old folder and got rid of it for good measure. However, I now notice the error message I get running the drush command in the console "drush @hostmaster hosting-task 1630 --debug" already references the new folder. Hence, the issue is still there.

I'm attempting to better understand

I used composer require drush/drush 8.x in the aegir directory and the sites/aegir directory.

I'm new to composer and not particularly flash with drush, but I can see potential that my old drush install needs to be brought into line with composer? Can someone let me know if that suggestion can literally be turned into
...:~/folder$ composer require drush/drush 8.x in each of the folders mentioned?

(sorry if a closed issue is not ideal for this, but the error message is the same and I figure it might help another lost sheep like me!)

fenstrat’s picture

@Milestech I don't think there's any need to manually composer require drush because that should be done as part of the aegir update. which drush should show /usr/local/bin/drush as drush should be installed globally. Try checking the version of drush you're using drush --version, it should be at the latest 8.x stable, currently 8.1.16. If it's different you may need to look at why it's got out of sync.

Then try clearing drush caches with drush cc drush, and then try the firing off the task again.

Milestech’s picture

@fenstrat As you suggested, I checked those things and yes it is all exactly as you said. So, I cleared the caches, and still no luck??

Using the aegir front end, a verify task sits there in grey and not starting as far as I can tell. Using the command line, drush first shows the error below.

PHP Fatal error: Class 'Provision_Service_http_https' not found in /var/aegir/hostmaster-7.x-3.144/profiles/hostmaster/modules/aegir/hosting_https/submodules/apache_https/drush/Provision/Service/http/https/apache.php on line 11

I am wondering if I may have not correctly turned off the server https settings (ie on the 'web' tab). It occurs to me if the verify task never ran that first time, much of what I did afterwards was done on top of an error I missed? Is there some way I manually reset some of these settings, or attack the error head on and just solve that specifically, some manual way?

There is also the question of the patch I applied from here during the update - https://www.drupal.org/project/hostmaster/issues/2773223 I have assumed that module was replaced during the update, and fairly harmless otherwise. But maybe I'm wrong?

fenstrat’s picture

@Milestech yeah so it looks like no tasks will start because of that PHP fatal. Probably try rolling back the patch from #2773223: Aegir Upgrade Stuck After Platforms Path Is Writable as your upgrade seems to have gone through ok, it's just now getting stuck on this fatal.

Odd that you have https/apache.php in that folder, looks like it should just be https.php https://cgit.drupalcode.org/hosting_https/tree/drush/Provision/Service/h... - something could be wrong with your local version of hostng_https? Odd. Perhaps try manually verifying your local copy?

Milestech’s picture

@fenstrat I went through that tree you linked to and you're looking in a different part of the tree to where my error message is coming from.
The difference is that the error is coming from the apache_https submodule. Which does have that file there.
https://cgit.drupalcode.org/hosting_https/tree/submodules/apache_https/drush/Provision/Service/http/https

Is this an issue still or is this confusion part of the problem I'm having?

fenstrat’s picture

@Milestech and I took this debugging offline and finally got to the bottom of it. Turns out it was due to a seriously old version of composer (1.0.0beta3 I think, that comes with ubuntu 16.04). Looks like that effected the autoloader which meant Provision_Service_http_https could not be found. So updating composer fixed this.

Milestech’s picture

Yep, thanks @fenstrat! There was much effort and methodical detective work by you (with me throwing around wild thoughts on a solution) to figure this out. For what it's worth there was also that drush alias file which we had to work on (a red herring maybe), overall getting composer up to date was when everything started behaving in a far more predictable way.