On Tue, Apr 30, 2019 at 01:12:43PM -0400, Robert Marcano wrote:

On 4/30/19 11:45 AM, David Howells wrote:

...

Hi,

I need to install a directory (/afs) that will be a mountpoint that a systemd service (also installed in the rpm) will mount upon.

Nope. New top-level directories are a big thing and need FPC approval: https://fedoraproject.org/w/index.php?title=Packaging:Guidelines&oldid=5... (I can't find the text in the new guidelines, but the new guidelines don't support searching, so finding anything is PITA, so I'll just assume that this is still valid...)

Regarding the FPC approval: I don't think it should be granted. There is no good reason to create a mount point like this under root. It should go somewhere under /run or /var.

Zbyszek

...

What's the best way to encode this in the specfile?

I did have:

%files /afs

but that doesn't upgrade correctly. Someone gave me another way to do it:

Just create it on your %install section

mkdir $RPM_BUILD_ROOT/afs

and continue adding the reference on the %files like:

%file %dir /afs

...

%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

The git repo is here:

http://git.infradead.org/users/dhowells/kafs-client.git/shortlog/refs/heads/...

The second patch from the top is the one that tries to fix the mountpoint dir installation issue ("spec: Treat /afs special").

Thanks, David _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

---

devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Many sites do intentionally, even - it's quite popular in University settings and in the financial sector. Nothing really drives that home like breaking support for it (which I'd like to say I've never done, but can't). Putting it anywhere other than /afs would be crazy - especially when /afs predates the FHS, and the FHS is violaged plenty of other places (usrmerge, anyone?).

Thanks, --Robbie

Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:

...

...

I need to install a directory (/afs) that will be a mountpoint that a systemd service (also installed in the rpm) will mount upon.

Nope. New top-level directories are a big thing and need FPC approval: https://fedoraproject.org/w/index.php?title=Packaging:Guidelines&oldid=5... (I can't find the text in the new guidelines, but the new guidelines don't support searching, so finding anything is PITA, so I'll just assume that this is still valid...)

I'm not entirely clear how I should go about requesting FPC approval. It says it is preferable that a ticket be filed in the packaging committee pagure - do they mean to raise an issue, do you know?

Regarding the FPC approval: I don't think it should be granted. There is no good reason to create a mount point like this under root.

Ummm... There's ~35 years of history of use of /afs as a cross-platform global namespace[*]; there are organisations, people, computers, scripts with this as an expectation. The Linux kernel now contains an AFS filesystem of its own, written from scratch and now enabled in the Fedora kernel; to be compatible with OpenAFS, AuriStor, Transarc, Arla it really needs the dynamic root mounting on /afs.

Note that, for my purposes, /afs only needs to exist if the kafs-client package is installed.

It should go somewhere under /run or /var.

Well, I could mount it there, but then I'd really need a symlink or bind mount at /afs to deal

Note the SELinux rules already have /afs as the mountpoint:

matchpathcon /afs/ /afs system_u:object_r:mnt_t:s0

Thanks, David

[*] Give or take Windows

Jason L Tibbitts III tibbs@math.uh.edu wrote:

DH> I'm not entirely clear how I should go about requesting FPC DH> approval. It says it is preferable that a ticket be filed in the DH> packaging committee pagure - do they mean to raise an issue, do you DH> know?

Just file a ticket:

https://pagure.io/packaging-committee/new_issue

That's it, really.

I've done that, thanks:

https://pagure.io/packaging-committee/issue/888

David

On Tue, 2019-04-30 at 17:29 +0000, Zbigniew Jędrzejewski-Szmek wrote:

On Tue, Apr 30, 2019 at 01:12:43PM -0400, Robert Marcano wrote:

...

On 4/30/19 11:45 AM, David Howells wrote:

...

Hi,

I need to install a directory (/afs) that will be a mountpoint that a systemd service (also installed in the rpm) will mount upon.

I seem to remember you can't create root level directories from a program either.

So the user needs to create these directories manually!

That problem hasn't been reported for a while so this may have changed.

Nope. New top-level directories are a big thing and need FPC approval:

https://fedoraproject.org/w/index.php?title=Packaging:Guidelines&oldid=5...

(I can't find the text in the new guidelines, but the new guidelines don't support searching, so finding anything is PITA, so I'll just assume that this is still valid...)

That's a great idea.

So, as has been happening, I have to advise users that they must create any mount point directories they need in / manually before starting autofs.

It's this sort of policy that makes me want to close bugs for this without any explanation of why the problem occurs!

Regarding the FPC approval: I don't think it should be granted. There is no good reason to create a mount point like this under root. It should go somewhere under /run or /var.

Rubbish, the package is following long standing conventions, there's no good reason to prevent this and, while it may be possible in this case, it's not always possible to know what directory (or directories) will need to be created therefore it's not possible to seek approval.

Zbyszek

...

...

What's the best way to encode this in the specfile?

I did have:

%files /afs

but that doesn't upgrade correctly. Someone gave me another way to do it:

Just create it on your %install section

mkdir $RPM_BUILD_ROOT/afs

and continue adding the reference on the %files like:

%file %dir /afs

...

%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

The git repo is here:

http://git.infradead.org/users/dhowells/kafs-client.git/shortlog/refs/heads/...

The second patch from the top is the one that tries to fix the mountpoint dir installation issue ("spec: Treat /afs special").

Thanks, David _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

---

devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

---

devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

On Wed, 1 May 2019 at 03:28, Ralf Corsepius rc040203@freenet.de wrote:

On 5/1/19 2:24 AM, Ian Kent wrote:

...

On Tue, 2019-04-30 at 17:29 +0000, Zbigniew Jędrzejewski-Szmek wrote:

...

On Tue, Apr 30, 2019 at 01:12:43PM -0400, Robert Marcano wrote:

...

On 4/30/19 11:45 AM, David Howells wrote:

...

Hi,

I need to install a directory (/afs) that will be a mountpoint that a systemd service (also installed in the rpm) will mount upon.

I seem to remember you can't create root level directories from a program either.

Well, creating root level directories actually is prohibited by the FHS ever since it exists, because root level directories are standardized (barring the fact, Fedora/RH diverged from these rule on many occasions).

That said /afs is nothing but a - though being not uncommon - a local convention, among many others (e.g. /com, /srv, ...).

And I think we have covered all the talking points from every previous argument. For: We have been doing this since the early 1980's Against: The FHS says you can't do it For: The FHS hasn't had an update in 15 years and hasn't approved a change in almost as long. The committee is a dead parrot. Against: It's not dead, it is merely resting. .. queue rest of Monty Python scripts ..

We are merely going through the same arguments which really started decades ago about arguments about AFS or NFS or...

On Wed, 1 May 2019 at 07:01, Stephen Gallagher sgallagh@redhat.com wrote:

On Wed, May 1, 2019 at 6:10 AM Stephen John Smoogen smooge@gmail.com wrote:

...

And I think we have covered all the talking points from every previous

argument.

...

For: We have been doing this since the early 1980's Against: The FHS says you can't do it For: The FHS hasn't had an update in 15 years and hasn't approved a

change in almost as long. The committee is a dead parrot.

The FHS migrated to the Linux Foundation a while back and is more active than once it was. Its last update is 3.0, ratified in 2015. It does not include /afs explicitly so far as I can see.

https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html

Dang-nabbit there goes my LWN quote of the week.. foiled by facts once again. I would have gotten it too if it hadn't been for that Gallagher and his Wikipedia article too.

When I went to look for where the FHS was.. the top links were http://www.pathname.com/fhs/ and a bunch of other pages referring to that link. Of course if I had clicked on the wikipedia article I would have been informed on it being updated to the 3.0 version. Which also goes into hier and similar standards which is where I remember various wars from long ago about /afs/ being fought. I went looking at the Debian packages associated with afs, and they look like they punt on /afs as the documentation makes it out like another kernel level filesystem (/run, /proc, /sys) but doesn't seem to create a /afs in what I could get from my 10km viewing.

---

devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

On Fri, 2019-05-03 at 00:30 -0400, Nico Kadel-Garcia wrote:

On Tue, Apr 30, 2019 at 8:25 PM Ian Kent raven@themaw.net wrote:

...

On Tue, 2019-04-30 at 17:29 +0000, Zbigniew Jędrzejewski-Szmek wrote:

...

On Tue, Apr 30, 2019 at 01:12:43PM -0400, Robert Marcano wrote:

...

On 4/30/19 11:45 AM, David Howells wrote:

...

Hi,

I need to install a directory (/afs) that will be a mountpoint that a systemd service (also installed in the rpm) will mount upon.

I seem to remember you can't create root level directories from a program either.

Of course you can. The program needs to run with root privileges. and not violate whatever SELinux or other "/" mountpoint restrictions exist.

What I'm referring to is (must have been) the selinux rules because automount(8) needs to be run as root.

It's a *Bad Idea(tm), since it violates the File System Hierarchy, but that hardly makes it impossible.

That's debatable but I'm not going to argue about it, but do disagree with this for the case of long time existing system services such as autofs.

...

So the user needs to create these directories manually!

That problem hasn't been reported for a while so this may have changed.

...

Nope. New top-level directories are a big thing and need FPC approval:

https://fedoraproject.org/w/index.php?title=Packaging:Guidelines&oldid=5...

...

...

(I can't find the text in the new guidelines, but the new guidelines don't support searching, so finding anything is PITA, so I'll just assume that this is still valid...)

That's a great idea.

So, as has been happening, I have to advise users that they must create any mount point directories they need in / manually before starting autofs.

Or better yet, in /opt/ or /usr/local/ or /var/lib/ or whatever makes the most sense with the File System Hierarchy.

That imposes a restriction on the system administrator, although /usr/local makes sense in some cases and is sometimes used, but it depends on the file system names space the administrator wants to use to get naming consistency while also keeping path names as short as possible.

This actually makes quite a difference for sites that have a large number of files and directories in their automount mount trees.

...

It's this sort of policy that makes me want to close bugs for this without any explanation of why the problem occurs!

...

Regarding the FPC approval: I don't think it should be granted. There is no good reason to create a mount point like this under root. It should go somewhere under /run or /var.

Rubbish, the package is following long standing conventions, there's no good reason to prevent this and, while it may be possible in this case, it's not always possible to know what directory (or directories) will need to be created therefore it's not possible to seek approval.

\And violating a much more important, namely the File System Hiearchy. If you can find a good reason to violate that, publish your reasoning.

By the way, I've dealt with /afs style automounting before, and it was a nightmare to clean up after when it inevitably croaked precisely due to the root filesystem location of "/afs".

Yes, there can problems from time to time with automounting.

autofs has a command line option to clear out all existing mounts at startup so you can start over but it's not exactly straight forward to use now we use systemd (at least I'm not aware of a way to add custom actions to units).

Ian

On Fri, May 3, 2019 at 5:22 AM David Howells dhowells@redhat.com wrote:

I really don't want to have to tell ordinary users that "you can't use this unless you first go and write some systemd scripting".

If you're willing to take on the work to activate afs dependent structures and components, it becomes your responsibility to integrate it well.

...

\And violating a much more important, namely the File System Hiearchy. If you can find a good reason to violate that, publish your reasoning.

Well, there's 35 years of history, expectation, experience, documentation and scripting for a start that expect the global AFS namespace to be mounted on /afs on a UNIX box (Windows is different).

Including the fact that, since its invention, it has *always* demanded a reboot of the client using it to clear the status of "/afs" in the root filesystem from screwing up basic system opertations that check anytingn in /. It's never worked well.

For the in-kernel AFS client to "work out of the box", it must mount the dynamic root on /afs. That is what people who use AFS generally expect.

And it destabilizes the client by locking up any queries of "/", mandating a reboot at least once a week. I first encountered that issue in the 1980's, and again lat MIT in the 1990's. Since those systems all got forced reboots anyway, on at least a weekly basis even if someone was logged into the workstations, it was And over time, it was deemed pretty pointless with autofs enabled NFS mounting thgouth "/net/$SERVERNAME/". As best I can tell, the "/afs/" automounting generated lockups of the "/" directory was never fixed. Do you have any experience that contradicts this weekly reboot requirement?

I'm not insisting it's not been fixed, but it was a big pain at the time.

...

By the way, I've dealt with /afs style automounting before, and it was a nightmare to clean up after when it inevitably croaked precisely due to the root filesystem location of "/afs".

"a nightmare to clean up"? "inevitably croaked"? "precisely due to the root filesystem location"? Please elaborate.

See above. It hung up kernel "stat" operations on the "/" directory, with increasing delays over the course of roughly a week until it could be cleared only by a reboot. It's a not an unheard of problem with confused mountpoints of any type that are mounted directly under "/", and it's one of the reasons the FSH delegates subdirectories.

"umount /afs" or "systemctl stop afs.mount" will unmount the kafs (the in-kernel afs filesystem) dynroot and all its automounts. Note that kafs works differently to, say, OpenAFS. OpenAFS has a single superblock that is the entire AFS namespace and every volume, every vnode you access appears in there. kafs, however, creates a superblock for each volume and uses the d_automount dentry operation to operate AFS mount points.

David

According to the Linux kernel notes about KAFS:

This filesystem provides a fairly simple secure AFS filesystem driver. It is under development and does not yet provide the full feature set. The documentation is at https://www.kernel.org/doc/Documentation/filesystems/afs.txt, and says:

The features it does support include:

(*) Security (currently only AFS kaserver and KerberosIV tickets). (*) File reading and writing. (*) Automounting. (*) Local caching (via fscache). It does not yet support the following AFS features: (*) pioctl() system call.

Does this sound ready for general Fedora use?

On Fri, May 03, 2019 at 03:25:25PM -0400, Nico Kadel-Garcia wrote:

On Fri, May 3, 2019 at 5:22 AM David Howells dhowells@redhat.com wrote:

...

Well, there's 35 years of history, expectation, experience, documentation and scripting for a start that expect the global AFS namespace to be mounted on /afs on a UNIX box (Windows is different).

Including the fact that, since its invention, it has *always* demanded a reboot of the client using it to clear the status of "/afs" in the root filesystem from screwing up basic system opertations that check anytingn in /. It's never worked well.

And it destabilizes the client by locking up any queries of "/", mandating a reboot at least once a week. I first encountered that issue in the 1980's, and again lat MIT in the 1990's. Since those systems all got forced reboots anyway, on at least a weekly basis even if someone was logged into the workstations, it was And over time, it was deemed pretty pointless with autofs enabled NFS mounting thgouth "/net/$SERVERNAME/". As best I can tell, the "/afs/" automounting generated lockups of the "/" directory was never fixed. Do you have any experience that contradicts this weekly reboot requirement?

See above. It hung up kernel "stat" operations on the "/" directory, with increasing delays over the course of roughly a week until it could be cleared only by a reboot. It's a not an unheard of problem with confused mountpoints of any type that are mounted directly under "/", and it's one of the reasons the FSH delegates subdirectories.

(I put all your comments into one block)

None of the problems you've described sound familiar to me at all, however I've only been using AFS since 1999. Unsurprisingly, there have been improvements in the code, and the in-kernel AFS client is a completely different client than the Transarc client from your era and also different from a modern OpenAFS client.

There are legacy isssues with runaway updatedb or find processes getting lost in /afs, but you'd get that in any sufficiently large complex NFS shares with hard mounts. And as with autofs, the dynamic AFS mounting with the kAFS module would not show any subdirectories to be traversed by an automated process.

According to the Linux kernel notes about KAFS:

This filesystem provides a fairly simple secure AFS filesystem driver. It is under development and does not yet provide the full feature set. The documentation is at https://www.kernel.org/doc/Documentation/filesystems/afs.txt, and says:

The features it does support include:

(*) Security (currently only AFS kaserver and KerberosIV tickets). (*) File reading and writing. (*) Automounting. (*) Local caching (via fscache). It does not yet support the following AFS features: (*) pioctl() system call.

Does this sound ready for general Fedora use?

It looks like the documentation describing the features was last updated in 2009. There's been significant effort in the past year to improve the in-kernel AFS code. I'll ask if maybe we can get that file updated with more recent features.

I know that I've been using it exclusively with krb5 tickets for months for read and write. I also know that the pioctl() system call support will never happen, and is being replaced with other methods.

Nico Kadel-Garcia nkadel@gmail.com wrote:

...

I really don't want to have to tell ordinary users that "you can't use this unless you first go and write some systemd scripting".

If you're willing to take on the work to activate afs dependent structures and components, it becomes your responsibility to integrate it well.

By "you" are you referring to me personally, or anyone wanting to use the kafs client?

If you're referring to someone wanting to just use the kafs client, why should they need to do anything other than install kafs-client? Say they're a student at a university that has an already-existing AFS infrastructure. They should just be able to install kafs-client, then they should immediately be able access the infrastructure with no required local configuration, provided the infrastructure includes DNS SRV or AFSDB records telling kafs where to find the cell's Volume Location servers and appropriate kerberos servers.

...

...

\And violating a much more important, namely the File System Hiearchy. If you can find a good reason to violate that, publish your reasoning.

Well, there's 35 years of history, expectation, experience, documentation and scripting for a start that expect the global AFS namespace to be mounted on /afs on a UNIX box (Windows is different).

Including the fact that, since its invention, it has *always* demanded a reboot of the client using it to clear the status of "/afs" in the root filesystem from screwing up basic system opertations that check anytingn in /. It's never worked well.

Perhaps kafs is different?

You can unmount things in /afs directly. You can evict all unbusy mounted cells by:

for i in /afs/*; do umount $i; done

But to some extent what you're describing is not the fault of AFS, no matter the client driver. Whatever is trawling the rootfs can observe the crossing into a separate filesystem. I should make statx() set attributes to tell you that (a) it's a general automounter, (b) it's a network filesystem and (c) the dirs are automount points - then the trawlers can work out for themselves to leave this alone.

...

For the in-kernel AFS client to "work out of the box", it must mount the dynamic root on /afs. That is what people who use AFS generally expect.

And it destabilizes the client by locking up any queries of "/", mandating a reboot at least once a week. I first encountered that issue in the 1980's, and again lat MIT in the 1990's. Since those systems all got forced reboots anyway, on at least a weekly basis even if someone was logged into the workstations, it was And over time, it was deemed pretty pointless with autofs enabled NFS mounting thgouth "/net/$SERVERNAME/". As best I can tell, the "/afs/" automounting generated lockups of the "/" directory was never fixed. Do you have any experience that contradicts this weekly reboot requirement?

kafs and AF_RXRPC have been written from scratch, sharing zero code with OpenAFS, Transarc or whatever you were using in the 1980s and 1990s.

I'm not insisting it's not been fixed, but it was a big pain at the time.

...

...

By the way, I've dealt with /afs style automounting before, and it was a nightmare to clean up after when it inevitably croaked precisely due to the root filesystem location of "/afs".

"a nightmare to clean up"? "inevitably croaked"? "precisely due to the root filesystem location"? Please elaborate.

See above. It hung up kernel "stat" operations on the "/" directory, with increasing delays over the course of roughly a week until it could be cleared only by a reboot. It's a not an unheard of problem with confused mountpoints of any type that are mounted directly under "/", and it's one of the reasons the FSH delegates subdirectories.

What's mounted on /afs by kafs is a pseudo-volume that's not backed by the network. Think of it as kafs's own automounter. Doing a stat on it is a trivial operation. Directories can be made in it by lookup of cell names (or by preloading).

...

"umount /afs" or "systemctl stop afs.mount" will unmount the kafs (the in-kernel afs filesystem) dynroot and all its automounts. Note that kafs works differently to, say, OpenAFS. OpenAFS has a single superblock that is the entire AFS namespace and every volume, every vnode you access appears in there. kafs, however, creates a superblock for each volume and uses the d_automount dentry operation to operate AFS mount points.

David

According to the Linux kernel notes about KAFS:

This filesystem provides a fairly simple secure AFS filesystem driver. It is under development and does not yet provide the full feature set. The documentation is at https://www.kernel.org/doc/Documentation/filesystems/afs.txt, and says:

The features it does support include:

(*) Security (currently only AFS kaserver and KerberosIV tickets). (*) File reading and writing. (*) Automounting. (*) Local caching (via fscache). It does not yet support the following AFS features: (*) pioctl() system call.

Does this sound ready for general Fedora use?

That's a bit out of date. See:

https://www.infradead.org/~dhowells/kafs/ https://www.infradead.org/~dhowells/kafs/todo.html

The pioctl thing is the most vexing bit. Linus point-blank refuses to let the pioctl interface into the code, so I'm having to build in workarounds:

https://www.infradead.org/~dhowells/kafs/user_interface.html

David

Nico Kadel-Garcia nkadel@gmail.com wrote:

...

...

...

I really don't want to have to tell ordinary users that "you can't use this unless you first go and write some systemd scripting".

If you're willing to take on the work to activate afs dependent structures and components, it becomes your responsibility to integrate it well.

By "you" are you referring to me personally, or anyone wanting to use the kafs client?

Anyone willing to do the work.

Do *what* work? Do you mean setting up an entire AFS cell and configuring all the servers?

...

If you're referring to someone wanting to just use the kafs client, why should they need to do anything other than install kafs-client? Say they're a student at a university that has an already-existing AFS infrastructure. They should just be able to install kafs-client, then they should immediately be able access the infrastructure with no required local configuration, provided the infrastructure includes DNS SRV or AFSDB records telling kafs where to find the cell's Volume Location servers and appropriate kerberos servers.

Say they're not, and need some other distinct setup. If it's standardized, as is seeming more apparent from the existing SELinux hooks, OK. Perhaps it's worth adding to the FSH, if it's such a standard usage?

The case I'm trying to make simplest is someone who just needs to gain access to an already existing AFS infrastructure. It can be made such that someone in that position has to do zero configuration, apart from installing the kafs-client package.

Anyone who wants to do anything more interesting, will have to do their own configuration, but the kafs-client rpm contains stuff that can be used as a template.

If you happen to be so inclined, kafs is almost completely network-namespace aware and can be used in containerised environments. You can mount individual volumes directly if you wish. The bits that aren't in place yet are the request-key upcall namespacing, which I'm working on, and the ability to provide keys to a container from the outside - which I'm also working on.

...

But to some extent what you're describing is not the fault of AFS, no matter the client driver. Whatever is trawling the rootfs can observe the crossing into a separate filesystem. I should make statx() set attributes to tell you

Not without getting the directory information about "/" to report information about that unique node. You see the problem?

No. That's something statx() should be able to tell you. Now, I will grant that at the moment it won't tell you that what is mounted on /afs is a magic dir full of automount points, but it *will* set STATX_ATTR_AUTOMOUNT on each inode that is an automount point. This is done by the core kernel for each inode that is flagged S_AUTOMOUNT internally.

...

That's a bit out of date. See:

    https://www.infradead.org/~dhowells/kafs/
    https://www.infradead.org/~dhowells/kafs/todo.html

The pioctl thing is the most vexing bit. Linus point-blank refuses to let the pioctl interface into the code, so I'm having to build in workarounds:

    https://www.infradead.org/~dhowells/kafs/user_interface.html

David

I'd be inclined to take Linux's opinion over yours on the matter. Not to question your personal expertise, but he's earned a lot of trust for his successful authorship and insight in the Linux kernel.

I should rotfl at that one! Besides, who said my opinion of the pioctl interface doesn't coincide with Linus's?

The reason I was trying to build pioctl into the kernel - or, at least, the kafs filesystem - is so that OpenAFS's toolset could be used directly with kafs. But the pioctl interface has been somewhat, um, abused, so Linus's position is understandable (and it's not just Linus who holds this opinion, I should add).

I'm curious what AFS is providing over NFSv4 and autofs based mounts?

Access to 35 years worth of existing AFS infrastructure and the data stored therein, through a global namespace with server transparency.

But this is really for other people to answer, and I suspect the answers may differ by organisation.

David

On Fri, May 3, 2019 at 9:13 PM jaltman jaltman@auristor.com wrote:

...

Say they're not, and need some other distinct setup. If it's standardized, as is seeming more apparent from the existing SELinux hooks, OK. Perhaps it's worth adding to the FSH, if it's such a standard usage?

The use of /afs as the default location to mount a cell's root volume "root.afs" dates back at least as far as 1989. Throughout the 90s /afs became the root of the public global AFS file namespace. Organizations that deployed AFS for private namespaces did use other top-level mounts but all of the worldwide public namespace paths are rooted at /afs regardless of operating system; even AFS on Windows uses the \AFS UNC path that is canonically equivalent to /afs.

I believe that /afs should be added to the FHS as the standard mount for the public AFS and AuriStorFS file namespace. All recent AFS-family clients will interpret the path component below /afs/ as a cell name and search for the cell's location servers in DNS using SRV or AFSDB records. This permits any individual or organization that controls a domain to standup storage that can be accessed from any internet connected device with close to zero configuration provided the required access requirements are met.

Then I think you want the fhs-discuss mailing list, to help this get through, at https://lists.linux-foundation.org/mailman/listinfo/fhs-discuss. It's a pretty quiet list, so there may be a more active relevant chat channel. Does anyone else know of a more active list or channel to update the FHS ?