Contrib.social

Add Drush command to allow running cron updates via console and by a separate user, for defense-in-depth

Open on Drupal.org →
Created on 3 April 2023, about 1 year ago
Updated 16 May 2023, about 1 year ago

Problem/Motivation

@pwolanin raised this here #3284443-19: [PP-1] Enable unattended updates → and @catch also mentioned something similar in ✨ Add Alpha level Experimental Package Manager module Needs review

Basically currently this module requires the file system to be writable by the webserver. Some hosts will not support that.

But if we had a terminal command that could run cron updates then it could be set up to be triggered externally by a more privileged user for example via nix crontab.

Proposed resolution

Terminal command

For the cron merge request this would need to be a standalone script. We would have to determine how hard it would be to bootstrap drupal in a console command. \Drupal\Core\Command\ServerCommand::boot does appear to be doing this but I am not positive

So we should first try to see if this is possible via just a symphony console command.

If that is not possible right now and we would need some Drupal core changes we could add a drush script to the contrib module in the meantime. If we can only do this via drush we should add the functionality in sub-module to avoid adding things to the main module that would have to be removed for the core merge request.

CommandCronUpdater class

We would likely need to extend CronUpdater for this. At the very least we would need to override \Drupal\automatic_updates\CronUpdater::triggerPostApply

Right now at the end of \Drupal\automatic_updates\CronUpdater::performUpdate we have 

// Perform a subrequest to run ::postApply(), which needs to be done in a
    // separate request.
    // @see parent::apply()
    $url = Url::fromRoute('automatic_updates.cron.post_apply', [
      'stage_id' => $stage_id,
      'installed_version' => $installed_version,
      'target_version' => $target_version,
      'key' => $this->state->get('system.cron_key'),
    ]);
    $this->triggerPostApply($url);

It probably would make sense in this issue to change this to
$this->triggerPostApply($stage_id, $installed_version, $target_version);
So we don't assume post apply happens via a http request. Then \Drupal\automatic_updates\CronUpdater::triggerPostApply could handle creating the URL and the new CommandCronUpdater::triggerPostApply would trigger post apply in some other way.

Remaining tasks

  1. As follow-up related to 📌 Research alternatives to curl request on post apply event during cron updates Closed: outdated we could look at we should never use the http request for post apply and see if we could always use the solution we create for CommandCronUpdater::triggerPostApply
  2. 📌 Add new setting for how unattended updates will be run Fixed . This would just be the setting and no UI but it also other side effect so it is it's own issue
  3. Right now we have no UI to enable cron updates but in 📌 Enable unattended updates Fixed we would add this.

User interface changes

We

API changes

Data model changes

📌 Task
Status

Fixed

Version

3.0

Component

Code

Created by

🇺🇸United States tedbow Ithaca, NY, USA

Live updates comments and jobs are added and updated live.
  • Security improvements

    It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

contrib.social Blog FAQ Discussions
Production build 0.69.0 2024