Issue #20 June 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.

Last month, we offered a tip about changing the behavior of the copy command. Boy, did we get mail! We've updated the response (and the associated Knowledgebase entry), so check it out.

Tips from RHCEs

Follow-up tip: Installing third-party RPMs

After rebuilding a system, it may be necessary to add several additional RPMs. These could be third party applications or vendor specific patches. Trying to do an RPM -i or -U with an *.rpm would fail if the process encountered an error. Since the list of RPMs might include packages that were not included with the RedHat distribution, a -F might not work. In such a case, the following could help:

find /start/dir -name "*.rpm" \
    -exec rpm -Uvh --aid {} \;

The first line of the command would get a list of the RPMs available in the directory (/start/dir, in the example). The second line would install each RPM in turn. Depending on the nature of the RPMs, it may be necessary to issue the command twice, though the --aid option should attempt to resolve dependencies.

Why does the Red Hat Enterprise Linux 4 installation process sometimes hang part way through installing packages over NFS or HTTP on a Legacy (pre-POWER5) iSeries system where the LPAR is configured to use partial processors?

Release Found: Red Hat Enterprise Linux 4

During installation via network (NFS or HTTP for example), an IBM Legacy (pre-POWER5) iSeries system configured to use partial processors and using a pcnet32 adapter may hang during package installation.

Both Red Hat and IBM are working on finding the cause and resolving this issue in a future update. Until an update is released, use one of the following workarounds:

  • Configure the Legacy (pre-POWER5) iSeries LPAR to use at least 1 (one) entire processor for installation, then change back to a partial processor configuration once the installation is complete.
  • Perform the complete installation using CDs.
  • If a network installation has to be performed use a network device other than the pcnet32 adapter.

Is Red Hat Enterprise Linux affected by the RealVNC vulnerability CVE-2006-2369?

This issue only affected version 4.1.1 of RealVNC. Red Hat Enterprise Linux 2.1, 3 and 4 shipped with RealVNC versions prior to 4.1.1.

It has been verified with the exploit and by code analysis that all versions of RealVNC with Red Hat Enterprise Linux 2.1, 3 and 4 are not affected.

More details about this issue can be found at:

Why can't I mount a GFS filesystem after changing the name of its cluster in Red Hat Enterprise Linux 4?

The cluster configuration tool system-config-cluster can be used to change the name of a cluster. However, doing this will prevent GFS filesystems from mounting, as the name of the cluster is used when the GFS filesystem is created.

The following error occurs if an attempt to mount a GFS filesystem is made after the name of the cluster is changed:

May 16 15:43:17 rh4cluster2 kernel: GFS: Trying to join cluster "lock_dlm", "rh4cluster:gfsNEW01"
May 16 15:43:17 rh4cluster2 kernel: lock_dlm: cman cluster name "newname" does not match file system cluster name "rh4cluster"
May 16 15:43:17 rh4cluster2 kernel: lock_dlm: init_cluster error -1
May 16 15:43:17 rh4cluster2 kernel: GFS: can't mount proto = lock_dlm, table = rh4cluster:gfsNEW01, hostdata =

To correct this problem, the superblock of the GFS filesystem must be altered so that it contains the correct cluster name. The following command should be issued from one node in the cluster:

gfs_tool sb /path/to/device table new_cluster_name:filesystem_name

Where "/path/to/device" is the location of the filesystem (for example, /dev/VolGroup00/LogVol00), and "new_cluster_name" is whatever the cluster name was changed to. The last argument "filestem_name" refers to the name the filesystem was given at the time it was created. The name can remain the same, or it can be changed at the same time the cluster name is changed.

After running the above command, the GFS filesystem should mount as expected.

Why does Red Hat Enterprise Linux 4 crash when DRAC4 Management Card is reset on my Dell server?

IDE is not a hot plug bus, and the driver is not "hot plug capable", yet "DRAC4" reset looks like a hot plug IDE event to the OS. To prevent this crash use the ide-scsi module with the virtual cd-rom on DRAC4.

Add "hdf=ide-scsi" to the kernel command line parameter (where hdf is the /dev/hdf virtual cd-rom drive). The virtual CD drive letter can be found by reading the /proc/ide/hd*/model files until the entry has the description "VIRTUAL CDROM DRIVE". This change can be made in the /etc/grub.conf file by adding this parameter to the kernel line being used to boot the server.

The DRAC4 has to reset itself under certain conditons, and when this happens, the virtual CD-ROM device disappears and reappears. The error handling in the Linux IDE drivers isn't robust enough to handle that gracefully, but works correctly when the SCSI mid layer is used (i.e. ide-scsi).

This is documented in Dell's Linux tech sheet, and any system that's installed in their factory or with the Dell Server Assistant disk will have this workaround implemented automatically.

Does Linux Software RAID ensure block level consistency?

Symptom: Software RAID consistency checks may indicate false data errors.

A Linux memory buffer may change while that memory buffer is queued for a write I/O. This may happen when memory-mapped files are used, or when an application uses direct I/O and the application changes the data before the write completes, or during regular file I/O if a file is deleted (truncated) before all the dirty buffers were written to disk.

If a software RAID implementation does not copy the buffer before it starts writing to disk, then it is possible for the RAID set to become inconsistent. For example, the data on one member of a RAID 1 set may not match the data on another member. This is not a problem, because the application will write the data again if it is still relevant, as described above. The problem is that certain utilities that check RAID sets for block-level consistency may report errors. These errors, although accurate, are not relevant with respect to operating system or application-level data integrity.

If the system deploys a legacy Software RAID solution such as LSI megaraid and a BIOS or system utility which performs a block-level consistency check, and the consistency check reports errors while the applications detect no problem, contact the hardware vendor to check if the situation described here applies.

Is PostgreSQL as shipped with Red Hat Enterprise Linux 2.1 vulnerable to CVE-2006-2313 or CVE-2006-2114?

The issues CVE-2006-2113 and CVE-2006-2114 describe a flaw in which a client improperly escapes a multibyte character string that could lead to an SQL injection attack. RHSA-2006:0526 fixes the way the PostgreSQL PQescapeString function escapes multibyte character strings for Red Hat Enterprise Linux 3 and 4. The PQescapeString function does not exist in the version of PostgreSQL shipped with Red Hat Enterprise Linux 2.1.

RHSA-2006:0526 also mentions a proactive fix which allows the PostgreSQL server to detect and prevent certain improperly escaped multibyte character strings. This preventative fix has been determined to be too dangerous and invasive to safely backport to the version of PostgreSQL shipped with Red Hat Enterprise Linux 2.1.

There are several ways in which a database server can be secured against these attacks without any code changes. Here are recommended approaches:

  • Use a single-byte client encoding (eg, one of the LATINn family). These are safe regardless of the server encoding.
  • Use UTF8 encoding (called UNICODE in the PostgreSQL 7.1 documentation). For safety, both client and server encodings must be UTF8.

Cases that are known to be dangerous include using SJIS, BIG5, GBK, GB18030, or UHC as client encoding (regardless of server encoding), and using UTF8 client encoding with a different server encoding.

How do I search for known hardware issues related to Red Hat Enterprise Linux on Dell systems?

Dell documents known Red Hat Enterprise Linux issues in their "White Papers and Tech Sheets" page. This is a valuable tool for quickly referencing known Dell Linux issues that affect hardware.

Preinstalled systems or systems with the Dell Server Assistant disk will have these workarounds implemented automatically.

However, for systems that are installed from Red Hat Enterprise Linux install media, there may be hardware issues that will have to be addressed as documented in these tech sheets to prevent known problems:

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.