CentOS Release Notes

Booting Anaconda

Installation-related notes

Notes on input methods

General notes

Kernel notes

The sequence for processing CD-ROMs has changed for CentOS 3. The first CD-ROM is required when booting the installation program, and again after subsequent CD-ROMs have been processed.

The CentOS installation program has the ability to test the integrity of the installation media. It works with the CD, hard drive ISO, and NFS ISO installation methods. We recommends that you test all installation media before starting the installation process, and before reporting any installation-related bugs (many of the bugs reported are actually due to improperly-burned CDs). To use this test, type linux mediacheck at the boot: prompt.

CentOS 3 includes a new 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 CentOS 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 remind you of this issue, the CentOS 3 kernel displays a message at boot time if your system configuration contains more than 16GB of memory. After the system has booted, the following command can be used to see if your system displayed the message:

dmesg | less

NOTE: To provide a 4GB address space for both kernel and user space, the kernel must maintain two separate virtual memory address mappings. This introduces overhead when transferring from user to kernel space; for example, in the case of system calls and interrupts. The impact of this overhead on overall performance is highly application dependent.

Also note that, because some drivers were not originally written to work well in large-memory environments, CentOS only supports a validated subset of drivers when the hugemem kernel is used. Drivers that have been validated for use with the hugemem kernel are contained in the kernel-hugemem package. Drivers that have not been validated, but are still provided, are available in the kernel-hugemem-unsupported RPM. To see the list of drivers in these RPMs, use the following command:

rpm -qlp <kernel-rpm>

(Where < kernel-rpm> is the complete filename of the appropriate hugemem RPM. Note that these RPMs can be found on CD-ROM #2, in the RedHat/RPMS/ directory.)

Should you decide that the hugemem kernel's additional overhead and the subset of available drivers present no problem for your hardware configuration and system environment, and you wish to use the hugemem kernel, you must first install it. 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.4.21-3.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.

CentOS 3 can be installed on the IBM eServer xSeries® 440 and 445. However, the installation process supports configurations containing no more than one chassis, and no attached RXE-100 Remote Expansion Enclosures. If your system configuration does not conform to these requirements, you can remove any additional chassis and/or RXE-100s, and then perform the installation. Once the installation is complete, the chassis and/or RXE-100s can then be re-installed, and will operate normally under CentOS.

CentOS 3 now includes support for Logical Volume Management (LVM). LVM is a means of allocating disk space into one or more logical volumes, which can then be used to implement easily-resizable file systems.

While most present-day computers are able to start the installation process by booting directly from the first CentOS distribution CD, some hardware configurations require the use of a boot diskette. If your hardware requires a boot diskette, you should be aware of the following change.

CentOS 3 uses a different boot diskette layout than previous releases of CentOS. There is now a single boot diskette image file (bootdisk.img) that is used to boot all systems requiring a boot diskette.

If you are performing anything other than an installation from an IDE or USB device, you will be asked to insert a driver diskette created from one of the following image files:

· drvnet.img — For network installations

· drvblock.img — For SCSI installations

· pcmciadd.img — For PCMCIA installations

As with previous releases of CentOS, these image files can be found in the images/ directory on the first installation CD.

Text mode installations using a serial terminal work best when the terminal supports UTF-8. Under UNIX and Linux, Kermit supports UTF-8. For Windows, Kermit '95 works well. Non-UTF-8 capable terminals will work as long as only English is used during installation. An enhanced serial display can be used by passing "utf8" as a boot-time option to the installation program. For example:

linux console=ttyS0 utf8

The firewall configuration screen in the CentOS installation program has been simplified. The previous "High", "Medium", and "No firewall" settings have been replaced by a more straightforward on/off-style control. In addition, the default firewall configuration is now stateful, making it more secure. The new design also makes it possible for users of NIS authentication, NFS, and DNS to deploy a firewall with no additional customization required (although customization by specifying port and protocol is still possible).

NOTE: This change also applies to the Security Level Configuration Tool (redhat-config-securitylevel).

Installation via VNC is now supported. To initiate a VNC-based installation, pass vnc as a boot-time option. If necessary, a password can be set by adding "vncpassword=<password>" to the boot-time options. The VNC display will be "<host>:1", where <host> is the hostname or IP address of the system installing CentOS.

It is also possible for the CentOS installation program to initiate a connection to a listening VNC client. This is done by using the vncconnect boot-time option:

linux vnc vncconnect=<client>[:<port>]

(Where <client> is the hostname or IP address of the system running the listening VNC client, and <port> is an optional port specification that may be specified if the VNC client is not listening on port 5500, which the default port for this type of connection). The following examples show the how the boot-time option is specified for standard and non-standard ports:

linux vnc vncconnect=pigdog.example.com

linux vnc vncconnect=pigdog.example.com:27910

The system that is to run the listening VNC client must then launch the appropriate software to run the VNC client in its listening mode. For the VNC client supplied with CentOS 3, the following command is sufficient:

vncviewer -listen

In addition, a new kickstart directive has been added to support VNC-based installations:

vnc [--password <password>] [--connect <host>[:<port>]]

(Where --password <password> is an optional parameter for specifying a VNC password, and [--connect <host>[:<port>]] is an optional parameter for specifying the host (and optionally, port) of a system running a listening VNC client.

NOTE: If you specify any of the VNC-related boot-time options, they will override the corresponding options present in the kickstart file.

The XFree86 open source vmware video driver is provided as a convenience to our customers and is not supported in any way. However, any problem reports with the XFree86 open source vmware video driver received will be forwarded to the appropriate VMware staff, so that they can investigate. Bug fixes that become available for this driver may be reviewed for potential inclusion in future errata and products as time permits.

Chinese (Simplified and Traditional)

Japanese

Korean

Simplified Chinese

To enter Simplified Chinese characters, you use the miniChinput input method. To activate the input method, press Ctrl-Space.

The miniChinput input method supports the following modules:

· intelligent pinyin input

· gbk pinyin input

· shuang pin input

· internal code (gb18030 code) input

The miniChinput package is installed by default if Simplified Chinese language support is selected during installation.

Traditional Chinese

To enter Traditional Chinese characters, you use the xcin input method. To activate the input method, press Ctrl-Space. Pressing Shift-Ctrl or Ctrl-Alt-Num allows you to change between input modules.

The xcin input method supports the following modules:

· CJ

· Simplex

· Phone

· CantonPing

· Bimsphone

· Bimspinyin

· Array30

· Cantonping (no intonation)

The xcin package is installed by default if Traditional Chinese language support is selected during installation.

Japanese

To enter Japanese characters, you use the Canna, FreeWnn or skk input methods. To activate the input method, press Shift-Space.

The following modules are supported:

· romaji

· kana (only Canna — depends on the configuration file)

The Canna, FreeWnn, and skkinput packages are installed by default if Japanese language support is selected during installation.

Korean

To enter Korean characters, you use the ami input method. To activate the input method, press Shift-Space.

The ami package is installed by default if Korean language support is selected during installation.

The Apache HTTP server has been updated to version 2.0. The updated package replaces version 1.3 and has been renamed to httpd.

· The auth_ldap, mod_put, mod_roaming, mod_auth_any, mod_bandwidth, mod_throttle, and mod_dav modules have been removed.

· WebDAV functionality is now included with the httpd package.

NOTE: Some changes to existing configuration files are needed. Third-party Apache modules may also require updating. Refer to the migration guide at /usr/share/doc/httpd-*/migration.html for more details.

CentOS 3 supports booting over the network using the PXE (Pre-Boot Execution Environment) protocol. As in previous releases it is possible to configure CentOS 3 as an installation server, which makes kernels and image files available for the purpose of starting network installations.

Also available in CentOS 3 is support for diskless environments. A diskless server (similar to an installation server) makes kernels and image files available to diskless client systems. After booting, the diskless client systems mount a root file system via NFS, eliminating the need for locally-attached storage.

The Network Booting Tool (redhat-config-netboot) is a graphical configuration tool allows you to configure both environments.

The LPRng print spooler has been replaced by CUPS, and the Printer Configuration Tool (redhat-config-printer) is the recommended tool for configuring it. It may be launched from the System Settings menu, using the Printing menu entry.

The Security Level Configuration Tool (redhat-config-securitylevel) has been simplified. The previous "High", "Medium", and "No firewall" settings have been replaced by a more straightforward on/off-style control. In addition, the default firewall configuration is now stateful, making it more secure. The new design also makes it possible for users of NIS authentication, NFS, and DNS to deploy a firewall with no additional customization required (although customization by specifying port and protocol is still possible).

NOTE: This change also applies to the CentOS installation program.

GNOME Print Manager, a simple graphical print queue management tool, is now included. It may be launched from the System Tools menu, using the Print Manager menu entry. In addition, when a print job is in the queue, an icon will appear in the panel's system notification area.

CentOS 3 includes the setarch utility. Setarch makes it possible to change the output produced by the uname command. This is useful for a number of reasons, such as running 32-bit applications (those written to expect a particular value from uname -m) in 64-bit environments.

The format for the setarch command is:

setarch <arch> <command>

(Where <arch> represents the desired architecture string (such as i386), and <command> represents the command to be run while the architecture has been modified.) Note that <command> can be omitted, in which case /bin/sh is run.

In addition, some applications (such as older versions of Java) are written to assume a 3GB virtual address space; when run on systems with larger virtual address spaces (such as 64-bit x86-64 systems, or 32-bit systems running the hugemem kernel) such applications can malfunction. The setarch utility makes it possible to emulate a 3GB virtual address space, allowing such applications to run properly:

setarch -3 java

CentOS 3 includes the Native POSIX Thread Library (NPTL), a new implementation of POSIX threads for Linux. This library provides performance improvements and increased scalability.

This thread library is designed to be binary compatible with the old LinuxThreads implementation; however, applications that rely on the places where the LinuxThreads implementation deviates from the POSIX standard will need to be fixed. Notable differences include:

· Signal handling has changed from per-thread signal handling to POSIX process signal handling.

· getpid() returns the same value in all threads.

· Thread handlers registered with pthread_atfork are not run if vfork() is used.

· No manager thread.

Applications that are known to have problems using NPTL include:

- Sun JRE prior to version 1.4.1

- IBM JRE

If an application does not work properly with NPTL, it can be run using the old LinuxThreads implementation by setting the following environment variable:

LD_ASSUME_KERNEL=<kernel-version>

The following versions are available:

· 2.4.19 — Linuxthreads with floating stacks

· 2.2.5 — Linuxthreads without floating stacks

Note that software using errno, h_errno, and _res must #include the appropriate header file (errno.h, netdb.h, and resolv.h respectively) before they are used. However, LD_ASSUME_KERNEL=2.4.19 can be used as a workaround until the software can be fixed.

Multi-threaded C++ programs using thread cancellation might need to be forced to use the LinuxThreads library using the LD_ASSUME_KERNEL=2.4.19 environment variable setting. Otherwise, the program will terminate abnormally if the cancellation is acted on (since the generated exception is not caught).

Newly-written C++ code that uses functions from the C runtime environment might have to be adjusted to take the cancellation into account. This can be done by one of the following methods:

· Not marking the C++ function with throw() (so that callers are aware that an exception might be thrown) and by compiling the code with exceptions. This is the default compilation option; users should not specify -fno-exceptions when compiling.

· Disabling cancellation completely before entering the functions that call the cancel-able C runtime functions. This can be done with the following call:

pthread_setcancelstate (PTHREAD_CANCEL_DISABLE, &oldstate)

After the C functions are called cancellation can be enabled again with the following call:

pthread_setcancelstate (oldstate, NULL)

NOTE: At this point the cancellations are acted upon and therefore the function calling pthread_setcancelstate() must be compiled with exceptions enabled and must be marked as throwing exceptions.

A new system message has been added to CentOS 3:

application bug: <app-name>(<app-pid>) has SIGCHLD set to SIG_IGN but calls wait(). (see the NOTES section of 'man 2 wait'). Workaround activated.

This message (which is displayed on the system console and/or in the system log files) indicates that the application is not completely standards compliant with respect to its handling of child processes. If you notice this message, you should alert the application's developers.

CentOS 3 includes the capability of producing Position Independent Executables (PIE) for C, C++, and Java. This feature is enabled with the -fpie and -fPIE GCC options to compile, which are similar in usage to the -fpic and -fPIC options, respectively, and at link time with the -pie option.

The fileutils, textutils, sh-utils, and stat packages have been replaced by the newer coreutils package.

The RPMs containing the Network Administration Tool (redhat-config-network) have changed names and functions. The redhat-config-network RPM contains the tool's graphical user interface, while redhat-config-network-tui contains the tool itself (along with its text-based user interface).

Support for XHTML1 — the reformulation of HTML in XML — has been improved. This has been done by adding the xhtml1-dtd package, installing the DTDs in the system catalog, and adding native support in the libxml2 and xsltproc tools.

The XML toolkit have been extended to support Relax-NG validation, and streaming of large files.

The OProfile system-wide profiler has been added to CentOS 3. OProfile is a programmer's tool for analyzing system performance, using special hardware built into many modern computers. Documentation for OProfile exists in the oprofile package; after installing CentOS 3, issue the command rpm -qd oprofile to obtain a listing of the available documentation. Visit the OProfile website at http://oprofile.sourceforge.net for more details.

NOTE: The kernel support for OProfile in CentOS 3 is based on the backported code from the 2.5 development kernel. Therefore, if you refer to the OProfile documentation, keep in mind that features listed as being 2.5-specific actually apply to the CentOS kernel, even though the kernel version is 2.4. Likewise, this means that features listed as being specific to the 2.4 kernel do not apply to the CentOS kernel.

At the present time, the X Window System makes use of 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, CentOS may support only fontconfig/Xft in place of the XFS font server as the default local font access method.

NOTE: One 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 CentOS 3 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 does not 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 commands 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-*-*-*-*-*-*".)

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.

The default FTP server in CentOS 3 is now vsftpd, and runs as a SysV service.

Change to fdisk's interpretation of partition size multipliers

The fdisk command now has a different interpretation of the size multipliers that may be used when creating new disk partitions. The size suffixes K, M, and G now refer to multiples of thousands, millions, and billions of bytes, respectively. This is more consistent with the disk size specifications provided by disk drive manufacturers.

Therefore, if a user wants to create a 512MB partition, the size value specified with an "M" suffix would be 512*1024*1024 (536,870,912), rounded up to a multiple of a million (537,000,000), and then divided by a million (537), resulting in a size specification of +537M.

While compatibility for executables and dynamic shared objects (DSOs, also known as shared libraries) created on earlier Red Hat Linux and CentOS is supported, the same does not apply to object (.o) files. Object files created on earlier versions can be used on CentOS 3 to create new executables or DSOs only if they were built without including any system header files.

Otherwise, the only way to use these files is to link the object files to the compatibility version of glibc (part of the compat-glibc package). Any newly-generated object file must use the headers from the compatibility package. For example, to compile object files, add the following to the beginning of the compiler command line:

-I/usr/lib/i386-redhat-linux7/include

To link the resulting executable or DSO add the following to the command line:

-L/usr/lib/i386-redhat-linux7/lib

Any mixture of old object files and those compiled against the current system headers can have negative results. Linking old object files with the regular system libraries may result in completely unusable executables or executables with subtle bugs (such as memory corruption).

The CentOS 3 kernel makes use of a new kernel packaging technique. Due to the almost limitless variety of available hardware, it is not possible for CentOS to fully support all hardware components. Therefore, while kernel modules for fully-supported hardware remain in the standard kernel packages, a series of new unsupported kernel packages are included with CentOS 3.

For each kernel package shipped there is a corresponding unsupported kernel package. For example, the unsupported kernel package for kernel-smp-2.4.21-3.EL.i686.rpm is kernel-smp-unsupported-2.4.21-3.EL.i686.rpm.

NOTE: The unsupported kernel packages are not installed by the CentOS installation program; therefore, in order to use unsupported kernel modules, you must manually install the unsupported kernel package corresponding to the kernel your system uses.

After installing the appropriate unsupported kernel package, you must use the following command to update the module dependency tree and your initrd:

/sbin/new-kernel-pkg --mkinitrd --depmod --install <kernel-version>

(Where <kernel-version> represents the version of the installed kernel.)

Drivers contained within the unsupported kernel packages are provided on a best-effort basis. This means that updates and upstream fixes may or may not be incorporated over time, and are not covered by the same support expectations as the fully supported drivers.

The CentOS 3 kernel includes more accurate process timing functionality. This new process timing mode uses timestamps to provide more accurate timing of idle and process times. When enabled, this information is available via the usual monitoring tools (such as top, vmstat, and procinfo), and the getrusage system call.

To enable timestamp-based process timing, you must boot your system using the following boot-time option:

process_timing=<value>

Where <value> can be one or more of the following, with multiple values separated by commas:

· irq — Use timestamps to account for IRQ interrupts

· softirq — Use timestamps to account for softirq time in the kernel

· process — Allow processes to enable timestamp-based process timing on themselves (It is then disabled for all processes by default)

· all_process — Force timestamp-based process timing on all processes (including the idle tasks)

· everything — Same as specifying irq,softirq,all_process

If the system is booted with the process option, no processes initially have timestamp-based process timing enabled by default. However, processes can use the prctl() system call to both determine and modify their process timing mode. The system call to determine the process timing mode is:

mode = prctl(PR_GET_TIMING, 0, 0, 0, 0);

The system call to set the process timing mode is:

status = prctl(PR_SET_TIMING, <mode>, 0, 0, 0)

(Where <mode> is PR_TIMING_STATISTICAL for enabling the traditional process timing mode, or PR_TIMING_TIMESTAMP for enabling timestamp-based process timing mode .) Note that enabling one process timing mode automatically disables the other.

NOTE: The prctl() system call can only be used on systems booted with the process value. Otherwise, the system call will return -EINVAL. This includes attempts to disable timestamp-based process timing on systems booted with the all_process option.

A child process's timing mode is inherited from its parent; however, the child can use the prctl() system call to modify its own process timing mode (subject to the conditions outlined in the previous note).

The BusLogic driver (for certain Mylex SCSI host bus adapters) is provided in the standard kernel packages, but it is only supported when the kernel is a guest operating system within VMWare™ virtual machine software. This is because VMWare presents an emulated SCSI adapter to the BusLogic driver, and this environment has been thoroughly tested and supported by VMWare, Inc. The BusLogic driver is not supported on physical SCSI host adapters because this driver has not been maintained in the official Linux kernel for several years, and has not received extensive testing in the CentOS kernel.

The qla1280 driver (for the Qlogic ISP1x80/1x160 SCSI adapters) has not been maintained in the official Linux kernel for many years. As a result, although this driver works correctly with the Intel x86 architecture, it does not work correctly with other architectures. Therefore, CentOS only supports the qla1280 driver on Intel x86 platforms.

Systems based on the Intel I865/I875 chipsets and utilizing these chipsets' ICH5 integrated AC97 audio functionality may experience a failure to produce any sound when running CentOS 3.

The ICH5 integrated AC97 audio subsystem can be identified by reviewing the output from the following command:

/sbin/lspci -n

The PCI vendor:device code for the ICH5 AC97 audio is 8086:24d5.

Systems based on the Intel I865/I875 chipsets and utilizing these chipsets' ICH5 Serial ATA (SATA) functionality should configure the BIOS settings for their SATA devices to "enhanced" or "native" mode. "Legacy" or "combined" mode SATA is supported, but discouraged.

NOTE: Not all BIOS implementations offer the ability to change these settings.

New kernel support has been added to provide IPv6 capabilities. This support is consistent with the upstream 2.6-based implementation as of 2.6.0-test3.

Note that CentOS will not be implementing additional IPv6 features (such as any of the draft standards for Mobile IP) for this release of CentOS; our goal is to focus exclusively on bugs in existing features.

EA (Extended Attributes) and ACL (Access Control Lists) functionality is now available for ext3 file systems. In addition, ACL functionality is available for NFS.

CentOS 3 contains a kernel providing EA and ACL support for the ext3 file system. Protocol extensions were also added to NFS to support ACL-related operations for NFS-exported file systems.

To enable ACLs on a locally-mounted file system, the file system must be mounted with the -o acl mount option. By default, the NFS server makes use of ACLs if the underlying file system supports them. To disable this feature, you must specify the no_acl export option.

EAs are used intrinsically for ACL support. To use EAs separately, the file system must be mounted with the -o user_xattr mount option.

The support for this comes in several packages:

· kernel — Provides support for storing EAs and ACLs on disk for ext3 file systems, as well the system calls to manipulate EAs and ACLs. Finally, the kernel package provides the mechanisms to enforce ACLs on file access.

· e2fsprogs — Includes knowledge of the new on-disk extended attribute formats so that fsck can check file systems using the new feature.

· attr, libattr — Provides access to extended attributes attached to files.

· acl, libacl — Provides tools to set, modify, and query the ACLs set on files.

· libattr-devel, libacl-devel — Libraries and include files to build programs using the acl and attr libraries.

· star — An archiving tool which can create and unpack both tar and pax format archives, and which can backup and restore EAs and ACLs.

NOTE: The options available for star are not completely equivalent with those available for tar; therefore, make sure you review the star man page.

· samba — Samba can export ACL functionality in this release. Refer to the samba documentation for information on how to enable this in your configuration.

In addition, the coreutils package has been updated so that the cp and mv commands copy the ACLs and EAs associated with a file.

For more information on setting and reading ACLs, refer to the setfacl and getfacl man pages. General information about ACLs can be found in the acl man page.

NOTE: The normal tar and dump commands will not backup ACLs and EAs.

Compatibility with older systems:

Any ext3 file system that has not had any ACLs or EAs set on it will work unchanged on older kernels, and can be checked using older e2fsprogs utilities.

Once an EA or an ACL has been set on any file on a given file system, that file system will acquire the ext_attr attribute. This attribute can be observed by using the following command:

tune2fs -l <filesystemdevice>

A file system that has acquired the ext_attr attribute can be mounted with older kernels, but obviously those kernels are incapable of enforcing any ACLs that have been set.

NOTE: Older versions of the file system checking program e2fsck refuse to check any file system with the ext_attr attribute. This corresponds to versions of the e2fsprogs package prior to 1.22.

The CentOS 3 kernel now includes support for NFS over TCP. To use NFS over TCP, you must include the "-o tcp" option to mount when mounting the NFS-exported file system on the client system.

NOTE: The default transport protocol for NFS remains UDP. Use the mount command with the "-o tcp" option to mount an NFS-exported file system using TCP; otherwise, UDP will be used by default.

In this kernel, the following command has been added to scan for new devices on all attached SCSI host adapters:

echo "scsi scan-new-devices" > /proc/scsi/scsi

This is currently a non-standard addition. In future kernels a different parameter may be used to provide the same capability, or the semantics of the same parameter (scan-new-devices) may change, as CentOS tracks the official Linux kernel in this area.

Change in permission semantics for user-mode memory locking

CentOS 3 now allows non-root processes to use user-mode memory locking system calls within the bounds of their RLIMIT_MEMLOCK resource limit. The default limit is one physical page per process. Limits can be reassigned by the system administrator on a per user-id, per group-id, or system-wide basis via the /etc/security/limits.conf file. Root processes are no longer constrained by this resource limit.

The system calls affected by this change in semantics are mlock(2), munlock(2), mlockall(2), munlockall(2), and shmctl(2).