Page Comparison

Table of Contents

maxLevel	3

Questions

Table of Contents

maxLevel	3

Questions

Assuming at least some of packages we need to ship with SIMP already belong to modular repository streams, how can/should we handle:

...

Note

80% Confidence it’s Possible — but it will be complicated and hacky

The current methods of downloading external packages AND pruning OS ISOs down to a minimal set of packages will both result in broken modular repositories.
- This could be solved by recreating the RPM’s module streams with exactly the same NSVCA values as the source repository—but practically every step of that will be hacky and require unsupported tooling or several workarounds.
The repo manipulation methods (createrepo, repoclosure) aren’t module-aware

...

Build a DVD overlay directory (and tarball) containing the SIMP packages.
☑ 1️⃣ ➡1️⃣ Download External packages (rake build:yum:sync) into yum_data/packages/
Unpack the base OS installation media into an ISO staging directory.
1. ☑ 1️⃣ ➡1️⃣2️⃣ Prune the unpacked ISO RPMs down to the Minimal Base OS packages.
Merge the DVD overlay contents & External packages on top of the files already in the ISO staging directory.
1. ☑ 2️⃣ ➡3️⃣ Create new yum repositories using createrepo
2. ☑ 3️⃣ ➡4️⃣ Verify that all ISO staging directory’s RPMs can self-resolve by running repoclosure (rake pkg:repoclosure).
Build a SIMP distribution ISO from the contents of the ISO staging directory
☑ 1️⃣ ➡1️⃣ Host yum mirrors containing subsets of External package repositories (like EPEL) on the SIMP download service (ex: https://download.simp-project.com/SIMP/yum/releases/6.5.0-1/el/7/x86_64/epel/).

Pain points with modularity + the current process

...

1️⃣: You can’t simply [download the modular RPMs you want/remove the modular RPMS you don’t need/throw a bunch of modular RPMs together] and run createrepo to re-host them. You also need the correct metadata (called modulemd metadata) for all downloaded modular RPMs' streams, and special new commands.

AFAICT, this metadata can only be obtained from the source repo.
There isn’t a complete “roll-your-own” solution to create modular repositories yet. Most of the tooling is meant to mirror existing repositories. There are community tools (~~dir2module~~, repo2module), but they are incomplete, unsupported, and buggy.

...

_64/epel/).

Pain points with modularity + the current process

The DVD overlay directory (and tarball)should not be affected, because it won’t contain modular RPMs (the SIMP project doesn’t create them).
Downloading External packages (rake build:yum:sync) into yum_data/packages/ has modularity problems:
1. 1️⃣: You can’t simply [download the modular RPMs you want → remove the modular RPMS you don’t need → collect various modular RPMs together in a directory] and run createrepo to re-host them in a new repository. You need the correct metadata (called modulemd metadata) for all downloaded modular RPMs' streams, and special new commands, like createrepo_c.
  1. This metadata can only be obtained from the modular RPMs' source repo.
2. There isn’t a “roll-your-own” solution to create arbitrary modular repositories yet The supported DNF repository tooling is mostly meant to mirror existing repositories.
  1. There are community tools (~~dir2module~~, repo2module), but they are incomplete, unsupported, and buggy. Some of these tools have been rolled into later versions of createrepo_c, but not the version on EL8 (and AFAIK, they may still be buggy).
  2. Pulp is the closest tool, because it supports some flavors of modular subsets
Unpack the base OS installation media into an ISO staging directory runs into problems with pruning:
1. 2️⃣: https://simp-project.atlassian.net/browse/SIMP-9644
  The naive pruning strategy of “rm RPM is it’s not in a *pkglist.txt file” may work with very specific RPMs, but it will still need to the original modularity metadata and additional information to ensure the correct modules are used
Merging the DVD overlay
1. 3️⃣: createrepo_c is needed to create a useable modular repository.
  However, it requires quite a few things before it can work:

...

1. - ⚠➡5️⃣ The correct modulemd data (see format specs) for modules.yaml from the original repository.

...

1. - ➡5️⃣ Some way of generating the modulemd YAML data for each module.

...

1. - ➡5️⃣ The ability to add all the modules' modulemd data into a single modules.yaml file for the entire repository.

...

1. - ⚠➡5️⃣ The correct tools to create/merge the repo and the module metadata (createrepo_mod or the *_c commands it runs)

...

1. 4️⃣: yum-utilsprovides a CLI compatibility layer with the newer DNF sub-commands (including repoclosure), but may require specific arguments (documented further below)
  - dnf repoclosureis sort of module-aware (bz#1547041), and may need extra logic to module enable non-default streams that need to be considered while depsolving.

...

1. ➡6️⃣: To generate the modulemd YAML data for each module and combine it into a single modulemd.yaml file for createrepo_c to consume, we will need to roll either:
  1. build logic to do it in one shot
  2. build logic to glue together

...

1. 1. a process that combines the buggy community tools from modulemd-tools.
Build a SIMP distribution ISO from the contents of the ISO staging directory
Host yum mirrors containing subsets of External package repositories (like EPEL) on the SIMP download serv

Creating repos with useable modularity streams

⚠8️⃣ We can use ⚠5️⃣ We can re-package specific packages into slimmer versions of their source modules and then use mergerepo_c (or creatrepo_mod) 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:

tools like ~~dir2module~~ and repo2module[note] to re-package specific packages into slimmer versions of their source modules and then use mergerepo_c (or creatrepo_mod) 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 (NSVCA). DNF must install these RPMs from modules (with modular metadata)—and will refuse to install them as ursine packages.
- dir2module and repo2modules require a complete NSVCA string generating module metadata for a directory of RPMs.
- 5️⃣ 6️⃣ 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; it . It is effectively useless; use . repo2module instead is better (which is still missing the Arch in NSVCA).
A repackaged (slim) module’s name and stream and context and architecture must match the values in the source repo’s metadata for the original module.
- 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 versionnumber must evaluate to more than the earlier (module versions) and less than the version of later modules in the full source repository. This number (like stream and context) is an arbitrary string set by the build platform, so we have to get it
- For practical purposes, you need to mirror the repo’s metadata YAML at the same time as you retrieve the packages—it might be updated later, even if the packages you see hosted there are the same
The ModularityLabel header is string unique to a module builds' NSVCfor a particular platform. The header data in RPMs packaged by RHEL/CentOS build system looks useful because a string it’s in NSVC format, however this data is actually arbitrary and cannot be relied uponto provide accurate NSVC data for the module.
The only canonical source for a module’s correct NSVCA/P data is the source repo’s metadata (generally under repodata/{XXXXX}-modules.yaml.gz, and defined by repodata/repomd.xml under <data type="modules">`)
🎉 I’ve tested a repacked “slim” repo alongside a repo with the full module w/identical NSVCA details, and it successfully resolved its metadata/packages with the full module.
- This should also behave correctly with updated modules, but I haven’t been able to stage that yet.

...

Info

Notes:

So far, the selinux-*policy RPMs have handled whatever I’ve tried
Ancient policy wikis at (last updated late 2018):
- SELinux Policy: https://fedoraproject.org/wiki/SELinuxModularityPackagingGuidance#Packaging_SELinux_Policy
- Design docs: https://fedoraproject.org/wiki/SELinuxModularityDesign

...

Code Block

dnf module list \
  | egrep -v '^(Extra|Name|Hint:|CentOS|Last)' \
  | sed -e '/^$/d' \
  | awk '{printf "%-20s %s\n", $1, $2}' \
  | sort
  
389-directory-server next
389-directory-server stable
389-directory-server testing
389-ds               1.4 
ant                  1.10
avocado              82lts
avocado              latest
cobbler              3
container-tools      1.0
container-tools      2.0
container-tools      rhel8
dwm                  latest
freeradius           3.0
gimp                 2.8
go-toolset           rhel8
httpd                2.4
idm           
gimp       DL1 idm         2.8
go-toolset        client inkscape  rhel8
httpd          0.92.3 javapackages-runtime 201801 jmc   2.4
idm              rhel8 libselinux-python   DL1
2.8idm libuv                epel8-buildroot
llvm-toolset   client
inkscape       rhel8

View packages in a module

Code Block
dnf module repoquery nodejs

Info
It looks `dnf module repoquery` only reports on the default stream, regardless of the module-spec specified (tested on EL8.3)

View modules/profiles that provide a package

Code Block
dnf module provides 389-ds-base

Info
This is one of the few (two?) module commands that reports which DNF Repo hosts the module

Info
Note that it also looks for packages across multiple repos and module:streams

Example:

Code Block

# dnf module provides 389-ds-base
Last metadata expiration check: 1:20:30 ago on Wed Mar 24 18:09:28 2021.
389-ds-base-1.4.3.17-1.module_el8+10764+2b5f8656.x86_64
Module   : 389-directory-server:stable:820201201092549:9edba152:x86_64
Profiles : default legacy minimal
Repo     : epel-modular
Summary  : 389 Directory Server

389-ds-base-1.4.3.8-6.module_el8.3.0+604+ab7bf9cc.x86_64
Module   : 389-ds:1.4:8030020201222185615:618f7055:x86_64
Profiles :
Repo     : appstream
Summary  : 389 Directory Server (base)

389-ds-base-1.4.4.9-1.module_el8+10763+39cf6b48.x86_64
Module   : 389-directory-server:testing:820201201092622:9edba152:x86_64
Profiles : default legacy minimal
Repo     : epel-modular
Summary  : 389 Directory Server

389-ds-base-2.0.1-1.module_el8+10522+e95198da 0.92.3
javapackages-runtime 201801
jmc                  rhel8
libselinux-python    2.8
libuv                epel8-buildroot
llvm-toolset         rhel8

View packages in a module

Code Block
dnf module repoquery nodejs

Info
It looks `dnf module repoquery` only reports on the default stream, regardless of the module-spec specified (tested on EL8.3)

View modules/profiles that provide a package

Code Block
dnf module provides 389-ds-base

Info
This is one of the few (two?) module commands that reports which DNF Repo hosts the module

Info
Note that it also looks for packages across multiple repos and module:streams

Example:

Code Block

# dnf module provides 389-ds-base
Last metadata expiration check: 1:20:30 ago on Wed Mar 24 18:09:28 2021.
389-ds-base-1.4.3.17-1.module_el8+10764+2b5f8656.x86_64
Module   : 389-directory-server:nextstable:820201104083723820201201092549:9edba152:x86_64
Profiles : default legacy minimal
Repo     : epel-modular
Summary  : 389 Directory Server

View the packages in each profile (for a specific stream)

Code Block

language	s

]# dnf module info --profile  nodejs:12
Last metadata expiration check: 2:59:10 ago on Thu 11 Mar 2021 11:02:32 PM UTC.
Name        : nodejs:12:8030020210304194546:30b713e6:x86_64
common      : nodejs
            : npm
development : nodejs
       

389-ds-base-1.4.3.8-6.module_el8.3.0+604+ab7bf9cc.x86_64
Module   : 389-ds:1.4:8030020201222185615:618f7055:x86_64
Profiles :
Repo     : appstream
Summary  : 389 Directory Server (base)

389-ds-base-1.4.4.9-1.module_el8+10763+39cf6b48.x86_64
Module   : 389-directory-server:testing:820201201092622:9edba152:x86_64
Profiles : default legacy minimal
Repo     : epel-modular
Summary  : 389 Directory Server

389-ds-base-2.0.1-1.module_el8+10522+e95198da.x86_64
Module   : 389-directory-server:next:820201104083723:9edba152:x86_64
Profiles : default minimal
Repo     : nodejsepel-develmodular
Summary  : 389 Directory Server

View the packages in each profile (for a specific stream)

Code Block

language	s

]# dnf module info --profile   nodejs:12
npmLast minimalmetadata expiration    : nodejs
s2i         : nodejs
    check: 2:59:10 ago on Thu 11 Mar 2021 11:02:32 PM UTC.
Name        : nodejs-nodemon
:12:8030020210304194546:30b713e6:x86_64
common            : npm

...

Find all modular RPM files that under a directory and print their module headers

This identifies modular RPMs that would need to have their module streams re-created when distributed independently from their source repos:

Code Block

language	bash

find "$DIR_WITH_RPMS" -name \*.rpm \
  -exec rpm -qp {} --qf '%{NVRA}   %{ModularityLabel}\n' \; \
  | grep -v '(none)' \
  | tee modular_rpms.txt

The %{ModularityLabel} header is in (module)name:stream:version:context:arch (N:S:V:C:A) format (on RedHat/CentOS/Fedora-built packages), so the result looks like this:

Code Block

389-ds-base-1.4.3.8-5.module_el8.3.0+473+53682548.x86_64   389-ds:1.4:8030020200831174107:618f7055
389-ds-base-devel-1.4.3.8-5.module_el8.3.0+473+53682548.x86_64   389-ds:1.4:8030020200831174107:618f7055
389-ds-base-legacy-tools-1.4.3.8-5.module_el8.3.0+473+53682548.x86_64   389-ds:1.4:8030020200831174107:618f7055
389-ds-base-libs-1.4.3.8-5.module_el8.3.0+473+53682548.x86_64   389-ds:1.4:8030020200831174107:618f7055
389-ds-base-snmp: nodejs
            : npm
development : nodejs
            : nodejs-devel
            : npm
minimal     : nodejs
s2i         : nodejs
            : nodejs-nodemon
            : npm

Anchor

	module-headers
	module-headers

Find all modular RPM files that under a directory and print their module headers

This identifies modular RPMs that would need to have their module streams re-created when distributed independently from their source repos:

Code Block

language	bash

find "$DIR_WITH_RPMS" -name \*.rpm \
  -exec rpm -qp {} --qf '%-62{NVRA}   %{ModularityLabel}\n' \; \
  | grep -v '(none)' \
  | tee modular_rpms.txt

The %{ModularityLabel} header is in (module)name:stream:version:context:arch (N:S:V:C:A) format (on RedHat/CentOS/Fedora-built packages), so the result looks like this:

Code Block

389-ds-base-1.4.3.8-56.module_el8.3.0+473604+53682548ab7bf9cc.x86_64         389-ds:1.4:80300202008311741078030020201222185615:618f7055
HdrHistogram-2.1.11-2.module_el8.2.0+460+6583c1d0.noarch   jmc:rhel8:8020020200731165725:21dc74c6
HdrHistogram-javadoc-2.1.11-2.module_el8.2.0+460+6583c1d0.noarch   jmc:rhel8:8020020200731165725:21dc74c6
Judy-1.0.5-18389-ds-base-libs-1.4.3.8-6.module_el8.13.0+217604+4d875839ab7bf9cc.x86_64    mariadb389-ds:101.34:80100201911150159158030020201222185615:cdc1202b618f7055
antpython3-distro-1.104.50-12.module_el8.03.0+47562+197dca37e162826a.noarch        antpython36:13.106:80000201906242023408030020201104034153:f7e686af24f1489c
antpython3-liblib389-1.104.3.58-16.module_el8.03.0+47604+197dca37ab7bf9cc.noarch   ant   389-ds:1.104:80000201906242023408030020201222185615:f7e686af618f7055
aopallianceruby-12.5.05-17106.module_el8.03.0+39571+6a9b6e22.noarchbab7c6bc.i686                  mavenruby:32.5:80000201906241406568030020201104071226:f7e686af30b713e6
aopallianceruby-12.5.05-20106.module_el8.3.0+568571+0c23fd64.noarchbab7c6bc.x86_64                mavenruby:32.65:80300202011040641128030020201104071226:a623df0530b713e6

However, it isn’t possible to re-create specific module/streams based on the RPM’s ModularityLabel headers.

...

(Works from CentOS 8.3 and CentOS 7.8, requires packages dnf and dnf-pluginplugins-core )

An example of this mirroring a mounted CentOS 8.3 ISO’s AppStream repository:

...

Create a modular repo from packages that already have a common module header

Status

colour	Yellow
title	WARNING

The approach of taking N:S:V:C:A from the RPM headers below is a.) incomplete and b.) cannot be relied upon to be accurate or present—the ModularityLabel header can contain any String.
Status
colour Red
title DO NOT PRODUCTIZE
Use another means to obtain N:V:S:C:A data; preferably from the repo itself (the data is sourced from the source repository’s {XXXXX}-modules.yaml.gz file)
Code Block
# Get the ModularityLabel from the RPMs ########################################################## #### UPDATE: DO NOT USE OR PRODUCTIZE THIS TECHNIQUE ##### ########################################################## # Notes: # - All RPMs in the module must have a SINGLE and IDENTICAL ModularityLabel # - The only thing required of this String is that it is unique to RPMs # from other modules (and different versions/contexts of this module) 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. ##### The actual NVSCA/P data can *ONLY* be obtained from the ##### original repo's metadata MODULE_HEADER=nodejs:10:8020020200707141642:6a468ee4

...

Versions Compared

Old Version 22

New Version Current

Key

Questions

Questions

Pain points with modularity + the current process

Pain points with modularity + the current process

Creating repos with useable modularity streams

View packages in a module

View modules/profiles that provide a package

View packages in a module

View modules/profiles that provide a package

View the packages in each profile (for a specific stream)

View the packages in each profile (for a specific stream)

Find all modular RPM files that under a directory and print their module headers

Find all modular RPM files that under a directory and print their module headers