October 12, 2006

Tips & tricks

Red Hat's customer service and support teams receive technical support questions from users all over the world. Red Hat technicians add the questions and answers to Red Hat Knowledgebase on a daily basis. Access to Red Hat Knowledgebase is free. Every month, Red Hat Magazine offers a preview into the Red Hat Knowledgebase by highlighting some of the most recent entries.

Rate this page del.icio.us  Digg slashdot StumbleUpon

Tips from RHCEs

Using lsusb

Last month's Red Hat Magazine discussed the use of a very useful command for hardware troubleshooting, lspci. We have seen that it provides a report showing which PCI cards were detected on the PCI bus.

Another similar tool is provided for the USB bus:


Just like lspci, this one provides a list of USB devices that are currently connected to the USB controller. Adding the '-v' argument will also let you dig through the guts of the USB standard (have fun!) and obtain information such as the power required by any particular USB device.

Names reported by the command, just like lspci, and coming from a standardized list that can be downloaded on the web:


Red Hat also includes a recent version of all these device lists in the hwdata RPM package, which installs the files under /usr/share/hwdata/.

How do I get audio working on Red Hat Enterprise Linux 3 on the HP xw4400, xw6400, xw8400 or xw9400 workstations?

Red Hat Enterprise Linux 3 does not ship with the ALSA subsystem. In order to get audio working in Red Hat Enterprise Linux 3, contact HP for an audio driver that will work with HP's xw4400, xw6400, xw8400 or xw9400 workstations.

Follow these steps to download the ALSA Drivers:

  1. Visit the website that corresponds to the model:
  2. select "Download drivers and software" under the "Tasks for HP xw{4,6,8}400 Workstation".
  3. Select "Red Hat Enterprise Linux 3 (AMD64/EM64T)" or "Red Hat Enterprise Linux 3 (x86 or AMD64/EM64T)" according to the architecture, the machine with the sound problem has.
  4. Select "Software" and then click on "Obtain software".

Why do I get the error "unsupported dictionary type: sdbm" in Red Hat Enterprise Linux 4 Update 4?

Release Found: Red Hat Enterprise Linux 4 Update 4

After installing the postfix package


The tls session cache database format changed in the Red Hat Enterprise Linux 4 Update 4 postfix. The new postfix 2.2.x version does not support sdbm as a database type as the previous postfix 2.1.x did. The new database format is btree.

Replace 'sdbm:' with 'btree:' for the tls session cache database entries in /etc/postfix/main.cf:

The old versions:

smtpd_tls_session_cache_database = sdbm:/etc/postfix/smtpd_scache
smtp_tls_session_cache_database = sdbm:/etc/postfix/smtp_scache

The new versions:

smtpd_tls_session_cache_database = btree:/etc/postfix/smtpd_scache
smtp_tls_session_cache_database = btree:/etc/postfix/smtp_scache

Restart postfix:

# service postfix restart

How do I enable the X Display Manager Protocol (XDMCP) for Red Hat Enterprise Linux 4?

Release Found: Red Hat Enterprise Linux 4

Symptom: X Window System clients are unable to get a graphical login from the server.


Enable the X Display Manager Control Protocol (XDMCP) in GDM (the default X display manager). Note: XDMCP is by no means a secure protocol. It also tends to be quite bandwidth intensive. Make it secure and use less bandwidth by tunneling the connection over SSH with compression enabled. This article does not address these issues. This article also assumes that there is nothing network-wise blocking XDMCP, such as a firewall.

Assuming that the default X Display Manager is being used, run gdmconfig as root:

# gdmconfig

Uncheck "Always disallow TCP coonections to X server" under the security tab, and check "Enable XDMCP" under the XDMCP tab.

Restart GDM for the changes to take effect. Assuming that the system is already in runlevel 5, make sure that the user is not logged unto a X Window System session. Go to a virtual terminal by pressing CTRL+ALT+F1. Login as root, and execute the command:

killall gdm-binary

A remote session should be established using XDMCP to the system just configured. Test the setup locally by running the following command from a virtual terminal:

X -query localhost :1

How do I allow remote access to a local display manager?

he following modifications are required to make a local display manager remotely accessible :
  1. Open the /etc/X11/gdm/gdm.conf file in a text editor.
    #vi /etc/X11/gdm/gdm.conf
  2. Change Enable from false to true under [xdmcp] section.
    # Distributions: Ship with this off.  It is never a safe thing to leave
    # out on the net.  Setting up /etc/hosts.allow and /etc/hosts.deny to only
    # allow local access is another alternative but not the safest.
    # Firewalling port 177 is the safest if you wish to have xdmcp on.
    # Read the manual for more notes on the security of XDMCP.
  3. Edit the file /etc/sysconfig/desktop and add the line given below if it is not already there:
    #vi /etc/sysconfig/desktop
  4. Edit the file /etc/inittab and change the runlevel to 5 if it is on some other level.
    vi /etc/inittab
    # Run xdm in runlevel 5
    x:5:respawn:/etc/X11/prefdm -nodaemon
  5. Re-examine the /etc/inittab file
    # init q
  6. Test the settings:
    # X :1 localhost -query

Why am I getting error messages when I try to update the i386 packages on an IA64 system with ia32el packages?

Release Found:
Red Hat Enterprise Linux 4 Update 2

The following errors are generated while trying to update i386 packages on the IA64 system with ia32el running:

error: %postun(audiofile-0.2.6-1.i386) scriptlet failed, exit status 0
error: %postun(audit-libs-1.0.3-6.EL4.i386) scriptlet failed, exit
status 0
error: %postun(bash-3.0-19.2.i386) scriptlet failed, exit status 0
error: %postun(curl-7.12.1-5.rhel4.i386) scriptlet failed, exit status 0
error: %preun(dbus-0.22-12.EL.5.i386) scriptlet failed, exit status 0

The update of many of the i386 packages depends on the ia32el package. So the ia32el package should be updated before updating the whole system.

# up2date ia32el
# service ia32el restart
# up2date

When multiple RSH connections are established in rapid succession, they sometimes freeze and the error "do_ypcall: clnt_call: RPC: Timed" appears in the logs. What is causing the errors, and how can I work around this issue ?

Some hardware platforms, such as IBM Bladecenters, implement the ASF Remote Management and Control Protocol in their firmware. This protocol uses TCP and UDP port 623. RPC services, such as RSH, use random ports between 600 and 699 to establish communication between client and server. If the client sends out a request on port 623, which is likely to happen at some point, the reply to that request will be diverted by the ASF protocol in the hardware. The client will therefore timeout while waiting for the reply, giving the error:

do_ypcall: clnt_call: RPC: Timed

In most cases, this should not cause a significant problem. However, in some cases an application can suffer performance degradations as a result of these timeouts. If this problem is impacting an application, the appropriate work around is to implement some iptables rules that re-route packets on port 623, so the ASF protocol doesn't "steal" them.

In the following example, the packets are temporarily diverted to port 599 (a randomly selected port with no assigned services):

# /etc/sysconfig/iptables

-A PREROUTING -p udp -m udp --dport 599 -j DNAT --to-destination :623
-A PREROUTING -p tcp -m tcp --dport 599 -j DNAT --to-destination :623
-A POSTROUTING -p udp -m udp --sport 623 -j SNAT --to-source :599
-A POSTROUTING -p tcp -m tcp --sport 623 -j SNAT --to-source :599

With the above iptables rules in place, the error should no longer appear, and any performance related side-effects should no longer present themselves.

How can I change the default operating system entry shown in GRUB at boot time?

At the time of installation, if GRUB detects another Operating System, it gives an option of selecting the default Operating System. If the default Operating System needs to be changed after the installation is finished, follow these steps:

  1. Open the /etc/grub.conf file in a text editor:
    #vi /etc/grub.conf
    Note: /etc/grub.conf is a soft link to the /boot/grub/grub.conf file.
  2. Change the default parameter and put the stanza number of the new operating system required as default. Here is an example for the process:
    1. Below is an example of the grub.conf file
      # grub.conf generated by anaconda
      # Note that you do not have to rerun grub after making changes to this file
      # NOTICE:  You have a /boot partition.  This means that
      #          all kernel and initrd paths are relative to /boot/, eg.
      #          root (hd0,0)
      #          kernel /vmlinuz-version ro root=/dev/VolGroup00/Root
      #          initrd /initrd-version.img
      title Red Hat Desktop (2.6.9-42.EL)		# Label for stanza 0
              root (hd0,0)
              kernel /vmlinuz-2.6.9-42.EL ro root=/dev/VolGroup00/Root rhgb quiet
              initrd /initrd-2.6.9-42.EL.img
      title Windows XP Pro				# Label for stanza 1
      	rootnoverify (hd0,0)
      	chainloader +1
    2. If the Red Hat Desktop is required as a default OS at boot time put:
    3. If Windows XP Pro is required as a default OS at boot time put:
  3. Save the file and exit.

Now when the system restarts, changes will take effect and the system will boot to the new default Operating System.

Why is the pam_mkhomedir, which is used to create home directories automatically, no longer working?

Release found:
Red Hat Enterprise Linux 4
Red Hat Enterprise Linux 5

The service pam_mkhomedir relies on the program doing the authentication (su, or login for example), to have enough permissions to create the home directories. This is not the case, as most authentication applications drops the permissions to avoid security problems.

To create home directories on-the-fly, use pam_oddjob_mkhomedir instead. In this case, the directory creation will be handled by a D-Bus service running as root instead.

To put it in place follow the steps below:
  • Update the oddjob package:
    up2date -i oddjob
  • Restart D-Bus, this might require to restart some services that rely on D-Bus, such as hal:
    #service messagebus restart 
  • Start the oddjob service:
    #service oddjobd restart 
  • Make sure it runs on startup:
    #chkconfig oddjobd on 
  • Modify the PAM configuration to use pam_oddjob_mkhomedir. For example, add this line at the bottom of /etc/pam.d/system-auth:
    session required /lib/security/$ISA/pam_oddjob_mkhomedir.so skel=/etc/skel/ umask=0022

Now to test if it is working, try to log in as a user that does not have a home directory.

Rate this page del.icio.us  Digg slashdot StumbleUpon

The information provided in this article is for your information only. The origin of this information may be internal or external to Red Hat. While Red Hat attempts to verify the validity of this information before it is posted, Red Hat makes no express or implied claims to its validity.

This article is protected by the Open Publication License, V1.0 or later. Copyright © 2006 by Red Hat, Inc.