<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html;
      charset=windows-1252">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hey Carl,<br>
    <br>
      Are the 4 RFEs I've sent you Q2/18 under this new system or do I
    need to resubmit them?<br>
    <br>
    Jez<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 26/09/18 18:40, Simon Thompson
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:CF45EE16DEF2FE4B9AA7FF2B6EE26545F5B723F3@EX13.adf.bham.ac.uk">
      <pre wrap="">Don't forget we have the upcoming pitch you RFE online meeting.

RFEs have not been flooding in and registrations for the pitch meeting are rather thin on the ground...

Simon
________________________________________
From: <a class="moz-txt-link-abbreviated" href="mailto:gpfsug-discuss-bounces@spectrumscale.org">gpfsug-discuss-bounces@spectrumscale.org</a> [<a class="moz-txt-link-abbreviated" href="mailto:gpfsug-discuss-bounces@spectrumscale.org">gpfsug-discuss-bounces@spectrumscale.org</a>] on behalf of Jonathan Buzzard [<a class="moz-txt-link-abbreviated" href="mailto:jonathan.buzzard@strath.ac.uk">jonathan.buzzard@strath.ac.uk</a>]
Sent: 26 September 2018 18:13
To: gpfsug main discussion list
Subject: Re: [gpfsug-discuss] replicating ACLs across GPFS's?

On Tue, 2018-09-25 at 17:22 +0000, Bryan Banister wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">Thanks Simon,

I tried out the older patched version of rsync to see if that would
work, but still not able to preserve ACLs from an non-GPFS source.
There was another thread about this on the user group some time ago
as well (2013!), but doesn’t look like any real solution was found
(Copy ACLs from outside sources).

I’ve also tried tar | tar, but not luck with that either.

GPFS doesn’t support the nfs4_getacl, nfs4_setfacl, nfs4_editfacl
suite of commands, but maybe that coulnfs4_acl_for_path.d be added??

</pre>
      </blockquote>
      <pre wrap="">
Well no they work completely differently. However I did write about
this last month. You can do this by modifying just nfs4_acl_for_path.c
and nfs4_set_acl.c so they read/write the GPFS ACL struct and convert
between the GPFS representation and the internal data structure used by
the nfs4-acl-tools to hold NFSv4 ACL's. I have it working for
nfs4_getacl. Though this in of itself gets nothing over mmgetacl, other
than proving the concept valid. I don't have a test GPFS cluster these
days so I need to tread very lightly.

However I had some questions that I was hoping someone from IBM might
answer but didn't and have been busy since. Namely

 1. What's the purpose of a special flag to indicate that it is smbd
    setting the ACL? Does this tie in with the undocumented "mmchfs -k
    samba" feature?

 2. There is a whole bunch of stuff in the documentation about v4.1
    ACL's. How does one trigger that. All I seem to be able to do is
    get POSIX and v4 ACL's. Do you get v4.1 ACL's if you set the file
    system to "Samba" ACL's?

</pre>
      <blockquote type="cite">
        <pre wrap="">I could maybe hack something up that would basically crawl the
“outside source” namespace, using the nfs4_getacl operation get the
NFSv4 ACLs, parse that output, then attempt to use GPFS `mmputacl` to
store the ACL again.  This seems like a horrible way to go, likely
prone to mistakes, tough to validate, nightmare to maintain.

</pre>
      </blockquote>
      <pre wrap="">
I have said it before and will say it again,  mmputacl is an
abomination that needs to be put down with extreme prejudice.

I still think that longer term it would be better to modify FreeBSD's
setfacl/getfacl (say renamed to mmsetfacl and mmgetfacl) to do the job,
on the basis that they handle both POSIX and NFSv4 ACL's in a
single command. Though strictly speaking you only need an mmsetfacl.

Perhaps a RFE?

JAB.

--
Jonathan A. Buzzard                         Tel: +44141-5483420
HPC System Administrator, ARCHIE-WeSt.
University of Strathclyde, John Anderson Building, Glasgow. G4 0NG


_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
<a class="moz-txt-link-freetext" href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a>
_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
<a class="moz-txt-link-freetext" href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a>
</pre>
    </blockquote>
    <br>
    <div class="moz-signature">-- <br>
      <div>
        <font face="arial" color="#000000">
          <b>Jez Tucker</b><br>
          Head of Research and Development, Pixit Media<br>
          07764193820 <font color="#FF0000">|</font> <a
            href="mailto:jtucker@pixitmedia.com">jtucker@pixitmedia.com</a><br>
          <a href="http://www.pixitmedia.com">www.pixitmedia.com</a> <font
            color="#FF0000">|</font> <a
            href="https://twitter.com/PixitMedia">Tw:@pixitmedia.com</a><br>
        </font>
      </div>
    </div>
  </body>
</html>

<br>
<div><a href="http://pixitmedia.com" target="_blank"><img src="http://pixitmedia.com/sig/sig-bve2018.jpg"></a><font face="Arial, Helvetica, sans-serif" size="1"><br>This email is confidential in that it is intended for the exclusive attention of the addressee(s) indicated. If you are not the intended recipient, this email should not be read or disclosed to any other person. Please notify the sender immediately and delete this email from your computer system. Any opinions expressed are not necessarily those of the company from which this email was sent and, whilst to the best of our knowledge no viruses or defects exist, no responsibility can be accepted for any loss or damage arising from its receipt or subsequent use of this email.</font></div>