...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
Table of Contents | ||
---|---|---|
|
...
Assuming at least some of packages we need to ship with SIMP already belong to repo modulesmodular repository streams, how can/should we handle:
building
...
SIMP distributions (pkglist.txt + packages.yaml, ISO, etc.,)
During the process of building a SIMP ISO, we use two files
📄 DVD/<os.release.major>-pkglist.txt — a list of packages to keep from OS’s base installation media (ex:, CentOS-8.3.2011-x86_64-dvd1.iso
). Anything not listed in this file will be pruned from the base OS installation packages before
📄 yum_data/packages.yaml — a manifest of additional packages needed to support a self-contained SIMP ISO installation. These are extra packages not found on the base OS’s installation media (or are not the correction version).
An example entry from the CentOS 7 packages.yaml file:
Code Block | ||
---|---|---|
| ||
Note | ||
80% Confidence it’s Possible — but it will be complicated and hacky
|
Current methods of building/sourcing RPM packages
SIMP is distributed as a self-contained collection of RPM packages:
SIMP packages are built by the SIMP team, from the repos under
src/
in Puppetfile.pinned.Minimal Base OS packages are filtered from a base OS’s installation media (usually a DVD ISO), down to the files
DVD/<os.release.major>-
pkglist.txt.External packages are RPMs downloaded based on the data in
yum_data/
packages.yaml, and come from additional sources (e.g., EPEL, Puppet, base OS extras, various vendors).(Optionally): Custom packages placed manually into the
packages/
directory and treated like External packages.
Together, these RPMs MUST self-resolve (enough) to install a basic SIMP system on a network-isolated host.
Current process to build SIMP distributions
Build a DVD overlay directory (and tarball) containing the SIMP and External packages.
Unpack the base OS installation media into an ISO staging directory.
Prune the unpacked ISO RPMs down to the Minimal Base OS packages.
Merge the DVD overlay contents over the files already in the ISO staging directory.
Verify that all ISO staging directory’s RPMs can self-resolve by running repoclosure.
Build a SIMP distribution ISO from the contents of the ISO staging directory.
Potential problems with DNF modules
...
Filtering an OS ISO down to its pkglist + adding external packages in packages.yaml
...
both
We can use tools like dir2module and repo2module to re-package specific modular packages into slimmer versions of their own modules and then use mergerepo_c to collect them into a slimmed-down AppStream/ repo (based on pkglist.txt) or SIMP/ (based on packages.yml). However, there are several issues that make this complicated:
...
RPM packages from repo modules contain a
ModularityLabel
header that is unique to the module’s name + stream + version + context + architecture (NVSCA). DNF must install these RPMs from modules (with modular metadata)—and will refuse to install them as ursine packages.dir2module requires a complete NVSCA string generating module metadata for a directory of RPMs.
The dir2module script provided by the EPEL8 RPM
modulemd-tools-0.7-1.el8.noarch
does not create a default (or any) profile for the module it creates.The master in the GitHub repo at
At a minimum, a repackaged (slim) module’s name and stream must match its source repo’s module metadata.
This is required so the packages maintain continuity with the complete upstream repo (e.g., receiving update from the complete AppStream repo, epel-modular, etc)
The module’s versionnumber must evaluate to more than the versions of earlier modules and less than the version of later modules in the full source repository.
The
ModularityLabel
header is string unique to a module builds' NVSCfor a particular platform. The header data in RPMs packaged by RHEL/CentOS build system is currently in NVSC format, however this data is arbitrary and cannot be relied uponto provide accurate NVSC data for the module.The only canonical source for a module’s correct NVSCA/P data is the source repo’s metadata (generally under
repodata/{XXXXX}-modules.yaml.gz
, and defined byrepodata/repomd.xml
under<data type="modules">
`)
...
Notes:
So far, the selinux-*policy RPMs have handled whatever I’ve tried
Ancient policy wikis at (last updated late 2018):
...
Can we repackage a “thinned-out” module with only select packages?
probably:
EL8 RPM prereqs: createrepo_c (appstream) + modulemd-tools (epel)
Process:
Create initial repo with ursine modules
Code Block mkdir -p $NEW_REPO_DIR/Packages/ursine cp "${URSINE_PACKAGE_FILES[@]}" "$NEW_REPO_DIR/Packages/ursine/" cd "$NEW_REPO_DIR" createrepo_c .
Create a modular repo from packages that already have a common module header
The approach of taking NSVCA from the RPM headers is incomplete and cannot be relied upon to be accurate or available—theStatus colour Yellow title WARNING ModularityLabel
header can contain any String
Use another means of obtaining this data; preferably from the repo itself (the data is sourced from the source repository’sStatus colour Red title DO NOT PRODUCTIZE {XXXXX}-modules.yaml.gz
file)Code Block # Get the ModularityLabel from the RPMs ### WARNING: All RPMs in the module must have a SINGLE and IDENTICAL ModularityLabel find "$DIR_WITH_RPMS" -name \*.rpm \ -exec rpm -qp {} --qf '%{ModularityLabel}\n' \; \ | sort -u ### WARNING: the ModularityLabel headers in RPMs build by EL and EPEL #### are (currently) in N:S:V:C format by convention, but in ##### reality this string is arbitrary and cannot be relied upon ##### to reflect the actual source module's metadata. MODULE_HEADER=nodejs:10:8020020200707141642:6a468ee4
...