Red Hat Enterprise Linux AS 4 Release Notes

The version of glibc provided with Red Hat Enterprise Linux 4 performs additional internal sanity checks to prevent and detect data corruption as early as possible. By default, should corruption be detected, a message similar to the following will be displayed on standard error (or logged via syslog if stderr is not open):

*** glibc detected *** double free or corruption: 0x0937d008 ***

By default, the program that generated this error will also be killed; however, this (and whether or not an error message is generated) can be controlled via the MALLOC_CHECK_ environment variable. The following settings are supported:

Should you have a program from a third party ISV that triggers these corruption checks and displays a message, you should file a defect report with the application's vendor, since this indicates a serious bug.

Red Hat Enterprise Linux 4 includes a kernel known as the hugemem kernel. This kernel supports a 4GB per-process user space (versus 3GB for the other kernels), and a 4GB direct kernel space. Using this kernel allows Red Hat Enterprise Linux to run on systems with up to 64GB of main memory. The hugemem kernel is required in order to use all the memory in system configurations containing more than 16GB of memory. The hugemem kernel can also benefit configurations running with less memory (if running an application that could benefit from the larger per-process user space, for example.)

To install the hugemem kernel, enter the following command while logged in as root:

rpm -ivh <kernel-rpm>

            

(Where <kernel-rpm> is the name of the hugemem kernel RPM file — kernel-hugemem-2.6.9-1.648_EL.i686.rpm, for example.)

After the installation is complete, reboot your system, making sure to select the newly-installed hugemem kernel. After testing your system for proper operation while running the hugemem kernel, you should modify the /boot/grub/grub.conf file so that the hugemem kernel is booted by default.

Although Red Hat Enterprise Linux 4 includes support for rawio, it is now a deprecated interface. If your application performs device access using this interface, Red Hat encourages you to modify your application to open the block device with the O_DIRECT flag. The rawio interface will exist for the life of Red Hat Enterprise Linux 4, but is a candidate for removal from future releases.

Asynchronous I/O (AIO) on file systems is currently only supported in O_DIRECT, or non-buffered mode. Also note that the asynchronous poll interface is no longer present, and that AIO on pipes is no longer supported.

The sound subsystem is now based on ALSA; the OSS modules are no longer available.

System environments using the kernel's "hugepage" functionality should be aware that the name of the /proc/ entry controlling this feature changed between Red Hat Enterprise Linux 3 and Red Hat Enterprise Linux 4:

The kernel shipped with Red Hat Enterprise Linux 4 now includes support for Enhanced Disk Device (EDD) polling, which queries for bootable disk device information directly from the disk controller BIOS and stores it as an entry in the /sys filesystem.

Two significant kernel command-line options related to EDD have also been added:

The initial release of Red Hat Enterprise Linux 4 does not support USB hard disk drives. However, other USB storage devices, such as flash media, CD-ROM and DVD-ROM devices are currently supported.

The kernel shipped with Red Hat Enterprise Linux 4 includes the new megaraid_mbox driver from LSI Logic, which replaces the megaraid driver. The megaraid_mbox driver has an improved design, is compatible with the 2.6 kernel, and includes support for the latest hardware. However, megaraid_mbox does not support some of the older hardware that was supported by the megaraid driver.

Adapters with the following PCI vendor ID and device ID pairs are not supported by the megaraid_mbox driver:

vendor, device

0x101E, 0x9010
0x101E, 0x9060
0x8086, 0x1960

The lspci -n command can be used to display the IDs for adapters installed in a particular machine. Products with these IDs are known by (but not limited to) the following model names:

Both Dell and LSI Logic have indicated that they no longer support these models in the 2.6 kernel. As a result, these adapters are not supported in Red Hat Enterprise Linux 4.

The initial release of Red Hat Enterprise Linux 4 does not include iSCSI software initiator or target support. Support for iSCSI is being evaluated for addition in a future update to Red Hat Enterprise Linux 4.

The Emulex LightPulse Fibre Channel driver (lpfc) is currently undergoing public review for possible inclusion in the Linux 2.6 kernel. It is included in Red Hat Enterprise Linux 4 for testing purposes. Changes to the driver are expected. If there are problems with the driver or, if for some reason it is no longer on-track for inclusion in the Linux 2.6 kernel, the driver may be removed from the final Red Hat Enterprise Linux release.

The lpfc driver currently has the following known issues:

In the past, the process of updating the kernel did not change the default kernel in the system's boot loader configuration.

Red Hat Enterprise Linux 4 changes this behavior to set newly-installed kernels as the default. This behavior applies to all installation methods (including rpm -i).

This behavior is controlled by two lines in the /etc/sysconfig/kernel file:

In order to eliminate the redundancy inherent in providing a separate package for the kernel source code when that source code already exists in the kernel's .src.rpm file, Red Hat Enterprise Linux 4 no longer includes the kernel-source package. Users that require access to the kernel sources can find them in the kernel .src.rpm file. To create an exploded source tree from this file, perform the following steps (note that <version> refers to the version specification for your currently-running kernel):

You can then proceed as usual.

obj-m    := foo.o

KDIR    := /lib/modules/$(shell uname -r)/build
PWD    := $(shell pwd)

default:
    $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules

              

Red Hat Enterprise Linux 4 includes an updated version of the Evolution graphical email client. This version adds a number of new features, including:

The gimp-perl package has been removed from Red Hat Enterprise Linux 4 because GIMP was updated to 2.0 and the Perl bindings were neither ready nor part of the main package anymore.

Users of Perl scripts in GIMP should install the Gimp Perl module from http://www.gimp.org/downloads/.

ja_JP.eucJP becomes ja_JP.UTF-8

ko_KR.eucKR becomes ko_KR.UTF-8

zh_CN.GB18030 becomes zh_CN.UTF-8

zh_TW.Big5 becomes zh_TW.UTF-8

Indian languages — iiimf-le-unit

Japanese — iiimf-le-canna

Korean — iiimf-le-hangul

Simplified Chinese — iiimf-le-chinput

Traditional Chinese — iiimf-le-xcin

ami causes iiimf-le-hangul to be installed

kinput2 causes iiimf-le-canna to be installed

miniChinput causes iiimf-le-chinput to be installed

xcin causes iiimf-le-xcin to be installed

By default, the Sendmail mail transport agent (MTA) does not accept network connections from any host other than the local computer. If you want to configure Sendmail as a server for other clients, you must edit /etc/mail/sendmail.mc and change the DAEMON_OPTIONS line to also listen on network devices (or comment out this option entirely using the dnl comment delimiter). You must then regenerate /etc/mail/sendmail.cf by running the following command (as root):

make -C /etc/mail

Note that you must have the sendmail-cf package installed for this to work.

Under the default SELinux security configuration, httpd is covered by the targeted policy. This increases security and Web server stability by specifically granting or denying httpd access to system objects. However, because this has the potential to cause previously-working configurations (such as those that use PHP) to no longer function, you must understand how SELinux works in order to ensure that your configuration is both secure and functional.

For example, a Boolean can be set to give specific permission to httpd to read objects in ~/public_html/ as long as they are labeled with the security context httpd_sys_content_t. The Apache daemon cannot access objects (files, applications, devices, and other processes) that have a security context not specifically granted access by SELinux to httpd.

By allowing Apache access to only what it needs to do its function, the system is protected from compromised or misconfigured httpd daemons.

Because of the need for both standard Linux directory and file permissions as well as SELinux file context labels, adminstrators and users will need to know about relabeling files. Examples of relabeling include the following commands (one for recursively relabeling the contents of a directory, and one for relabeling a single file):

chcon -R -h -t httpd_sys_content_t public_html
chcon -t httpd_sys_content_t public_html/index.html

            

A file or directory which is not labeled with a context on the list of Apache's allowable types will generate a 403 Forbidden error.

You can configure Boolean values or selectively disable targeted policy coverage for just Apache (or any of the covered daemons) using system-config-securitylevel. Under the SELinux tab, within the Modify SELinux Policy area, you can modify the Boolean values for Apache. If you wish, you can select to Disable SELinux protection for httpd daemon, which disables the transition from unconfined_t (the default type that acts transparently like standard Linux security without SELinux) to the specific daemon type, i.e., httpd_t. Disabling this transition effectively turns off SELinux coverage for that daemon, returning it to standard Linux security only.

For more information about Apache and SELinux policy, refer to the Red Hat SELinux Policy Guide at http://www.redhat.com/docs.

By default, the httpd daemon is now started using the C locale, rather than using the configured system locale setting. This behavior can be changed by setting the HTTPD_LANG variable in the /etc/sysconfig/httpd file.

The default /etc/php.ini configuration file has been changed to use the "production" defaults rather than "development" defaults; notable differences are:

The package now uses the "apache2handler" SAPI for integration with Apache httpd 2.0 rather than the "apache2filter" SAPI. If upgrading from previous releases, the SetOutputFilter directives should be removed from the /etc/httpd/conf.d/php.conf file.

The following changes have been made to the packaging of PHP extension modules:

Red Hat Enterprise Linux 4 includes the new xorg-x11-deprecated-libs package. This package contains X11-related libraries that are deprecated, and may be removed from future versions of Red Hat Enterprise Linux. By packaging deprecated libraries in this manner, binary compatibility with existing applications is maintained while allowing 3rd-party software providers time to transition their applications away from these libraries.

Currently, this package contains the Xprint library (libXp). This library should not be used in new application development. Applications that currently use this library should begin migrating to the supported libgnomeprint/libgnomeprintui printing APIs.

There has been some confusion regarding font-related issues under the X Window System in recent versions of Red Hat Enterprise Linux (and versions of Red Hat Linux before it.) At the present time, there are two font subsystems, each with different characteristics:

- The original (15+ year old) subsystem is referred to as the "core X font subsystem". Fonts rendered by this subsystem are not anti-aliased, are handled by the X server, and have names like:

-misc-fixed-medium-r-normal--10-100-75-75-c-60-iso8859-1

The newer font subsystem is known as "fontconfig", and allows applications direct access to the font files. Fontconfig is often used along with the "Xft" library, which allows applications to render fontconfig fonts to the screen with antialiasing. Fontconfig uses more human-friendly names like:

Luxi Sans-10

Over time, fontconfig/Xft will replace the core X font subsystem. At the present time, applications using the Qt 3 or GTK 2 toolkits (which would include KDE and GNOME applications) use the fontconfig and Xft font subsystem; most everything else uses the core X fonts.

In the future, Red Hat Enterprise Linux may support only fontconfig/Xft in place of the XFS font server as the default local font access method.

NOTE: An exception to the font subsystem usage outlined above is OpenOffice.org (which uses its own font rendering technology).

If you wish to add new fonts to your Red Hat Enterprise Linux 4 system, you must be aware that the steps necessary depend on which font subsystem is to use the new fonts. For the core X font subsystem, you must:

1. Create the /usr/share/fonts/local/ directory (if it doesn't already exist):

mkdir /usr/share/fonts/local/

2. Copy the new font file into /usr/share/fonts/local/

3. Update the font information by issuing the following commands (note that, due to formatting restrictions, the following commands may appear on more than one line; in use, each command should be entered on a single line):

ttmkfdir -d /usr/share/fonts/local/ -o /usr/share/fonts/local/fonts.scale

mkfontdir /usr/share/fonts/local/

4. If you had to create /usr/share/fonts/local/, you must then add it to the X font server (xfs) path:

chkfontpath --add /usr/share/fonts/local/

Adding new fonts to the fontconfig font subsystem is more straightforward; the new font file only needs to be copied into the /usr/share/fonts/ directory (individual users can modify their personal font configuration by copying the font file into the ~/.fonts/ directory).

After the new font has been copied, use fc-cache to update the font information cache:

fc-cache <directory>

(Where <directory> would be either the /usr/share/fonts/ or ~/.fonts/ directories.)

Individual users may also install fonts graphically, by browsing fonts:/// in Nautilus, and dragging the new font files there.

NOTE: If the font filename ends with ".gz", it has been compressed with gzip, and must be decompressed (with the gunzip command) before the fontconfig font subsystem can use the font.

Due to the transition to the new font system based on fontconfig/Xft, GTK+ 1.2 applications are not affected by any changes made via the Font Preferences dialog. For these applications, a font can be configured by adding the following lines to the file ~/.gtkrc.mine:

style "user-font" {

fontset = "<font-specification>"

}

widget_class "*" style "user-font"

(Where <font-specification> represents a font specification in the style used by traditional X applications, such as "-adobe-helvetica-medium-r-normal--*-120-*-*-*-*-*-*".)

The full set of LVM2 commands is now installed in /usr/sbin/. In boot environments where /usr/ is not available, it is necessary to prefix each command with /sbin/lvm.static (/sbin/lvm.static vgchange -ay, for example).

In environments where /usr/ is available, it is no longer necessary to prefix each command with lvm (/usr/sbin/lvm vgchange -ay becomes /usr/sbin/vgchange -ay, for example).

The new LVM2 commands (such as /usr/sbin/vgchange -ay and /sbin/lvm.static vgchange -ay) detect if you are running a 2.4 kernel, and transparently invoke the old LVM1 commands if appropriate. The LVM1 commands have been renamed to end with ".lvm1" (for example, /sbin/vgchange.lvm1 -ay).

The nscd name service cache daemon may now maintain a persistent cache across restarts or system reboots. Each database (user, group, and host, respectively) can be made selected to be persistent by setting the appropriate line in /etc/nscd.conf to "yes". Entries are not removed from the cache until they are proven to be no longer of interest. All entries whose time-to-live expires but are otherwise interesting are automatically reloaded, which helps in situations where the directory and name services become temporarily unavailable.

Under the default SELinux security configuration, this daemon is covered by the targeted policy. This increases security by specifically granting or denying access to system objects that that the daemon normally uses. However, because this has the potential to cause previously-working configurations to no longer function, you must understand how SELinux works in order to ensure that your configuration is both secure and functional.

For more information about SELinux policy, refer to the Red Hat SELinux Policy Guide at http://www.redhat.com/docs.