https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-17226 Lustre <p>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.</p> llnl build farm <br/> <br/> lustre 2.15.3_3.llnl LU-17226

l_getsepol does not build due to not requiring openssl-devel

Bug Minor Open Unresolved Sebastien Buisson Gian-Carlo Defazio llnl Tue, 24 Oct 2023 20:22:49 +0000 Sat, 20 Jan 2024 00:51:08 +0000 Lustre 2.15.3 Lustre 2.16.0 0 6 <p>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?</p> <p>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?</p> <p>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.</p> <p>l_getsepol is only used on systems with selinux.</p> <p>So (need to run l_getsepol) implies (running selinux)</p> <p>I'm not sure if (running selinux) implies (need to run l_getsepol)</p> <p>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  <a href="https://jira.whamcloud.com/browse/LU-11914" title="Build error for l_getsepol.c due to missing openssl/evp.h" class="issue-link" data-issue-key="LU-11914"><del>LU-11914</del></a> sees this and decides not to build l_getsepol instead of attempting to build it and failing. </p> <p>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.</p> <p>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.</p> <p>Sébastien</p> <p>What do you advise here?</p> <p>Peter</p> <p>Today we have this in the .spec file for the <tt>lustre</tt> (or <tt>lustre-client</tt>) package:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>%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 </pre> </div></div> <p>So we already have a require on libselinux, but indeed a require on openssl-devel only for "with gss".</p> <p>I think it could be too strong to require openssl-devel in all cases.<br/> So maybe the most suitable fix could be to improve the config check so that we simply do not build <tt>l_getsepol</tt> 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).</p> <p>&gt; 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. </p> <p>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 <b>actual build</b> requirements and the <b>advertised</b> build requirements are consistent.</p> <p>&gt; 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).</p> <p>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?</p> <p>Yes, good point Olaf.</p> <p>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 <tt>--disable-l_getsepol</tt> or something?</p> <p>Otherwise we can add openssl-devel to the <tt>BuildRequires</tt> as default, if it is not a too strong requirement.</p> <p>Thanks!</p> <p>"Gian-Carlo DeFazio &lt;defazio1@llnl.gov&gt;" uploaded a new patch: <a href="https://review.whamcloud.com/c/fs/lustre-release/+/52849" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/c/fs/lustre-release/+/52849</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-17226" title="l_getsepol does not build due to not requiring openssl-devel" class="issue-link" data-issue-key="LU-17226">LU-17226</a> build: create config option for l_getsepol<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: deddcb57ab27ba7fb4b961ce0aa51db7f1129612</p> Related LU-11914 Development Rank 1|i03zfr: Rank (Obsolete) 9223372036854775807 Severity