10:28 p.m.
TL;DR:
I have implemented NFSv4 -> POSIX ACL mapping in FSAL_VFS. I would
like to submit a simplified version that doesn't attempt to build on
FreeBSD. That would vastly simplify the code and reduce the amount of
review required. It would look something like this:
https://github.com/martin-schwenke/nfs-ganesha/commits/vfs-acls-no-freebsd
Some of the "build" commits could be squashed together if desired.
Details:
I have implemented NFSv4 -> POSIX ACL mapping in FSAL_VFS. Once I
understood what needed to be done, this was a fairly simple plumbing
job... apart from FreeBSD compatibility.
This is currently sitting in
https://github.com/martin-schwenke/nfs-ganesha/commits/vfs-acls
However, before putting it up for review, I have some questions,
mostly about FreeBSD support.
First, the ACL part of the discussion...
Although FreeBSD supports POSIX ACLs, I don't think anyone wants to use
a mapping to POSIX ACLs on FreeBSD. I think they would want to use
FreeBSD's NFSv4 ACLs on ZFS. That would mean including some entirely
different hunks of code in src/FSAL/FSAL_VFS/vfs/attrs.c, or perhaps
even src/FSAL/FSAL_VFS/zfs/. I think my attempts at fixing the FreeBSD
build (see below) show that I'm not qualified to attempt this. It
should be done by an experienced FreeBSD developer.
Now for the build problems...
While getting this to compile I found several places where NFS Ganesha
wouldn't compile on FreeBSD. Some of this might be because I was using
the default clang compiler, but switching to gcc made things fail in
different places, so I stuck with the default.
The simplest solution was this:
cmake -DUSE_9P=OFF -DUSE_NFS3=OFF \
-DUSE_FSAL_PROXY_V4=OFF -DUSE_FSAL_GPFS=OFF \
-DUSE_GSS=OFF \
../nfs-ganesha/src
Then I only needed a couple the first couple of fixes from:
https://github.com/martin-schwenke/nfs-ganesha/commits/freebsd-build-fixes
* If I switch on 9p and NFS3 then I need the rest, but those "fixes"
become increasingly dodgy.
* It seems clear that the GPFS support should be more cooperative about
disabling itself without being forced off. I'll look into that some
other time.
* Building with GSS support has link-time problems resolving symbols in
Kerberos libraries. My lack of understanding about FreeBSD's different
Kerberos versions and how to make them play nicely with cmake made me
shrug my shoulders and move on. This isn't fixed in the above branch.
* I'm happy to take advice on which of the above fixes I should submit
for upstream inclusion. The first 3 or 4 seem fairly obvious.
In summary, the FreeBSD build seems quite broken. NFS Ganesha was
removed from FreeBSD's ports and it seems that not many people care.
If people agree then, to simplify the code, I can drop all of the
FreeBSD compatibility and only enable the ACL mapping if Linux's
acl/libacl.h is available.
Thanks...
peace & happiness,
martin
9:21 a.m.
I have implemented NFSv4 -> POSIX ACL mapping in FSAL_VFS. I
would like to
submit a simplified version that doesn't attempt to build on FreeBSD. That
would vastly simplify the code and reduce the amount of review required. It
would look something like this:
https://github.com/martin-schwenke/nfs-ganesha/commits/vfs-acls-no-
freebsd
Some of the "build" commits could be squashed together if desired.
That sounds like a reasonable way to proceed. Please do squash commits as appropriate.
TLDR: FreeBSD has never had long term committed support. We just barely have the resources
to maintain the stuff we use so adding FreeBSD maintenance would be too much. Please feel
free to not attempt to make FreeBSD work.
Details:
I have implemented NFSv4 -> POSIX ACL mapping in FSAL_VFS. Once I
understood what needed to be done, this was a fairly simple plumbing job...
apart from FreeBSD compatibility.
This is currently sitting in
https://github.com/martin-schwenke/nfs-ganesha/commits/vfs-acls
However, before putting it up for review, I have some questions, mostly about
FreeBSD support.
First, the ACL part of the discussion...
Although FreeBSD supports POSIX ACLs, I don't think anyone wants to use a
mapping to POSIX ACLs on FreeBSD. I think they would want to use FreeBSD's
NFSv4 ACLs on ZFS. That would mean including some entirely different hunks of
code in src/FSAL/FSAL_VFS/vfs/attrs.c, or perhaps even src/FSAL/FSAL_VFS/zfs/.
I think my attempts at fixing the FreeBSD build (see below) show that I'm not
qualified to attempt this. It should be done by an experienced FreeBSD
developer.
A "full" solution would be to support both paths... And yea, a zfs sub-FSAL
would be the way to handle the availability of NFSv4 native ACLs.
Now for the build problems...
While getting this to compile I found several places where NFS Ganesha
wouldn't compile on FreeBSD. Some of this might be because I was using the
default clang compiler, but switching to gcc made things fail in different places,
so I stuck with the default.
The simplest solution was this:
cmake -DUSE_9P=OFF -DUSE_NFS3=OFF \
-DUSE_FSAL_PROXY_V4=OFF -DUSE_FSAL_GPFS=OFF \
-DUSE_GSS=OFF \
../nfs-ganesha/src
Then I only needed a couple the first couple of fixes from:
https://github.com/martin-schwenke/nfs-ganesha/commits/freebsd-build-
fixes
* If I switch on 9p and NFS3 then I need the rest, but those "fixes"
become increasingly dodgy.
* It seems clear that the GPFS support should be more cooperative about
disabling itself without being forced off. I'll look into that some
other time.
Yea, that might be good.
* Building with GSS support has link-time problems resolving symbols
in
Kerberos libraries. My lack of understanding about FreeBSD's different
Kerberos versions and how to make them play nicely with cmake made me
shrug my shoulders and move on. This isn't fixed in the above branch.
* I'm happy to take advice on which of the above fixes I should submit
for upstream inclusion. The first 3 or 4 seem fairly obvious.
I suppose we could take a set of fixes for FreeBSD but I'm not sure how worthwhile
that is if we are not committing to full support. What might be an option is to push your
FreeBSD fixes branch into the nfs-ganesha Github repo so someone coming along later
wanting to make FreeBSD work again could look to those patches to jump start their
efforts.
In summary, the FreeBSD build seems quite broken. NFS Ganesha was
removed
from FreeBSD's ports and it seems that not many people care.
If there's no visible "champion" for FreeBSD, we should let it drift back
into bit rot.
If people agree then, to simplify the code, I can drop all of the
FreeBSD
compatibility and only enable the ACL mapping if Linux's acl/libacl.h is available.
Yes, please do so.
Thanks for this effort
Frank
9:59 a.m.
On 4/12/22 10:21, Frank Filz wrote:
> I have implemented NFSv4 -> POSIX ACL mapping in FSAL_VFS. I
would like to
> submit a simplified version that doesn't attempt to build on FreeBSD. That
> would vastly simplify the code and reduce the amount of review required. It
> would look something like this:
>
> https://github.com/martin-schwenke/nfs-ganesha/commits/vfs-acls-no-
> freebsd
>
> Some of the "build" commits could be squashed together if desired.
That sounds like a reasonable way to proceed. Please do squash commits as appropriate.
TLDR: FreeBSD has never had long term committed support. We just barely have the
resources to maintain the stuff we use so adding FreeBSD maintenance would be too much.
Please feel free to not attempt to make FreeBSD work.
Unless you'd like to help support FreeBSD. If that's the case, we're
happy to have help maintaining it.
Daniel
3:20 a.m.
On Tue, 12 Apr 2022 10:59:54 -0400, Daniel Gryniewicz <dang(a)redhat.com>
wrote:
On 4/12/22 10:21, Frank Filz wrote:
> TLDR: FreeBSD has never had long term committed support. We
just
> barely have the resources to maintain the stuff we use so adding
> FreeBSD maintenance would be too much. Please feel free to not
> attempt to make FreeBSD work.
Unless you'd like to help support FreeBSD. If that's the
case, we're
happy to have help maintaining it.
No thanks. I spent enough time trying to make this work on FreeBSD
that I'm convinced my time is better spent elsewhere. :-)
On the other hand, if the FreeBSD build is magically fixed then I would
commit to not breaking it in future commits. That's much easier...
peace & happiness,
martin
3:30 a.m.
On Tue, 12 Apr 2022 07:21:29 -0700, "Frank Filz"
<ffilzlnx(a)mindspring.com> wrote:
> I have implemented NFSv4 -> POSIX ACL mapping in FSAL_VFS. I
would like to
> submit a simplified version that doesn't attempt to build on FreeBSD. That
> would vastly simplify the code and reduce the amount of review required. It
> would look something like this:
>
> https://github.com/martin-schwenke/nfs-ganesha/commits/vfs-acls-no-
> freebsd
>
> Some of the "build" commits could be squashed together if desired.
That sounds like a reasonable way to proceed. Please do squash
commits as appropriate.
Thanks for the feedback.
I did some more cleanups and got it down to 9 commits. The commits
should be nice and easy to review the way they are. I'm happy to
accept any other suggestions for more squashing. I come from a Samba
background, where tiny, simple-to-review patches are the norm.
Latest is also at:
https://github.com/martin-schwenke/nfs-ganesha/commits/vfs-acls
One of the commits has a bit of commentary where I've probably got the
cmake-fu wrong. Heh, that probably applies to other commits too... :-)
I suppose we could take a set of fixes for FreeBSD but I'm not
sure
how worthwhile that is if we are not committing to full support. What
might be an option is to push your FreeBSD fixes branch into the
nfs-ganesha Github repo so someone coming along later wanting to make
FreeBSD work again could look to those patches to jump start their
efforts.
I'll keep my branches around and hopefully anyone how comes across this
thread can find them. Happy to push them somewhere else too.
[...]
If there's no visible "champion" for FreeBSD, we should
let it drift
back into bit rot.
Yep, I think this is true. It seems to be a platform that requires
expertise to develop for...
> If people agree then, to simplify the code, I can drop all of
the
> FreeBSD compatibility and only enable the ACL mapping if Linux's
> acl/libacl.h is available.
Yes, please do so.
Done. Pushed to gerrithub.
peace & happiness,
martin
1:55 p.m.
-----Original Message-----
From: Martin Schwenke [mailto:martin@meltin.net]
Sent: Wednesday, April 13, 2022 1:30 AM
To: Frank Filz <ffilzlnx(a)mindspring.com>
Cc: devel(a)lists.nfs-ganesha.org
Subject: [NFS-Ganesha-Devel] Re: FSAL_VFS ACL mapping and FreeBSD
On Tue, 12 Apr 2022 07:21:29 -0700, "Frank Filz"
<ffilzlnx(a)mindspring.com> wrote:
> > I have implemented NFSv4 -> POSIX ACL mapping in FSAL_VFS. I would
> > like to submit a simplified version that doesn't attempt to build on
> > FreeBSD. That would vastly simplify the code and reduce the amount
> > of review required. It would look something like this:
> >
> >
> > https://github.com/martin-schwenke/nfs-ganesha/commits/vfs-acls-no-
> > freebsd
> >
> > Some of the "build" commits could be squashed together if desired.
>
> That sounds like a reasonable way to proceed. Please do squash commits
> as appropriate.
Thanks for the feedback.
I did some more cleanups and got it down to 9 commits. The commits should be
nice and easy to review the way they are. I'm happy to accept any other
suggestions for more squashing. I come from a Samba background, where tiny,
simple-to-review patches are the norm.
Thanks, maybe a bit more squashing of the cmake stuff.
We tend to a bit larger commits, but smaller commits are fine also.
Latest is also at:
https://github.com/martin-schwenke/nfs-ganesha/commits/vfs-acls
One of the commits has a bit of commentary where I've probably got the
cmake-fu wrong. Heh, that probably applies to other commits too... :-)
> I suppose we could take a set of fixes for FreeBSD but I'm not sure
> how worthwhile that is if we are not committing to full support. What
> might be an option is to push your FreeBSD fixes branch into the
> nfs-ganesha Github repo so someone coming along later wanting to make
> FreeBSD work again could look to those patches to jump start their
> efforts.
I'll keep my branches around and hopefully anyone how comes across this
thread can find them. Happy to push them somewhere else too.
> [...]
> If there's no visible "champion" for FreeBSD, we should let it drift
> back into bit rot.
Yep, I think this is true. It seems to be a platform that requires expertise to
develop for...
> > If people agree then, to simplify the code, I can drop all of the
> > FreeBSD compatibility and only enable the ACL mapping if Linux's
> > acl/libacl.h is available.
> Yes, please do so.
Done. Pushed to gerrithub.
Thanks
Frank
751
days inactive
752
days old
5 comments
3 participants
participants (3)
-
Daniel Gryniewicz -
Frank Filz -
Martin Schwenke