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.

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

Fix symlink to same exterior location #1167

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

Conversation

abadger
Copy link
Member

@abadger abadger commented Jan 22, 2024

Note: #1166 must be merged first and then this PR should be rebased.

In the present code, when we have two separate links to the same file outside of /etc/pki, the real
file is copied to the location of both links. The problem with this is when the user makes changes
to the file in the future, they will have to edit both files whereas before they would only have had
to edit one of the files (since they linked to the same underlying file). Example:

  Host:
  lrwxrwxrwx.  1 badger badger  13 Jan 22 03:42 fileA -> /etc/sourceFile
  lrwxrwxrwx.  1 badger badger  13 Jan 22 03:42 fileB -> /etc/sourceFile

  Becomes:

  -rw-r--r--.  1 badger badger  12 Jan 22 03:43 fileA
  -rw-r--r--.  1 badger badger  12 Jan 22 03:43 fileB

fileA and fileB are separate copies of /etc/sourceFile.

This change makes it so anytime two links eventually point to the same exterior file, the first link will be copied and the second link will becone a symlinks to that copy like this:

  -rw-r--r--.  1 badger badger  12 Jan 22 03:43 fileA
  lrwxrwxrwx.  1 badger badger  13 Jan 22 03:42 fileB -> /etc/pki/fileA

This is the behaviour even if the second link went through several other exterior links to reach the
same sourceFile (but not if there is another interior link in between). Example:

  Host:
  lrwxrwxrwx.  1 badger badger  13 Jan 22 03:42 fileA -> /etc/sourceFile
  lrwxrwxrwx.  1 badger badger  13 Jan 22 03:42 fileB -> /etc/sourceFile
  lrwxrwxrwx.  1 badger badger  13 Jan 22 03:42 fileC -> /etc/external-to-same-file
  lrwxrwxrwx.  1 badger badger  13 Jan 22 03:42 fileD -> /etc/external-to-interior-link

  lrwxrwxrwx.  1 badger badger  13 Jan 22 03:42 /etc/external-to-same-file -> /etc/sourceFile
  lrwxrwxrwx.  1 badger badger  13 Jan 22 03:42 /etc/external-to-interior-link -> pki/fileB

  Becomes:
  -rw-r--r--.  1 badger badger  12 Jan 22 03:43 fileA
  lrwxrwxrwx.  1 badger badger  13 Jan 22 03:42 fileB -> /etc/pki/fileA
  lrwxrwxrwx.  1 badger badger  13 Jan 22 03:42 fileC -> /etc/pki/fileA
  lrwxrwxrwx.  1 badger badger  13 Jan 22 03:42 fileD -> /etc/pki/fileB

The drawback to the end user is that, unless you trace all the way through the chain of symlinks, it
is confusing that fileA ends up being a real file and fileC ends up pointing to it. It's not
immediately obvious how the two are related.

The advantage is if the end user makes any changes to either fileA or fileC, then the changes will
be visible in both files which is the behaviour that existed on the host system.

* Symlinks to a directory inside of /etc/pki were being created as empty directories.
* Note: unittests being added for both this problem and a second problem:
  two links to the same external file will be copied as two separate files but ideally we want one
  to be a copy and the other to link to the copy.  The unittests for the second problem are
  commented out.

Fixes: https://issues.redhat.com/browse/RHEL-3284
In the present code, when we have two separate links to the same file outside of /etc/pki, the real
file is copied to the location of both links.  The problem with this is when the user makes changes
to the file in the future, they will have to edit both files whereas before they would only have had
to edit one of the files (since they linked to the same underlying file). Example:

  Host:
  lrwxrwxrwx.  1 badger badger  13 Jan 22 03:42 fileA -> /etc/sourceFile
  lrwxrwxrwx.  1 badger badger  13 Jan 22 03:42 fileB -> /etc/sourceFile

  Becomes:

  -rw-r--r--.  1 badger badger  12 Jan 22 03:43 fileA
  -rw-r--r--.  1 badger badger  12 Jan 22 03:43 fileB

fileA and fileB are separate copies of /etc/sourceFile.

This change makes it so anytime two links eventually point to the same exterior file, the first link will be copied and the second link will becone a symlinks to that copy like this:

  -rw-r--r--.  1 badger badger  12 Jan 22 03:43 fileA
  lrwxrwxrwx.  1 badger badger  13 Jan 22 03:42 fileB -> /etc/pki/fileA

This is the behaviour even if the second link went through several other exterior links to reach the
same sourceFile (but not if there is another interior link in between).  Example:

  Host:
  lrwxrwxrwx.  1 badger badger  13 Jan 22 03:42 fileA -> /etc/sourceFile
  lrwxrwxrwx.  1 badger badger  13 Jan 22 03:42 fileB -> /etc/sourceFile
  lrwxrwxrwx.  1 badger badger  13 Jan 22 03:42 fileC -> /etc/external-to-same-file
  lrwxrwxrwx.  1 badger badger  13 Jan 22 03:42 fileD -> /etc/external-to-interior-link

  lrwxrwxrwx.  1 badger badger  13 Jan 22 03:42 /etc/external-to-same-file -> /etc/sourceFile
  lrwxrwxrwx.  1 badger badger  13 Jan 22 03:42 /etc/external-to-interior-link -> pki/fileB

  Becomes:
  -rw-r--r--.  1 badger badger  12 Jan 22 03:43 fileA
  lrwxrwxrwx.  1 badger badger  13 Jan 22 03:42 fileB -> /etc/pki/fileA
  lrwxrwxrwx.  1 badger badger  13 Jan 22 03:42 fileC -> /etc/pki/fileA
  lrwxrwxrwx.  1 badger badger  13 Jan 22 03:42 fileD -> /etc/pki/fileB

The drawback to the end user is that, unless you trace all the way through the chain of symlinks, it
is confusing that fileA ends up being a real file and fileC ends up pointing to it.  It's not
immediately obvious how the two are related.

The advantage is if the end user makes any changes to either fileA or fileC, then the changes will
be visible in both files.  This is the behaviour that existed on the host system.
Copy link

Thank you for contributing to the Leapp project!

Please note that every PR needs to comply with the Leapp Guidelines and must pass all tests in order to be mergeable.
If you want to request a review or rebuild a package in copr, you can use following commands as a comment:

  • review please @oamg/developers to notify leapp developers of the review request
  • /packit copr-build to submit a public copr build using packit

Packit will automatically schedule regression tests for this PR's build and latest upstream leapp build. If you need a different version of leapp from PR#42, use /packit test oamg/leapp#42

It is possible to schedule specific on-demand tests as well. Currently 2 test sets are supported, beaker-minimal and kernel-rt, both can be used to be run on all upgrade paths or just a couple of specific ones.
To launch on-demand tests with packit:

  • /packit test --labels kernel-rt to schedule kernel-rt tests set for all upgrade paths
  • /packit test --labels beaker-minimal-8.9to9.3,kernel-rt-8.9to9.3 to schedule kernel-rt and beaker-minimal test sets for 8.9->9.3 upgrade path

[Deprecated] To launch on-demand regression testing public members of oamg organization can leave the following comment:

  • /rerun to schedule basic regression tests using this pr build and latest upstream leapp build as artifacts
  • /rerun 42 to schedule basic regression tests using this pr build and leapp*PR42* as artifacts
  • /rerun-sst to schedule sst tests using this pr build and latest upstream leapp build as artifacts
  • /rerun-sst 42 to schedule sst tests using this pr build and leapp*PR42* as artifacts

Please open ticket in case you experience technical problem with the CI. (RH internal only)

Note: In case there are problems with tests not being triggered automatically on new PR/commit or pending for a long time, please contact leapp-infra.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant