Deployment GuideThe RPM Package Manager (RPM) is an open packaging system, which runs on Red Hat Enterprise Linux as well as other Linux and UNIX systems. Red Hat, Inc. and the Fedora Project encourage other vendors to use RPM for their own products. RPM is distributed under the terms of the GPL (GNU General Public License). The RPM Package Manager only works with packages built to work with the RPM format. RPM is itself provided as a pre-installed rpm package. For the end user, RPM makes system updates easy. Installing, uninstalling and upgrading RPM packages can be accomplished with short commands. RPM maintains a database of installed packages and their files, so you can invoke powerful queries and verifications on your system. The RPM package format has been improved for Red Hat Enterprise Linux 6. RPM packages are now compressed using the XZ lossless data compression format, which has the benefit of greater compression and less CPU usage during decompression, and support multiple strong hash algorithms, such as SHA-256, for package signing and verification. For most package management tasks, the Yum package manager offers equal and often greater capabilities and utility than RPM. Yum also performs and tracks complicated system dependency resolution, and will complain and force system integrity checks if you use RPM as well to install and remove packages. For these reasons, it is highly recommended that you use Yum instead of RPM whenever possible to perform package management tasks. Refer to Chapter 6, Yum. If you prefer a graphical interface, you can use the PackageKit GUI application, which uses Yum as its back end, to manage your system's packages. Refer to Chapter 7, PackageKit for details. When installing a package, ensure it is compatible with your operating system and processor architecture. This can usually be determined by checking the package name. Many of the following examples show RPM packages compiled for the AMD64/Intel 64 computer architectures; thus, the RPM file name ends in x86_64.rpm. During upgrades, RPM handles configuration files carefully, so that you never lose your customizations-something that you cannot accomplish with regular .tar.gz files. For the developer, RPM allows you to take software source code and package it into source and binary packages for end users. This process is quite simple and is driven from a single file and optional patches that you create. This clear delineation between pristine sources and your patches along with build instructions eases the maintenance of the package as new versions of the software are released. Because RPM makes changes to your system, you must be logged in as root to install, remove, or upgrade an RPM package. To understand how to use RPM, it can be helpful to understand the design goals of RPM: - Upgradability
With RPM, you can upgrade individual components of your system without completely reinstalling. When you get a new release of an operating system based on RPM, such as Red Hat Enterprise Linux, you do not need to reinstall a fresh copy of the operating system your machine (as you might need to with operating systems based on other packaging systems). RPM allows intelligent, fully-automated, in-place upgrades of your system. In addition, configuration files in packages are preserved across upgrades, so you do not lose your customizations. There are no special upgrade files needed to upgrade a package because the same RPM file is used to both install and upgrade the package on your system. - Powerful Querying
RPM is designed to provide powerful querying options. You can perform searches on your entire database for packages or even just certain files. You can also easily find out what package a file belongs to and from where the package came. The files an RPM package contains are in a compressed archive, with a custom binary header containing useful information about the package and its contents, allowing you to query individual packages quickly and easily. - System Verification
Another powerful RPM feature is the ability to verify packages. If you are worried that you deleted an important file for some package, you can verify the package. You are then notified of anomalies, if any-at which point you can reinstall the package, if necessary. Any configuration files that you modified are preserved during reinstallation. - Pristine Sources
A crucial design goal was to allow the use of pristine software sources, as distributed by the original authors of the software. With RPM, you have the pristine sources along with any patches that were used, plus complete build instructions. This is an important advantage for several reasons. For instance, if a new version of a program is released, you do not necessarily have to start from scratch to get it to compile. You can look at the patch to see what you might need to do. All the compiled-in defaults, and all of the changes that were made to get the software to build properly, are easily visible using this technique. The goal of keeping sources pristine may seem important only for developers, but it results in higher quality software for end users, too.
RPM has five basic modes of operation (not counting package building): installing, uninstalling, upgrading, querying, and verifying. This section contains an overview of each mode. For complete details and options, try rpm --help or man rpm. You can also refer to Section B.5, "Additional Resources" for more information on RPM. B.2.1. Finding RPM PackagesBefore using any RPM packages, you must know where to find them. An Internet search returns many RPM repositories, but if you are looking for Red Hat RPM packages, they can be found at the following locations: B.2.2. Installing and UpgradingRPM packages typically have file names like tree-1.5.3-2.el6.x86_64.rpm. The file name includes the package name (tree), version (1.5.3), release (2), operating system major version (el6) and CPU architecture (x86_64). You can use rpm's -U option to: upgrade an existing but older package on the system to a newer version, or install the package even if an older version is not already installed.
That is, rpm -U <rpm_file> is able to perform the function of either upgrading or installing as is appropriate for the package. Assuming the tree-1.5.3-2.el6.x86_64.rpm package is in the current directory, log in as root and type the following command at a shell prompt to either upgrade or install the tree package as determined by rpm: rpm -Uvh tree-1.5.3-2.el6.x86_64.rpm
The -v and -h options (which are combined with -U) cause rpm to print more verbose output and display a progress meter using hash signs. If the upgrade/installation is successful, the following output is displayed: Preparing... ########################################### [100%] 1:tree ########################################### [100%] rpm provides two different options for installing packages: the aforementioned -U option (which historically stands for upgrade), and the -i option, historically standing for install. Because the -U option subsumes both install and upgrade functions, we recommend to use rpm -Uvh with all packages except kernel packages.
You should always use the -i option to simply install a new kernel package instead of upgrading it. This is because using the -U option to upgrade a kernel package removes the previous (older) kernel package, which could render the system unable to boot if there is a problem with the new kernel. Therefore, use the rpm -i <kernel_package> command to install a new kernel without replacing any older kernel packages. For more information on installing kernel packages, refer to Chapter 24, Manually Upgrading the Kernel. The signature of a package is checked automatically when installing or upgrading a package. The signature confirms that the package was signed by an authorized party. For example, if the verification of the signature fails, an error message such as the following is displayed: error: tree-1.5.3-2.el6.x86_64.rpm: Header V3 RSA/SHA256 signature: BAD, key IDd22e77f2 If it is a new, header-only, signature, an error message such as the following is displayed: error: tree-1.5.3-2.el6.x86_64.rpm: Header V3 RSA/SHA256 signature: BAD,key ID d22e77f2 If you do not have the appropriate key installed to verify the signature, the message contains the word NOKEY: warning: tree-1.5.3-2.el6.x86_64.rpm: Header V3 RSA/SHA1 signature: NOKEY, key ID 57bbccba B.2.2.1. Package Already InstalledIf a package of the same name and version is already installed, the following output is displayed: Preparing... ########################################### [100%] package tree-1.5.3-2.el6.x86_64 is already installed However, if you want to install the package anyway, you can use the --replacepkgs option, which tells RPM to ignore the error: rpm -Uvh --replacepkgs tree-1.5.3-2.el6.x86_64.rpm
This option is helpful if files installed from the RPM were deleted or if you want the original configuration files from the RPM to be installed. B.2.2.2. Conflicting FilesIf you attempt to install a package that contains a file which has already been installed by another package, the following is displayed: Preparing... ################################################## file /usr/bin/foobar from install of foo-1.0-1.el6.x86_64 conflictswith file from package bar-3.1.1.el6.x86_64 To make RPM ignore this error, use the --replacefiles option: rpm -Uvh --replacefiles foo-1.0-1.el6.x86_64.rpm
B.2.2.3. Unresolved DependencyRPM packages may sometimes depend on other packages, which means that they require other packages to be installed to run properly. If you try to install a package which has an unresolved dependency, output similar to the following is displayed: error: Failed dependencies: bar.so.3()(64bit) is needed by foo-1.0-1.el6.x86_64 If you are installing a package from the Red Hat Enterprise Linux installation media, such as from a CD-ROM or DVD, the dependencies may be available. Find the suggested package(s) on the Red Hat Enterprise Linux installation media or on one of the active Red Hat Enterprise Linux mirrors and add it to the command: rpm -Uvh foo-1.0-1.el6.x86_64.rpm bar-3.1.1.el6.x86_64.rpm
If installation of both packages is successful, output similar to the following is displayed: Preparing... ########################################### [100%] 1:foo ########################################### [ 50%] 2:bar ########################################### [100%] You can try the --whatprovides option to determine which package contains the required file. rpm -q --whatprovides "bar.so.3"
If the package that contains bar.so.3 is in the RPM database, the name of the package is displayed: bar-3.1.1.el6.i586.rpm Although we can force rpm to install a package that gives us a Failed dependencies error (using the --nodeps option), this is not recommended, and will usually result in the installed package failing to run. Installing or removing packages with rpm --nodeps can cause applications to misbehave and/or crash, and can cause serious package management problems or, possibly, system failure. For these reasons, it is best to heed such warnings; the package manager-whether RPM, Yum or PackageKit-shows us these warnings and suggests possible fixes because accounting for dependencies is critical. The Yum package manager can perform dependency resolution and fetch dependencies from online repositories, making it safer, easier and smarter than forcing rpm to carry out actions without regard to resolving dependencies. B.2.3. Configuration File ChangesBecause RPM performs intelligent upgrading of packages with configuration files, you may see one or the other of the following messages: saving /etc/foo.conf as /etc/foo.conf.rpmsave This message means that changes you made to the configuration file may not be forward-compatible with the new configuration file in the package, so RPM saved your original file and installed a new one. You should investigate the differences between the two configuration files and resolve them as soon as possible, to ensure that your system continues to function properly. Alternatively, RPM may save the package's new configuration file as, for example, foo.conf.rpmnew, and leave the configuration file you modified untouched. You should still resolve any conflicts between your modified configuration file and the new one, usually by merging changes from the old one to the new one with a diff program. If you attempt to upgrade to a package with an older version number (that is, if a higher version of the package is already installed), the output is similar to the following: package foo-2.0-1.el6.x86_64.rpm (which is newer than foo-1.0-1) is already installed To force RPM to upgrade anyway, use the --oldpackage option: rpm -Uvh --oldpackage foo-1.0-1.el6.x86_64.rpm
Uninstalling a package is just as simple as installing one. Type the following command at a shell prompt: rpm -e foo Notice that we used the package name foo, not the name of the original package file, foo-1.0-1.el6.x86_64. If you attempt to uninstall a package using the rpm -e command and the original full file name, you will receive a package name error. You can encounter dependency errors when uninstalling a package if another installed package depends on the one you are trying to remove. For example: rpm -e ghostscripterror: Failed dependencies: libgs.so.8()(64bit) is needed by (installed) libspectre-0.2.2-3.el6.x86_64 libgs.so.8()(64bit) is needed by (installed) foomatic-4.0.3-1.el6.x86_64 libijs-0.35.so()(64bit) is needed by (installed) gutenprint-5.2.4-5.el6.x86_64 ghostscript is needed by (installed) printer-filters-1.1-4.el6.noarch
Similar to how we searched for a shared object library (i.e. a <library_name>.so.<number> file) in Section B.2.2.3, "Unresolved Dependency", we can search for a 64-bit shared object library using this exact syntax (and making sure to quote the file name): ~]# rpm -q --whatprovides "libgs.so.8()(64bit)"ghostscript-8.70-1.el6.x86_64 Although we can force rpm to remove a package that gives us a Failed dependencies error (using the --nodeps option), this is not recommended, and may cause harm to other installed applications. Installing or removing packages with rpm --nodeps can cause applications to misbehave and/or crash, and can cause serious package management problems or, possibly, system failure. For these reasons, it is best to heed such warnings; the package manager-whether RPM, Yum or PackageKit-shows us these warnings and suggests possible fixes because accounting for dependencies is critical. The Yum package manager can perform dependency resolution and fetch dependencies from online repositories, making it safer, easier and smarter than forcing rpm to carry out actions without regard to resolving dependencies. Freshening is similar to upgrading, except that only existent packages are upgraded. Type the following command at a shell prompt: rpm -Fvh foo-2.0-1.el6.x86_64.rpm
RPM's freshen option checks the versions of the packages specified on the command line against the versions of packages that have already been installed on your system. When a newer version of an already-installed package is processed by RPM's freshen option, it is upgraded to the newer version. However, RPM's freshen option does not install a package if no previously-installed package of the same name exists. This differs from RPM's upgrade option, as an upgrade does install packages whether or not an older version of the package was already installed. Freshening works for single packages or package groups. If you have just downloaded a large number of different packages, and you only want to upgrade those packages that are already installed on your system, freshening does the job. Thus, you do not have to delete any unwanted packages from the group that you downloaded before using RPM. In this case, issue the following with the *.rpm glob: rpm -Fvh *.rpm
RPM then automatically upgrades only those packages that are already installed. The RPM database stores information about all RPM packages installed in your system. It is stored in the directory /var/lib/rpm/, and is used to query what packages are installed, what versions each package is, and to calculate any changes to any files in the package since installation, among other use cases. To query this database, use the -q option. The rpm -q package name command displays the package name, version, and release number of the installed package <package_name>. For example, using rpm -q tree to query installed package tree might generate the following output: tree-1.5.2.2-4.el6.x86_64 You can also use the following Package Selection Options (which is a subheading in the RPM man page: see man rpm for details) to further refine or qualify your query: -a - queries all currently installed packages.
-f <file_name> - queries the RPM database for which package owns <file_name>rpm -qf /bin/ls instead of rpm -qf ls).
-p <package_file> - queries the uninstalled package <package_file>
There are a number of ways to specify what information to display about queried packages. The following options are used to select the type of information for which you are searching. These are called the Package Query Options. -i displays package information including name, description, release, size, build date, install date, vendor, and other miscellaneous information.
-l displays the list of files that the package contains.
-s displays the state of all the files in the package.
-d displays a list of files marked as documentation (man pages, info pages, READMEs, etc.) in the package.
-c displays a list of files marked as configuration files. These are the files you edit after installation to adapt and customize the package to your system (for example, sendmail.cf, passwd, inittab, etc.).
For options that display lists of files, add -v to the command to display the lists in a familiar ls -l format. Verifying a package compares information about files installed from a package with the same information from the original package. Among other things, verifying compares the file size, MD5 sum, permissions, type, owner, and group of each file. The command rpm -V verifies a package. You can use any of the Verify Options listed for querying to specify the packages you wish to verify. A simple use of verifying is rpm -V tree, which verifies that all the files in the tree package are as they were when they were originally installed. For example: To verify a package containing a particular file: rpm -Vf /usr/bin/tree
In this example, /usr/bin/tree is the absolute path to the file used to query a package. To verify ALL installed packages throughout the system (which will take some time): rpm -Va
To verify an installed package against an RPM package file: rpm -Vp tree-1.5.3-2.el6.x86_64.rpm
This command can be useful if you suspect that your RPM database is corrupt.
If everything verified properly, there is no output. If there are any discrepancies, they are displayed. The format of the output is a string of eight characters (a "c" denotes a configuration file) and then the file name. Each of the eight characters denotes the result of a comparison of one attribute of the file to the value of that attribute recorded in the RPM database. A single period (.) means the test passed. The following characters denote specific discrepancies: 5 - MD5 checksum
S - file size
L - symbolic link
T - file modification time
D - device
U - user
G - group
M - mode (includes permissions and file type)
? - unreadable file (file permission errors, for example)
If you see any output, use your best judgment to determine if you should remove the package, reinstall it, or fix the problem in another way. B.3. Checking a Package's SignatureIf you wish to verify that a package has not been corrupted or tampered with, examine only the md5sum by typing the following command at a shell prompt (where <rpm_file> is the file name of the RPM package): rpm -K --nosignature <rpm_file>
The message <rpm_file>: rsa sha1 (md5) pgp md5 OK-K with -Kvv in the command. On the other hand, how trustworthy is the developer who created the package? If the package is signed with the developer's GnuPG key, you know that the developer really is who they say they are. An RPM package can be signed using GNU Privacy Guard (or GnuPG), to help you make certain your downloaded package is trustworthy. GnuPG is a tool for secure communication; it is a complete and free replacement for the encryption technology of PGP, an electronic privacy program. With GnuPG, you can authenticate the validity of documents and encrypt/decrypt data to and from other recipients. GnuPG is capable of decrypting and verifying PGP 5.x files as well. During installation, GnuPG is installed by default. That way you can immediately start using GnuPG to verify any packages that you receive from Red Hat. Before doing so, you must first import Red Hat's public key. To verify Red Hat packages, you must import the Red Hat GnuPG key. To do so, execute the following command at a shell prompt: rpm --import /usr/share/rhn/RPM-GPG-KEY
To display a list of all keys installed for RPM verification, execute the command: rpm -qa gpg-pubkey*
For the Red Hat key, the output includes: gpg-pubkey-db42a60e-37ea5438 To display details about a specific key, use rpm -qi followed by the output from the previous command: rpm -qi gpg-pubkey-db42a60e-37ea5438
B.3.2. Verifying Signature of PackagesTo check the GnuPG signature of an RPM file after importing the builder's GnuPG key, use the following command (replace <rpm-file> with the file name of the RPM package): rpm -K <rpm-file>
If all goes well, the following message is displayed: md5 gpg OK. This means that the signature of the package has been verified, that it is not corrupt, and therefore is safe to install and use. B.4. Practical and Common Examples of RPM UsageRPM is a useful tool for both managing your system and diagnosing and fixing problems. The best way to make sense of all its options is to look at some examples. Perhaps you have deleted some files by accident, but you are not sure what you deleted. To verify your entire system and see what might be missing, you could try the following command: rpm -Va
If some files are missing or appear to have been corrupted, you should probably either re-install the package or uninstall and then re-install the package. At some point, you might see a file that you do not recognize. To find out which package owns it, enter: rpm -qf /usr/bin/ghostscript
The output would look like the following: ghostscript-8.70-1.el6.x86_64 We can combine the above two examples in the following scenario. Say you are having problems with /usr/bin/paste. You would like to verify the package that owns that program, but you do not know which package owns paste. Enter the following command, rpm -Vf /usr/bin/paste
and the appropriate package is verified. Do you want to find out more information about a particular program? You can try the following command to locate the documentation which came with the package that owns that program: rpm -qdf /usr/bin/free
The output would be similar to the following: /usr/share/doc/procps-3.2.8/BUGS/usr/share/doc/procps-3.2.8/FAQ/usr/share/doc/procps-3.2.8/NEWS/usr/share/doc/procps-3.2.8/TODO/usr/share/man/man1/free.1.gz/usr/share/man/man1/pgrep.1.gz/usr/share/man/man1/pkill.1.gz/usr/share/man/man1/pmap.1.gz/usr/share/man/man1/ps.1.gz/usr/share/man/man1/pwdx.1.gz/usr/share/man/man1/skill.1.gz/usr/share/man/man1/slabtop.1.gz/usr/share/man/man1/snice.1.gz/usr/share/man/man1/tload.1.gz/usr/share/man/man1/top.1.gz/usr/share/man/man1/uptime.1.gz/usr/share/man/man1/w.1.gz/usr/share/man/man1/watch.1.gz/usr/share/man/man5/sysctl.conf.5.gz/usr/share/man/man8/sysctl.8.gz/usr/share/man/man8/vmstat.8.gz You may find a new RPM, but you do not know what it does. To find information about it, use the following command: rpm -qip crontabs-1.10-32.1.el6.noarch.rpm
The output would be similar to the following: Name : crontabs Relocations: (not relocatable)Version : 1.10 Vendor: Red Hat, Inc.Release : 32.1.el6 Build Date: Thu 03 Dec 2009 02:17:44 AM CETInstall Date: (not installed) Build Host: js20-bc1-11.build.redhat.comGroup : System Environment/Base Source RPM: crontabs-1.10-32.1.el6.src.rpmSize : 2486 License: Public Domain and GPLv2Signature : RSA/8, Wed 24 Feb 2010 08:46:13 PM CET, Key ID 938a80caf21541ebPackager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>Summary : Root crontab files used to schedule the execution of programsDescription :The crontabs package contains root crontab files and directories.You will need to install cron daemon to run the jobs from the crontabs.The cron daemon such as cronie or fcron checks the crontab files tosee when particular commands are scheduled to be executed. If commandsare scheduled, it executes them.Crontabs handles a basic system function, so it should be installed onyour system. Perhaps you now want to see what files the crontabs RPM package installs. You would enter the following: rpm -qlp crontabs-1.10-32.1.el6.noarch.rpm
The output is similar to the following: /etc/cron.daily/etc/cron.hourly/etc/cron.monthly/etc/cron.weekly/etc/crontab/usr/bin/run-parts/usr/share/man/man4/crontabs.4.gz
These are just a few examples. As you use RPM, you may find more uses for it. B.5. Additional ResourcesRPM is an extremely complex utility with many options and methods for querying, installing, upgrading, and removing packages. Refer to the following resources to learn more about RPM. B.5.1. Installed Documentation- Maximum RPM - http://www.rpm.org/max-rpm/
The Maximum RPM book, which you can read online, covers everything from general RPM usage to building your own RPMs to programming with rpmlib.
While the heart of Red Hat Enterprise Linux is the kernel, for many users, the face of the operating system is the graphical environment provided by the X Window System, also called X. Other windowing environments have existed in the UNIX world, including some that predate the release of the X Window System in June 1984. Nonetheless, X has been the default graphical environment for most UNIX-like operating systems, including Red Hat Enterprise Linux, for many years. The graphical environment for Red Hat Enterprise Linux is supplied by the X.Org Foundation, an open source organization created to manage development and strategy for the X Window System and related technologies. X.Org is a large-scale, rapid-developing project with hundreds of developers around the world. It features a wide degree of support for a variety of hardware devices and architectures, and runs on myriad operating systems and platforms. The X Window System uses a client-server architecture. Its main purpose is to provide network transparent window system, which runs on a wide range of computing and graphics machines. The X server (the Xorg binary) listens for connections from X client applications via a network or local loopback interface. The server communicates with the hardware, such as the video card, monitor, keyboard, and mouse. X client applications exist in the user space, creating a graphical user interface (GUI) for the user and passing user requests to the X server. Red Hat Enterprise Linux 6 uses X server version, which includes several video drivers, EXA, and platform support enhancements over the previous release, among others. In addition, this release includes several automatic configuration features for the X server, as well as the generic input driver, evdev, that supports all input devices that the kernel knows about, including most mice and keyboards. X11R7.1 was the first release to take specific advantage of making the X Window System modular. This release split X into logically distinct modules, which make it easier for open source developers to contribute code to the system. In the current release, all libraries, headers, and binaries live under the /usr/ directory. The /etc/X11/ directory contains configuration files for X client and server applications. This includes configuration files for the X server itself, the X display managers, and many other base components. The configuration file for the newer Fontconfig-based font architecture is still /etc/fonts/fonts.conf. For more information on configuring and adding fonts, refer to Section C.4, "Fonts". Because the X server performs advanced tasks on a wide array of hardware, it requires detailed information about the hardware it works on. The X server is able to automatically detect most of the hardware that it runs on and configure itself accordingly. Alternatively, hardware can be manually specified in configuration files. The Red Hat Enterprise Linux system installer, Anaconda, installs and configures X automatically, unless the X packages are not selected for installation. If there are any changes to the monitor, video card or other devices managed by the X server, most of the time, X detects and reconfigures these changes automatically. In rare cases, X must be reconfigured manually. C.2. Desktop Environments and Window ManagersOnce an X server is running, X client applications can connect to it and create a GUI for the user. A range of GUIs are available with Red Hat Enterprise Linux, from the rudimentary Tab Window Manager (twm) to the highly developed and interactive desktop environment (such as GNOME or KDE) that most Red Hat Enterprise Linux users are familiar with. To create the latter, more comprehensive GUI, two main classes of X client application must connect to the X server: a window manager and a desktop environment. C.2.1. Desktop EnvironmentsA desktop environment integrates various X clients to create a common graphical user environment and a development platform. Desktop environments have advanced features allowing X clients and other running processes to communicate with one another, while also allowing all applications written to work in that environment to perform advanced tasks, such as drag-and-drop operations. Red Hat Enterprise Linux provides two desktop environments: Both GNOME and KDE have advanced-productivity applications, such as word processors, spreadsheets, and Web browsers; both also provide tools to customize the look and feel of the GUI. Additionally, if both the GTK+ 2 and the Qt libraries are present, KDE applications can run in GNOME and vice versa. Window managers are X client programs which are either part of a desktop environment or, in some cases, stand-alone. Their primary purpose is to control the way graphical windows are positioned, resized, or moved. Window managers also control title bars, window focus behavior, and user-specified key and mouse button bindings. The Red Hat Enterprise Linux repositories provide five different window managers. -
metacity The Metacity window manager is the default window manager for GNOME. It is a simple and efficient window manager which supports custom themes. This window manager is automatically pulled in as a dependency when the GNOME desktop is installed. -
kwin The KWin window manager is the default window manager for KDE. It is an efficient window manager which supports custom themes. This window manager is automatically pulled in as a dependency when the KDE desktop is installed. -
compiz The Compiz compositing window manager is based on OpenGL and can use 3D graphics hardware to create fast compositing desktop effects for window management. Advanced features, such as a cube workspace, are implemented as loadable plug-ins. To run this window manager, you need to install the compiz package. -
mwm The Motif Window Manager (mwm) is a basic, stand-alone window manager. Since it is designed to be stand-alone, it should not be used in conjunction with GNOME or KDE. To run this window manager, you need to install the openmotif package. -
twm The minimalist Tab Window Manager (twm), which provides the most basic tool set among the available window managers, can be used either as a stand-alone or with a desktop environment. To run this window manager, you need to install the xorg-x11-twm package.
C.3. X Server Configuration FilesThe X server is a single binary executable /usr/bin/Xorg; a symbolic link X pointing to this file is also provided. Associated configuration files are stored in the /etc/X11/ and /usr/share/X11/ directories. The X Window System supports two different configuration schemes. Configuration files in the xorg.conf.d directory contain preconfigured settings from vendors and from distribution, and these files should not be edited by hand. Configuration in the xorg.conf file, on the other hand, is done completely by hand but is not necessary in most scenarios. All necessary parameters for a display and peripherals are auto-detected and configured during installation. The configuration file for the X server, /etc/X11/xorg.conf, that was necessary in previous releases, is not supplied with the current release of the X Window System. It can still be useful to create the file manually to configure new hardware, to set up an environment with multiple video cards, or for debugging purposes. The /usr/lib/xorg/modules/ (or /usr/lib64/xorg/modules/) directory contains X server modules that can be loaded dynamically at runtime. By default, only some modules in /usr/lib/xorg/modules/ are automatically loaded by the X server. When Red Hat Enterprise Linux 6 is installed, the configuration files for X are created using information gathered about the system hardware during the installation process by the HAL (Hardware Abstraction Layer) configuration back end. Whenever the X server is started, it asks HAL for the list of input devices and adds each of them with their respective driver. Whenever a new input device is plugged in, or an existing input device is removed, HAL notifies the X server about the change. Because of this notification system, devices using the mouse, kbd, or vmmouse driver configured in the xorg.conf file are, by default, ignored by the X server. Refer to Section C.3.3.3, "The ServerFlags section" for further details. Additional configuration is provided in the /etc/X11/xorg.conf.d/ directory and it can override or augment any configuration that has been obtained through HAL. C.3.1. The Structure of the ConfigurationThe format of the X configuration files is comprised of many different sections which address specific aspects of the system hardware. Each section begins with a Section "section-name" line, where "section-name" is the title for the section, and ends with an EndSection line. Each section contains lines that include option names and one or more option values. Some of these are sometimes enclosed in double quotes ("). Some options within the /etc/X11/xorg.conf file accept a Boolean switch which turns the feature on or off. The acceptable values are: 1, on, true, or yes - Turns the option on.
0, off, false, or no - Turns the option off.
The following shows a typical configuration file for the keyboard. Lines beginning with a hash sign (#) are not read by the X server and are used for human-readable comments. # This file is autogenerated by system-setup-keyboard. Any # modifications will be lost.Section "InputClass" Identifier "system-setup-keyboard" MatchIsKeyboard "on" Option "XkbModel" "pc105" Option "XkbLayout" "cz,us"# Option "XkbVariant" "(null)" Option "XkbOptions" "terminate:ctrl_alt_bksp,grp:shifts_toggle,grp_led:scroll"EndSection C.3.2. The xorg.conf.d DirectoryThe X server supports two configuration directories. The /usr/share/X11/xorg.conf.d/ provides separate configuration files from vendors or third-party packages; changes to files in this directory may be overwritten by settings specified in the /etc/X11/xorg.conf file. The /etc/X11/xorg.conf.d/ directory stores user-specific configuration. Files with the suffix .conf in configuration directories are parsed by the X server upon startup and are treated like part of the traditional xorg.conf configuration file. These files may contain one or more sections; for a description of the options in a section and the general layout of the configuration file, refer to Section C.3.3, "The xorg.conf File" or to the xorg.conf(5) man page. The X server essentially treats the collection of configuration files as one big file with entries from xorg.conf at the end. Users are encouraged to put custom configuration into /etc/xorg.conf and leave the directory for configuration snippets provided by the distribution. C.3.3. The xorg.conf FileIn previous releases of the X Window System, /etc/X11/xorg.conf file was used to store initial setup for X. When a change occurred with the monitor, video card or other device managed by the X server, the file needed to be edited manually. In Red Hat Enterprise Linux, there is rarely a need to manually create and edit the /etc/X11/xorg.conf file. Nevertheless, it is still useful to understand various sections and optional parameters available, especially when troubleshooting or setting up unusual hardware configuration. In the following, some important sections are described in the order in which they appear in a typical /etc/X11/xorg.conf file. More detailed information about the X server configuration file can be found in the xorg.conf(5) man page. This section is mostly intended for advanced users as most configuration options described below are not needed in typical configuration scenarios. C.3.3.1. The InputClass sectionInputClass is a new type of configuration section that does not apply to a single device but rather to a class of devices, including hot-plugged devices. An InputClass section's scope is limited by the matches specified; in order to apply to an input device, all matches must apply to the device as seen in the example below:
Section "InputClass" Identifier "touchpad catchall" MatchIsTouchpad "on" Driver "synaptics"EndSection If this snippet is present in an xorg.conf file or an xorg.conf.d directory, any touchpad present in the system is assigned the synaptics driver. Note that due to alphanumeric sorting of configuration files in the xorg.conf.d directory, the Driver setting in the example above overwrites previously set driver options. The more generic the class, the earlier it should be listed. The match options specify which devices a section may apply to. To match a device, all match options must correspond. The following options are commonly used in the InputClass section: MatchIsPointer, MatchIsKeyboard, MatchIsTouchpad, MatchIsTouchscreen, MatchIsJoystick - Boolean options to specify a type of a device.
MatchProduct "product_name" - this option matches if the product_name substring occurs in the product name of the device.
MatchVendor "vendor_name" - this option matches if the vendor_name substring occurs in the vendor name of the device.
MatchDevicePath "/path/to/device" - this option matches any device if its device path corresponds to the patterns given in the "/path/to/device" template, for example /dev/input/event*. Refer to the fnmatch(3) man page for further details.
MatchTag "tag_pattern" - this option matches if at least one tag assigned by the HAL configuration back end matches the tag_pattern pattern.
A configuration file may have multiple InputClass sections. These sections are optional and are used to configure a class of input devices as they are automatically added. An input device can match more than one InputClass section. When arranging these sections, it is recommended to put generic matches above specific ones because each input class can override settings from a previous one if an overlap occurs. C.3.3.2. The InputDevice sectionEach InputDevice section configures one input device for the X server. Previously, systems typically had at least one InputDevice section for the keyboard, and most mouse settings were automatically detected. With Red Hat Enterprise Linux 6, no InputDevice configuration is needed for most setups, and the xorg-x11-drv-* input driver packages provide the automatic configuration through HAL. The default driver for both keyboards and mice is evdev. The following example shows a typical InputDevice section for a keyboard: Section "InputDevice" Identifier "Keyboard0" Driver "kbd" Option "XkbModel" "pc105" Option "XkbLayout" "us"EndSection The following entries are commonly used in the InputDevice section: Identifier - Specifies a unique name for this InputDevice section. This is a required entry.
Driver - Specifies the name of the device driver X must load for the device. If the AutoAddDevices option is enabled (which is the default setting), any input device section with Driver "mouse" or Driver "kbd" will be ignored. This is necessary due to conflicts between the legacy mouse and keyboard drivers and the new evdev generic driver. Instead, the server will use the information from the back end for any input devices. Any custom input device configuration in the xorg.conf should be moved to the back end. In most cases, the back end will be HAL and the configuration location will be the /etc/X11/xorg.conf.d directory.
Option - Specifies necessary options pertaining to the device.
A mouse may also be specified to override any auto-detected values for the device. The following options are typically included when adding a mouse in the xorg.conf file: Protocol - Specifies the protocol used by the mouse, such as IMPS/2.
Device - Specifies the location of the physical device.
Emulate3Buttons - Specifies whether to allow a two-button mouse to act like a three-button mouse when both mouse buttons are pressed simultaneously.
Consult the xorg.conf(5) man page for a complete list of valid options for this section.
C.3.3.3. The ServerFlags sectionThe optional ServerFlags section contains miscellaneous global X server settings. Any settings in this section may be overridden by options placed in the ServerLayout section (refer to Section C.3.3.4, "The ServerLayout Section" for details). Each entry within the ServerFlags section occupies a single line and begins with the term Option followed by an option enclosed in double quotation marks ("). The following is a sample ServerFlags section: Section "ServerFlags" Option "DontZap" "true"EndSection The following lists some of the most useful options: "DontZap" "boolean" - When the value of <boolean> is set to true, this setting prevents the use of the Ctrl+Alt+Backspace key combination to immediately terminate the X server.
Even if this option is enabled, the key combination still must be configured in the X Keyboard Extension (XKB) map before it can be used. One way how to add the key combination to the map is to run the following command: setxkbmap -option "terminate:ctrl_alt_bksp"
"DontZoom" "boolean" - When the value of <boolean> is set to true, this setting prevents cycling through configured video resolutions using the Ctrl+Alt+Keypad-Plus and Ctrl+Alt+Keypad-Minus key combinations.
"AutoAddDevices" "boolean" - When the value of <boolean> is set to false, the server will not hot plug input devices and instead rely solely on devices configured in the xorg.conf file. Refer to Section C.3.3.2, "The InputDevice section" for more information concerning input devices. This option is enabled by default and HAL (hardware abstraction layer) is used as a back end for device discovery.
C.3.3.4. The ServerLayout SectionThe ServerLayout section binds together the input and output devices controlled by the X server. At a minimum, this section must specify one input device and one output device. By default, a monitor (output device) and a keyboard (input device) are specified. The following example shows a typical ServerLayout section: Section "ServerLayout" Identifier "Default Layout" Screen 0 "Screen0" 0 0 InputDevice "Mouse0" "CorePointer" InputDevice "Keyboard0" "CoreKeyboard"EndSection The following entries are commonly used in the ServerLayout section: Identifier - Specifies a unique name for this ServerLayout section.
Screen - Specifies the name of a Screen section to be used with the X server. More than one Screen option may be present.
The following is an example of a typical Screen entry: Screen 0 "Screen0" 0 0 The first number in this example Screen entry (0) indicates that the first monitor connector, or head on the video card, uses the configuration specified in the Screen section with the identifier "Screen0". If the video card has more than one head, another Screen entry with a different number and a different Screen section identifier is necessary. The numbers to the right of "Screen0" give the absolute X and Y coordinates for the upper left corner of the screen (0 0 by default). InputDevice - Specifies the name of an InputDevice section to be used with the X server.
It is advisable that there be at least two InputDevice entries: one for the default mouse and one for the default keyboard. The options CorePointer and CoreKeyboard indicate that these are the primary mouse and keyboard. If the AutoAddDevices option is enabled, this entry needs not to be specified in the ServerLayout section. If the AutoAddDevices option is disabled, both mouse and keyboard are auto-detected with the default values. Option "option-name" - An optional entry which specifies extra parameters for the section. Any options listed here override those listed in the ServerFlags section.
Replace <option-name> with a valid option listed for this section in the xorg.conf(5) man page.
It is possible to put more than one ServerLayout section in the /etc/X11/xorg.conf file. By default, the server only reads the first one it encounters, however. If there is an alternative ServerLayout section, it can be specified as a command line argument when starting an X session; as in the Xorg -layout <layoutname> command. C.3.3.5. The Files sectionThe Files section sets paths for services vital to the X server, such as the font path. This is an optional section, as these paths are normally detected automatically. This section can be used to override automatically detected values. The following example shows a typical Files section: Section "Files" RgbPath "/usr/share/X11/rgb.txt" FontPath "unix/:7100"EndSection The following entries are commonly used in the Files section: C.3.3.6. The Monitor sectionEach Monitor section configures one type of monitor used by the system. This is an optional entry as most monitors are now detected automatically. This example shows a typical Monitor section for a monitor: Section "Monitor" Identifier "Monitor0" VendorName "Monitor Vendor" ModelName "DDC Probed Monitor - ViewSonic G773-2" DisplaySize 320 240 HorizSync 30.0 - 70.0 VertRefresh 50.0 - 180.0EndSection The following entries are commonly used in the Monitor section: Identifier - Specifies a unique name for this Monitor section. This is a required entry.
VendorName - An optional parameter which specifies the vendor of the monitor.
ModelName - An optional parameter which specifies the monitor's model name.
DisplaySize - An optional parameter which specifies, in millimeters, the physical size of the monitor's picture area.
HorizSync - Specifies the range of horizontal sync frequencies compatible with the monitor, in kHz. These values help the X server determine the validity of built-in or specified Modeline entries for the monitor.
VertRefresh - Specifies the range of vertical refresh frequencies supported by the monitor, in kHz. These values help the X server determine the validity of built-in or specified Modeline entries for the monitor.
Modeline - An optional parameter which specifies additional video modes for the monitor at particular resolutions, with certain horizontal sync and vertical refresh resolutions. Refer to the xorg.conf(5) man page for a more detailed explanation of Modeline entries.
Option "option-name" - An optional entry which specifies extra parameters for the section. Replace <option-name> with a valid option listed for this section in the xorg.conf(5) man page.
C.3.3.7. The Device sectionEach Device section configures one video card on the system. While one Device section is the minimum, additional instances may occur for each video card installed on the machine. The following example shows a typical Device section for a video card: Section "Device" Identifier "Videocard0" Driver "mga" VendorName "Videocard vendor" BoardName "Matrox Millennium G200" VideoRam 8192 Option "dpms"EndSection The following entries are commonly used in the Device section: Identifier - Specifies a unique name for this Device section. This is a required entry.
Driver - Specifies which driver the X server must load to utilize the video card. A list of drivers can be found in /usr/share/hwdata/videodrivers, which is installed with the hwdata package.
VendorName - An optional parameter which specifies the vendor of the video card.
BoardName - An optional parameter which specifies the name of the video card.
VideoRam - An optional parameter which specifies the amount of RAM available on the video card, in kilobytes. This setting is only necessary for video cards the X server cannot probe to detect the amount of video RAM.
BusID - An entry which specifies the bus location of the video card. On systems with only one video card a BusID entry is optional and may not even be present in the default /etc/X11/xorg.conf file. On systems with more than one video card, however, a BusID entry is required.
Screen - An optional entry which specifies which monitor connector or head on the video card the Device section configures. This option is only useful for video cards with multiple heads.
If multiple monitors are connected to different heads on the same video card, separate Device sections must exist and each of these sections must have a different Screen value. Values for the Screen entry must be an integer. The first head on the video card has a value of 0. The value for each additional head increments this value by one. Option "option-name" - An optional entry which specifies extra parameters for the section. Replace <option-name> with a valid option listed for this section in the xorg.conf(5) man page.
One of the more common options is "dpms" (for Display Power Management Signaling, a VESA standard), which activates the Energy Star energy compliance setting for the monitor.
C.3.3.8. The Screen sectionEach Screen section binds one video card (or video card head) to one monitor by referencing the Device section and the Monitor section for each. While one Screen section is the minimum, additional instances may occur for each video card and monitor combination present on the machine. The following example shows a typical Screen section: Section "Screen" Identifier "Screen0" Device "Videocard0" Monitor "Monitor0" DefaultDepth 16 SubSection "Display" Depth 24 Modes "1280x1024" "1280x960" "1152x864" "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 16 Modes "1152x864" "1024x768" "800x600" "640x480" EndSubSectionEndSection The following entries are commonly used in the Screen section: Identifier - Specifies a unique name for this Screen section. This is a required entry.
Device - Specifies the unique name of a Device section. This is a required entry.
Monitor - Specifies the unique name of a Monitor section. This is only required if a specific Monitor section is defined in the xorg.conf file. Normally, monitors are detected automatically.
DefaultDepth - Specifies the default color depth in bits. In the previous example, 16 (which provides thousands of colors) is the default. Only one DefaultDepth entry is permitted, although this can be overridden with the Xorg command line option -depth <n>, where <n>
SubSection "Display" - Specifies the screen modes available at a particular color depth. The Screen section can have multiple Display subsections, which are entirely optional since screen modes are detected automatically.
This subsection is normally used to override auto-detected modes. Option "option-name" - An optional entry which specifies extra parameters for the section. Replace <option-name> with a valid option listed for this section in the xorg.conf(5) man page.
The optional DRI section specifies parameters for the Direct Rendering Infrastructure (DRI). DRI is an interface which allows 3D software applications to take advantage of 3D hardware acceleration capabilities built into most modern video hardware. In addition, DRI can improve 2D performance via hardware acceleration, if supported by the video card driver. This section is rarely used, as the DRI Group and Mode are automatically initialized to default values. If a different Group or Mode is needed, then adding this section to the xorg.conf file will override the default values. The following example shows a typical DRI section: Section "DRI" Group 0 Mode 0666EndSection Red Hat Enterprise Linux uses Fontconfig subsystem to manage and display fonts under the X Window System. It simplifies font management and provides advanced display features, such as anti-aliasing. This system is used automatically for applications programmed using the Qt 3 or GTK+ 2 graphical toolkits, or their newer versions. The Fontconfig font subsystem allows applications to directly access fonts on the system and use the X FreeType interface library (Xft) or other rendering mechanisms to render Fontconfig fonts with advanced features such as anti-aliasing. Graphical applications can use the Xft library with Fontconfig to draw text to the screen. Fontconfig uses the /etc/fonts/fonts.conf configuration file, which should not be edited by hand. Any system where the user expects to run remote X applications needs to have the fonts group installed. This can be done by selecting the group in the installer, and also by running the yum groupinstall fonts command after installation. C.4.1. Adding Fonts to FontconfigAdding new fonts to the Fontconfig subsystem is a straightforward process: To add fonts for an individual user, copy the new fonts into the .fonts/ directory in the user's home directory. To add fonts system-wide, copy the new fonts into the /usr/share/fonts/ directory. It is a good idea to create a new subdirectory, such as local/ or similar, to help distinguish between user-installed and default fonts. Run the fc-cache command as root to update the font information cache: fc-cache <path-to-font-directory>
In this command, replace <path-to-font-directory> with the directory containing the new fonts (either /usr/share/fonts/local/ or /home/<user>/.fonts/).
Individual users may also install fonts interactively, by typing fonts:/// into the Nautilus address bar, and dragging the new font files there. In most cases, the Red Hat Enterprise Linux installer configures a machine to boot into a graphical login environment, known as runlevel 5. It is possible, however, to boot into a text-only multi-user mode called runlevel 3 and begin an X session from there. When in runlevel 3, the best way to start an X session is to log in and type startx. The startx command is a front-end to the xinit command, which launches the X server ( Xorg) and connects X client applications to it. Because the user is already logged into the system at runlevel 3, startx does not launch a display manager or authenticate users. Refer to Section C.5.2, "Runlevel 5" for more information about display managers. When the startx command is executed, it searches for the .xinitrc file in the user's home directory to define the desktop environment and possibly other X client applications to run. If no .xinitrc file is present, it uses the system default /etc/X11/xinit/xinitrc file instead. The default xinitrc script then searches for user-defined files and default system files, including .Xresources, .Xmodmap, and .Xkbmap in the user's home directory, and Xresources, Xmodmap, and Xkbmap in the /etc/X11/ directory. The Xmodmap and Xkbmap files, if they exist, are used by the xmodmap utility to configure the keyboard. The Xresources file is read to assign specific preference values to applications. After setting the above options, the xinitrc script executes all scripts located in the /etc/X11/xinit/xinitrc.d/ directory. One important script in this directory is xinput.sh, which configures settings such as the default language. The xinitrc script attempts to execute .Xclients in the user's home directory and turns to /etc/X11/xinit/Xclients if it cannot be found. The purpose of the Xclients file is to start the desktop environment or, possibly, just a basic window manager. The .Xclients script in the user's home directory starts the user-specified desktop environment in the .Xclients-default file. If .Xclients does not exist in the user's home directory, the standard /etc/X11/xinit/Xclients script attempts to start another desktop environment, trying GNOME first, then KDE, followed by twm.
When in runlevel 3, the user is returned to a text mode user session after ending an X session. When the system boots into runlevel 5, a special X client application called a display manager is launched. A user must authenticate using the display manager before any desktop environment or window managers are launched. Depending on the desktop environments installed on the system, three different display managers are available to handle user authentication. GDM (GNOME Display Manager) - The default display manager for Red Hat Enterprise Linux. GNOME allows the user to configure language settings, shutdown, restart or log in to the system.
KDM - KDE's display manager which allows the user to shutdown, restart or log in to the system.
xdm (X Window Display Manager) - A very basic display manager which only lets the user log in to the system.
When booting into runlevel 5, the /etc/X11/prefdm script determines the preferred display manager by referencing the /etc/sysconfig/desktop file. A list of options for this file is available in this file: /usr/share/doc/initscripts-<version-number>/sysconfig.txt
where <version-number> is the version number of the initscripts package. Each of the display managers reference the /etc/X11/xdm/Xsetup_0 file to set up the login screen. Once the user logs into the system, the /etc/X11/xdm/GiveConsole script runs to assign ownership of the console to the user. Then, the /etc/X11/xdm/Xsession script runs to accomplish many of the tasks normally performed by the xinitrc script when starting X from runlevel 3, including setting system and user resources, as well as running the scripts in the /etc/X11/xinit/xinitrc.d/ directory. Users can specify which desktop environment they want to use when they authenticate using the GNOME or KDE display managers by selecting it from the menu item accessed by selecting ⤍ ⤍ ⤍ . If the desktop environment is not specified in the display manager, the /etc/X11/xdm/Xsession script checks the .xsession and .Xclients files in the user's home directory to decide which desktop environment to load. As a last resort, the /etc/X11/xinit/Xclients file is used to select a desktop environment or window manager to use in the same way as runlevel 3. When the user finishes an X session on the default display (:0) and logs out, the /etc/X11/xdm/TakeConsole script runs and reassigns ownership of the console to the root user. The original display manager, which continues running after the user logged in, takes control by spawning a new display manager. This restarts the X server, displays a new login window, and starts the entire process over again. The user is returned to the display manager after logging out of X from runlevel 5. For more information on how display managers control user authentication, refer to the /usr/share/doc/gdm-<version-number>/README, where <version-number> is the version number for the gdm package installed, or the xdm man page. C.6. Additional ResourcesThere is a large amount of detailed information available about the X server, the clients that connect to it, and the assorted desktop environments and window managers. C.6.1. Installed Documentation/usr/share/X11/doc/ - contains detailed documentation on the X Window System architecture, as well as how to get additional information about the Xorg project as a new user.
/usr/share/doc/gdm-<version-number>/README - contains information on how display managers control user authentication.
man xorg.conf - Contains information about the xorg.conf configuration files, including the meaning and syntax for the different sections within the files.
man Xorg - Describes the Xorg display server.
http://www.X.org/ - Home page of the X.Org Foundation, which produces major releases of the X Window System bundled with Red Hat Enterprise Linux to control the necessary hardware and provide a GUI environment. http://dri.sourceforge.net/ - Home page of the DRI (Direct Rendering Infrastructure) project. The DRI is the core hardware 3D acceleration component of X.
|
