I manage several air-gapped networks which require sneaker netting any files to the network. This includes updates. Please keep that in mind in the responses.
Because of compliance requirements, we try to minimize application use. What that means in this case is that we do not wish to introduce a web server into the environment because it adds immensely to the regulatory/administrative overhead
Those stated, for all our Linux OS’s we home our repositories on a file share.
Current issue
I have set up a rocky 8 server in the DMZ and have used DNF --reposync to get the repositories to this server (same method as I use on RHEL). I have brought these files to the inside with our isolation device, scanned and copied to my designated repository share, created the required directories and mounted the repository share. have the entries in my .repo file pointing to
baseurl=file:///<mount_path>/BaseOS/
(mount_path does not include special characters, has been used for years for other linux distros)
When I try to run a DNF update, It list the items to be updated. prompts for approval, but then returns “Empty mirrorlist and no basepath specified”
This is basically the same setup I use successfully with RHEL 8 and as was used in getting additional files from the install dvd post install. Am I missing a step here? Setting DNF for full debug, I am seeing it have util.py, line 115 and repo.py, line 499, which appear to deal with URL handling, which in turn sparks errors in several other python scripts in the system
The only reason you’d get the error you’re getting is that you have misconfigured your repo files. The default repo files use a mirror list configuration but provide a commented baseurl. Ensure that you are using baseurl and properly pointing to your internal repositories.
[baseos]
name=Rocky Linux $releaseserver -BaseOS
gpgcheck=1
enable=1
baseurl=file:///<repo_path>/BaseOS/
gpgkey=///etc/pki/rpm-gpg/RPM-GPG-KEY-rockyofficial
With the exeptions of rocky specific items, this same setup works for cent7 and RHEL8. File is placed in /etc/yum.repos.d . Have made sure that all original .repo files are out of directory. As specified in the requirements, we do not host these repos from a webserver, but from an NFS share mounted in fstab. Now we do have restrictions on those mounts of
noexec,nodev,nosuid
which is not an issue with other distros, so I have discounted it.
And you’ve ensured the default repo files didn’t come back? These generally come back when rocky-release and rocky-repos are updated (which can happen semi-frequently).
Yep, totally gone, only the custom repo file. Had been my first thought as RHEL is notorious for repopulating unless you kill subscription manager. Also thought about the possibility that it might be pulling from another path. Double checked dnf, yum confs just out of caution. Am in the process of getting current month’s updates transferred over, so will see if it something that did not get transfered by weeks end.
An update, not completely sure I have isolated the issue. I did get it to update by doing the following:
eliminating file:// from baseurl=file:///<repo_path>/BaseOS/
disabled gpgcheck ( not an acceptable condition long term, is in violation of stig)
unfortunately, this is the only system I have at the moment built out in rocky 8, so I cannot test if eliminating the two additional slashes in the gpgkey line to see if it is an issue there also and can get gpgchecking back on line. Will post after next update cycle or after I get my next unit built, whichever comes first. Thanks for your assistance.
Update. Problem appears to be tied to the GPG keys and the check required. The keys appear to be in the rpm-pki folder, however do not appear to be functioning correctly. Unfortunately, have run the updates for this month, so will have to get another machine built out to test import of keys from one of the repo mirrors, to see if that makes a difference or if the original import did not take right. If it is still a problem after that will open a new conversation on the GPG key issue. Thanks for your help, again