Warning: include(/homepages/10/d653673895/htdocs/clickandbuilds/Tutarticle/wp-includes/wp-session-manager.php): failed to open stream: Permission denied in /homepages/10/d653673895/htdocs/clickandbuilds/Tutarticle/wp-load.php on line 1

Warning: include(): Failed opening 'wp-includes/wp-session-manager.php' for inclusion (include_path='.:/usr/lib/php7.0') in /homepages/10/d653673895/htdocs/clickandbuilds/Tutarticle/wp-load.php on line 1
Managing RPM Packages with YUM in Linux | Tutarticle

Managing RPM Packages with YUM in Linux

The Yellowdog Updater Modified (YUM) project set out to solve the headache of managing dependencies with RPM packages. Its major contribution was to stop thinking about RPM packages as individual components and think of them as parts of larger software repositories. With repositories, the problem of dealing with dependencies fell not to the person who installed the software, but to the Linux distribution or third-party software distributor that makes the software available. So, for example, it would be up to the Fedora project to make sure that every component needed by every package in its Linux distribution could be resolved by some other package in the repository. Repositories could also build on each other. So, for example, the rpmfusion.org repository could assume that a user already had access to the main Fedora repository. So if a package being installed from rpmfusion.org needed a library or command from the main Fedora repository, the Fedora package could be downloaded and installed at the same time you install the rpmfusion.org package.

yum-in-rhel-6

The yum repositories could be put in a directory on a web server (http://), an FTP server (ftp://), or a local medium such as a CD, DVD, or local directory (file://). The locations of these repositories would then be stored on the user’s system in the /etc/yum.conf file or, more typically, in separate configuration fi les in the /etc/yum.repos.d directory

Understanding how yum works

This is the basic syntax of the yum command:

# yum [options] command

Using that syntax, you can find packages, see package information, find out about package groups, update packages, or delete packages, to name a few features. With the YUM repository and configuration in place, a user can install a package by simply typing something like this:

# yum install firefox

 The user only needs to know the package name (which could be queried in different ways, as described in the section “Searching for packages” later in this chapter). The YUM facility finds the latest version of that package available from the repository, downloads it to the local system, and installs it. Figure shows what happens when someone installs a package using the yum command.

The result of a yum install package command is that the package requested is copied from the yum repository to the local system. The files in the package are put in the filesystem where needed (/etc, /bin, /usr/share/man, and so on). Information about the package is stored in the local RPM database, where it can be queried.

To gain more experience with the YUM facility, and see where there are opportunities for you to customize how YUM works on your system, follow the descriptions of each phase of the YUM install process illustrated in Figure  and defined here.

 

  1. Checking /etc/yum.conf

When any yum command starts, it checks the fi le /etc/yum.conf for default settings. The /etc/yum.conf fi le is the basic YUM confi guration fi le. You can also identify the location of repositories here, although the /etc/yum.repos.d directory is the more typical location for identifying repositories. Here’s an example of /etc/yum.conf on a RHEL 7 system:

 

[main]

cachedir=/var/cache/yum/$basearch/$releasever

keepcache=0

debuglevel=2

logfile=/var/log/yum.log

exactarch=1

gpgcheck=1

plugins=1

Settings in yum.conf tell YUM where to keep cache files (/var/cache/yum) and log entries (/var/log/yum.log), and whether to keep cache files around after a package is installed (0 means no). You can raise the debug level value in the yum.conf file to above 2 if you want to see more details in your log files.

Next, you can see whether the exact architecture (x86, x86_64, and so on) should be matched when choosing packages to install (1 means yes) and whether to use plugins (1 means yes) to allow for things such as blacklists, whitelists, or connecting to Red Hat Network for packages.

Finally, gpgcheck says whether to validate each package against a key you receive from those who built the RPM. For packages that come with Fedora or RHEL, the key is included with the distribution to check all packages. However, if you try to install packages that are not from your distribution, you need to either import the key needed to sign those

packages or turn off that feature (gpgcheck=0).

To find other features you can set in the yum.conf file, type man yum.conf.

 

  1. Checking /etc/sysconfig/rhn/up2date (RHEL only)

For Red Hat Enterprise Linux systems, instead of pointing to a single public software repository (as Fedora does), you register your system with Red Hat Network and purchase entitlements to download software from different channels.When your system is registered with Red Hat Network, information is added to the /etc/sysconfig/rhn/up2date fi le to tell yum where to fi nd Red Hat Enterprise Linux packages (either from a hosted Red Hat Network or from an RHN Satellite server).

  1. Checking /etc/yum.repos.d/*.repo files

Software repositories can be enabled by dropping fi les ending in .repo into the directory /etc/yum.repos.d/ that point to the location of one or more repositories. In Fedora, even your basic Fedora repositories are enabled from .repo fi les in this directory. Here’s an example of a simple yum configuration file named /etc/yum.repos.d/ myrepo.repo:

[myrepo]

name=My repository of software packages

baseurl=http://myrepo.example.com/pub/myrepo

enabled=1

gpgcheck=1

gpgkey=file:///etc/pki/rpm-gpg/MYOWNKEY

Each repository entry begins with the name of the repository enclosed in square brackets. The name line contains a human-readable description of the repository. The baseurl line identifies the directory containing the RPM fi les, which can be an httpd://, ftp://, or file:// entry.

The enabled line indicates whether the entry is active. A 1 is active; 0 is inactive. If there is no enabled line, the entry is active. The last two lines in the preceding code indicate whether to check the signatures on packages in this repository. The gpgkey line shows the location of the key that is used to check the packages in this repository. You can have as many repositories enabled as you like. However, keep in mind that when you use yum commands, every repository is checked and metadata about all packages is downloaded to the local system running the yum command. So to be more efficient, don’t enable repositories you don’t need.

  1. Downloading RPM packages and metadata from a YUM repository

After yum knows the locations of the repositories, metadata from the repodata directory of each repository is downloaded to the local system. In fact, it is the existence of a repodata directory in a directory of RPMs that indicates that it is a yum repository. Metadata information is stored on the local system in the /var/cache/yum directory. Any further queries about packages, package groups, or other information from the repository are gathered from the cached metadata until a timeout period is reached. After the timeout period is reached, yum retrieves fresh metadata if the yum command is run. By default, the timeout is 90 minutes. You can change that period by setting metadata_expire in the /etc/yum.conf fi le. Uncomment that line, and change the number of minutes.

Next, yum looks at the packages you requested to install and checks if any dependent packages are needed by those packages. With the package list gathered, yum asks you if it is okay to download all those packages. If you choose yes, the packages are downloaded to the cache directories and installed.

  1. RPM packages installed to Linux file system

After all the necessary packages are downloaded to the cache directories, yum runs rpm commands to install each package. If a package contains preinstall scripts (which might create a special user account or make directories), those scripts are run. The contents of the packages are copied to the filesystem (commands, config files, docs, and so on). Then any post install scripts are run. (Post install scripts run additional commands needed to configure the system after each package is installed.)

  1. Store YUM repository metadata to local RPM database

The metadata contained in each RPM package that is installed is ultimately copied into the local RPM database. The RPM database is contained in fi les stored in the /var/lib/rp directory. After information about installed packages is in the local RPM database, you can do all sorts of queries of that database. You can see what packages are installed, list components of those packages, and see scripts or change logs associated with each package. You can even validate installed packages against the RPM database to see if anyone has tampered with installed components.

The rpm command (described in the section “Installing, Querying, and Verifying Software with the rpm Command” later in this chapter) is the best tool for querying the RPM database. You can run individual queries with rpm or use it in scripts to produce reports or run common queries over and over again.

Now that you understand the basic functioning of the yum command, your Fedora system should be automatically confi gured to connect to the main Fedora repository and the Fedora Updates repository. You can try some yum command lines to install packages right now. Or you can enable other third-party YUM repositories to draw software from.

Leave a reply:

Your email address will not be published.

Site Footer