|
|
Because no software is perfect, software developers are constantly trying to find ways to improve and enhance their products. The two most important reasons you should be vigilant about updating your system are security and stability.
Security-With the ever-growing popularity of Linux, discovering and correcting the security vulnerabilities of the software used on Linux systems becomes paramount. The fixes that emerge are made available to the community by your distribution vendor in the package format chosen for that distribution. Fedora Core is no different. Updates are provided in RPM format for end-user consumption.
Stability-Bugfix updates, while of lower priority than are security updates, are still very important as they directly affect the stability of your system. For the most part, minor bugs are fixed upstream by the software developers and do not spawn an update rpm for the current Fedora Core release. As the severity of the bug increases, so does the possibility of an update rpm being issued for the current Fedora Core release.
There are many ways to keep your Fedora Core system up to date. These include:
Automated updates-Using tools that automate the installation of updates, as well as resolving dependencies for the updates. These methods can be totally automated (with scheduled times for automatically processing updates), or triggered manually.
Manual updates-Manually seeking out available updates and processing them by hand. This method is satisfactory for single updates, but becomes tiresome when you need to handle lots of updates and/or large numbers of systems.
Source updates-Using source code to update existing software. This method may be useful when you need an update before a new package is made available, but it is also highly discouraged as it will lead to the irrelevance (what's actually on your system doesn't match what's in your RPM database) of your package management system as it's only able to track what you install/update in RPM format.
| Caution |
While it may seem on the surface that source installs will make only that package irrel-evant in your RPM database, all the packages that rely on this package or interact with it will also suffer from expecting one version of the package while a newer version is installed via source. This can cause a cascading effect as you gradually replace more and more packaged software with source to overcome the irrelevance of that first single package. While this may not happen with every user or package, it's necessary to warn against it. |
The preferred method of keeping your Fedora Core system up to date is with automated update tools. Two such tools are included with Fedora Core: up2date and yum.
up2date is the familiar Red Hat-developed tool that has both a command-line interface and a graphical user interface (GUI). up2date has been given some pretty significant enhancements with Fedora Core, including the ability to access yum, apt-rpm, and dir repositories. (yum and apt-rpm are discussed later in this chapter.) While up2date is technically able to communicate with Red Hat Network (RHN), currently there are no Fedora Core channels available at RHN and thus this functionality is wholly unused.
To go along with these new features, up2date has a new configuration file. Given that RHN functionality is no longer used in Fedora Core, you can safely ignore all other up2date configuration files, save the new one. This file holds a list of the yum/apt-rpm/dir repository you wish to use. The format is one repository entry per line. The first word on each line reflects the type of repository. The /etc/sysconfig/rhn/sources file contains the following active entries:
yum fedora-core-1 http://fedora.redhat.com/releases/fedora- core-1 yum updates-released http://fedora.redhat.com/updates/released/fedora-core-1
The first line shows a yum style repository named fedora-core-1 for the base OS packages (all the packages you'd find on Fedora Core CDs 1-3). The second line shows another yum style repository named updates-released for the released updates for Fedora Core 1. You can add as many repository lines as you wish, even linking to third-party repository for all your extra software.
| Note |
There's a line in /etc/sysconfig/rhn/sources that contains up2date default. It is safe to ignore this line, which is a vestigial artifact of the development process. If you want the full explanation, read on. The line is for use with RHN servers. It is included, and the client supports RHN servers, because at the time of the initial beta cycles, the decision had not yet been made as to whether RHN would carry Fedora content. The decision was later made not to carry Fedora content, but the application still supports RHN protocol. |
Each repository type has its own syntax. The syntax of each repository that can appear in the sources file used by up2date is covered in Table 3-1.
|
Repository Type |
Syntax |
Example [*] |
|---|---|---|
|
yum |
Type + channel-label + url |
yum fedora-core-1 http://fedora.redhat.com/releases/ fedora-core-1 |
|
apt |
Type + channel-label + service:server + path + repo-name |
apt arjan-2.6-kernel http://people.redhat.com~arjan/2.5 kernel |
|
dir |
Type + repo-label + path |
dir my-local-rpms /home/buiIdman/RPMS/ |
|
[*]Each repository name should be one line, with no breaks. |
||
Multiple versions of all repositories can be used, aside from RHN repositories. Dependencies can be resolved cross-repository if need be, meaning that if you wish to install a package from one configured repository, and it requires a package located in a different repository, the second package can be found and installed from within its repository. This means that each repository does not have to be self-hosting, and can depend on other repositories to fulfill package requirements.
By default, up2date is configured to use the yum repository at fedora.redhat.com. If you've used up2date in the past, the usage syntax has not changed, even though the backend repository has. To check for available updates, type
# /usr/sbin/up2date -1
or
# /usr/sbin/up2date --list
If you are using a GUI when you first call up2date, it will bring up a screen to help you configure up2date. Each option is self-explanatory, and most often the defaults will suffice. It will also bring up a box asking you to import the Fedora GPG key into your rpm keyring. This will allow rpm to make an extra check of the package validity.
The next time you run up2date (configured for yum) it will need some time to download all the available package headers from the repository. Do not be alarmed if up2date seems to stall; check for network activity before killing any processes.
If there are any updates available, up2date will list them for you. You can update them individually, or choose to install all available updates. To update a single package, type
# /usr/sbin/up2date -u package
where package is the update you want to install.
| Caution |
When using up2date to update single packages, beware that if the package you pass to up2date is not currently installed, up2date will install that package, and any dependencies it may need. |
If you wish to process all the available updates at once, just type
# /usr/sbin/up2date -u
If you use the GNOME or KDE desktop environments, you'll have a panel icon that can look like a blue ball with a white checkmark, or like a red ball with a white exclamation point, depending on whether any updates are available. This is the Red Hat Network Alert Notification Tool. This tool uses the repositories configured in /etc/sysconfig/rhn/sources to periodically check for available updates, changing from the blue check (no updates available) to the red exclamation point (updates available). Clicking the icon brings up a window that shows available updates and allows you to launch a graphical up2date interface to process the available updates.
This interface does not offer as much functionality as the command-line interface, but can be used to check for updates and install individual updates or all available updates. Figure 3-1 shows the graphical up2date with an update available, and Figure 3-2 shows the graphical up2date downloading an update.
Once you understand the basics of what up2date does, you might want to look into some of the extra features that come with it. Here are a few tips and tricks that might interest you:
Package search-up2date has the ability to display all the packages available for download. The command to see this is up2date-showall. You can pipe the output of this through grep to search for a specific package or packages.
Source package retrival-up2date can retrieve a given srpm without trying to resolve dependencies. This option is -get-src.
Force install-up2date by default is set to skip kernel packages. To override this setting without editing the /etc/sysconfig/rhn/up2date configuration file, you can supply the - f flag on the command line. This will force up2date to ignore package exclusion rules and install/update what you ask it to.
Test run-up2date can be ran in a test mode, where it will process its task without actually doing the task. This can help you see the expected outcome of a complicated task without actually making any changes. The option for this is -dry - run.
There are many more options and configurations for up2date. Consult the up2date man page and the core configuration file /etc/sysconfig/rhn/up2date for more information.
yum stands for Yellowdog Updater, Modified. You could say that yum started its life as a tool called yup or Yellowdog Updater for the Yellowdog Linux distribution. Yellowdog Linux is a Linux distribution built for Apple hardware and based on Red Hat Linux. The description of yum from its home page (http://linux.duke.edu/projects/yum) is:
yum is an automatic updater and package installer/remover for rpm systems. It automatically computes dependencies and figures out what things should occur to install packages. It makes it easier to maintain groups of machines without having to manually update each one using rpm.
Originally a very popular third-party package management tool, yum was officially included in Red Hat systems starting with Fedora Core 1. One of yum's best features is how easy it is to set up a yum server.
For clients to be able to use a yum repository, they need to define that repository in their /etc/yum.conf configuration file. There are two sections to this configuration file: main and servers. The main section defines all the global configuration options, while the server section defines the entries for each repository. Table 3-2 shows the main configuration items and their default values. You can read more about these and other options on the yum.conf man page.
|
Options |
Usage |
Default Value |
|---|---|---|
|
Cachedir |
Directory that holds the cached header info |
/var/cache/yum |
|
Debug level |
Controls the amount of debug output |
2 |
|
Logfile |
File that yum log into |
/var/log/yum.log |
|
Pkgpolicy |
Package sorting order (for use with multiple repositories) |
newest (install the newest version found) |
|
Distroverpkg |
Package used to determine distribution release |
fedora-release |
|
Tolerant |
How to treat errors on the command-line options |
0 (not tolerant) |
|
Exactarch |
Force yum to be strict with package archs |
1 (enabled) |
Following the main options is the repository configuration section. This section lists the repositories one by one, each usually in a three-line set per repository. The first line is the serverid, contained in square ([]) brackets. This must be a unique name, all one word. The next line holds the human readable name for the repository. This is the name you'll see on the command line. The syntax for this line is name=My Repository Name. The final line is the actual URL to the repository. This can be in the form of http://, ftp://, or file://. The syntax is baseurl=url://server/path/to/repository.
| Note |
Don't forget the third slash (/) when defining a file-based repository, for example, baseurl=file:///var/packages. |
You can also specify more than one URL, to set up a failover array of URLs, by just adding more URL lines. (Don't add another baseurl line or you'll get bizarre results from yum) By default, there are two servers configured for your Fedora system.
| Cross-Reference |
See Appendix A for a list of third-party repositories you can use with your Fedora Core system and yum. yum repositories can be added to your /etc/yum.conf file. Please consult the yum.conf man page as well as /etc/yum.conf for examples. |
Now that you have your configuration file just the way you like it, it's time to actually use the application. yum is incredibly simple to use; simplicity is one of its strong points, and one of the goals behind the development of yum. To check for available updates, type the following:
# /usr/bin/yum list updates
If there are any updates available, yum will list them for you. You can update them individually, or choose to install all available updates. To update a single package type
# /usr/bin/yum update package
where package is the update you want to install. In order to process all the available updates at once, type
# /usr/bin/yum update
| Note |
This command will ask you to verify that you wish to install each update. This can get very tiresome if there are a lot of updates available. To assume yes for every question, pass yum the -y option. This will make yum fully automatic. |
Setting up your own yum server has many benefits. Updates can be downloaded once to a local system, and then other local systems can update from it, saving wasted bandwidth from duplicate downloads. Custom repositories can be created with special content. Repositories can be created for systems that don't ship with yum.
There is no specific protocol for yum. yum supports http, ftp, local directory, and just about any remote file system protocol. There is no specific directory structure either. You can create any kind of file structure, and just make the top directory (and the subdirectories) available by one of the available protocols. The following instructions show how to set up a yum repository on an HTTP server.
Copy the software packages to the directory structure you want to use. Assuming the packages you want are in the current directory, you could type
# mkdir /var/www/html/mypackages-1 # cp *.rpm /var/www/html/mypackages-1
Create the metadata needed by the yum client as follows:
# yum-arch /var/www/html/mypackages-1/
Enable the httpd server if you haven't already done so.
As shown in the code example, yum-arch takes one main argument: the location of the RPMS you want to scan for. This argument will scan from the argument directory down through all its subdirectories, gathering information about all the RPMs it finds along the way. yum-arch will create a directory named headers/. This directory holds the compressed RPM header information. This directory tree is now ready to be a yum repository.
Although on the surface yum appears to be a simple tool, it is remarkably powerful and useful. Here are a few neat things that yum supports:
Package information-yum has the ability to display a package summary and description, even if the package is not installed. The option for this is info. It takes a package name or names as arguments, for example, # /usr/bin/yum info kernel.
Package removal-yum has the ability to remove packages, as well as any other packages that might depend on the package you're trying to remove. This can be extremely handy when trying to slim down an installation base. This option is remove. It takes a package name or names as arguments, for example, # /usr/bin/yum remove gimp.
Alternative configuration file-yum can be told to use an alternative configuration file for an operation. This comes in handy when you need to use a separate repository that is not normally used. Also, with yum's ability to read a configuration file over the Internet (http/ftp), you can maintain a single configuration file for an entire work group of computers, minimizing maintenance tasks when needing to make changes to yum's configuration. The option to use a different configuration file is - c and it takes a file location or an http/ftp file location as its argument, for example, # /usr/bin/yum -c http://mywebserver/myyumconf.conf update.
yum also supports some advanced features like package group operations and package listing options. For more information consult the yum and yum.conf man pages and the /etc/yum.conf configuration file.
In some situations, you may prefer manual updates to automatic updates. This could be because you wish to quickly update a critical package without waiting for a possibly lengthy update program to run, or you wish to update a system that does not have any external Internet access.
In order to update your system manually, you'll need to know what updates are available and where you can download them from. Typically you can use the location of available updates to glean what updates are available, just by looking at the packages within the updates directory. There is also a Red Hat-sponsored mailing list setup for update announcements at www.redhat.com/mailman/listinfo/fedora-announce-list. This page also has an archive of past messages sent to the list.
Messages sent to this list have two main formats. One format is for security-related updates, and the other format is for non-security-related updates. Listing 3-1 shows a security update for the Linux kernel, and Listing 3-2 shows a nonsecurity update for the kernel as well.
 |
From: Dave Jones <davej redhat com> To: fedora-announce-list redhat com Subject: [SECURITY] Updated kernel resolves security vulnerability Date: Tue, 6 Jan 2004 13:18:20 +0000 ------------------------------------------------------------------ Fedora Update Notification FEDORA-2003-046 2004-01-05 ------------------------------------------------------------------ Name : kernel Version : 2.4.22 Release : 1.2138.nptl Summary : The Linux kernel (the core of the Linux operating system) Description :The kernel package contains the Linux kernel (vmlinuz), the core of your Red Hat Linux operating system. The kernel handles the basic functions of the operating system: memory allocation, process allocation, device input and output, etc. Paul Starzetz discovered a flaw in bounds checking in mremap() in the Linux kernel versions 2.4.23 and previous which may allow a local attacker to gain root privileges. No exploit is currently available; however, it is believed that this issue is exploitable (although not trivially.) The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0985 to this issue. All users are advised to upgrade to these errata packages, which contain a backported security patch that corrects this issue. Red Hat would like to thank Paul Starzetz from ISEC for disclosing this issue as well as Andrea Arcangeli and Solar Designer for working on the patch. These packages also contain a fix for a minor information leak in the real time clock (rtc) routines. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0984 to this issue. ------------------------------------------------------------------- * Wed Dec 24 2003 Dave Jones <davej redhat com> - Fix mremap corner case. * Tue Dec 23 2003 Dave Jones <davej redhat com> - Numerous USB fixes (#110307, #90442, #107929, #110872) * Tue Dec 16 2003 Dave Jones <davej redhat com> - Fix leak in CDROM IOCTL. (#112249) ------------------------------------------------------------------ This update can be downloaded from: http://download.fedora.redhat.com/pub/fedora/linux/core/updates/1/ C9a94fe6d6a3cffb2604a17bf42839e2 SRPMS/kernel-2.4.22-1.2138.nptl.src.rpm 841d46869Z37a9acce1c5e667e13807e i3867kernel-source-2.4.22- 1.2138.nptl.i386.rpm ad2e530db065ddc5cceef49ff825d606 i386/kernel-doc-2.4.22- 1.2138.nptl.i386.rpm ed345bd737557d25437d8a06ff10c6ed i386/kernel-BOOT-2.4.22- 1.2138.nptl.i386.rpm bc4dab2573386726679014c6fa2eb059 i386/debug/kernel-debuginfo-2.4.22- 1.2138.nptl.i386.rpm 88bb242ald86c54674c8be1b2a5d918e i386/kernel-2.4.22-1.2138.nptl.i586.rpm e5f61174a8586eb7487453dae7ea1875 i386/debug/kernel-debuginfo-2.4.22- 1.2138.nptl.i586.rpm ee7ac4fferdfa5ceff18e10d9c5b776b i386/kernel-2.4.22-1.2138.nptl.i686.rpm 50a7aabcbb8642c878714e3c58a49dff i386/kernel-smp-2.4.22- 1.2138.nptl.i686.rpm fdd33ad20548d78295e59a3d3c7d1f5b i386/debug/kernel-debuginfo-2.4.22- 1.2138.nptl.i686.rpm 8b6ee386df3bcb68dd1c149c91f677e5 i386/kernel-2.4.22-1.2138.nptl.athlon.rpm 01 af9cea1186fefc4e844c4d78cc7a06 i386/kernel-smp-2.4.22- 1.2138.nptl.athlon.rpm 01592b67d16d33f577c4de864f3799e5 i386/debug/kernel-debuginfo-2.4.22- 1.2138.nptl.athlon.rpm This update can also be installed with the Update Agent; you can launch the Update Agent with the 'up2date' command. ------------------------------------------------------------------ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0985 http://isec.pl/vulnerabilities/isec-0013-mremap.txt
|
|
From :Dave Jones <davej redhat com> To :fedora-announce-list redhat com Subject: Fedora Core 1 kernel update. Date : Tue, 13 Jan 2004 20:24:56 +0000 ------------------------------- ------------------------------------- Fedora Update Notification FEDORA-2003-048 2004-01-13 -------------------------------------------------------------------- Name : kernel Version : 2.4.22 Release : 1.2149.nptl Summary : The Linux kernel (the core of the Linux operating system) Description : The kernel package contains the Linux kernel (vmlinuz), the core of your Fedora Core Linux operating system. The kernel handles the basic functions of the operating system: memory allocation, process allocation, device input and output, etc. ------------------------------------------------------------------ * Wed Jan 07 2004 Dave Jones <davej redhat com> - Merge several EXT2/3 fixes from 2.4.25pre - EXT2/3 fixes. - Reclaim pages in truncate - 2.6 EA symlink compatibility - forward-compatibility: online resizing - Allow filesystems with expanded inodes to be mounted - Handle j_commit_interval == 0 - IDE timeout race fix - Merge some 2.4.23pre patches that were missed. - Make root a special case for per-user process limits. - out_of_memory() locking - Drop module count if lockd reclaimer thread failed to start - Fix potential fsync() race condition - s/Red Hat/Fedora/ in specfile (#112992) - Add PCI ident for new Intel e1000 card. (#105046) - Actually wire up 3c59x ethtool ioctl. - Fix up numeric sysctls to match mainline. ------------------------------------------------------------------ This update can be downloaded from: http://download.fedora.redhat.com/pub/fedora/linux/core/updates/1/ 0528ff2ef4b077e34a6e9f0bdc4c4c43 SRPMS/kernel-2.4.22-1.2149.nptl.src.rpm cf2da4c300650d6a68aeb3141e8de93e i386/kernel-source-2.4.22- 1.2149.nptl.i386.rpm b6ffe9lb11cb64af23f08de19c965677 i386/kernel-doc-2.4.22- 1.2149.nptl.i386.rpm 37bdb02f23cd936fc6a68c8b2f176275 i386/kernel-BOOT-2.4.22- 1.2149.nptl.i386.rpm fe89710f267b238c9e5fcdf3d2658383 i386/debug/kernel-debuginfo-2.4.22- 1.2149.nptl.i386.rpm 68de6d015862dfc63d40b68a8fa1affa i386/kernel-2.4.22-1.2149.nptl.i586.rpm 9714ae57c042a42400336c06ae07f2c3 i386/debug/kernel-debuginfo-2.4.22- 1.2149.nptl.i586.rpm ccc831fbb9ffa04ed7504f058411febc i386/kernel-2.4.22-1.2149.nptl.1686.rpm 257145cc01flea38fbcf22304b93d566 i386/kernel-smp-2.4.22- 1.2149.nptl.i686.rpm baff2d70eb4e24b626511b9f3feacccd i386/debug/kernel-debuginfo-2.4.22- 1.2149.nptl.i686.rpm 70b1314d932ff4283cab39a289b7aedc i386/kernel-2.4.22-1.2149.nptl.athlon.rpm af27b81477979c6ff42a9e1475adaf3b i386/kernel-smp-2.4.22- 1.2149.nptl.athlon.rpm 307fb0efbbc54a55e3d0c2a4b134c691 i386/debug/kernel-debuginfo-2.4.22- 1.2149.nptl.athlon.rpm This update can also be installed with the Update Agent; you can launch the Update Agent with the 'up2date' command.
|
The main differences between the two formats are the subject lines, the update description, and the references. Security updates get a special [SECURITY] prefix to their subject lines. This makes it easier for an administrator to pay close attention to security-based updates. The nature of a security update means there is more information given in the update description. The security flaw is described, and any external security tracking cases are referenced as well (like CVE or Common Vulnerabilities and Exposures). At the bottom of the notification, the external references are listed once more, with specific URLs.
These messages provide URLs to the updated packages, and you can find a mirror list at http://fedora.redhat.com/download/mirrors.html. You can manually download the packages and install them, using the -Uvh option, to rpm:
# rpm -Uvh gaim-0.74-5.i386.rpm
Updating packages manually means that you'll have to resolve the dependencies manually as well. This can sometimes be tricky. Thankfully, Fedora Core's rpm system is now able to make package suggestions for missing dependencies if you have the rpmdb-fedora package installed. (If you don't have this package installed, and you plan on manually updating your system, I highly recommend you install it.) Here's an example of rpm's ability to suggest resolutions:
# rpm -ivh xsane-gimp-0.91-1.i386.rpm
error: Failed dependencies:
libieee1284.so.3 is needed by xsane-gimp-0.91-1
libsane.so.1 is needed by xsane-gimp-0.91-1
Suggested resolutions:
libieee1284-0.2.8-1.i386.rpm
sane-backends-1.0.12-4.i386.rpm
The output suggests that we install libieee1284 and sane-backends to satisfy the dependency requirements of xsane-gimp.
Source updates, while technically possible, are highly discouraged. Updating via source tarballs involves downloading the latest source from a project website, compiling the source, and installing over the current software set. This method is not very clean, as the default source install may not put files in the same places that the previous package did, does not update your rpm database, and may be missing critical patches that are necessary for operation on your Fedora Core system.
If you must go the source route, I recommend that you use a tool that will keep your RPM database up to date. Checkinstall (http://asic-linux.com.mx/~izto/checkinstall/) provides a way to take a set of sources and build RPMs out of them. It's still not as clean as RPM updates provided by the Fedora Project, but it is cleaner than straight source installs.
Many problems can occur when updating your system. Many of the errors involve network problems of one kind or another. When you do run into update problems, make sure you can access the server you have configured. Try using mirrors of the server. If you are using a development tree, beware that the tree can sometimes be inconsistent and not all dependency resolutions are complete.
|
|