Skip to content
This repository has been archived by the owner on Aug 1, 2024. It is now read-only.

copy-node-modules.sh fails on Linux during LMS provisioning due to permission error #1138

Closed
4 tasks done
timmc-edx opened this issue Jul 28, 2023 · 1 comment
Closed
4 tasks done
Assignees

Comments

@timmc-edx
Copy link
Contributor

timmc-edx commented Jul 28, 2023

Developers with a previous devstack installation cannot re-provision due to file permission issues.

This has only been observed on Linux; it may or may not occur on Mac, since we've observed inconsistent behavior in whether files end up as root-owned there.

Acceptance criteria

Symptoms

When the provisioning script runs npm ci, npm ends up running the postinstall script scripts/copy-node-modules.sh (as of PR openedx/edx-platform#32767). On Linux, this fails with the following:

Copying studio-frontend JS & CSS from node_modules into vendor directories... 
+ read -r -d '' src_file
++ find node_modules/@edx/studio-frontend/dist -type f -print0
+ [[ node_modules/@edx/studio-frontend/dist/accessibilityPolicy.min.css = *.css ]]
+ cp --force node_modules/@edx/studio-frontend/dist/accessibilityPolicy.min.css common/static/common/css/vendor
cp: cannot remove 'common/static/common/css/vendor/accessibilityPolicy.min.css': Permission denied

Cause

The files in common/static/common/css/vendor are owned by the user root, whereas the script is running as the user app (as determined by adding a call to whoami.) This still happens if I just run npm install from inside make lms-shell -- even though I'm running that command as root, by default.

npm performs this change-of-user for all of its scripts, with no apparent workaround:

When npm is run as root, scripts are always run with the effective uid and gid of the working directory owner.

As far as I can tell, there's no workaround (see npm/rfcs#546) so maybe we can just switch to calling the script explicitly after the npm ci call completes.

Workaround

In edx-platform:

sudo rm -rf common/static/common/css/
sudo rm -rf common/static/common/js/

(More thorough version that will also clear out root-owned pycache files that keep cropping up: sudo find -user 0 -group 0 -prune -exec rm -rf '{}' \;)

Once this is done, npm install inside lms-shell will succeed, and the re-created files in those directories will have the UID and GID of the desktop user.

@rgraber rgraber moved this to Prioritized in Arch-BOM Jul 31, 2023
@timmc-edx timmc-edx moved this from Prioritized to Groomed in Arch-BOM Aug 7, 2023
@timmc-edx timmc-edx self-assigned this Aug 7, 2023
@timmc-edx timmc-edx moved this from Groomed to In Progress in Arch-BOM Aug 7, 2023
timmc-edx added a commit to openedx/edx-platform that referenced this issue Aug 8, 2023
This should help avoid permissions errors for existing devstack users when
they re-provision.

Ticket: openedx-unsupported/devstack#1138
@timmc-edx
Copy link
Contributor Author

timmc-edx commented Aug 8, 2023

Should be able to reproduce the issue this way:

  • sudo chown -R root: common/static/common/css/ in edx-platform to simulate lingering root-owned files
  • Add a newline to the front of package.json in edx-platform to bust the cache
  • make dev.destroy dev.pull.lms dev.provision

@timmc-edx timmc-edx moved this from In Progress to In Code Review in Arch-BOM Aug 9, 2023
@timmc-edx timmc-edx moved this from In Code Review to In Progress in Arch-BOM Aug 9, 2023
timmc-edx added a commit to openedx/edx-platform that referenced this issue Aug 9, 2023
This should help avoid permissions errors for existing devstack users when
they re-provision.

Ticket: openedx-unsupported/devstack#1138
@github-project-automation github-project-automation bot moved this from In Progress to Done in Arch-BOM Aug 9, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant