xcat.conf was installed as an ordinary payload file and then deleted and
recreated from the Apache-version template in %post. rpm therefore held
no record of what was on disk, and an upgrade replaced an edited file
silently, leaving neither .rpmnew nor .rpmsave. A site that had added
Indexes to the /install block lost it on upgrade and directory listings
began returning 403.
Select the Apache 2.2 or 2.4 configuration at build time, using the same
distribution macros the rest of the spec already relies on, and mark
both /etc/httpd/conf.d/xcat.conf and /etc/apache2/conf.d/xcat.conf as
%config(noreplace). rpm then keeps a modified file and installs the new
vendor version alongside it as xcat.conf.rpmnew.
The old payload recorded the 2.2 file while %post wrote the 2.4 one, so
rpm cannot distinguish a stock file from an edited one across the
transition. A migration compares the active file with the templates the
outgoing package saved under conf.orig and removes it only when it is a
regular file still byte-for-byte identical to one of them. A stock
upgrade then completes without an unnecessary .rpmnew, and anything that
differs is left untouched.
That migration runs in %pretrans, not %pre. rpm fixes each config file's
fate before %pre, so removing the active file there can happen after rpm
has already resolved to write only xcat.conf.rpmnew, leaving the system
with no active configuration at all. %pretrans runs before that decision.
It is an embedded Lua scriptlet because a pre-transaction scriptlet
cannot rely on any dependency being unpacked yet, which also means the
comparison needs no external tool.
bc was needed only by the version check the service-node package no
longer performs.
The Apache directives are unchanged. Document a later-loading conf.d
file as the place for site rules, since that survives upgrades without a
merge.
The service node runs mknb directly rather than through xcatconfig, and nothing
looks at what it returned, so a failure leaves the node without a current
Genesis image and says nothing at all.
Check it and say so.
The security response headers added to xcat.conf are wrapped in
<IfModule mod_headers.c>, so they only take effect where mod_headers is loaded.
EL loads it by default and the Debian postinst enables it with a2enmod, but SUSE
apache2 does not load it by default, so the headers stayed inactive there. Enable
it in the RPM %post for the apache2 case, guarded so it is a no-op on EL (where
a2enmod is absent and mod_headers is already loaded).
Verified on openSUSE Leap 15.6: mod_headers is off by default, the hardened
config still starts, and after a2enmod the served response carries all four
security headers. The need to load mod_headers on SUSE was identified in the
lenovobuild branch (660df81379 / xcat.conf.apach24.sles), here done via
a2enmod rather than a separate config file.
Co-authored-by: Jarrod Johnson <10814490+jjohnson42@users.noreply.github.com>
xCAT and xCATsn hard-required elilo-xcat on every non-s390x install. elilo only
provides the ia64 (Itanium) UEFI loader; modern x86-64 UEFI netboot uses
xnba.efi and aarch64 uses grub2, so the dependency pulls a loader no current
platform needs. Drop the Requires (xnba-undi, which the UEFI path does use, is
kept). elilo-xcat can still be installed by hand for legacy ia64.
An OVMF x86-64 UEFI client netboots through xnba.efi with no elilo involved.
Recovered from the unmerged lenovobuild branch (e53b62e0).
Co-authored-by: Jarrod Johnson <10814490+jjohnson42@users.noreply.github.com>
The single flat xcat-core repo serves el8/el9/el10 from one build, but two spec
decisions were resolved at BUILD time and so were wrong for the other ELs that
share the same repo.
1. DHCP backend. xCAT.spec and xCATsn.spec selected the dhcp provider with a
build-time %if (rhel >= 10 -> kea, else dhcpd), so an el10 build wrongly
required kea on el8/el9 (and an el8/el9 build wrongly required dhcpd on
el10). Replace it with an install-time RPM rich dependency:
Requires: (kea if (system-release >= 10) else /usr/sbin/dhcpd)
Requires: (kea-hooks if (system-release >= 10))
dnf now resolves it per client: kea on el10+ (which dropped ISC dhcp from the
distro), dhcpd on el8/el9. SLES has no "system-release" provide, so the
condition is false there and it falls back to /usr/sbin/dhcpd, preserving
prior behavior. system-release is versioned per release package
(el10=10.x, el9=9.x, el8=8.x).
2. openssl. Make the xCAT-server openssl Requires uniform across EL (non-SUSE)
instead of el10-only, so the produced package set does not depend on which EL
the build host happened to be.
Also drop xCAT-genesis-base from the default @PACKAGES set in buildrpms.pl: its
initramfs bundles the build-chroot kernel/glibc and is therefore OS- and
arch-dependent, so it cannot ship in the single flat core. It is now built per
target by the xcat-dep pipeline (mockbuild-all.pl, via
`buildrpms.pl --package xCAT-genesis-base`) and ships in xcat-dep/rh<N>. The
explicit `--package xCAT-genesis-base` build path is retained.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
Vinícius Ferrão
Daniel Hilst
Mark Gurevich
cxhong
GONG Jie
Victor Hu
zet809
Bin Xu
Chuck Brazie
yangsong
Chuck Brazie
GONG Jie
chenglch
Patrick Lundgren
Jarrod Johnson
immarvin
hu-weihua
Casandra Qiu
ligc
lissav
Bruce Potter
bp-sawyers
jjhua