Trouble using eups distrib install with extended ACLs

heather999 · August 30, 2017, 6:54pm

Hi,
I’m building DMstack (lsst_distrib) at SLAC, using the same version I recently set up at NERSC. It seems extended ACLs were recently enabled on our NFS space and this is causing trouble when cp is used during the build process. I’m wondering if anyone else has experienced this and if there might be a workaround.
Here is a related stack exchange link:

and here’s the tail end of the build.log for apr:

/usr/bin/install -c -m 644 apr.pc /nfs/farm/g/desc/u1/software/redhat6-x86_64-64
bit-devtoolset-3/DMstack/w_2017_26_py3/stack/miniconda3-4.2.12-7c8e67/Linux64/apr/1.5.2/lib/pkgconfig/apr-1.pc
for f in libtool shlibtool; do \
	    if test -f ${f}; then /usr/bin/install -c -m 755 ${f} /nfs/farm/g/de
sc/u1/software/redhat6-x86_64-64bit-devtoolset-3/DMstack/w_2017_26_py3/stack/miniconda3-4.2.12-7c8e67/Linux64/apr/1.5.2/build-1; fi; \
	done
/usr/bin/install -c -m 755 /nfs/farm/g/desc/u1/software/redhat6-x86_64-64bit-devtoolset-3/DMstack/w_2017_26_py3/stack/miniconda3-4.2.12-7c8e67/EupsBuildDir/Linux64/apr-1.5.2/apr-1.5.2/build/mkdir.sh /nfs/farm/g/desc/u1/software/redhat6-x86_64-64bit-devtoolset-3/DMstack/w_2017_26_py3/stack/miniconda3-4.2.12-7c8e67/Linux64/apr/1.5.2/build-1
for f in make_exports.awk make_var_export.awk; do \
	    /usr/bin/install -c -m 644 /nfs/farm/g/desc/u1/software/redhat6-x86_
64-64bit-devtoolset-3/DMstack/w_2017_26_py3/stack/miniconda3-4.2.12-7c8e67/EupsBuildDir/Linux64/apr-1.5.2/apr-1.5.2/build/${f} /nfs/farm/g/desc/u1/software/redhat6-x86_64-64bit-devtoolset-3/DMstack/w_2017_26_py3/stack/miniconda3-4.2.12-7c8e67/Linux64/apr/1.5.2/build-1; \
	done
/usr/bin/install -c -m 644 build/apr_rules.out /nfs/farm/g/desc/u1/software/redh
at6-x86_64-64bit-devtoolset-3/DMstack/w_2017_26_py3/stack/miniconda3-4.2.12-7c8e
67/Linux64/apr/1.5.2/build-1/apr_rules.mk
/usr/bin/install -c -m 755 apr-config.out /nfs/farm/g/desc/u1/software/redhat6-x
86_64-64bit-devtoolset-3/DMstack/w_2017_26_py3/stack/miniconda3-4.2.12-7c8e67/Linux64/apr/1.5.2/bin/apr-1-config
cp: preserving permissions for `/nfs/farm/g/desc/u1/software/redhat6-x86_64-64bit-devtoolset-3/DMstack/w_2017_26_py3/stack/miniconda3-4.2.12-7c8e67/Linux64/apr/
1.5.2/ups/apr.cfg': Operation not supported
cp: preserving permissions for `/nfs/farm/g/desc/u1/software/redhat6-x86_64-64bit-devtoolset-3/DMstack/w_2017_26_py3/stack/miniconda3-4.2.12-7c8e67/Linux64/apr/1.5.2/ups/apr.table': Operation not supported
cp: preserving permissions for `/nfs/farm/g/desc/u1/software/redhat6-x86_64-64bi
t-devtoolset-3/DMstack/w_2017_26_py3/stack/miniconda3-4.2.12-7c8e67/Linux64/apr/1.5.2/ups/eupspkg.cfg.sh': Operation not supported
cp: preserving permissions for `/nfs/farm/g/desc/u1/software/redhat6-x86_64-64bit-devtoolset-3/DMstack/w_2017_26_py3/stack/miniconda3-4.2.12-7c8e67/Linux64/apr/1.5.2/ups/pkginfo': Operation not supported
+ exit -5

Thanks,
Heather

ktl · August 30, 2017, 7:17pm

We might get away with modifying eupspkg.sh to use cp -p (possibly with additions if we really want symlinks) instead of cp -a.

github.com

RobertLuptonTheGood/eups/blob/master/lib/eupspkg.sh#L240


install_ups()
{
	# Copy the contents of ups/ to $PREFIX/ups and expand the table files
	#
	# It's necessary to call this if the native install method doesn't
	# copy/expand ups/ content


	[ ! -d ups ] && die "no 'ups' directory to copy to destination (are you running from package root?)";


	mkdir -p "$PREFIX/ups"
	cp -f -a ./ups/* "$PREFIX/ups"


	# Expand the table file, if any
	if [[ -f "$PREFIX/ups/$PRODUCT.table" ]]; then
		eups expandtable -i -W '^(?!LOCAL:)' "$PREFIX/ups/$PRODUCT.table"
		info "expanded table file '$PREFIX/ups/$PRODUCT.table'"
	else
		msg "no table file to expand (looked for '$PREFIX/ups/$PRODUCT.table')".
	fi
}

heather999 · August 31, 2017, 8:41pm

Thanks, @ktl. I tried modifying eupspkg.sh, using -p didn’t change the result, but using -dR worked. That allowed me to get beyond the apr package, however, cfitsio failed with the same error. Apparently cfitsio’s Makefile includes a “/bin/cp -a”. I’ll try fixing that up and hope that no other packages similarly use “cp -a” during their build process. Meanwhile, the SLAC computing group is looking to disable the extended ACL on our end (not optimal as we want to use ACLs) or find some other solution.
Take care,
Heather

ktl · September 1, 2017, 7:07am

I think the problem is that the extended ACLs aren’t available on both sides (the source and destination of the copy). So either disabling them on the source side or enabling them on the destination would solve this.