How to Add a New Enterprise Linux Series¶
Throughout this document, we will refer to the new Enterprise Linux series as
ELX, and the previous EL series as
For example, if we are adding el9, then
ELX refers to
This document explains how to add support for a new
ELX series to an existing
For adding a new OSG series, see the New Release Series documentation.
See the documentation in the OSG Technology/Software and Release/Infrastructure Google Drive folder for details on the infrastructure.
Prepare Koji and OSG-Build¶
ELXKoji tags and targets
Modify this script as appropriate and run: https://github.com/opensciencegrid/osg-next-tools/blob/master/koji/create-new-koji-elX-tags-etc
In particular, update
ELas appropriate (eg,
el9), and update the
### external repos ###section with a new block of external repos to add to the
Then for the OSG-series specific tags, modify this script as appropriate and run: https://github.com/opensciencegrid/osg-next-tools/blob/master/koji/create-new-koji-osg3X-tags-etc
In particular, set
SERIESto the current OSG series, and include ONLY the new
el9). (Do not include
ELversions that already exist for this series.)
Then for the devops tags, modify this script as appropriate and run: https://github.com/opensciencegrid/osg-next-tools/blob/master/koji/create-new-koji-devops-tags-etc
In particular, set
SERIESto the current OSG series, and set
ELto the new
Add Koji package signing, as necessary
With any luck, you can use the existing RPM signing key for the OSG series to which you are adding the new EL series.
If it turns out that you need to create a new RPM signing key for
ELX(because reusing the one for the current OSG series doesn't work in
ELXfor some unexpected reason), then you will need to generate a new key in the keyring for the Koji sign plugin, and save it (encrypted) in the Koji Ansible config. See Infrastructure Google Drive folder for details.
Either way, you will need to make modifications to the
[email protected]:osg-services.git, so get a checkout of that ready.
$ ssh koji.chtc.wisc.edu $ git clone [email protected]:osg-services.git $ cd osg-services
If you are adding a new RPM signing key, you need to edit
koji/roles/signplugin/vars/main.ymlto add the key name, password, and list of tags the key should be used for; and
koji/roles/signplugin/templates/sign.conf.j2to add template code for generating the
sign.confconfig blocks for those tags.
If you are using the existing RPM signing key for the OSG series, you only need to edit
Find the tags section for your current signing key, eg,
osg3_build_tags, and add all
ELXbuild tags to this section. Eg, for el9 to OSG 3.6:
osg3_build_tags: - dist-el9-build - osg-el9-internal-build - osg-3.6-el9-build - osg-3.6-upcoming-el9-build
Apply the Koji Ansible config on the Koji Hub host.
# ssh koji.chtc.wisc.edu # git clone [email protected]:osg-services.git $ cd ~/osg-services/koji $ ansible-playbook -K -c local -l $(hostname -f) --ask-vault-pass --check --diff secure.yml # If the above looks good, run again without --check to apply for real $ ansible-playbook -K -c local -l $(hostname -f) --ask-vault-pass --diff secure.yml # -K = prompt you for sudo password (BECOME password) # -c local = use the "local" connection method # -l $(hostname -f) = apply the changes to the current machine only # --ask-vault-pass = prompt you for the ansible-vault pw # --check = dry-run mode # --diff = show the diffs of any file changes it (would) make # secure.yml = the "playbook" of changes to apply
If you are adding a new RPM signing key, export the ASCII-armored public key as
<N>is the previous key's number incremented by one), and add it to the
In the script
generate-repo-files.shensure that the logic for selecting the
GPGKEYincludes the correct behavior for the new
ELXto reference the latest key file.
osg-buildto add the new
ELXto the various
dversin python scripts, and
promoter.ini; and add the new
ELXtags and targets to the test scripts. See the Git commits on
opensciencegrid/osg-buildfor SOFTWARE-5342 for details on how to do this. Use this version of
osg-buildfor subsequent steps.
This section is incomplete.
But for starters, begin with the Build prerequisite packages section of the New Release Series documentation.
In general, you will not have to repeat steps for creating a new
series, but you will have to create a new
buildsys-macros.elX package for