This minor update releases typically provide feature enhancements, bugfixes and new hardware support. From the release notes:

Highlights of the Red Hat Enterprise Linux 5.5 release include hardware enablement for the Intel Boxboro-EX platform, AMD Magny-Cours processor and IBM Power 7 processor.
Virtualization is improved, with support for multiple 10 GigE SR-IOV cards, and automatic usage of hugepages for virtual guest memory when enabled on the system. Interoperability improvements include boot support for virtual machines using Microsoft based PXE services.

A summary of technical details would highlight:

• Kickstart improvements to logging post-install
• New hardware driver support (pmcraid, ibmvfs, bfa, be2iscsi)
• Updated hardware support (too many to list)
• Run-time memory allocation for KVM guests (memory ballooning)
• PCI passthrough improvements (hotswapping PCI devices, 1:1 performance improvements)
• Detecting kernel tasks stuck in the uninterruptible sleep state (D-state)
• Improved CFQ I/O scheduler performance
• Kernel CIFS updates and new GFS mount option (for troubleshooting)

Apart from this Red Hat also shared Technology Previews within each release. Functionality that is not yet supported, but available for testing purposes:

• FCoE (Fibre Channel over Ethernet)
• ext4 filesystem support
• gcc 4.4 and new glibc malloc
• Trusted Platform Module (TPM) hardware support
• eCryptfs cryptographic filesystem
• Stateless Linux
• SGPIO Support for dmraid
• Device Failure Monitoring of RAID sets
• iSER support (block storage transfer across a network)

The above Technology Preview features of RHEL5.5 may become part of a future RHEL5 release! Even though there is no predicted timeline for CentOS releases, CentOS 5.5 is not expected before May 4th 2010.

For more details on the changelog, please check the release notes here.

Before you start, A word of advice i believe most experienced RHEL/CentOS users will show you regarding what you’re thinking:

Upgrade between minor versions (i.e. CentOS 5.2 -> 5.3 -> 5.4, or even 5.0 -> 5.4) YES
Upgrade between major system versions (i.e. CentOS 4.8 to CentOS 5.4) NO

As far as I recall, not even Red Hat recommends this – although they do guarantee the miner updates will go smoothly. Even if you manage to hammer that 4.8 to 5.4 upgrade into place, you might end up with a mess that will be very difficult to maintain. Before processing the system update, it’s suggested to create a backup!

If you are currently running a version of RHEL/CentOS earlier than 4.8 (cat /etc/redhat-release), then please do a proper ‘yum update‘ and get your current system updated to 4.8 before we start.

Then the first thing we need to do is to make sure none of our core binaries, libraries or other content is immutable as it causes package installation failures. If you use immutable bits on system paths then you should run these commands:

chattr -Ria /bin
chattr -Ria /etc
chattr -Ria /etc
chattr -Ria /include
chattr -Ria /lib
chattr -Ria /sbin
chattr -Ria /usr/bin
chattr -Ria /usr/include
chattr -Ria /usr/lib
chattr -Ria /usr/libexec
chattr -Ria /usr/local/bin
chattr -Ria /usr/local/include
chattr -Ria /usr/local/lib
chattr -Ria /usr/local/sbin
chattr -Ria /usr/sbin
chattr -Ria /usr/share
chattr -Ria /var/lib
chattr -Ria /var/lock
chattr -Ria /var/log
chattr -Ria /var/run
chattr -Ria /var/spool/repackage

Once finished, go ahead and have a quick run through of cleaning up yum cache, double check that any pending updates are installed and rebuild the rpmdb:

yum clean all && yum update

If you run into any dependency issues for packages that are not essential, such as syslinux and lftp then you can either exclude them or better just remove them. If the denpency issue is openssh-server related, you can enable telnet login during update by modifing /etc/xinetd.d/telnet.

rpm -e lftp syslinux mkboot

OR (but not recommended)

yum update --exclude=syslinux --exclude=lftp --exclude=mkboot

At this point you should be able to run a ‘yum update‘ command with optional exclude and receive no errors. Now we are ready to get going, please google around, find and download these packages, they mostly available at CentOS official mirror site:

# ls
centos-release-5-4.el5.centos.1.i386.rpm    python-elementtree-1.2.6-5.el4.centos.i386.rpm
centos-release-notes-5.4-4.i386.rpm       python-elementtree-1.2.6-5.el5.i386.rpm
kernel-2.6.18-164.el5.i686.rpm            python-elementtree-1.2.6-5.i386.rpm
kernel-devel-2.6.18-164.el5.i686.rpm      python-sqlite-1.1.7-1.2.1.i386.rpm

We need to go ahead and setup the centos-release package as follows:

rpm -Uhv centos-release-*.rpm

If you see that CentOS-Base.repo was created as /etc/yum.repos.d/CentOS-Base.repo.rpmnew then move it to the right place:

# mv /etc/yum.repos.d/CentOS-Base.repo.rpmnew /etc/yum.repos.d/CentOS-Base.repo

Now we are ready to go with kernel changes, this is an important part so pay attention. The key to successful upgrade is that you remove ALL OLD KERNELS as many packages will fail to install during the upgrade if they detect a release 4.x kernel due to minimum kernel version dependency checks. We will first start with installing the new CentOS 5.4 kernel so it preserves grub templating:

rpm -ivh kernel-2.6.18-164.el5.i686.rpm kernel-devel-2.6.18-164.el5.i686.rpm --nodeps

NOTE: release 5.x has smp support integrated into the standard kernel, so no *-smp version is required for multi-processor systems.

If you are running an older system the chances are you got allot of older kernel packages installed, so make sure you get them all out of the way:

rpm -e $(rpm -qa | grep kernel | grep -v 2.6.18 | tr 'n' ' ') --nodeps

That said and done you should now only have 2 kernel packages installed which are the 2.6.18 release 5.x kernels. DO NOT under any circumstance continue if you still got 2.6.9 release 4.x kernels packages installed, remove them ALL!

# rpm -qa | grep -i kernel
kernel-2.6.18-164.el5
kernel-devel-2.6.18-164.el5

A cleanup of /etc/grub.conf may be required, though the rpm command should have done this for you already, but review it anyways for good measure. You should find that 2.6.18-164.el5 is the only kernel in the file. When kernel updated, a reboot here is OK, but it’s not suggested.

Then we can continute the system updates. There is a known bug with python-elementtree package versions which cause yum/rpm to think the release 4.x version is newer than the 5.x version, to get around this without blowing up the entire python installation we need to remove the package from just the rpmdb as follows:

rpm -e --justdb python-elementtree --nodeps

We can now go ahead and use yum to start the upgrade process, this is a dry run and will take some minutes to compile list of available packages and associated dependency checks. You should carry the exclude options, if any, that you used during the ‘yum update’ process as so to avoid unresolvable dependencies:

yum clean all
yum upgrade

You will end up with a small list of dependency errors, these should be resolved by again evaluating a packages need as a critical system component and either removing it with ‘rpm -e‘ or excluding it with ‘–exclude‘ (remember to query description if you are unsure what something does). In my case the packages that threw up red flags were stuff I had manually installed over time such as nfs in addition to default installed samba, these can all safely be removed or excluded as you prefer.

    Error: Missing Dependency: perl(Convert::ASN1) is needed by package samba
    Error: Missing Dependency: libevent-1.1a.so.1 is needed bypackage nfs-utils

At this point you should be ready to do a final dry run and see where we stand on dependencies, rerun the earlier ‘yum upgrade‘ while making sure to carry over any exclude options you are using.

You should now end up with a summary of actions that yum needs to perform, go ahead and kick it off… this will take a bit time to complete.

    Transaction Summary
    ===========================================================
    Install 183 Package(s)
    Update 527 Package(s)
    Remove 0 Package(s)
    Total download size: 679 M
    Is this ok [y/N]:Y

Once yum has completed we need to fix a few things, the first is the rpmdb needs a rebuild due to version changes that will cause any rpm commands to fail:

rm -f /var/lib/rpm/__db.00*
rpm --rebuilddb
yum clean all

The next issue on the list is python-elementtree and python-sqlite, one or both of these may have ended up in a broken state that will cause all yum commands to break, so we will go ahead and reinstall both of them:

rpm -e --justdb python-elementtree --nodeps
rpm -ivh python-elementtree-1.2.6-5.el5.i386.rpm
rpm -ivh python-sqlite-1.1.7-1.2.1.i386.rpm --nodeps --force

The yum command should now work, go ahead and run it with no options, if you do not get any errors, you are all sorted!

Hopefully the install went well for you, the only thing left to do is go ahead and reboot the system:

shutdown -rf now

For the sake of avoiding a system raised fsck, we will reboot with the -f option to skip fsck.

The hardware clock is generally only used to set the system clock when your operating system boots, and then from that point until you reboot or turn off your system, the system clock is the one used to keep track of time.

On Linux systems, you have a choice of keeping the hardware clock in UTC/GMT time or local time. The preferred option is to keep it in UTC. The disadvantage with keeping the hardware clock in UTC is that if you dual boot with an operating system (like DOS) that expects the hardware clock to be set to local time, the time might be wrong in that OS.

Set your timezone

The timezone under Linux is set by a symbolic link from /etc/localtime to a file in the /usr/share/zoneinfo directory that corresponds with what timezone you are in. For example, since I’m of same timezone as Hong Kong, /etc/localtime is a symlink to /usr/share/zoneinfo/Asia/Hong_Kong. To set this up, run:

[admon@planet ~]# ls -F /usr/share/zoneinfo/
Africa/      CST6CDT  Etc/     Greenwich  Kwajalein  Navajo     SystemV/   iso3166.tab
America/     Canada/  Europe/  HST        Libya      PRC        Turkey     posix/
Antarctica/  Chile/   Factory  Hongkong   MET        PST8PDT    UCT        posixrules
Arctic/      Cuba     GB       Iceland    MST        Pacific/   US/        right/
Asia/        EET      GB-Eire  Indian/    MST7MDT    Poland     UTC        zone.tab
Atlantic/    EST      GMT      Iran       Mexico/    Portugal   Universal
Australia/   EST5EDT  GMT+0    Israel     Mideast/   ROC        W-SU
Brazil/      Egypt    GMT-0    Jamaica    NZ         ROK        WET
CET          Eire     GMT0     Japan      NZ-CHAT    Singapore  Zulu

[admon@planet ~]# ln -sf /usr/share/zoneinfo/Asia/Hong_Kong /etc/localtime

Replace your timezone with something like US/Pacific or Europe/Paris. Have a look in the directories under /usr/share/zoneinfo to see what timezones meet your needs.

This assumes that you are running Red Hat (or Redhat based Linux) . On older systems, you’ll find that /usr/lib/zoneinfo is used instead of /usr/share/zoneinfo.

Set the system clock

To set the system clock under Linux, use the date command. As an example, to set the current time and date to Sun Dec 13 10:02:00 AM CST 2009, type date 12131002 (note that the time is in 24 hour notation).

[admon@planet ~]# date
Sun Dec 13 10:09:29 CST 2009
[admon@planet ~]# date 12131002
Sun Dec 13 10:02:00 CST 2009

You can reset system time without date information like this:

[admon@planet ~]# date -s 10:04
Sun Dec 13 10:04:00 CST 2009

If you wanted to change the year as well, just type date 121310022009. To set the seconds as well, type date 12131002.30 or date 121310022009.30. The following line is an example. When the command runs succesfully, it returns current system time:

[admon@planet ~]# date 121310212009.30
Sun Dec 13 10:21:30 CST 2009

An alternative way is to load system date and time from BIOS like this:

[admon@planet ~]# date
Sun Dec 13 10:02:04 CST 2009
[admon@planet ~]# hwclock --hctosys
[admon@planet ~]# date
Sun Dec 13 10:09:29 CST 2009

Set the hardware clock

When Linux boots, A initialization script will run the /sbin/hwclock program to copy the current hardware clock time to the system. To set the hardware clock, a common way is to set the system clock first, and then sync the new system time to hardware clock by typing /sbin/hwclock –systohc (or /sbin/hwclock –systohc –utc if you are keeping the hardware clock in UTC).

[admon@planet ~]# date
Sun Dec 13 10:29:57 CST 2009
[admon@planet ~]# hwclock --systohc
[admon@planet ~]# hwclock
Sun Dec 13 10:30:13 2009  -0.716300 seconds
[admon@planet ~]# date
Sun Dec 13 10:30:13 CST 2009

Sync local time with a time server
This can be done by an entry in root’s crontab like this:

[admon@planet ~]# crontab -l
MAILTO=""
30 4,16 * * * (/usr/sbin/ntpdate -s clock.redhat.com time.nist.gov ntp.admon.org)

It means your system time will be synced with these time servers every 12 hours. If you have a cluster of machines which must share the same time, it’s suggested to build your own time server, and get other servers synchronized with it.

Instead of keeping your system time up-to-date with the world, a local time server can be configed to supply delayed time, that means you can keep your system time delayed with the public. It’s helpful for some specific environment, like if you need some delayed mysql replication servers.

1, Install from RPM packages
Generally we need these RPM packages, you can search and download them from Google.com.

[root@storage cax]# ls
srvadmin-cm-6.1.0-648.i386.rpm       srvadmin-omcommon-6.1.0-648.i386.rpm
srvadmin-deng-6.1.0-648.i386.rpm     srvadmin-omhip-6.1.0-648.i386.rpm
srvadmin-hapi-6.1.0-648.i386.rpm     srvadmin-omilcore-6.1.0-648.i386.rpm
srvadmin-isvc-6.1.0-648.i386.rpm     srvadmin-syscheck-6.1.0-648.i386.rpm
srvadmin-omacore-6.1.0-648.i386.rpm
srvadmin-cm-6.1.0-648.i386.rpm

These packages can be used on both RHEL-4 and RHEL-5. After the downloading, let’s start the installation:

[root@storage cax]# uname -a
Linux storage.admon 2.6.9-78.ELsmp #1 SMP Wed Jul 9 15:46:26 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux
[root@storage cax]# rpm -ivh srv*.rpm
Preparing...                ########################################### [100%]
1:srvadmin-omilcore      ########################################### [ 11%]
To start all installed services without a reboot,
enter the following command:  srvadmin-services.sh  start
2:srvadmin-syscheck      ########################################### [ 22%]
3:srvadmin-deng          ########################################### [ 33%]
4:srvadmin-hapi          ########################################### [ 44%]
5:srvadmin-omcommon      ########################################### [ 56%]
6:srvadmin-omacore       ########################################### [ 67%]
7:srvadmin-isvc          ########################################### [ 78%]
8:srvadmin-cm            ########################################### [ 89%]
9:srvadmin-omhip         ########################################### [100%]
[root@storage cax]#

Now, it’s ready for use! enjoy!

The following two steps are from Dell’s official website, and it’s officially supported by Dell!

2, Setup for usage with yum

The minimum required yum is 2.4.x, and it’s tested on RHEL5, CentOS, Scientific Linux, RHEL4+yum, SLES+yum. The version of yum distributed on CentOS 3 by default is very old (yum 2.0.8), so you need to upgrade to a 2.4.x version in order to use these repositories. The older version of yum does not support plugins or mirrorlists, which are required for these repos to work.

Set up this repository, type:

[root@storage cax]# wget -q -O - http://linux.dell.com/repo/hardware/OMSA_6.1/bootstrap.cgi | bash

Optional Install OpenManage Server Administrator:

[root@storage cax]# yum install srvadmin-all

NOTE: OMSA will not install on unsupported systems. If you receive a message at install that the system is not supported, it is likely that your system is not supported, and the install will fail. This is most common on Dell SC-class systems, as OMSA is completely unsupported on these systems.

3, Set up for usage with up2date

Follow these instructions for use with up2date on RHEL4:

Set up this repository:

[root@storage cax]# wget -q -O - http://linux.dell.com/repo/hardware/OMSA_6.1/bootstrap.cgi | bash

Optional Install OpenManage Server Administrator:

[root@storage cax]# up2date -i srvadmin-all

NOTE: OMSA will not install on unsupported systems. If you receive a message at install that the system is not supported, it is likely that your system is not supported, and the install will fail. This is most common on SC-class systems, as OMSA is completely unsupported on these systems.

In addition to the command line interface, hpasmcli is also usable for incorporating into shell scripts. The return value of hpasmcli can be used to verify a command executed successfully. If multiple commands are executed, only the status of the last command is returned to the shell.

Hpasmcli supports TAB completion of command names and has a history buffer that can be accessed using the up/down arrows. The following examples are created on a HP ProLiant DL380 G4 server.

As an example, the following first executes the ´SHOW SERVER´ command to retrieve basic system information, and next reads the environment temperature:

[root@example email]# hpasmcli -s 'show server; show temp'

System        : ProLiant DL380 G4
Serial No.    : CN-HIDED-YD
ROM version   : P51 12/02/2004
iLo present   : Yes
Embedded NICs : 2
NIC1 MAC: 00:13:21:cc:33:49
NIC2 MAC: 00:13:21:cc:33:48

Processor: 0
Name         : Intel Xeon
Stepping     : 1
Speed        : 3000 MHz
Bus          : 800 MHz
Socket       : 1
Level2 Cache : 1024 KBytes
Status       : Ok

Processor: 1
Name         : Intel Xeon
Stepping     : 1
Speed        : 3000 MHz
Bus          : 800 MHz
Socket       : 2
Level2 Cache : 1024 KBytes
Status       : Ok

Processor total  : 2

Memory installed : 8192 MBytes
ECC supported    : Yes

Sensor   Location              Temp       Threshold
------   --------              ----       ---------
#0        SYSTEM_BD             -          -
#1        PROCESSOR_ZONE       40C/104F   62C/143F
#2        CPU#1                46C/114F   80C/176F
#3        I/O_ZONE             43C/109F   60C/140F
#4        CPU#2                50C/122F   80C/176F
#5        POWER_SUPPLY_BAY     32C/89F    50C/122F

[root@example email]# echo $?
0

You can use “show dimm” to check details about the memory arrary. It’s more specific compared to dmidecode that we mentioned before:

hpasmcli> show dimm
DIMM Configuration
------------------
Cartridge #:   0
Module #:      1
Present:       Yes
Form Factor:   9h
Memory Type:   12h
Size:          1024 MB
Speed:         333 MHz
Status:        Ok

Cartridge #:   0
Module #:      2
Present:       Yes
Form Factor:   9h
...

The other supported commands are listed here: CLEAR | DISABLE | ENABLE | EXIT | HELP | QUIT | SHOW. For example we can set the boot sequence at command-line mode like this:

hpasmcli> SET BOOT [enter]
Invalid Arguments
SET BOOT FIRST [ CDROM | FLOPPY | HDD | PXE | USBKEY ]
SET BOOT ONCE [ CDROM | FLOPPY | HDD | PXE | RBSU ]
hpasmcli> SET BOOT FIRST HDD

It can also be used to enable/disable Automatic Server Recovery, Processor Hyper-Threading, PXE BOOT on specified NIC and Wake-On-Lan feature, etc.

HPASMCLI manual page is avaiable on hp.com, and the binary itself is avaiable on ftp.compaq.com, and the installation itself is as easy as installing normal rpm. For any issues, dont forget to raise a thread at our support forum.

make, GCC, rpm-build, redhat-rpm-config

If they havn’t installed yet, you can start the installation by yum like this “yum install make“. After finished, run the “rpmbuild –showrc” or the more terse “rpmbuild –version command” to check that it’s OK. Then let’s start the configuration.

As an unprivileged user create the following directories:

mkdir ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}

These directories are the exact working place, which are actually alternative ones that are different from system default path /usr/src/redhat.

Then, create a new file ~/.rpmmacros and put the following basic macros in it:

%_topdir      %(echo $HOME)/rpmbuild
%_smp_mflags  -j3
%__arch_install_post   /usr/lib/rpm/check-rpaths   /usr/lib/rpm/check-buildroot

All macros that are set in ~/.rpmmacros override the system-wide macros that have been set in other locations. The meaning of these directives are listed below:
%_topdir macro is the path of the root directory of your RPM building environment, ~/rpmbuild in this case.

%_smp_mflags macro usually contains only the -j (–jobs) option for the make command, which defines the number of jobs (make commands) that may run simultaneously. Usually, this is set to the number of CPU cores plus one. So, on a dual core CPU, this flags are set to -j3.

%__arch_install_post macro contains various checks that should be run on the files in the BUILDROOT location. I trust Fedora guys and use the defaults check-rpaths and check-buildroot on Fedora and CentOS. This macro is optional.

To check which paths are checked for macro files, enter the following command:

rpm --showrc | grep macrofiles

For the whole current configuration for RPM building, run “rpm –showrc“. All the available macros can be found in /usr/lib/rpm/macros. From that point you’re ready to go. Simply install the src.rpm as normal and the files will be unpacked in your new build tree.

It’s very helpful for you to keep your RHEL installations up-to-date without paying to Redhat, as RHSA releases all updated source code in SRPM package.

The Life Cycle identifies the various levels of maintenance for each major release of Red Hat Enterprise Linux over a total period of seven years from the initial release date, which is often referred to as the general availability date. The seven year life cycle for a major release of Red Hat Enterprise Linux is divided into three phases.

Production 1 Life Cycle Phase

During Production 1, at a minimum, qualified security errata of important and critical impact, as well as, urgent priority bug-fix errata may be released independent of minor releases.

If available, refreshed hardware enablement and select enhanced software functionality may be provided at the discretion of Red Hat, generally via minor releases. Minor releases will also include all available and qualified errata.

Production 2 Life Cycle Phase

During the Production 2 life cycle phase, at a minimum, qualified security errata of important or critical impact, as well as, urgent priority bug-fix errata may be released independent of minor releases.

If available, refreshed hardware enablement that does not require substantial software changes may be provided at the discretion of Red Hat via minor releases. New software functionality is not available during this phase. All available and qualified errata will be provided via the minor releases. The focus for minor releases during this life cycle phase lies on resolving defects with a minimum priority of high.

Production 3 Life Cycle Phase

During Production 3, at a minimum, qualified security errata of important or critical impact and selected mission critical bug fixes may be released independent of minor releases.

No new functionality, new hardware enablement or or updated installation images are planned for release in Production 3 life cycle phase. There are no minor releases planned during this phase.

For detailed information, please refer to this link at official website Redhat.com.

Red Hat Enterprise Linux 3 with a 2.4 kernel base uses a single, robust, general purpose I/O elevator. The I/O schedulers provided in Red Hat Enterprise Linux 4, embedded in the 2.6 kernel, have advanced the I/O capabilities of Linux significantly. With Red Hat Enterprise Linux 4, applications can now optimize the kernel I/O at boot time, by selecting one of four different I/O schedulers to accommodate different I/O usage patterns:

* Completely Fair Queuing—elevator=cfq (default)
* Deadline—elevator=deadline
* NOOP—elevator=noop
* Anticipatory—elevator=as

The I/O scheduler can be selected at boot time using the “elevator” kernel parameter. In the following example, the system has been configured to use the deadline scheduler in the grub.conf file.

title Red Hat Enterprise Linux Server (2.6.18-8.el5)
root (hd0,0)
kernel /vmlinuz-2.6.18-8.el5 ro root=/dev/vg0/lv0 elevator=deadline
initrd /initrd-2.6.18-8.el5.img

In Red Hat Enterprise Linux 5, it is also possible to change the I/O scheduler for a particular disk on the fly.

# cat /sys/block/sdb/queue/scheduler
noop anticipatory deadline [cfq]
# echo ‘deadline’ > /sys/block/sdb/queue/scheduler
# cat /sys/block/sdb/queue/scheduler
noop anticipatory [deadline] cfq

The following are the tunable files for the deadline scheduler. They can be tuned to any suitable value according to hardware performance and software requirements:

/sys/block/DEVNAME/queue/iosched/read_expire
/sys/block/DEVNAME/queue/iosched/write_expire
/sys/block/DEVNAME/queue/iosched/fifo_batch
/sys/block/DEVNAME/queue/iosched/write_starved
/sys/block/DEVNAME/queue/iosched/front_merges

DEVNAME is the name of block device (such as sda, sdb, hda, etc)

A detailed description of the deadline I/O scheduler can be found at:
/usr/share/doc/kernel-[version]/Documentation/block/deadline-iosched.txt.

The concept is simple, click a button, and your VM moves from one machine to the next. The execution for similar architectures has been done for ages, AMD can do it from E-Step Opterons to a promise of Magny Cours. Intel is a little more restrictive, but they can do it between iCore iNumber iNumberals as iwell.

The trick up till now has been to do the same thing between servers from different CPU vendors, it is the holy grail of virtualisation. Please note, there are about 37 holy grails of virtualisation at the moment, so this does not signal the end of days, just that the holy grail clock in Times Square dropped to 36.

If you look at the video here,you will see that they did it. Live migration while streaming HD video isn’t all that bad a trick mind you, but doing it between a Barcelona, Shanghai and Intel box is. 36 more of these, and we will be in great shape. original version is here.

Mostly you just need to disable IPv6 protocol. But in some case, you do not need it at all or it may increase browsing speed. Linux has Internet Protocol Version 6 (IPv6) enabled. By default, almost all distros enable it.

Red Hat and similar ones (like Fedora and CentOS)

Open your modprob.conf file and add following lines:

# vi /etc/modprobe.conf

Add following line in the bottom:

alias ipv6 off

alias net-pf-10 off

The run chkconfig ip6tables off to disable IPv6 firewalls.  After that reboot your system.

An alternative way (which might be easier and works on any release with /etc/modprobe.d):

Debian and similar ones ( like Ubuntu)

If you are running Debian based Linux (like Ubuntu), open file /etc/modprobe.d/aliases
# vi /etc/modprobe.d/aliases
Find the line:
alias net-pf-10 ipv6
Replace to:
alias net-pf-10 off
alias ipv6 off

There is also an alternative method in Debian kernel 2.6:
open “/etc/modprobe.d/blacklist“, add a line

blacklist ipv6

followed by a reboot will be OK.

OpenSuSE /SuSE Enterprise Linux (SuSE 9.1/9.2/9.3/10.0, etc)

the official method to disable IPv6:

open “/etc/modprobe.conf“, change the line:

alias net-pf-10 ipv6

to:

alias net-pf-10 ipv6
install ipv6 /bin/true

then, reboot …

An alternative method is also available in SuSE 9.1/9.2/9.3/10.0, Mandriva/Slackware:
Open “/etc/modprobe.conf”, make sure you change

alias net-pf-10 ipv6

to

alias net-pf-10 off
alias ipv6 off

then, save and reboot the system. IPv6 support will now be disabled and it did improve the DNS performance.