DIRACGrid / DIRACOS

Project for creating bundle of DIRAC dependencies.
GNU General Public License v3.0
2 stars 9 forks source link

Remove libselinux.so.1 for CentOS 8 support #99

Closed chrisburr closed 5 years ago

chrisburr commented 5 years ago

As there is now a docker image for CentOS 8 I thought I'd quickly try it and unsurprisingly everything is horribly broken. More surprisingly it's trivial to fix enough that the client tests work.

The error when installing is:

2019-10-02 11:16:38 UTC dirac-install [NOTICE]  Defaults written to defaults-DIRAC.cfg
2019-10-02 11:16:38 UTC dirac-install [NOTICE]  Executing /admin/runit-2.1.2/scripts/dirac-externals-requirements...
/usr/bin/coreutils: symbol lookup error: /usr/bin/coreutils: undefined symbol: mode_to_security_class

It is due to LD_LIBRARY_PATH is causing coreutils to take libselinux.so.1 from DIRAC OS. Ideally LD_LIBRARY_PATH shouldn't be used at all but as that isn't an option I think it can be taken from the host instead of being included in DIRACOS.

CentOS 8 Installation Steps

$ docker run --rm -it centos:8 bash
dnf -y groupinstall "Development Tools"
dnf -y config-manager --set-enabled PowerTools
dnf -y install glibc-static wget freetype fontconfig pixman libXrender psmisc
wget http://smarden.org/runit/runit-2.1.2.tar.gz
tar xvf runit-2.1.2.tar.gz
cd admin/runit-2.1.2/
package/install
curl -O  -L https://github.com/DIRACGrid/DIRAC/raw/integration/Core/scripts/dirac-install.py
chmod +x dirac-install.py
dnf -y install python2
# Must set python to be python2 for dirac-install.py to work
alternatives --set python /usr/bin/python2
./dirac-install.py -r v7r0 -t client
petricm commented 5 years ago

Thank you for trying, but there are 150 libs in DIRACOS that link against libselinux.so.1 if you remove this lib from the LD_LIBRARY_PATH, all these will use the system lib from a newer glibc. I don't think this will work.

chrisburr commented 5 years ago

DIRAC OS already depends on the backwards compatibility of the libc binary provided by the host so I don't see what the problem would be?

petricm commented 5 years ago

Currently we are compiling everything down to libc level, therefore the compatibility. What you want is, if I understand you correctly, to exclude selinux from this, which means that there would be a different version of selinux used for each platform (2.0 vs. 2.5 vs. 2.8 -- CentOS 6, 7, 8), which is also build against a different glibc. This in itself kind of violates the commandments of diracos:

thou shall use the same versions of libraries on all thy platforms

Regardless of the previous argument, I am not sure that a library from diracos that was originally build against selinux 2.0 (built against glibc 2.12) will work or exhibit same behaviour when run under selinux 2.8 (built against glib 2.28).

What you would need is that the selinux library would exhibit the same backwards compatibility features as the libc library, of which I am not sure.

chrisburr commented 5 years ago

I could check the ABI of the various SE linux binaries but I guess that's only a symptomatic solution. The real problem is that LD_LIBRARY_PATH is being abused.

Is there a plan for what happens to DIRAC OS when CentOS 6 reaches EOL (November 2020)? Or how a Python 3 version would be made?

petricm commented 5 years ago

No definitive plans have been made. But once all sites relevant for the DIRAC community are migrated away from SLC6, we can "rebase" DIRACOS on CC7 and go for centos 8 compatibility, but I can easily see this taking longer than Nov. 2020.

chaen commented 5 years ago

I concur with Marko