How to install a mountpoint directory from an rpm?

[David Howells]

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.

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:

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


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

Thanks,
David

[Robert Marcano]

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.
>  
>  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/hea...
>  
>  
>  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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>

[Zbigniew Jędrzejewski-Szmek]

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&oldi...
(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/hea...
> >
> >
> >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(a)lists.fedoraproject.org
> >To unsubscribe send an email to devel-leave(a)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/[e-mail]
> >
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/[e-mail]

[Stephen John Smoogen]

On Tue, 30 Apr 2019 at 13:30, Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl&gt;
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.
>
>  Nope. New top-level directories are a big thing and need FPC approval:
>
>
> https://fedoraproject.org/w/index.php?title=Packaging:Guidelines&oldi...
>  (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.
>
>  
Where to mount Andrew Filesystems in Linux distributions is one of those
perennial arguments... which I think we really hope will go away because
who uses AFS anymore... [turns out a lot of sites do.. mainly because they
did N years ago and don't have the forklifts to fix it. Just like ypbind...
] Conventions says it is mounted as /afs and then dealt with elsewhere but
that is also been seen as against various filesystems and such. Linux
conventions say it would need distribution approval to break the FHS (which
was last updated in 2004???) .



>  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/hea...
>  > >
>  > >
>  > >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(a)lists.fedoraproject.org
>  > >To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  > >
>  > _______________________________________________
>  > devel mailing list -- devel(a)lists.fedoraproject.org
>  > To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 
Stephen J Smoogen.

[Robbie Harwood]

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

[Tomasz Torcz]

On Tue, Apr 30, 2019 at 05:29:17PM +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.
>  
>  Nope. New top-level directories are a big thing and need FPC approval:
>
> https://fedoraproject.org/w/index.php?title=Packaging:Guidelines&oldi...
>  (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. 
  Yes. For example, for OWFS we mount at /run/owfs, which we create with
RuntimeDirectory=owfs in owfs.service.


-- 
Tomasz Torcz              ,,If you try to upissue this patchset I shall be seeking
xmpp: zdzichubg(a)chrome.pl   an IP-routable hand grenade.'' -- Andrew Morton
(LKML)

[David Howells]

Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl&gt; 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&oldi...
>  (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]

> >>>> "DH" == David Howells
> <dhowells(a)redhat.com&gt; writes: 
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.

Personally I wouldn't be particularly happy with "/afs" if it were a new
thing, but I'm not sure it's worth fighting with that much history.

 - J<

[David Howells]

Jason L Tibbitts III <tibbs(a)math.uh.edu&gt; 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

[Jonathan Billings]

On Tue, Apr 30, 2019 at 09:40:13PM +0100, David Howells wrote:
>  > 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 
In addition to SELinux rules, the default configuration for mlocate
specifically mentions /afs, see:

    https://src.fedoraproject.org/rpms/mlocate/blob/master/f/updatedb.conf

It'll ignore AFS mounted elsewhere because 'afs' is included in
PRUNEFS, but this is just more evidence that Fedora already expects an
/afs mountpoint, historically.

There's really no question of where AFS will be mounted.  It will be
/afs.  It's mostly a question of whether a Fedora package can set up
that mountpoint, or if it should be left as a partial implementation
that requires the user to run 'mkdir /afs' before starting the
service. 

-- 
Jonathan Billings <billings(a)negate.org&gt;

[Ian Kent]

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&oldi...
>  (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/hea...
>  > > 
>  > > 
>  > > 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(a)lists.fedoraproject.org
>  > > To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  > > 
>  > 
>  > _______________________________________________
>  > devel mailing list -- devel(a)lists.fedoraproject.org
>  > To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]

[Ralf Corsepius]

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, ...).

Ralf

[Stephen John Smoogen]

On Wed, 1 May 2019 at 03:28, Ralf Corsepius <rc040203(a)freenet.de&gt; 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...


-- 
Stephen J Smoogen.

[Stephen Gallagher]

On Wed, May 1, 2019 at 6:10 AM Stephen John Smoogen <smooge(a)gmail.com&gt; 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

[Stephen John Smoogen]

On Wed, 1 May 2019 at 07:01, Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:

>  On Wed, May 1, 2019 at 6:10 AM Stephen John Smoogen
> <smooge(a)gmail.com&gt;
>  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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 
Stephen J Smoogen.

[Nico Kadel-Garcia]

On Tue, Apr 30, 2019 at 8:25 PM Ian Kent <raven(a)themaw.net&gt; 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.

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

>  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&oldi...
>  > (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.

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

[Ian Kent]

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(a)themaw.net&gt;
> 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&oldi...
>  > > (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

[David Howells]

Nico Kadel-Garcia <nkadel(a)gmail.com&gt; wrote:

>  > 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.
>  
>  It's a *Bad Idea(tm), since it violates the File System Hierarchy, but
>  that hardly makes it impossible. 
Note that I don't feel any requirement that the /afs directory should be
installed by the filesystem rpm.  For my purposes, it would be fine if it's
created or installed by the kafs-client rpm or created on demand by the
systemd script for starting the mount.

Note further that there does need to be a systemd script to effect the mount
as this has a dependency on another systemd script that loads the
configuration into the kernel.

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

>  \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).

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.

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

"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

[Nico Kadel-Garcia]

On Fri, May 3, 2019 at 5:22 AM David Howells <dhowells(a)redhat.com&gt; 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?

[Stephen John Smoogen]

On Fri, 3 May 2019 at 15:26, Nico Kadel-Garcia <nkadel(a)gmail.com&gt; wrote:

>  On Fri, May 3, 2019 at 5:22 AM David Howells
> <dhowells(a)redhat.com&gt; wrote:
>
>  > "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?
>  
Sounds more stable than other features we already have in general use. If a
large portion of your rant sounds like 'I ate brocolli when I was a kid and
it was awful then and I am sure it is awful now.' asking if 'does serving
brocolli sound like something Fedora should do?' is not going to get much
weight.. especially when we have been serving brocolli in some form for
years.

 Yes, AFS could lock up your system 30 years ago and even 20 years ago. It
might even do so now.. but we can do so in at least 10 different ways with
containers, virtual machines, or half a dozen other packaged up
applications. The whole arguments for or against AFS have not changed in
the last 30 years.. And rarely do they go past: did you or your professor
go to MIT or CMU? And which was better Andrew or Athena..


-- 
Stephen J Smoogen.

[Jonathan Billings]

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(a)redhat.com&gt; 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.

-- 
Jonathan Billings <billings(a)negate.org&gt;

[jaltman]

>  On Fri, May 03, 2019 at 03:25:25PM -0400, Nico Kadel-Garcia wrote:
>  
>  (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. 
The AFS kernel modules of the IBM era are known to have suffered from the following
limitations and implementation flaws:

1. distributed lock hierarchy violations resulting in distributed dead locks

2. /afs was backed by the configured cell's "root.afs" volume.  If there
were connectivity issues or the fileservers failed to serve the volume, then there could
be extended timeouts

3. most afs servers were configured to restart every Sunday morning and required the
equivalent of "fsck" on every afs volume before restarting which would result in
volumes becoming unavailable for an extended period of time.

4. all location server address information was stored in local configuration files.   If
IP address changes were not reflected in local configuration updates, cache managers would
experience timeouts or loss of access.

These are just a few of the many issues that have been addressed over the decades.  kafs
is a 100% clean room implementation specifically designed for and integrated with the
Linux kernel.  kafs does not mount "root.afs" volumes instead it follows the
"dynamic root" model whereby /afs/ directory entries are evaluated on demand as
cell names using a combination of DNS and local configuration files.  OpenAFS and
AuriStorFS servers are rarely configured for weekly restarts and when they do restart the
startup time is in fractions of a second instead of hours.  kafs attempts to be as
"zero config" as possible.  I'm not sure if there is anything more than
specifying the name of the top-level mount point.

In any case, these implementation defects from the 90s should have no bearing on the
packaging of kafs-client for Fedora.  The AF_RXRPC and AFS kernel features have been
shipping in Fedora kernels distributed with F28, F29, and F30.   The kafs-client package
is the final piece required to permit end users to choose the native Linux implementation
over third-party, out-of-tree, GPL2 license incompatible implementations.  

Sincerely,

Jeffrey Altman

[David Howells]

Nico Kadel-Garcia <nkadel(a)gmail.com&gt; 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]

On Fri, May 3, 2019 at 5:02 PM David Howells <dhowells(a)redhat.com&gt; wrote:
>  Nico Kadel-Garcia <nkadel(a)gmail.com&gt; 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.

>  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?

>  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?

>  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'm
curious what AFS is providing over NFSv4 and autofs based mounts?

[David Howells]

Nico Kadel-Garcia <nkadel(a)gmail.com&gt; 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

[jaltman]

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

Sincerely,

Jeffrey Altman

[Nico Kadel-Garcia]

On Fri, May 3, 2019 at 9:13 PM jaltman <jaltman(a)auristor.com&gt; 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 ?

[Jeffrey Altman]

>  On Fri, May 3, 2019 at 9:13 PM jaltman
> <jaltman(a)auristor.com&gt; wrote:
>  
>  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 ? 
I have submitted a Bugzilla request to the FHS at 

  https://bugs.linuxfoundation.org/show_bug.cgi?id=1438