[LU-17226] l_getsepol does not build due to not requiring openssl-devel

• Status: Open
• Project: Lustre
• Affects Version/s: Lustre 2.15.3
• Fix Version/s: Lustre 2.16.0
• Type: Bug
• Priority: Minor
• Reporter: Gian-Carlo Defazio
• Assignee: Sebastien Buisson
• Resolution: Unresolved
• Labels: llnl

Environment

llnl build farm

lustre 2.15.3_3.llnl

• Severity: 3

Description

The l_getsepol utility does not build in our buildfarm because openssl-devel is not installed. The only "BuildRequires: openssl-devel" is for "with gss" and we aren't using gss.

Issue Links

• is related to: LU-11914 Build error for l_getsepol.c due to m...

Comments

[Gian-Carlo Defazio]

Would it make sense to group a "BuildRequires: openssl-devel" with any  instances of "BuildRequires: pkgconfig(libselinux)" since l_getsepol will only be used on systems with selinux?

[Patrick Farrell]

I think we should only group actual build requirements, not other associations even if expected.  Anything else seems to be asking for trouble in the future?

Or are you saying l_getsepol is always used on systems with selinux and selinux won't work without it?  In that case, it wouldn't be a buildrequires, but a configure check.

[Gian-Carlo Defazio]

l_getsepol is only used on systems with selinux.

So (need to run l_getsepol) implies (running selinux)

I'm not sure if (running selinux) implies (need to run l_getsepol)

The issue is that our build farm installs rpms based on BuildRequires, so openssl-devel needs to be in the .spec file somewhere, otherwise the openssl-devel rpm doesn't get installed, and the config check from  LU-11914 sees this and decides not to build l_getsepol instead of attempting to build it and failing.

So our situation is we want to build l_getsepol but openssl-devel doesn't get installed without a BuildRequires, and the only current BuildRequires is for gss which we don't use, and I'm trying to find a reasonable place to add openssl-devel so that things will work in our build farm. I get that this might just have to be a local patch, but I was wondering if there was a more elegant solution.

[Patrick Farrell]

You know, going back on what I said before, it's probably fine to just stick it with pkconfig(libselinux), since it's a widely available package and easy to install.  Definitely shouldn't have to do a local patch for something this simple.

[Peter Jones]

Sébastien

What do you advise here?

Peter

[Sebastien Buisson]

Today we have this in the .spec file for the lustre (or lustre-client) package:

%if %{with gss}
BuildRequires: krb5-devel openssl-devel
%endif
%if "%{_vendor}" == "redhat" || "%{_vendor}" == "fedora" || "%{_vendor}" == "openEuler"
#suse don't support selinux
BuildRequires: pkgconfig(libselinux)
%endif

So we already have a require on libselinux, but indeed a require on openssl-devel only for "with gss".

I think it could be too strong to require openssl-devel in all cases.
So maybe the most suitable fix could be to improve the config check so that we simply do not build l_getsepol if openssl-devel is not available. This binary is not strictly required to be able to run a Lustre client with SELinux enabled, it is only needed if 'send_sepol' is explicitly activated (it is off by default).

[Olaf Faaland]

> So maybe the most suitable fix could be to improve the config check so that we simply do not build l_getsepol if openssl-devel is not available.

I believe this is what is currently implemented. But this contradicts the way "mock" (the build tool used by fedora, redhat, and others) work. It extracts BuildRequires from the spec file and installs the named packages in the build environment, and then performs the build. This then provides verification that the actual build requirements and the advertised build requirements are consistent.

> This binary is not strictly required to be able to run a Lustre client with SELinux enabled, it is only needed if 'send_sepol' is explicitly activated (it is off by default).

If there is a config flag to enable the builder to separately decide whether or not to build l_getsepol (I'm guessing not)? If not, then shouldn't we always require openssm to be consistent with that?

[Sebastien Buisson]

Yes, good point Olaf.

There is currently no config flag to disable l_getsepol build. Would that help with "mock", if we build l_getsepol by default but give the ability to disable via --disable-l_getsepol or something?

Otherwise we can add openssl-devel to the BuildRequires as default, if it is not a too strong requirement.

Thanks!

[Gerrit Updater]

"Gian-Carlo DeFazio <[e-mail]>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/52849
Subject: LU-17226 build: create config option for l_getsepol
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: deddcb57ab27ba7fb4b961ce0aa51db7f1129612