Artifactory can act as a full-fledged YUM local repository. As such, it enables:
- RPM metadata calculation for RPMs hosted in Artifactory local repositories.
- Provisioning RPMs directly from Artifactory to YUM clients.
- Detailed RPM metadata views from Artifactory's web UI.
RPM Metadata for Hosted RPMs
The RPM metadata generated by Artifactory is identical to the basic-mode output of the Red Hat-based Linux command
A folder named
repodata is created in the configured location within a local repository with the following files in it:
|Contains an XML file describing the primary metadata of each RPM archive.|
|filelists.xml.gz||Contains an XML file describing all the files contained within each RPM archive.|
|other.xml.gz||Contains an XML file describing miscellaneous information regarding each RPM archive.|
|repomd.xml||Contains information regarding all the other metadata files.|
YUM Support is Platform Independent!
Artifactory employs a pure Java based RPM metadata calculation.
It does not rely on the existence of the
createrepo binary or on running external processes on the host on which Artifactory is running.
Triggering RPM Metadata Updates
When enabled, the metadata calculation is triggered automatically by some actions, and can also be invoked manually by others. Either way, the metadata produced is served to YUM clients.
RPM metadata is automatically calculated:
- When deploying/removing/copying/moving an RPM file.
- When performing content import (both system and repository imports).
You can manually invoke RPM metadata calculation:
- By clicking Calculate Now in the local repository YUM configuration tab.
- Via Artifactory's REST-API.
Metadata calculation cleans up YUM metadata that already existed as a result of manual deployment or import. This includes RPM metadata stored as SQLite database files.
To enable RPM metadata calculation on a local repository, select the repository which you want to enable as a YUM repository as described in Configuring Repositories, and select the Packages tab, set Auto-calculate YUM Metadata.
YUM Metadata Folder Depth
Informs Artifactory under which level of directory to search for RPMs and save the
By default this value is 0 and refers to the repository's root folder. In this case, Artiafctory searches the entire repository for RPMs and saves the
Using a different depth is useful in cases where generating metadata for a repository separates its artifacts by name, version and architecture.
YUM Group File Names
A comma-separated list of YUM group files associated with your YUM packages.
Note that at each level (depth), the
Auto-calculate YUM Metadata
|When set, YUM metadata calculation is automatically triggered by the actions described above.|
Artifactory remote repositories support YUM out-of-the-box, and there no need for any special configuration needed in order to work with RPMs in a remote repository.
All you need to do is point your YUM client at the remote repository, and you are ready to use YUM with Artifactory.
To define a remote repository to proxy a YUM remote repository, follow the steps below:
- In the Admin tab under Configuration | Repositories go to the Remote Repositories section and select "New" (or "Edit" if the repository has already been created).
- Set the Repository Key value, and specify the URL to the remote repository in the URL field as displayed below.
- Click "Create" or "Save"
- Under Browser | Tree Browser, select the repository. In the Tree Browser, the repository name is appended with "-cache".
- In the General tab, under Repository Reference, copy the value of the url tag.
- Next, create the
targetCentos.repoand paste the following configuration into it:
Using Yum to install RPM packages from Artifactory
After configuring the
yum-local repository in Artifactory, you need to configure your local machine to install software packages from it by executing the following steps:
artifactory.repofile with root privileges
Paste the following configuration into the
Now, every RPM file deployed to the root of the
yum-local repository can be installed using:
A YUM group is a set of RPM packages collected together for a specific purpose. For example, you might collect a set of "Development Tools” together as a YUM group.
A group is specified by adding a group XML file to same directory as the RPM packages included in it. The group file contains the metadata of the group including pointers to all the RPM files that make up the group.
A group file can also be created by running the following command:
Attaching a YUM Group
The process of attaching YUM group metadata to a local repository is simple:
- Create an XML file in the groups format used by YUM. You can either just type it out manually using any text editor, or run the
- Deploy the created group file to the
Artifactory will automatically perform the following steps:
- Create the corresponding
.gzfile and deploy it next to the deployed group XML file.
- Invoke a YUM calculation on the local repository.
- Attach the group information (both the XML and the
.gzfile) to the
- Create the corresponding
- Make sure the group file names are listed in the YUM Group File Names field of the Packages tab. This tells Artifactory which files should be attached as repository group information.
This is how a local repository may appear after deploying a
groups.xml metadata file to it (
repodata is calculated to depth 0):
YUM Group Commands
The following table lists some useful YUM group commands:
|Install the YUM group. The group must be deployed to the root of the YUM local repository.|
|Remove the RPM group|
Update the RPM group. The group must be deployed to the root of the YUM local repository.
|List the RPM packages within the group.|
|List the YUM groups|
Setting Group Properties
YUM group properties can be set in the
/etc/yum.config file as follows:
|overwrite_groups||0 or 1|
Determines YUM's behavior if two or more repositories offer package groups with the same name.
If set to 1 then the group packages of the last matching repository will be used.
If set to 0 then the groups from all matching repositories will be merged together as one large group.
|groupremove_leaf_only||0 or 1|
Determines YUM's behavior when the groupremove command is run.
If set to 0 (default) then all packages in the group will be removed.
If set to 1 then only those packages in the group that aren't required by another package will be removed.
|enable_group_conditionals||0 or 1|
Determines whether YUM will allow the use of conditionals packages.
If set to 0 then conditionals are not allowed
If set to 1 (default) package conditionals are allowed.
|group_package_types||optional, default, mandatory||Tells YUM which type of packages in groups will be installed when |
Proxy Server Settings
If your organization uses a proxy server as an intermediary for Internet access, specify the
proxy settings in
/etc/yum.conf. If the proxy server also requires authentication, you also need to specify the
If you use the yum plugin (
yum-rhn-plugin) to access the ULN, specify the
httpProxy settings in
/etc/sysconfig/rhn/up2date. In addition, If the proxy server requires authentication, you also need to specify the
proxyPassword settings as shown below.
YUM supports SSL from version 3.2.27.
To secure a repository with SSL, execute the following steps:
- Generate a private key and certificate using OpenSSL.
Define your protected repository in a
.repofile as follows:
gpgkey is a URL pointing to the ASCII-armored GPG key file for the repository . This option is used if YUM needs a public key to verify a package and the required key has not been imported into the RPM database.
If this option is set, YUM will automatically import the key from the specific URL. You will be prompted before the key is installed unless the assumeyes option is set.
Using Yum Variables
You can use and reference the following built-in variables in
yum commands and in all YUM configuration files (i.e.
/etc/yum.conf and all
.repo files in the
|This is replaced with the package's version, as listed in |
|This is replaced with your system's architecture, as listed by |
|This is replaced with your base architecture. For example, if |
The following code block is an example of how your
/etc/yum.conf file might look:
Creating A GPG Key and Signing RPMs
In order to create a GPG Key for signing RPMs ,use the gnupg package and gpg utilities (notice that gnupg2 will not work with these steps).
Creating a Public/Private GPG Key Pair
The following commands create a Private/Public GPG Key Pair (Note you should actually login to console/ssh with this user, not sudo to it):
You will be asked a series of questions, answer as follows (answers in italic):
- Please select what kind of key you want: (1) DSA and ElGamal (default)
- What keysize do you want? 2048
- Key is valid for? 0 (key does not expire)
- Real name: John Doe
- Email Address: firstname.lastname@example.org
- Comment: RPM Development
Generating GPG keys
Generating the GPG key may take some time, and once complete will display the following output:
Exporting Private/Public Keys for Safe Keeping
You must export the keys so that you can save them in a secure location (and also, so that they can be imported in the future). To list the keys you have installed execute the following command:
Exporting the Public GPG Key
In order to use the GPG Key with RedHat Network (RHN), you will need to make the Public portion available in a Public GPG Key by executing the following commands:
The Public Key is the only portion that should ever be made public. The Private Key must be kept secure, preferably on a system that does not allow outside access from the public internet. It is also recommended to make a hard copy (burned on a CD/USB key) of the Public/Private key pair and keep that somewhere secure like a Safe Deposit Box. Anyone who obtains your Private/Public key pair can sign RPMs as if they were signed by you and potentially perform malicious acts in your name.
You will need to make the public key available, and a common way to do this is to upload it to your web server (usually in the
/pub folder or root of your repository).
For this document we will assume that the MYORG-GPG-KEY is available at the following URL: http://<Domain>/<root folder>/MYORG-GPG-KEY
Viewing Individual RPM Information
You can view all the metadata that annotates an RPM by choosing it in Artifactory's tree browser and selecting the
RPM Info tab:
Metadata Fields as Properties
The corresponding RPM metadata fields are automatically added as properties of an RPM artifact in YUM repositories accessed through Artifactory:
Properties can be used for searching and other functions. For more details please refer to Properties.
Watch the Screencast
Watch this short screencast to learn how easy it is to host RPMs in Artifactory.