Fedora Account System
Red Hat Associate
Red Hat Customer
In the FreeIPA container (https://github.com/freeipa/freeipa-container) we use /data volume in the container to hold any persistent configuration, data, and logs. In the container image we have symlinks pointing to the respective locations under that /data volume, so that software finds what it needs at the original location. So for example, in the container # ls -la /var/named lrwxrwxrwx. 1 root root 15 Nov 5 13:41 /var/named -> /data/var/named With bind-9.18.41-1.fc43.x86_64 we observe that the original /var/named/named.* files were turned into symlinks /var/named/named.ca -> ../../etc/named.ca /var/named/named.empty -> ../../usr/share/named/named.empty /var/named/named.localhost -> ../../usr/share/named/named.localhost /var/named/named.loopback -> ../../usr/share/named/named.loopback presumably in https://src.fedoraproject.org/rpms/bind/c/54750e536007a5b744f7c516b032276f77b12a81. These symlinks work fine in a situation when /var and /var/named are directories but when they themselves happen to be symlinks that don't have the same number of components, the relative ../../* symlinks are dangling. Could you consider changing those symlinks to absolute ones? Reproducible: Always Steps to Reproduce: 1. Move /var/named to /data/var/named and make symlink /var/named -> /data/var/named. 2. Start the named service. 3. Check journal. Actual Results: Nov 05 15:04:25 ipa.example.test systemd[1]: Finished named-setup-rndc.service - Generate rndc key for BIND (DNS). Nov 05 15:04:25 ipa.example.test systemd[1]: Starting named.service - Berkeley Internet Name Domain (DNS)... Nov 05 15:04:25 ipa.example.test bash[8467]: could not configure root hints from 'named.ca': file not found Nov 05 15:04:25 ipa.example.test systemd[1]: named.service: Control process exited, code=exited, status=1/FAILURE Nov 05 15:04:25 ipa.example.test systemd[1]: named.service: Failed with result 'exit-code'. Nov 05 15:04:25 ipa.example.test systemd[1]: Failed to start named.service - Berkeley Internet Name Domain (DNS). Expected Results: No error. Additional Information: Checking https://docs.fedoraproject.org/en-US/packaging-guidelines/#_symlinks there is not a definitive guidance whether relative or absolute symlinks should be preferred. In this case the relative symlinks in /var/named cause the * Relative symlinks may break or behave unexpectedly when a part of a filesystem is mounted to a custom location. * Relative symlinks may break when bind mounting or symlinking directories. But I acknowledge that the use of relative symlinks has the pro of * Relative symlinks will point to the same file inside or outside of a chroot. One argument for absolute symlinks is the use of absolute paths in https://src.fedoraproject.org/rpms/bind/c/666db3a14e01939dcbb331952069db339921039b If there is a specific reason why bind went with the relative symlinks, we should be able to workaround it in the FreeIPA container's Dockerfiles. It would just be easier if the symlinks could be absolute right out of Fedora's rpms.
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.