By vhelmont on

Hello,

I have a drupal 10.0.9 site running in a virtual machine under Ubuntu 22.04 to explore drupal.

Recently the “Status report” suggested that I had to upgrade to drupal 10.1.0.

Looking into the 10.1.0 Release notes it suggested that upgrading was as simple as running the following commands:

$ cd To_Document_Root
$ sudo -u www-data composer update "drupal/core-*" --with-all-dependencies

Unfortunately the composer command generated an error that it couldn’t delete the “/var/www/drupal/sites/default/default.services.yml” file and when I went to my drupal site the graphical interface was replaced by a bunch of links.

I reinstalled the drupal 10.0.9 site from backup and started to experiment.

Here is the log describing the upgrade process that resulted in a working drupal 10.1.0 site. <!--break-->

  1. Login to the drupal site as a user with "Administer software updates" permission.
  2. Put the site into maintenance mode.
    Important: Don’t logout because drupal prevents you to login after the execution of the composer command.
  3. Backup files and database
    $ cd /var/www
$ sudo cp -rp /var/www/drupal drupal_backup
  4. Temporary change the “/var/www/drupal/sites/default/” permissions.
    $ cd /var/www/drupal/sites/
$ sudo -u www-data chmod 755 default
  5. Use composer to update your site and all dependencies to the latest version of Drupal:
    $ cd /var/www/drupal
$ sudo -u www-data composer update "drupal/core-*" --with-all-dependencies
  6. Reset the “/var/www/drupal/sites/default/” permissions.
    $ cd /var/www/drupal/sites/
$ sudo -u www-data chmod 555 default
  7. Mix in your customizations.
    $ tkdiff /var/www/drupal/.htaccess /var/www/drupal_backup/.htaccess
$ tkdiff /var/www/drupal/composer.json /var/www/drupal_backup/composer.json
$ tkdiff /var/www/drupal/robots.txt /var/www/drupal_backup/robots.txt
$ tkdiff /var/www/drupal/sites/default/default.settings.php /var/www/drupal_backup/sites/default/default.settings.php
$ tkdiff /var/www/drupal/sites/default/settings.php /var/www/drupal_backup/sites/default/settings.php
$ tkdiff /var/www/drupal/sites/default/settings.php /var/www/drupal/sites/default/default.settings.php
  8. Using the browser and the still logged in user with "Administer software updates" permission, run update.php by visiting:
    https://localhost.localdomain/update.php

    This will update the core database tables.

    - The graphical interface is gone!
- Click the "Continue" link.
- Click the "Apply pending updates" link.
- The graphical interface is restored!
- Click the "Administration pages" link.
- Goto Reports : Status report
- Run the Cron
- No errors should be displayed!

  9. Verify that everything is working as expected.

  10. Switch off Maintenance mode.

Question: Is this a valid upgrade method or is there a more easy one?

Regards,

Albert

⋅ Categories: Drupal 10.x

Comments

gisle’s picture

gisle
he/him
Primary language Norwegian Bokmål
Location Norway
commented

Your original error:

couldn’t delete the “/var/www/drupal/sites/default/default.services.yml” file

was due to permissions. I notice that you're using sudo to run composer as the webserver (www-data) , and this file was for some reason not owned by webserver, so composer was unable to replace it.

I understand that the decision to use sudo comes from here: https://www.drupal.org/forum/support/installing-drupal/2023-01-04/using-... I'll take a look at that and try to understand your requirements. IMHO, sudo is probably not the right solution for this, but I need to better understand the use case.

IMHO, running composer as the web server is not a good idea. This makes anything in your code base downloaded by composer owned by the webserver,  which creates a very large  attack surface area. If some threat agent manages to compromise the webserver, they can do whatever they want, including altering or replacing your entire code base. Drupal's security philosophy is very much defence in depth, so even if your web server is compromised, your site's code base should still be protected.

If you're the single person managing the code base, make sure the code base is owned by you, and run composer as yourself in order to update it. Apart from the public and private file system, the web server should not have more than read access to files, while you yourself have full access (e.g.: 744).

When you've set up file permissions correctly, you shall be able to update the core with this:

$ cd To_Document_Root
$ composer update "drupal/core-*" --with-all-dependencies
$ drush updb
$ drush cr

The last two lines uses drush to first run the database update script, and then rebuild all caches.

If there is a team of people managing the code base, a slightly more complex setup is required, involving the group bit,  but it sounds like you're the sole maintainer of the code base, so I'll leave it at that.

- gisle

vhelmont’s picture

vhelmont commented

Hello Gisle

  • /var/www/drupal/sites/default/default.services.yml has the correct permission:
    -rw-rw-r-- 1 www-data www-data 9069 Jul  1 14:14 /var/www/drupal/sites/default/default.services.yml

    The parent directory seems to be the problem:

    dr-xr-xr-x 3 www-data www-data 4096 Jul  1 14:14 default

    The 555 protection, which seems to be needed by drupal, prevents composer from moving, removing the file /var/www/drupal/sites/default/default.services.yml and creating another file in the default directory.

  • I always learned that a website under apache needs to be owned by the user www-data. Isn't that the case anymore?
    If the website is owned by www-data, how can composer update it, when not executed by user www-data?
  • At the moment I am the only person managing the code base but that will change in the future.
    I probably have to create a new user, which manage the code base, and give other people which also need to manage the code base, access to tha t user.
  • At the moment the full website is situated at /var/www/drupal/ and www-data owns it.
    Are you suggesting that I have to move the drupal directory somewhere in my home directory, make myself owner of it and change the protection of all the items under the drupal directory to 755 allowing www-data to access it via the world bit (5) and giving me full access.
    Won't using the 744 protection, you suggested, produce problems on directories?
    To make it work I probably have to create a symbolic link from /var/www/drupal/ pointing to the drupal directory in my home directory.
    Is this corrector or is there a better solution?

Regards,

Albert

gisle’s picture

gisle
he/him
Primary language Norwegian Bokmål
Location Norway
commented

I always learned that a website under apache needs to be owned by the user www-data. Isn't that the case anymore?

AFAIK, this has never been the case. I am in charge of more than 100 websites under Apache2 (Drupal, Wordpress, Grav). None of these are owned by the user www-data. There has never been a problem updating these, using standard best practices. What is the source of what you've "always learned"?

The 555 protection, which seems to be needed by drupal, prevents composer from moving, removing the file /var/www/drupal/sites/default/default.services.yml and creating another file in the default directory.

This setting is not required by Drupal. On a Unix and Gnu/Linux system, directories need to be treated different that ordinary files. To be processed correctly by composer, directories need 755, and composer must be used without sudo.

If the website is owned by www-data, how can composer update it, when not executed by user www-data?

It can't (well it can, but how to do it introduces so bad practices that I won't tell you how to). That's why it is a very bad idea to have the website owned by www-data.

Are you suggesting that I have to move the drupal directory somewhere in my home directory,

No. I suggest you leave it where it is, but owned by you, and that when updating, you run composer without sudo.

Won't using the 744 protection, you suggested, produce problems on directories?

I didn't address directories, only files. For directories, use 755.

To make it work I probably have to create a symbolic link from /var/www/drupal/ pointing to the drupal directory in my home directory.

Don't move the drupal directory to your home directory. Only fix the permissions.

Edit: Permission for directories should be 755.

- gisle

vhelmont’s picture

vhelmont commented

Hello Gisle,

I learned a lot from this thread, seems google isn't always write.

I'll put your advice to the test on my local test site and let you know the results.

Many thanks.

Regards,

Albert