Bug 2412646
| Summary: | Relative ../.. symlinks in /var/named make moving the whole directory to different location hard | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jan Pazdziora <adelton> |
| Component: | bind | Assignee: | Petr Menšík <pemensik> |
| Status: | ASSIGNED --- | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 43 | CC: | anon.amish, dns-sig, mruprich, pemensik, zdohnal |
| Target Milestone: | --- | Keywords: | Regression |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | --- | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | --- | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Jan Pazdziora
2025-11-05 15:51:25 UTC
No, I do not want them point to absolute locations. This change were done to work in ImageMode machine, which is important RHEL feature. That requires to have those files somewhere else than /var directory, because it might not have any content on fresh imagemode machine. That was primary reason to move them somewhere else. I would suggest if you are moving those directories always, then remove package original symlinks and create symlinks from your location to /usr/share/named files directly. They are not supposed to be changed anyway. A bit special case is named.ca. That leads to /etc/named.ca, because only in this case it might make sense to replace it with local content. But I have created dns-root-data package, which should contain root server hints instead. My plan is to depend on it and symlink /etc/named.ca to /usr/share/dns-root-data/root.hints. Main reason is absolute paths produce warnings on every bind build. From that I assume they are less reliable. Wouldn't it be more reliable to use volume for whole /var for local data. Then another volume for /etc/ customization? (In reply to Petr Menšík from comment #1) > > No, I do not want them point to absolute locations. This change were done to work in ImageMode machine, which is important RHEL > feature. That requires to have those files somewhere else than /var directory, because it might not have any content on fresh > imagemode machine. That was primary reason to move them somewhere else. I get that (even if I'm not sure why not refer to the ultimate locations from whatever is referencing them) but does that force the symlinks to be relative? > Main reason is absolute paths produce warnings on every bind build. From that I assume they are less reliable. Is it some rpm warning that the symlink is a dangling one in build time? > Wouldn't it be more reliable to use volume for whole /var for local data. > Then another volume for /etc/ customization? I don't think it would. With containers you don't get the rpm upgrade operation so you'd end up with /var and /etc content created by old package versions. Now we already have mechanisms in the FreeIPA container to emulate the rpm upgrades when we detect that a newer image is used with /data produced by old image but we only have to do this for the FreeIPA content, not for possibly all packages in the image. That would not be sustainable. We've been using this approach for over 10 years in that container image and IIRC this is the first time the symlinks created by the packages give us trouble. (In reply to Jan Pazdziora from comment #2) > I get that (even if I'm not sure why not refer to the ultimate locations > from whatever is referencing them) but does that force the symlinks to be > relative? No, nothing forces it to be relative. But using absolute symlink creates warning after build. > Is it some rpm warning that the symlink is a dangling one in build time? > > > Wouldn't it be more reliable to use volume for whole /var for local data. > > Then another volume for /etc/ customization? I think my relative symlinks rely on ../../usr from /var/named leads to /usr. Would it help if you would create symlink in your /data volume, usr -> ../usr (or /usr)? # ln -s /usr /data/usr > > I don't think it would. With containers you don't get the rpm upgrade > operation so you'd end up with /var and /etc content created by old package > versions. Now we already have mechanisms in the FreeIPA container to emulate > the rpm upgrades when we detect that a newer image is used with /data > produced by old image but we only have to do this for the FreeIPA content, > not for possibly all packages in the image. That would not be sustainable. > > We've been using this approach for over 10 years in that container image and > IIRC this is the first time the symlinks created by the packages give us > trouble. yes, I admit those symlinks lead potentially from one volume to another volume. Although relative symlinks should in general work in more cases than absolute symlinks. The problem is you move only part of subtree to different levels. I think that can be fixed on your side with one usr symlink extra. I have there some doc symlinks leading to those new files in absolute path, because I have not found simple way to make them relative. Because %doc macro does have precomputed target directory. I would like get rid of those too. Warnings I wrote about look like:
RPM build warnings:
absolute symlink: /usr/share/doc/bind/sample/var/named/named.ca -> /etc/named.ca
absolute symlink: /usr/share/doc/bind/sample/var/named/named.empty -> /usr/share/named/named.empty
absolute symlink: /usr/share/doc/bind/sample/var/named/named.localhost -> /usr/share/named/named.localhost
absolute symlink: /usr/share/doc/bind/sample/var/named/named.loopback -> /usr/share/named/named.loopback
Finish: rpmbuild bind-9.18.41-2.fc44.src.rpm
After each mockbuild.
|