Red Hat

From ConShell
Jump to: navigation, search

This page contains tips for beginners and experts alike. Applicable to Red Hat, Fedora, CentOS and other distros using RPM package format.

RPM package building

Go read

Build RPMs as a normal user. Shortcut to setup:

mkdir -p ~/redhat; cd ~/redhat; mkdir SOURCES SPECS BUILD RPMS SRPMS

Then put this in ~/.rpmmacros

%_topdir     ~/redhat

Now you can drop .spec files in the SPECS folder and build like so:

rpmbuild -bb something.spec

Or you can also drop .src.rpm files (sometimes named .srpm) into the SRPMS folder.

rpmbuild --rebuild something-x.y.z.srpm

In either case, you'll usually end up with something usable in ~/redhat/RPMS/i386/

Visit RPMBuildBox and RPMBuilding for addl. details.

RPM extraction

Sometimes you may find yourself wanting one or more files that live inside an RPM package (somepackage.rpm). Usually this is a SPEC file, but whatever the case, here is how to get at it. Make sure the rpm2cpio utility is installed -- I think it comes with rpm.

 rpm2cpio somepackage.rpm | cpio --make-directories --extract

To get a specific file, such as the .spec file...

 rpm2cpio somepackage.rpm | cpio --extract \*.spec

Yum and RPM package signing

Yum repositories usually have RPM packages that are signed. This means the package used a gpg/php key to sign the RPM upon creation to ensure it's validity can be verified by third party. The third party (me, you, somebody) must trust the public-key component of the gpg/pgp key used for siging.

Here is how to show what gpg/pgp keys you are trusting on a given system.

 rpm -q gpg-pubkey --qf '%{name}-%{version}-%{release} --> %{summary}\n'
 gpg-pubkey-db42a60e-37ea5438 --> gpg(Red Hat, Inc <>)

Alternatively, on newer version (e.g. RHEL4) the signing keys are represented as packages, and you can use this command to see them.

 rpm -qa | grep gpg-pubkey

...and to get more detail...

 rpm -qi gpg-pubkey-443e1821-421f218f

Here is how to import a GPG/PGP key provided by a package signer.

 rpm --import /path/to/gpg-key

Real-world uses of the above command.

 # Dag Wieers (Dag Apt Repository v1.0) <>
 rpm --import
 # CentOS-3 Key <>
 rpm --import /usr/share/doc/centos-release-3/RPM-GPG-KEY-CentOS-3
 # Red Hat, Inc <>
 rpm --import /usr/share/doc/centos-release-3/RPM-GPG-KEY
 # CentOS-4 key <>
 # Note: this is the same as /usr/share/doc/centos-release-4/RPM-GPG-KEY-centos4
 rpm --import /usr/share/doc/centos-release-4/RPM-GPG-KEY

Here is the error you will get if you try to use yum to install a signed RPM package that you don't trust.

 warning: rpmts_HdrFromFdno: V3 DSA signature: NOKEY, key ID 025e513b
 Error: Could not find the GPG Key necessary to validate pkg   /var/cache/yum/update/packages/somepackage.i386.rpm
 Error: You may also check that you have the correct GPG keys installed

RPM database corruption, locking and recovery issues

If you see (something like) this:

rpmdb: Suspiciously high nelem of 4294967294 on page 0
error: db4 error(-30979) from db->verify: DB_VERIFY_BAD: Database verification failed

Do this:

rpm --rebuilddb -v

If you see (something like) this:

error: rpmdbNextIterator: skipping h#     347 region trailer:
BAD, tag 1768055647 type 2002872692 offset -1885955104 count 1650549611

Try this:

rm /var/lib/rpm/__db.*
rpm --rebuilddb

If you see this:

rpmdb: Lock table is out of available locker entries
error: db4 error(22) from db->close: Invalid argument


Yum backup packages

To have yum make backup RPMs when you do an upgrade, add this to yum.conf.



Rooting out RPM divergence on x86_64 platform

If you run x86_64 distro, you can easily find the some i386 or i686 packages have snuck their way into your system. These can be easily discovered using the following command.

rpm -qa --qf '%{name}-%{version}-%{release}.%{arch}\n' | grep i.86

Cleanup using rpm -e.

Note that this output format can be made permanent by putting this line in ~/.rpmmacros or /etc/rpm/macros

 %_query_all_fmt %%{name}-%%{version}-%%{release}.%%{arch}


The flash tips below assume the use of version 2 quota (eg. aquota.user) for users and not groups - adjust accordingly per man pages if this is not so. See for a more detailed explanation.

  • (Re)build the quota statistics (note, the -v is optional)
/sbin/quotaoff -avu /home
/sbin/quotacheck -avu -F vfsv0
/sbin/quotaon -avu /home
  • Drop these commands into a script called /etc/cron.daily/quotacheck to maintain and check your quotas. The output will be emailed to root.
 # Update/Check for quota violation
 /sbin/quotaoff -au
 /sbin/quotacheck -au
 /sbin/quotaon -au
 /usr/sbin/repquota -a
  • Show a report of quota compliance
repquota -avus -F vfsv0
  • Set or modify a user's quota
    • 6gb = 6 x 1024^2 = 6291456
setquota username 6291456 6291456 0 0 /home
    • 4gb = 4 x 1024^2 = 4194304
setquota username 4194304 4194304 0 0 /home
    • 2gb = 2 x 1024^2 = 2097152
setquota username 2097152 2097152 0 0 /home
    • 800mb soft, 1gb hard
setquota username 819200 1048576 0 0 /home
    • 240Msoft, 256M hard
setquota username 245760 262144 0 0 /home
    • Reset (no quota)
setquota username 0 0 0 0 /home

See also: Implementing quotas to restrict disk space usage


chkconfig can be finnicky to work with. I first used chkconfig on SGI IRIX and it was straightforward. On Red Hat it is much less so.

 [root@rh ~]$ /sbin/chkconfig --list xinetd
 xinetd          0:off   1:off   2:off   3:off   4:off   5:off   6:off

Ok this shows me xinetd is not supposed to be started automatically at ANY run level. Note I had to specify /sbin/chkconfig instead of just chkconfig. Apparently Red Hat does not augment your path to include /sbin and /usr/sbin when using su, so in order to have a complete root environment use - (dash) with su. i.e su -

 [root@rh ~]$ /sbin/chkconfig --add xinetd
 [root@rh ~]$ /sbin/chkconfig --list xinetd
 xinetd          0:off   1:off   2:off   3:off   4:off   5:off   6:off

Huh? Didn't I just tell chkconfig I wanted xinetd turned on? For some reason --add works SOMETIMES but not others.

 [root@rh ~]$ /sbin/chkconfig xinetd on
 [root@rh ~]$ /sbin/chkconfig --list xinetd
 xinetd          0:off   1:off   2:on    3:on    4:on    5:on    6:off

Ok, this is closer to SGI IRIX style, using on or off after the name.

 [root@rh ~]$ /sbin/chkconfig xinetd
 [root@rh ~]$

On SGI this would have spit out the equivalent of /sbin/chkconfig --list xinetd

Update: enhancement submitted to reinstate IRIX-like behavior, see

Font / Terminal issues

Man pages look screwy? Beginning with Red Hat 8.0 the environment began using utf8 which comes out looking badly in some cases. Use one of these to fix quickly.

 (tcsh/csh) setenv LC_ALL C
 (bash) export LANG=en_US

The permanent fix appears to be changing /etc/sysconfig/i18n to remove the .utf8 string.

Bonding module (NIC teaming)

Here's how to use bonding in red hat linux. The example assumes you have two network interfaces, eth0 and eth1.

First make sure these entries appear in /etc/modprobe.conf

alias bond0 bonding
options bonding mode=1 miimon=100 primary=eth0

Now setup the ifcfg files...

IPADDR=    #adjust
NETMASK= #adjust
/etc/sysconfig/network-scripts/ifcfg-ethX (where ethX=eth0 or ethX=eth1)
DEVICE=ethX #adjust

Just make sure to use eth0 or eth1 in place of ethX above.

Reboot to pick up the changes and use ifconfig to see the output. Note that you can add bond0:0 (ip aliases) also...

There are multiple modes the module can operate under, so read Documentation/bonding.txt in the linux kernel source if you must know more. There are some hairy interoperability issues with 802.3ad link aggre

IP Aliases

Excerpted from the CentOS mailing list, Johnn Tann explains how to allocate aliased IP address ranges:

 > Note that Linux (as opposed to Solaris, I 
 > think?) uses eth0:0 as the first IP alias of eth0 (eth0 itself being 
 > the primary/non-alias IP address), not eth0:1. eth0:1 would be for the 
 > 2nd IP alias of eth0.
 > But if you're doing a range, then instead of 
 > /etc/sysconfig/network-scripts/ifcfg-eth0:0, you'd want 
 > /etc/sysconfig/network-scripts/ifcfg-eth0-range0
 > and then instead of IPADDR=, use
 > and

Realize also the any outgoing traffic will appear to come from the primary (eth0) IP address and not the eth0:0 IP. For instance if you are running the squid web proxy, the sites it connects to will see the src IP as whatever eth0 has assigned.

See Also