I believe the issue(s) I've reported in the past may boil down to this: the core version being displayed on the core entity itself never updates, even when the core version in the domain entities on that same core do.

Two domains (default and a multisite) on one core.

Domains as reported on their individual DRD pages:

Domain 1:
Drupal 8.6.15
Installation profile Minimal (minimal-8.6.15)

Domain 2:
Drupal 8.6.15
Installation profile Custom (custom-8.x-1.7.1)

Core as reported on its DRD page:

Drupal version
8.6.1

I have a custom view that lists all our sites, and I've been relying on the core's Drupal version to display there. I think I can work around it by displaying the domain's version, instead, but it does seem like the core version should be matching the domains.

Comments

wrd created an issue. See original summary.

jurgenhaas’s picture

jurgenhaas
he/him
Primary language German
Location Gottmadingen
CreditAttribution: jurgenhaas at LakeDrops, PARAGON Executive Services GmbH commented

This is strange. I remember that had been a bug w while ago which got fixed and I just checked by installations and it does work there as expected, i.e. when the domains get recognized with new core versions, then their core records gets updated too.

So I'm not sure what we could do about this right now. Are you calling the drd action to receive used project versions from remote domains regularely?

wrd’s picture

wrd CreditAttribution: wrd as a volunteer commented

I may have (yet another) misunderstanding of how this is meant to work -- cron jobs are being run every hour (and aren't throwing any errors), but I haven't set up anything specific to DRD.

Interesting thing, though -- several minutes after manually executing that action, the core versions updated. So it's clearly working, it's just not happening when I expect it to, and not without intervention. Perhaps I simply need to set up some additional cron jobs specifically to execute these updates.

jurgenhaas’s picture

jurgenhaas
he/him
Primary language German
Location Gottmadingen
CreditAttribution: jurgenhaas at LakeDrops, PARAGON Executive Services GmbH commented

You may want to have a look into the "Best practice" section in the documentaion of DRD. There is one page which describes the recommended cron job on your OS: https://www.drupal.org/docs/8/modules/drupal-remote-dashboard/best-pract...

wrd’s picture

wrd CreditAttribution: wrd as a volunteer commented

Thank you! I remember now why I wasn't using those -- when I attempt to execute DRD commands through drush or drupal console, they fail, like so:

- on id 135: Test site

[WARNING] drd_action_ping [drd_domain/135]: Remote instance does not support DRD. Test site
[ERROR] failure!
Completed!

Running them through the web interface works, however. I decided to disable the cron jobs and return to that issue later, and then completely forgot about it.

So I assume there's a firewall rule blocking https requests when I execute them from the command line, but isn't blocking them when they're executed by apache.

jurgenhaas’s picture

jurgenhaas
he/him
Primary language German
Location Gottmadingen
CreditAttribution: jurgenhaas at LakeDrops, PARAGON Executive Services GmbH commented

That's hard to believe because both the UI and the console are both using PHP to execute the very same code.

When you run DRD from the console, is the ping failing for all domains or just for some?

wrd’s picture

wrd CreditAttribution: wrd as a volunteer commented

Well, now I'm completely confused. But you're right, it has nothing to do with CLI vs Web UI. I've getting "Remote instance does not support DRD" on nearly every action now, both in the web UI and the CLI. However, yesterday I successfully got it to list the correct version of Drupal for every core, so clearly *something* is working. And one command *does* work on the CLI:

bash-4.2$ drupal drd:projects:status
Executing Check status for all projects

[OK] ok!

Completed!

I wonder if the self-signed certificate the state network uses could be interfering. I'm not sure why it would *sometimes* succeed (e.g., I can paste in the access token and successfully connect a domain)...

jurgenhaas’s picture

jurgenhaas
he/him
Primary language German
Location Gottmadingen
CreditAttribution: jurgenhaas at LakeDrops, PARAGON Executive Services GmbH commented

Well, the action drd:projects:status is not talking to any of your remote sites. Instead it's talking to drupal.org to grab available releases for each of your used projects.

For the issues with talking to your remote sites, it is strange but as we know, when not changing anything, the tool would always do the same thing. So, the task is to find out what has changed. Or you go ahead and debug just a single instance where a action can not be performed and try to find out what's going on, e.g. by calling the action on the command line in debug mode.

wrd’s picture

wrd CreditAttribution: wrd as a volunteer commented

I'm sorry to let this languish for so long. I have a theory, and I want to bounce it off you to see if it sounds sane, which would hopefully give my request to our datacenter team a bit more weight.

Over the past few days, I've managed to get them to resolve some firewall issues that were preventing my DRD site from communicating with my other sites. I can now run commands and get responses -- but some of them fail, with the message that the remote site does not support DRD.

Thinking this might have something to do with a version mismatch on the agent library (a random shot in the dark, really), I thought I'd try pushing the latest library out to the other sites. First I tried building, and I got a failure:

bash-4.2$ drush drd:library:build

Executing Build the library
===========================

In LibraryBuild.php line 28:

creating archive "/site/httpdocs/sites/default/files/drd-1.7.0.phar" disabl
ed by the php.ini setting phar.readonly

I've put in a request to have that php.ini setting changed. What I'm wondering is this: does DRD perform a routine check on the agent library when performing certain commands? And to do this, does it need to build the library and compare its build against the version the agent is using?

If so, is it possible that having this process fail, because PHP is configured to prevent writing .phar files, would be reported as the remote site not supporting DRD?

wrd’s picture

wrd CreditAttribution: wrd as a volunteer commented

OK, further progress.

First: yes, changing that php.ini setting eliminated the above error, which brings me to the new error, which strikes me as really, really strange:

bash-4.2$ drush drd:library:build

Executing Build the library
===========================

In PharExtensionInterceptor.php line 38:

Unexpected file extension in "phar:///site/httpdocs/sites/default/files/drd
-1.7.0.phar/"

I'm not sure where that trailing slash is coming from, or whether that's the "unexpected file extension" to which the error refers. Any idea what could be going on there?

jurgenhaas’s picture

jurgenhaas
he/him
Primary language German
Location Gottmadingen
CreditAttribution: jurgenhaas at LakeDrops, PARAGON Executive Services GmbH commented

Building the phar file is not intended for production use, it's for the development environment really. And it's not required either. DRD sends the required phar version with every single request to the remote site. If that version is not available there, the remote site will automatically download that exact version from drupal.org

So, we need to find out why the remote site doesn't seem to support DRD (yet). The best way to do that:

  • Turn on debug mode on the remote site
  • Turn on debug mode on the DRD master site
  • Execute the failing DRD command with drush by also using the argument --debug

Then we need to know exactly the output at the console and in addition also if anything is provided in watchdog for both sites, master and remote.

wrd’s picture

wrd CreditAttribution: wrd as a volunteer commented

Thanks so much for the response. Testing is yielding some strange and inconsistent results...I'm going to take some time and make sure all the codebases are current, delete and re-add them to DRD, and re-test.

wrd’s picture

wrd CreditAttribution: wrd as a volunteer commented

OK, after a lot of work with our systems and network admins, I'm having a lot more success. DRD seems to be communicating with most sites properly. I've run into one exception so far.

I've got a multisite installation with six sites on it. Five of those sites are working as expected with DRD, but the sixth can't be connected; after pasting the access token, the browser returns to the domains list for the core, and the sixth site is still requesting an access token.

I'm finding two errors that look relevant. A PHP error:

Exception: DRD Library not available in _drd_get_lib() (line 75 of /mnt/www/html/moweb3/docroot/sites/all/modules/contrib/drd_agent/drd_agent.module).

...and a Watchdog error:

DRD Remote
Date October 21, 2019 at 5:21 pm
User Anonymous (not verified)
Location https://foo.bar.gov/drd-agent
Referrer
Message Can not read input
Severity error

The latter seems like a consequence of the former, but that's just a guess. What strikes me as more peculiar is that this "DRD Library not available" error would be affecting only one site out of six. They're all using the same copy of the module. I saw this error on another codebase, but it was affecting all sites on that codebase; I found that it was running an older version of DRD Agent. Updating the agent module fixed the problem for all sites.

Any thoughts as to what might cause this issue?

Thanks!

jurgenhaas’s picture

jurgenhaas
he/him
Primary language German
Location Gottmadingen
CreditAttribution: jurgenhaas at LakeDrops, PARAGON Executive Services GmbH commented

The first error is caused by this:

    $response = drupal_http_request(DRD_AGENT_LIB_BASE_URI . $archive);
    if (empty($response->code) || $response->code != 200) {
      throw new Exception('DRD Library not available');
    }

So, either this site can not do external http requests (which can sometimes happen if too many other http requests have happened before) or the response is something different from 200.

The second error usually happens when DRD gets to the remote agent behind a redirect, because then the POST values get lost.

In such cases, the command drush drd:ping --domain-id=# --debug will provide a lot of useful information (replace the # symbol with the ID of the domain in DRD).

wrd’s picture

wrd CreditAttribution: wrd as a volunteer commented

Well, I went through a whole bunch of repeated attempts to add the site, I inserted debug code into the function that was throwing that exception, I disabled other modules, and just as I thought I was getting close to some useful information, one of the tests succeeded. Instead of a "Can not read input," I got a bunch of "stat failed for..." warnings, and the site was added to the dashboard. I have no explanation. Thanks again for all the help. My hope is that with the network config changes made by our admins, updates via cron will be successful going forward.

jurgenhaas’s picture

jurgenhaas
he/him
Primary language German
Location Gottmadingen
CreditAttribution: jurgenhaas at LakeDrops, PARAGON Executive Services GmbH commented

Can you not just run that drush command with the --debug option? I know from experience that this console output would help a lot.

wrd’s picture

wrd CreditAttribution: wrd as a volunteer commented

I'm sorry, I meant to include that output, and then deleted it when everything started working. The drush command worked, and returned a successful ping:

! [NOTE] drd_action_ping [drd_domain/54]: Success with response
! {"data":"pong"} null

[OK] ok!

pong

[OK] Completed!

I can paste the full output if you think it'd be helpful, but I was assuming that since it didn't fail, it couldn't tell us anything.

jurgenhaas’s picture

jurgenhaas
he/him
Primary language German
Location Gottmadingen
CreditAttribution: jurgenhaas at LakeDrops, PARAGON Executive Services GmbH commented

Thanks, but didn't you say that there is a site left which doesn't work? It would be interesting to run this on exactly that failing site.

wrd’s picture

wrd CreditAttribution: wrd as a volunteer commented

There were two sites that didn't work -- one of them is the one that started working when I posted #15. The only remaining site is the one that's running the dashboard itself. That one, I can't successfully create the core, so I have no domain ID to ping. I'm 95% sure that's just a network configuration problem, but I haven't had a chance to troubleshoot it with our network people yet.

jurgenhaas’s picture

jurgenhaas
he/him
Primary language German
Location Gottmadingen
CreditAttribution: jurgenhaas at LakeDrops, PARAGON Executive Services GmbH commented
Status: Active » Postponed (maintainer needs more info)
jurgenhaas’s picture

jurgenhaas
he/him
Primary language German
Location Gottmadingen
CreditAttribution: jurgenhaas at LakeDrops, PARAGON Executive Services GmbH commented
Status: Postponed (maintainer needs more info) » Closed (duplicate)

https://gitlab.com/drupalspoons/drd/-/issues/48