#888 Need to work out how to install "/afs" directory for upcoming kafs-client package
Closed: accepted 2 years ago by james. Opened 2 years ago by dhowells.


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:


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:


but that doesn't upgrade correctly. Someone gave me a fix that creates the dir on the fly:

%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

%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.

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.

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.

"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

2 years ago

From this weeks meeting: https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2019-06-06/fpc.2019-06-06-16.00.txt

  • #888 How to install "/afs" directory for kafs-client package
    (geppetto, 16:06:25)
  • ACTION: Allow /afs to be included in filesystem, or afs-filesystem
    if desired, for rawhide/f31 (+1:6, 0:0, -1:0) (geppetto, 16:19:07)
  • Can use the scriptlet dir. creation hack for f30, but not f31+
    (geppetto, 16:19:36)

Metadata Update from @james:
- Issue close_status updated to: accepted
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.