Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Prevent permission issues after ingesting compat layer update tarballs #144

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Prevent permission issues after ingesting compat layer update tarballs #144

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
5abae5b
use --no-same-owner for tar command
bedroge Feb 2, 2023
631c03e
also use --no-same-permissions for tar command
bedroge Feb 2, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion scripts/ingest-tarball.sh
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -182,7 +182,7 @@ function ingest_compat_tarball() {
echo_yellow "Removing the existing layer, and adding the new one from the tarball..."
cvmfs_server transaction "${repo}"
rm -rf "/cvmfs/${repo}/${basedir}/${version}/compat/${os}/${arch}/"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bedroge We should probably check with CVMFS devs if there's a recommend approach for this type of "replace" operation...

Ideally we don't need to unpack the tarball at all, without having to publish the removal first

Copy link
Collaborator Author

@bedroge bedroge Feb 2, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed during the monthly meeting, we could ingest the new tarball/layer to a directory with a revision number in its name (e.g. 2021.12-1), and then switch a (variant) symlink 2021.12 to that actual version. In case of issues, we can easily revert to the older version. And if things are okay, we could even remove the old (and possibly insecure) version after a while.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That does require a change in the tarball itself, as we can't simply ingest it to the versions base dir. We would either need to modify the way the tarball is created, or somehow strip the first directory (2021.12) from every file/dir in the tarball and replace it by / ingest it to 2021.12-<n>.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we strongly prefer using cmvfs_server ingest, we should change the way the tarball is created.

The ingest script could then also fail hard if the top-level directory isn't what's expected (2021.12.<n+1> if the current is 2021.12.<n>).

I would prefer using a versioning scheme like 2021.12-001, 2021.12-002 (since that sorts better)

tar -C "/cvmfs/${repo}/${basedir}/" -xzf "${tar_file}"
tar --no-same-owner --no-same-permissions -C "/cvmfs/${repo}/${basedir}/" -xzf "${tar_file}"
cvmfs_server publish -m "update compat layer for ${version}, ${os}, ${arch}" "${repo}"
ec=$?
if [ $ec -eq 0 ]
Expand Down