Configuring local repositories mirroring BaseOS, AppStream

Infrastructure
1

Having a few dozen RL machines in LAN, I would like to setup a local repository mirroring (to start with) BaseOS and AppStream repos. I have found and followed this page. It is working and I am able to install individual (new) packages but an attempt to dnf update failed completely, showing dozens of messages like:

- cannot install both perl-libs-4:5.30.1-452.module+el8.5.0+690+b6cd1280.x86_64 and perl-libs-4:5.26.3-420.el8.x86_64
- package perl-interpreter-4:5.30.1-452.module+el8.5.0+690+b6cd1280.x86_64 requires perl(:MODULE_COMPAT_5.30.1), but none of the providers can be installed
- package nginx-1:1.21.4-1.module_el8+13280+3abe831f.x86_64 is filtered out by modular filtering

It seems that it is module packages in appstream that cause these problems. Some of them are duplicates of non-module packages with different version numbers.
Compare:

# dnf list perl-libs
Last metadata expiration check: 0:00:05 ago on Tue 30 Nov 2021 09:37:11 PM CET.
Installed Packages
perl-libs.x86_64                4:5.26.3-420.el8            baseos
Available Packages
perl-libs.i686                  4:5.26.3-420.el8            baseos         

and

# dnf --disablerepo=appstream --enablerepo=localrepo-appstream list perl-libs
RockyLinux Base                                  66 kB/s | 3.0 kB     00:00    
Installed Packages
perl-libs.x86_64  4:5.26.3-420.el8                           baseos
Available Packages
perl-libs.i686    4:5.26.3-420.el8                           baseos             
perl-libs.x86_64  4:5.30.1-452.module+el8.5.0+690+b6cd1280   localrepo-appstream

I know close to nothing about modules so any hints would be welcome.

2

Reading the link, they run createrepo after doing a reposync. I would suggest not doing this, as it will remove module metadata and comps metadata. I would run these by itself (without createrepo) and try again:

dnf reposync -g --delete -p /path/to/baseos --download-metadata --repoid=baseos
dnf reposync -g --delete -p /path/to/appstream --download-metadata --repoid=appstream
dnf reposync -g --delete -p /path/to/powertools --download-metadata --repoid=powertools
3

I run plain rsync (from nearest mirror, on EL7 host). It does not attempt to do anything “smart” with the contents.

4

Thanks @nazunalika for the hint. I rebuilded the local repos without the createrepo steps and it seems to be working fine. I was able to update one of my 8.4 servers to 8.5 using that repo located on another server in my LAN.

5

I want to keep the original DVD (ISO) contents ‘intact’ (with the original repodata, comps*xml and metadata), so I create 2 additional YUM repos (some call them ‘dnf’) within the ‘updates’ and ‘appstream-updates’ directories (within each, are distribution-specific sub-directories, such as “centos-7.5-x86_64” and “rocky-8.4-x86_64”) and after ‘replicating’ (or unpacking) the original ISO to the “kickstart” directory ‘tree’, replicate all of the packages to the YUM directories, and execute “creatrepo” to create the ‘repodata’ sub-directory and meta contents ‘there’…

So that, I have the original ISO package contents within the “Kickstart” directory tree (containing the original “os” and “appstream” repos, and a copy, along with any updates from the ‘mirrors’(via reposync) in the YUM ‘updates’ and ‘appstream-updates’ directory trees (which are referenced during both initial installation and YUM updates) .

It keeps the original comps*xml file intact (with the vendor package groups and categories) and permits me to have a custom ‘comps’ file as well, with ‘my’ group definitions (ie. “KDE-desktop-that-works”).

It’s a grand waste of disk space, but functions well…

6

You do know that online BaseOS and AppStream (I did not check the Powertools) have both ‘os’ and ‘kickstart’ subtrees (with ‘os’ including the updates)?

1 Like
7

Can you be more ‘specific’ ?

I do ‘not’ use the ‘online’ repositories (only local repos, sync’d from them).

8

Note how Index of /pub/rocky/8.5/ (and its mirrors) have
{BaseOS,AppStream,PowerTools,extras}/$arch/{kickstart,os} ?
(Well, the ‘extras’ has only the ‘os’.)

The */$arch/os are the “online repositories” that default config does use.
The */$arch/kickstart are the “initial release”, essentially what the ISOs contain.

If I would like to have the “original contents” locally, then I would

  1. rsync the */$arch/kickstart from online once, after release of point update
  2. Locally sync */kickstart tree to */os tree
  3. Periodically resync (with rsync) */os tree from online to get updates
  4. Define the local */os in my systems, (‘my-baseos’, ‘my-appstream’, ‘my-powertools’, ‘my-extras’)
  5. Disable the online repos (‘baseos’, ‘appstream’, ‘extras’) in config

In other words, practically same routine as yours, with couple name/tool differences.

9

Since my primary webserver isn’t Rocky (or even CentOS) 8 I use rsync to create my local repos. I’ve documented (and provided scripts) here: GitHub - sweharris/centos8-local: How I build CentOS 8 VMs locally

I updated the scripts for Rocky-8 a couple of days ago, and was successfully able to hands-free virt-install from the tree using the provided kickstart file.

Obviously this is tuned to my setup, but may help others!

1 Like
10

I seeeeeee…

Yes, that would work nicely, keeping the ‘initial’ release intact, and directing all of the ‘updates’ to a customizable (‘my’ comps file) local repository.

I don’t remember such a ‘granular’ directory tree existing when Rocky was originally released (ver 8.3)

Thanks !

1 Like