Hi,
The Linux kernel now has its own AFS client filesystem included in it, and this has been turned on in the Fedora kernel: https://bugzilla.redhat.com/show_bug.cgi?id=1616016
To make the userspace side "work out of the box", I have a kafs-client package that I'm preparing to propose for inclusion in Fedora:
http://git.infradead.org/users/dhowells/kafs-client.git/shortlog/refs/heads/next
Amongst other bits, this has a systemd unit file that mounts the AFS dynamic root.
But this is where the problem starts: To be compatible with 35 years' worth of AFS experience, scripting and history, and to be compatible with OpenAFS, Auristor, Arla and Transarc on UNIX, I need to mount the dynamic root on "/afs". That is what users of AFS expect; this is what the AFS documentation assumes everywhere. It's a global namespace expected to be rooted on that directory on every partaking machine. (With the exception of Windows, where it couldn't work like this).
The issue is, however, that this is a "new" top-level directory as far as Fedora is concerned - kind of[*], and so it requires FPC approval as I'm led to understand things.
[*] Note that the SELinux policy expects /afs to be a mountpoint already: matchpathcon /afs/ /afs system_u:object_r:mnt_t:s0
So what do I do about this? Ideally, I'd have the /afs directory created by installation of kafs-client and removed on its removal. I was creating the dir during kafs-client %install and then doing:
%files /afs
but that doesn't upgrade correctly. Someone gave me a fix that creates the dir on the fly:
%post %systemd_post afs.mount # Create /afs directory if it doesn't exist if [ ! -d /afs ]; then mkdir /afs chown root.root /afs chmod 0755 /afs [ -x /usr/sbin/restorecon ] && /usr/sbin/restorecon /afs fi %files %ghost %dir /afs
but rpmlint complains about the chown:
kafs-client.x86_64: W: dangerous-command-in-%post chown
I could have systemd create it when creating the mount and attempt to remove it later.
Anyway, any guidance would be appreciated. Thanks, David
As much as I don't like to get out ahead of the FHS here, the usual path for this thing has been /afs since I started working as a sysadmin in 1989. I can't imagine we'd want to deviate now, and see no harm in letting some AFS-related package create this directory.
/afs
However, the issue that prevents a package from trying to create /afs if there is already a magic filesystem mounted there is rather outside the scope. I don't think there's a good way out of that one, and certainly creating it and changing ownership in %post has its own set of problems. My suggestion would be to introduce the directory in rawhide and let system upgrades (from F30 to F31, for example) handle creation of the directory.
%post
"My suggestion would be to introduce the directory in rawhide" - create it in which package? In kafs-client or do you mean in filesystem?
Or possibly add an afs-filesystem or filesystem-afs rpm that just supplies the /afs directory. This would get around the upgrade problem that kafs-client has with putting the /afs directory in %files there.
Metadata Update from @ignatenkobrain: - Issue tagged with: meeting
From this weeks meeting: https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2019-06-06/fpc.2019-06-06-16.00.txt
Metadata Update from @james: - Issue close_status updated to: accepted - Issue status updated to: Closed (was: Open)