New with Scientific Linux 7: Scientific Linux Context Framework!
Starting with Scientific Linux 7 it is even easier to deploy use case specific customizations.
The context framework is designed to scale from smaller projects to collaborations. Through leveraging package repos and groups, specific tools and configurations can be provided in parallel with any on-site systems management procedures or the packages can be used as a payload by those tools.
Physical locations, scientific applications, or experiments can provide the tools they use in a traditional package repository. Interested users can then quickly locate specific behaviors and add them as needed.
|For users familiar with previous spins, such as Scientific Linux Fermi (SLF), these are now packaged as a Scientific Linux Context.
2. Installing a Context
There are several ways to install a Scientific Linux Context:
Kickstart (at Install)
Boot Line at Install Time
Interactive at Install Time
Interactive After Installation
Using an Anaconda addon, the settings can be specified directly in the kickstart file.
Additional details can be specified:
The --testing argument enables the context testing repo for all enabled contexts.
If url is omitted the default is assumed.
If testing is omitted, the default (off) is assumed and the context’s testing repo will not be enabled.
The entry is a pipe delimited list,
|The --testing argument will force the testing repo
to be enabled for all contexts.
This means our first and second examples are functionally equivalent.
%addon org_scientificlinux_contexts --testing
2.2. Boot Line at Install Time
Using an Anaconda addon, the settings can be specified directly on the boot line.
context.testing is identical to --testing for kickstart
context.enable= is a comma-separated list of entries identical to kickstart
vmlinuz context.enable=example context.testing
vmlinuz context.enable=example|testing vmlinuz context.enable=http://url|example vmlinuz context.enable=http://url|example|testing vmlinuz context.enable=http://url|example|testing,secondexample
|The samples here should be equivalent to the Kickstart examples above.
2.3. Interactive at Install Time
The Scientific Linux installation media includes an installation screen for
CONTEXT where individual contexts can be located and selected.
CONTEXT menu option is available in both GUI and Text mode. Though,
Text mode is significantly more limited than the GUI.
2.4. Reloading The Context
You can reload the context packages by running:
Yum’s default configuration is to load
However, this script will honor whatever you’ve set for
2.5. Reading the Local Yum Database
You can review state via
yum group info example.
$ yum group info fermilab
Group: Packages to support the Fermilab Context
Description: These are packages for the Fermilab context.
2.6. Interactive After Installation
Installing a context after system installation requires a few steps:
yum install yum-conf-context-example
|The sleep statement is required as yum-conf-context-example is performing some background tasks which must complete before the yum update.
3. Making Your Own Context
Each Context is about enabling a specific computing goal. Whether the goal is computing on-site at Fermilab or performing CMS analysis does not really matter so long as it is specific.
An example Context named
example is provided to help demonstrate the
|Nearly all content within the Scientific Linux Context Framework
is provided via RPM packages.
Anyone interested in making their own Context should be familiar with creating RPMs.
3.1. Naming Your Context
Context names have a few rules:
The name may only contain the following:
lower case Latin characters
For clarity, the name should be obviously associated with the computing context
3.1.1. Defining Your Scope
The behaviors your Context provides should stop at the earliest clear endpoint.
This can be somewhat nebulous, but, if built correctly, your Context should be able to co-exist with another Context.
|It would not be out of place for a CMS Context to depend on a CVMFS Context, rather than maintain that software stack internally.
When building your behaviors, you can always add new functionality. It is often difficult to remove features and transition to alternate software sources.
|Ask yourself, “Based on the name of my Context, does it make sense to add this item?”
Contexts are not required to support all architectures provided by Scientific Linux.
Based on the scope of your context can limit what architectures your packages support.
3.2. Types of Behavior
Each customization you add should serve a narrow purpose.
We believe the following behavior types should cover all expected use cases:
A base package should depend on other packages providing the basic feature set for a given, often complex, task. It should contain no files, have no scripts, and provide no triggers.
A conf package should provide the configuration for a defined behavior.
Whenever possible a conf package should utilize any
service.ddirectories. In that case, the configuration file should be correctly tagged as
If an existing configuration file, provided by another package, must be modified, this should be performed via a RPM trigger.
A logo package should contain any relevant artwork.
A repo package contains a yum compatible RPM package repository. The recommended default state of this repository is
enabled, but this is not a requirement.
A util package contains an application, a set of utilities, or a program. It may also contain its configuration files.
3.2.1. Scripts and Triggers
Any script or trigger must only utilize commands available within TUV’s base package set.
If at all possible, the commands and behaviors should be those from TUV’s initial release (#.0). Tools and behaviors from later updates may only be used if the RPM package Requires are correctly filled out to note the restriction.
Any triggers altering configuration files (provided by conf packages) may only execute under the following conditions:
The initial installation of either the trigger package or the conf package
The conf package is being upgraded
|A trigger provided by a conf package should not alter files under any other conditions.
4. Context Directory Structure
|-- contexts/example/README.html -> docs/index.html
| `-- contexts/example/debuginfo/repodata
| |-- contexts/example/mirrors/base
| |-- contexts/example/mirrors/debuginfo
| |-- contexts/example/mirrors/SRPMS
| `-- contexts/example/mirrors/testing
| `-- contexts/example/SRPMS/repodata
| `-- contexts/example/testing/x86_64
Is the toplevel metadata file which contains a single JSON array naming the contexts.
There is only one
.contexts.jsonfile at the top of the contexts tree. It is not tied to any particular context.
This file is optional. If you create a README.html, it must be a link to some file within the docs/ directory. Exactly which file it points at is up to you.
README.htmlshould serve as a quick start guide for your users.
Contains the GPG key, or keys, used for signing all RPMs within the context.
Contains documentation on this context - possible usage suggestions, kickstarts, or other relevant documentation.
Contains all the debuginfo for all binary packages within the context repo. This includes debuginfo for any testing packages.
Contains all the source rpms for all packages within the context repo. This includes SRPMS for any testing packages.
Contains all the testing rpms, for a given architecture. Even if your context does not utilize testing at this time, this repo is required. There is no problem with it remaining empty.
Contains all the rpms, for a given architecture.
Contains a mirror list for the $basearch repo.
Contains a mirror list for the debuginfo repo.
Contains a mirror list for the SRPMS repo.
Contains a mirror list for the testing/$basearch repo.
This directory structure can be hosted on a website, ftp server, or on the top level of a DVD image.
|If the context is included in the top level of a DVD it will be automatically scanned and its contents will be listed for selection.
4.1. Context Metadata
%post section of
yum-conf-context-example the local
yum database will be configured to install the yum group
4.1.1. Package Groups
The default package set of a Scientific Linux system is often a product of the
selected Package Groups. These are defined by the repository’s metadata in a
file either named
|The traditional name is
comps.xml and will be used here going forward.
Anaconda (the installation program), yum, and dnf, all take the content of every enabled repository into account before determining a course of action.
This behavior is not unexpected.
The default behavior during package installation, for example, is to install the package with the highest version number – regardless of which repository contains the package.
This behavior extends to Package Groups. The group metadata from all available comps.xml files from each repository is merged into one namespace before any packages are selected. As a result, your Context can add packages to the most common groups easily.
Your Context must include a group named after your context that can be utilized for adding your feature set. This group may contain no packages.
|You can generate your own
comps.xml with the yum-groups-manager
yum-groups-manager --id example -n example --description='Support file for the example context' --merge comps.xml --mandatory example-base_virt-tools
yum-groups-manager --id example -n example --merge comps.xml --optional example-conf_kerberos
yum-groups-manager --id example -n example --merge comps.xml example-logo_mycompany
4.2. Generating Your Update Information
Over time your Context will probably have package updates. Each updated package should include information about the update.
Scientific Linux has standardized on the upstream updateinfo.xml metadata for this information.
|Scientific Linux provides a full python library for generating and
manipulating updateinfo.xml documents within the python-Updateinfo
package contained in the
Tutorial information for python-Updateinfo is maintained with that library.
Scientific Linux hosted Contexts must have complete update information for all packages within the production repositories.
|Packages within the testing repositories are strongly encouraged to provide this metadata, but it is not required.
4.3. Naming Your RPM Packages
The naming convention for Context packages is designed to produce clear origin of packages and quick understanding of their purposes.
The format of context packages consists of:
In this way you can quickly filter packages by Context, behavior, and purpose.
|Well known packages with defined names(such as python support libraries
or commonly used applications such as rootd) are not required to rename
However, they are encouraged to add a rpm Provides for what the package would be named if it were renamed for the context.
5. Submitting Your Context to Scientific Linux
Currently the code is accessible at:
git clone https://cdcvs.fnal.gov/projects/scientificlinux-anaconda-context