Paranoid Penguin - Using Yum for RPM Updates
Configuring Yum is fairly simple; all you need to do is edit one file, which is named, predictably, /etc/yum.conf. Listing 1 shows the default /etc/yum.conf file that comes with Fedora Core 1's Yum RPM.
Listing 1. Fedora Core 1's /etc/yum.conf File
[main] cachedir=/var/cache/yum debuglevel=2 logfile=/var/log/yum.log pkgpolicy=newest distroverpkg=fedora-release tolerant=1 exactarch=1 [base] name=Fedora Core $releasever - $basearch - Base baseurl=http://fedora.redhat.com/releases/fedora-core-$releasever [updates-released] name=Fedora Core $releasever - $basearch - Released Updates baseurl=http://fedora.redhat.com/updates/released/fedora-core-$releasever #[updates-testing] #name=Fedora Core $releasever - $basearch - Unreleased Updates #baseurl=http://fedora.redhat.com/updates/testing/fedora-core-$releasever
As you can see, this file consists of a list of global variable settings, followed by one or more [server] blocks ([base] and [updates-released] in Listing 1), each of which specifies settings for a different type of RPM group. I'm not going to cover every possible global or server block setting; that's what the yum.conf(5) man page is for. But let's discuss a few key settings.
In the global section, debuglevel determines how verbose Yum's output is. This value may range from 0, for no output, to 10, for maximum debugging output. The default value of 2 is shown in Listing 1. As far as I can tell, this debuglevel affects only standard output, not Yum's log file, whose location is specified by logfile. Still, I like to change this value to 4, which I arrived at by playing with the yum command's -d value. For example, (yum -d 4 yum-commands) is equivalent to and overrides debuglevel.
Also in the global section, pkgpolicy specifies how Yum should decide which version to use if a given package turns up across multiple [server] blocks. distroverpkg specifies the name of your local release file package. Your release file, for example, /etc/fedora-release or /etc/redhat-release, contains the name and version of your Linux distribution.
Each [server] block defines a set of RPMs. Personally, I wish these were called [package-type] blocks instead, because they don't distinguish by server but rather by RPM group. A single block may contain the URLs of many servers. In Listing 1, the [base] block contains a single URL pointing to the main Fedora repository at fedora.redhat.com.
Fedora mirrors that contain the same collection of RPMs can be listed with additional baseurl lines. Any line in a [server] block may use the variables $releasever, which resolves to the version number of your Linux distribution, and $basearch, which expands to the CPU family of your system. CPU families exist here in the most generic sense; Athlons are considered part of i386 in this context.
The /etc/yum.conf file installed by your Yum RPM probably works fine, but you should augment each default URL, http://fedora.redhat.com... in Listing 1, with at least one mirror site URL. Doing so minimizes the chance that your updates fail due to one server being unavailable. Be sure to use your favorite Web browser to test-drive any URL you add to yum.conf to make sure it successfully resolves to a directory containing a directory named headers. Also, make sure your URL ends with a trailing slash.
The other thing worth noting in Listing 1 is that one important [server] option is missing: gpgcheck. Listing 2 shows a corrected [base] block that uses this option.
Listing 2. Customized [base] Section
[base] name=Fedora Core $releasever - $basearch - Base baseurl=http://mirror.eas.muohio.edu/fedora/ ↪linux/core/$releasever/$basearch/os/baseurl= ↪http://fedora.redhat.com/releases/ ↪fedora-core-$releasever gpgcheck=1 failovermethod=priority
Setting gpgcheck=1 causes Yum to check the GnuPG signature in each RPM it downloads. For this to work, you need the appropriate GnuPG keys incorporated into your RPM database. On Fedora Core 1 systems, these keys were installed on your system as part of the fedora-release package. To copy them to your RPM database, execute this command:
rpm --import /usr/share/doc/fedora-release-1/RPM-GPG*
The rpm --import command also can use a URL as its argument, so if the GnuPG key of your Yum source is on-line, you can use the form:
rpm --import http://your.distro.homepage/GPGsignature
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Tech Tip: Really Simple HTTP Server with Python
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script