RE: ACL Problem in SL7.2

2016-11-07 Thread Bill Maidment 
Hi again
My research has revealed that nfs in SL 7.2 is translating the POSIX ACL to 
NFSv4 ACL (a completely different format).
vi appears to recognise NFSv4 ACL, but Nautilus, ls and probably other 
programs, only seem to recognise POSIX ACL.

So I have the following alternatives:
1. Stop nfs translating to NFSv4 ACL
2. Change the guest mount to translate NFSv4 ACL back to POSIX ACL
3. Change Nautilus, etc to recognise NFSv4 ACL
4. Use Samba instead of nfs

I'm not sure if 1. or 2. are possible and 3. may happen one day. Does anyone 
know of a practical solution/workaround?
Cheers
Bill
 
-Original message-
> From:Bill Maidment 
> Sent: Sunday 6th November 2016 19:56
> To: Karel Lang AFD ; SCIENTIFIC-LINUX-USERS@FNAL.GOV
> Subject: RE: ACL Problem in SL7.2
> 
> Thanks for the response Karel.
> umask is the standard 0022 and this is a top level directory on the host 
> machine.
> I am using SL 6.8 to access the directory via nfs share.
> It looks like there is no problem if the file is created with vi
> But if I use Nautilus then that's when I get the issue.
> So Nautilus on SL 6.8 seems to be the culprit (or is it caused by nfs?)
> Cheers
> Bill
> 
> -Original message-
> > From:Karel Lang AFD 
> > Sent: Sunday 6th November 2016 16:16
> > To: Bill Maidment ; SCIENTIFIC-LINUX-USERS@FNAL.GOV
> > Subject: Re: ACL Problem in SL7.2
> > 
> > Hi Bill
> > just pasted your work here to CLI and works OK on SL 6.7 and SL 7.2 here...
> > It has to be something else .. umask? or inherited from directory higher up?
> > Maybe strace would help to see whats happening exactly?
> > 
> > cheers
> > 
> > On 11/06/2016 03:58 AM, Bill Maidment wrote:
> > > Hi
> > > I am trying to set up ACL on a directory such that any new file created 
> > > in the directory has permissions of 0660.
> > > However, when I create a new file, the permissions are set as 0664 (see 
> > > test.txt file below)
> > > Is this a bug or am I doing something wrong?
> > >
> > > These are the commands I used:
> > >
> > > chmod -R u+rwX,g+rwXs,o-rwx /pictures
> > >
> > > setfacl -d -m u::rwx,g::rwx,o::--- /pictures
> > >
> > > getfacl /pictures
> > > getfacl: Removing leading '/' from absolute path names
> > > # file: pictures
> > > # owner: nfs01
> > > # group: nfs01
> > > # flags: -s-
> > > user::rwx
> > > group::rwx
> > > other::---
> > > default:user::rwx
> > > default:group::rwx
> > > default:other::---
> > >
> > > ls -latrh /pictures
> > > total 4.0K
> > > dr-xr-xr-x. 22 root  root  4.0K Nov  6 12:41 ..
> > > drwxrws---+  2 nfs01 nfs01   21 Nov  6 13:10 Testing
> > > -rw-rw-r--   1 nfs01 nfs010 Nov  6 13:44 test.txt
> > > drwxrws---+  3 nfs01 nfs01   35 Nov  6 13:44 .
> > >
> > > Cheers
> > > Bill Maidment
> > >
> > 
> > 
> 
>

Re: How I upgrade Krusader to 2.5.0 on Red Hat

2016-11-07 Thread Mark Whidby 
On Fri, 2016-11-04 at 11:59 +0100, David Sommerseth wrote:
> On 04/11/16 11:13, Todd Chester wrote:
> > On 11/03/2016 04:38 AM, Nico Kadel-Garcia wrote:
> > 
> >> Or, you could try what I do for backports. Install "mock", add
> >> yourself to the "mock" group, and run:
> >>
> >>   mock -r epel-7-x86_64 krusader-2.5.0-1.fc26.src.rpm
> >>
> >> Then install RPMs from /var/lib/mock/ or /var/cache/mock/
> > 
> > What is "mock"?
> 
> That is the a build tool which does all the RPM builds inside a fresh,
> autocreated chroot to ensure you get a clean build.  If the spec file is
> lacking needed dependencies, the build will fail.  Which again helps
> preventing creating an RPM package including dependencies which just
> happened to be installed.
> 
> Mock is what is used under the hood of Koji when Fedora packages are
> built (including Fedora EPEL) and the RHEL packages.
> 
> Mock also allows you to build RPMs for multiple distributions/versions
> on the same host.  The chroot will contain the proper version of
> libraries, compilers and linkers so it will match the environment the
> RPM is targeted at.
> 
> I highly encourage everyone using rpmbuild to use mock instead.  When a
> mock built package have completed, it will have a far higher success
> factor on all hosts it will be installed on.  Plus, it is built in a
> much "cleaner" and pristine environment.
> 
> 

I struggled with mock until I found this "getting started" guide:

http://blog.packagecloud.io/eng/2015/05/11/building-rpm-packages-with-mock/

I hope this helps someone as much as it helped me.

-- 
Mark Whidby
System Administrator/Operations
IT Services