Common unused / rarely used daemons
The following list contains daemons that may not be used by a 'normal' end-user. You can compare the list of daemons started up on your system to this list, and see if you could safely disable some of those daemons.
Bluetooth
hcid, sdpd and hidd (These daemons provide Bluetooth services and are unnecessary if you don't have any Bluetooth hardware)
Printing
cups and cups-config-daemon (These daemons provide printer services and are unnecessary if you don't have any printer hardware attached to your local pc or to a network pc)
hpiod and hpssd (These daemons provide extensive support for HP printers. They can safely be disabled if you never print using an HP printer)
Console
gpm (This daemon provides mouse support for text-based applications, like Midnight Commander. It also provides copying/pasting with the middle mouse button in console environments. Can be disabled if you do not use the console much)
Webserver
httpd (This daemon provides web hosting services, and is unecessary on workstations and servers that do not host any websites or webinterfaces)
mysqld and postgresqld (These daemons provide database backend services. You can usually disable them if you're not running a webserver, although some applications use these databases for their data storage)
Firewall
netfilter/iptables (This daemon provides firewall services. Those are not that necessary if you're behind a router or smoothwall with a built-in firewall)
InfraRed
irda (This daemon enables your computer to communicate with other devices using IR (InfraRed) hardware. If you haven't got such hardware, you can safely disable this service)
lircd (This daemon provides remote control support using IR (InfraRed) receivers. Can be disabled if you don't have hardware capable of receiving IR signals)
Multiple CPU's
irqbalance (This daemon balances interrupts over multiple CPU's in the system. Can be disabled if you don't have multiple CPU's or a dual core processor)
Software RAID
mdmonitor, mdadm and mdmpd (These daemons provide information about and management functionality over software RAID devices. They are unnecessary if you don't use software RAID)
DNS Server
named (also known as BIND) (This daemon provides DNS server functionality. It is usually not needed on workstations)
Remote kernel logging
netdump, netcrashdump and netconsole (These services provide functionality for kernel logging and debugging over network connections. Only necessary if you want to view your kernel's log and debugging messages on an other computer)
Fileservers
NFS server
nfs (This daemon provides NFS server functionality, allowing other computers with NFS clients to connect to your computer and access files. You can disable this if you don't need/want others to access your system using NFS)
portmap (This daemon manages RPC connections, used by protocols like NFS and NIS. Only needed on computers that need to act as a server)
rpcsvcgssd (This daemon manages RPCSEC GSS contexts for the NFSv4 server and is not needed unless you are running an NFS server)
Samba server
smbd and nmbd (These daemons provides other computers (Windows computers, too) with access to your files. This is not needed if you don't want others to be able to access your files over the network)
Network Authentication
nscd (This daemon handles passwd and group lookups and caches their results. Only needed when using a 'slow' name service, like NIS, NIS+, LDAP, or hesiod)
portmap (This daemon manages RPC connections, used by protocols like NFS and NIS. Only needed on computers that need to act as a server)
Remote time setting
ntpd (This daemon sets your system time to a value it retrieves from a so-called ntp server, which usually serves a very accurate time. Although it is a useful feature, it tends to slow your system's startup a lot, especially if the server cannot be found)
Process Accounting
psacct (also known as acct) (This daemon provides process accounting, which gives a more detailed insight into the execution of commands on your system. This is usually not needed unless you are running a server that is accessed by a lot of people that you cannot trust entirely)
Plaintext Authentication Requests
saslauthd (This daemon handles SASL Plaintext Authentication Requests, and is only required on a server that needs to communicate using SASL mechanisms)
Mailserver
sendmail (This daemon sends and forwards email messages, acting as a server. You don't

need this daemon to be able to send a normal message. It is only needed if you need your computer to act as a mailserver)
spamd (also known as Spamassassin) (This daemon checks incoming mail messages for spam. This can usually be disabled, but keep in mind that some mail clients, like KMail, can use spamd's functionality)
SSH Server
sshd (This daemon allows remote login to your computer using the SSH protocol. It can be disabled if you don't want/need this access)
VNC Server
vncserver or xvnc (This daemon allows others to get a virtual graphical Desktop that actually runs on your computer)
Task Scheduler
cron (and variants, like vixie-cron...) (This daemon runs periodic tasks on your system, like updating the search index or the manpage index, but also rotating logfiles. This one is generally required for a server system to run correctly, but workstations may be able to run without it)

Step by Step installation of mysql under linux using source file.

# groupadd mysql
# useradd -r -g mysql mysql
# cd /usr/local
# tar zxvf /path/to/mysql-VERSION-OS.tar.gz
# ln -s full-path-to-mysql-VERSION-OS mysql
# cd mysql
# chown -R mysql .
# chgrp -R mysql .
# scripts/mysql_install_db --user=mysql
# chown -R root .
# chown -R mysql data ;

# cp support-files/my-medium.cnf /etc/my.cnf ;

# bin/mysqld_safe --user=mysql &

# cp support-files/mysql.server /etc/init.d/mysql.server ;
# ln -s /usr/local/mysql/bin/mysql /usr/bin/mysql ;
# ln -s /usr/local/mysql/bin/mysqladmin /usr/bin/mysqladmin ;
# /etc/init.d/mysql.server restart ;
# chkconfig mysql.server on ;

Delete ALL users who are not root:
mysql> delete from mysql.user where not (host="localhost" and user="root");
Query OK, 5 rows affected (0.15 sec)

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)

mysql>
Change root database admin password: (note: once this step is complete you’ll need to login with: mysql -p -u root)
mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('mypass');
Query OK, 0 rows affected (0.00 sec)

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)


Change root username to something less guessable for higher security.
mysql> update mysql.user set user="mydbadmin" where user="root";
Query OK, 2 rows affected (0.00 sec)
Rows matched: 2 Changed: 2 Warnings: 0

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)
Remove anonymous access to the database(s):
mysql> DELETE FROM mysql.user WHERE User = '';
Query OK, 2 rows affected (0.00 sec)

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)
Add a new user with database admin privs for all databases:
mysql> GRANT ALL PRIVILEGES ON *.* TO 'warren'@'localhost' IDENTIFIED BY 'mypass' WITH GRANT OPTION;
Query OK, 0 rows affected (0.00 sec)

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)
Add a MySQL database:
mysql> create database bugzilla;
Query OK, 1 row affected (0.15 sec)

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)
Configuring the ODBC Connector under wine

downlaod mysql connector
http://mysql.mirror.iweb.ca/Downloads/Connector-ODBC/5.1/mysql-connector-odbc-5.1.9-win32.msi
downlaod MDAC
http://software-files-l.cnet.com/s/software/10/72/94/97/mdac_typ.exe?e=1321303803&h=703f96c1be2d85c8a1be98dab1ff2220&lop=link&ptype=1901&ontid=10250&siteId=4&edId=3&spi=6cb40692746e8d5a1961a5439319e4c2&pid=10729497&psid=10729498&&fileName=mdac_typ.exe

Install Mdac in wine
wine mdac_typ.exe

Install mysql connector odbc
wine msiexec /i mysql-connector-odbc-5.1.9-win32.msi

configuring ODBC Data Sourc

# wine control

in User DSN add new data source → select new odbc driver - > enter data sourc name ,mysql server ip
,port,user,password,database etc.. check test if succesfully show then click on ok
then apply connection pooling to new odbc driviers. Then Driver meny and selecty driver and apply

10 Simple Steps to RedHat Linux Security

Configure Security Banners/Disclaimers

The Security Banner refers to the message that is displayed when users log in. Banners provide legal protection against unauthorized access attempts and provide a means to prosecute violators.

Here is an example of a generic banner:

Warning! This is a private system. Unauthorized access to or use of this system is strictly prohibited. Unauthorized users are subject to criminal prosecution and penalties.

To configure a banner in Redhat, edit the file /etc/issue:

su root
Enter root password
vi /etc/issue

Use vi commands to edit file and replace with your banner text. Enter ESC:x! when finished to save file.

In order for this banner to be displayed when users attempt to ssh to your server you will need to add it to the sshd_config file.

vi /etc/ssh/sshd_config

Arrow down to the line that begins with Banner. By default it should be

#Banner /some/banner

Edit this line, removing the # character and change the path to point to the /etc/issue file from above.

Banner /etc/issue

Enter ESC:x! when finished to save file.

Enter the following command to restart the ssh server for the changes to take effect:

/etc/init.d/sshd restart

Set GRUB boot loader password

Setting a password on the grub boot loader will require you to enter a password before booting the system. Although this is a recommended security practice, it is worth mentioning that this can be annoying, especially if you ever need to reboot the system remotely. I would not recommend this if you do not have physical access to the server.

The first step is to create a MD5 representation of your password. Enter the following to execute the grub md5 utility:

/sbin/grub-md5-crypt

Enter your password and confirm it. The program will generate an encrypted string. Carefully copy this string to a notepad.

Next you will need to edit the grub config file and add this encrypted password:

su root
Enter root password
vi /boot/grub/grub.conf

Insert a new line as following, placing your md5 password string after the –md5:

password –md5 $5Hhd9D4HEO7$%df8fHdLO9PDjU70

Save the file by entering ESC:x!

Reboot and verify that the new password is working.

Note: If for some reason this doesn’t work you may be locked out of your system. You will need to insert the RedHat installation CD/DVD and boot the system in recovery mode in order to undo the changes. To undo above edit the /boot/grub/grub.conf file and remove or comment out the password line.

Password protect single user mode

Single user mode is a system maintenance mode similar to windows safemode. If an attacker obtains access to the console he/she could potentially exploit this capability to bypass security controls and obtain root access to the system. It is a good idea to protect single user mode with a password to help prevent this.

Doing so is actually quite easy. Edit the /etc/inittab as followsg:

su root
Enter root password
vi /etc/inittab

Insert the following line:

~~:S:wait:/sbin/sulogin

Type ESC:x! to save and exit.

Configure Password Policy

The following settings force users to change their password every 90 days and enforce passwords at least 8 characters long.

su root
Enter root password
vi /etc/login.defs

Edit the file as follows:

PASS_MAX_DAYS 90
PASS_MIN_DAYS 1
PASS_MIN_LEN 8
PASS_WARN_AGE 14

Type ESC:x! to save and exit

Disable Unnecessary Services

An important security principle is “if you don’t need it, disable it”. All running services expose the system to some level of risk. Obviously, some services are much more vulnerable than others but often you don’t know what the vulnerabilities of any given service are, and some may yet to have been discovered.

To see what services are enabled enter:

/sbin/chkconfig –list

To disable a service enter:

/sbin/chkconfig -del service

At a minimum the following should be disabled:

/sbin/chkconfig -del bluetooth
/sbin/chkconfig -del cups
/sbin/chkconfig -del autofs
/sbin/chkconfig -del isdn
/sbin/chkconfig -del portmap
/sbin/chkconfig -del vncserver
/sbin/chkconfig -del mdmonitor
/sbin/chkconfig -del winbind

It is also a good idea to go through the /etc/xinetd.d directory and delete any unused services here. For example:

rm /etc/xinetd.d/gssftp
rm /etc/xinetd.d/krb5-telnet
rm /etc/xinetd.d/tftp
rm /etc/xinetd.d/daytime*
rm /etc/xinetd.d/chargen*
rm /etc/xinetd.d/ekrg5-telnet*

Delete Unnecessary accounts and groups

There are a number of default accounts and groups that you probably will never need and having them around can be a potential risk. Use the following commands to delete them:

/sbin/userdel adm
/sbin/groupdel adm
/sbin/userdel lp
/sbin/groupdel lp
/sbin/userdel shutdown
/sbin/groupdel shutdown
/sbin/userdel halt
/sbin/groupdel halt
/sbin/userdel news
/sbin/groupdel news
/sbin/userdel uucp
/sbin/groupdel uucp
/sbin/userdel operator
/sbin/groupdel operator
/sbin/userdel games
/sbin/groupdel games
/sbin/userdel gopher
/sbin/groupdel gopher
/sbin/userdel ftp
/sbin/groupdel ftp
/sbin/userdel mail
/sbin/groupdel mail
/sbin/userdel xfs
/sbin/groupdel xfs
/sbin/userdel ntp
/sbin/groupdel ntp
/sbin/userdel mailnull
/sbin/groupdel mailnull
/sbin/userdel pcap
/sbin/groupdel pcap

Restrict su to sysadmin group

Another layer of protection is to prevent unprivileged users from being able to execute the su command, denying them the ability to become more powerful users.

The first step is to create a system administrators group. Only trusted system admins should be made members of this group.

/usr/sbin/groupadd sysadmin

Next, enter the following commands to restrict the su command to this group:

chgrp sysadmin /bin/su
chmod o-rwx /bin/su

Finally, make sure to add existing system admins to the sysadmin group. For each account execute the following:

/usr/sbin/usermod -g sysadmin username

Prevent root login through ssh

There is one very well known account that you can’t really get rid of: root. However, one measure you can take to prevent people from trying to access this account is to disallow login as root through ssh.

This is another very easy one to implement. All you need to do is edit the /etc/ssh/sshd_config, uncomment the PermitRootLogin line and set it to no.

su root
Enter root password
vi /etc/ssh/sshd_config

Change the line:

#PermitRootLogin yes

To:

PermitRootLogin no

Configure IP Access Controls with tcp_wrappers

TCP_Wrappers is a security framework used to enforce ip address access controls on services such as ssh and ftp. It is installed by default in RedHat and most linux/unix distros. It can be used two ways: you can deny specified ip address or you can restrict access to only allowed ip addresses. In the following example we will do the later.

There are two configuration files that control the access: /etc/hosts.allow and /etc/hosts.deny. As the names imply, hosts.allow lists ip addresses that are allowed, and hosts.deny lists ip addressses that are not allowed.

In the following example we will first configure the hosts.deny file to deny ALL, and then configure the hosts.allow file to only permit ssh for users on the 192.168.1 subnet.

su root
Enter root password
vi /etc/hosts.deny

add the line:

ALL: ALL

ESC:x! to save

vi /etc/hosts.allow

add the line:

sshd: 192.168.1

ESC:x! to save

Resource Limits

These settings will prevent users from consuming too many resources. These changes will have the following effects: file sized will be limited to 100 MB and users can have a maximum of 150 concurrent processes running.

su root
Enter root password
vi /etc/security/limits

Insert the following lines at the bottom of the file:
hard fsize 102400
hard nproc 150

set up Chroot Sftp on Red Hat Enterprise Linux 5

       How do I set up Chroot Sftp on Red Hat Enterprise Linux 5 ?

       How to setup sftp so that a specially-created ftp user can't get out of its home directory?

       How to setup sftp such that user can only access to his home directory and its subdirectories? It is called a "chroot-jail" in FTP terminology.

Environment

       Red Hat Enterprise Linux 5.4

       openssh-server-4.3p2-30.el5 or later

Resolution

Chroot sftp is possible with openssh (openssh-server-4.3p2-30.el5) which is shipped in Red Hat enterprise Linux 5.4. If you are using an older openssh version than this, upgrade it to openssh-server-4.3p2-30.el5 or later.

Below is a sample chroot sftp configuration :

   1.  Create a specific chrooted directory.

mkdir /chroot/home

   2.  Mount it to /home as follows:

mount -o bind /home /chroot/home

   3.  Edit /etc/ssh/sshd_config as follows:

ChrootDirectory /chroot

Subsystem sftp internal-sftp

Please ensure the directories of ChrootDirectory, "/chroot" in this example, are root owned directories and are not writable by any other user or group. This affects all users, however. There is no per-user configuration.

4. Save & Exit

service sshd restart

Please refer to sshd_config man page for details on ChrootDirectory

Notes

In RHEL5, Once sftp configured to use chroot, it will not allow users to login via normal ssh including root. A workaround is to run multiple copies of ssh server ( listening on different port/address) , one with the default configuration and another instance for chrooted sftp  or use RHEL 6 which includes a newer version of openssh that allows chroot environment on a per-user/group basis.

Configuring bonded devices on Red Hat Enterprise Linux 5

Introduction

Bonding (or channel bonding) is a technology enabled by the Linux kernal and Red Hat Enterprise Linux, that allows administrators to combine two or more network interfaces to form a single, logical "bonded" interface for redundancy or increased throughput. The behavior of the bonded interfaces depends upon the mode; generally speaking, modes provide either hot standby or load balancing services. Additionally, they may provide link-integrity monitoring.

This article describes the configuration methods of bonding on Red Hat Enterprise Linux 3, Red Hat Enterprise Linux  4 and Red Hat Enterprise Linux 5.

Configuring bonded devices on Red Hat Enterprise Linux 5

Single bonded device on RHEL5

 

To configure the bond0 device with the network interface eth0 and eth1, perform the following steps:

  1.   Add the following line to /etc/modprobe.conf:

alias bond0 bonding

  2.   Create the channel bonding interface file  ifcfg-bond0 in the /etc/sysconfig/network-scripts/ directory:

# cat /etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0
IPADDR=192.168.50.111
NETMASK=255.255.255.0
USERCTL=no
BOOTPROTO=none
ONBOOT=yes
BONDING_OPTS="mode=0 miimon=100"

Note:

       Configure the bonding parameters in the file /etc/sysconfig/network-scripts/ifcfg-bond0, as above, BONDING_OPTS="mode=0 miimon=100".

       The behavior of the bonded interfaces depends upon the mode. The mode 0 is the default value, which causes bonding to set all slaves of an active-backup bond to the same MAC address at enslavement time. For more information about the bonding modes, refer to The bonding modes supported in Red Hat Enterprise Linux.

  3.   Configure the ethernet interface in the file /etc/sysconfig/network-scripts/ifcfg-eth0.  Both eth0 and eth1 should look like the following example:

DEVICE=eth<N>
BOOTPROTO=none
HWADDR=54:52:00:26:90:fc
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no

Note:

       Replace <N> with the numerical value for the interface, such as 0 and 1 in this example. Replace the HWADDR value with the MAC for the interface.

       Red Hat suggest that configure the MAC address of the ethernet card into the file /etc/sysconfig/network-scripts/ifcfg-eth<N>.

  4.   Restart the network service:

# service network restart

  5.   In order to check the bonding status, check the following file:

# cat /proc/net/bonding/bond0

Multiple bonded device on RHEL5

In Red Hat Enterprise Linux 5.3 (or update to initscripts-8.45.25-1.el5) and later, configuring multiple bonding channels is similar to configuring a single bonding channel. Setup the ifcfg-bond<N> and ifcfg-eth<X> files as if there were only one bonding channel. You can specify different BONDING_OPTS for different bonding channels so that they can have different modes and other settings. Refer to the section 15.2.3. Channel Bonding Interfaces in the Red Hat Enterprise Linux 5 Deployment Guide for more information.

To configure the bond0 device with the ethernet interface eth0 and eth1, and configure the bond1 device with the Ethernet interface eth2 and eth3,  perform the following steps:

  1.   Add the following line to /etc/modprobe.conf:

alias bond0 bonding
alias bond1 bonding

  2.   Create the channel bonding interface files ifcfg-bond0 and ifcfg-bond1, in the /etc/sysconfig/network-scripts/ directory:

# cat /etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0
IPADDR=192.168.50.111
NETMASK=255.255.255.0
USERCTL=no
BOOTPROTO=none
ONBOOT=yes
BONDING_OPTS="mode=0 miimon=100"

# cat /etc/sysconfig/network-scripts/ifcfg-bond1
DEVICE=bond1
IPADDR=192.168.30.111
NETMASK=255.255.255.0
USERCTL=no
BOOTPROTO=none
ONBOOT=yes
BONDING_OPTS="mode=1 miimon=50"

Note: there are different bonding modes for bond0 and bond1. For the bond0 device, it is the balance-rr policy (mode=0).  For the bond1 device, it is the fail_over_mac policy (mode=1). More information about the bonding modes please refer to The bonding modes supported in Red Hat Enterprise Linux

   3.   Configure the ethernet interface in the file /etc/sysconfig/network-scripts/ifcfg-eth0.  Both eth0 and eth1 should look like the following example:

DEVICE=eth<N>
BOOTPROTO=none
HWADDR=54:52:00:26:90:fc
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no

Note:

       Replace <N> with the numerical value for the interface, such as 0 and 1 in this example. Replace the HWADDR value with the MAC for the interface.

       Red Hat suggest that configure the MAC address of the ethernet card into the file /etc/sysconfig/network-scripts/ifcfg-eth<N>.

  4.   Restart the network service:

# service network restart

  5.   In order to check the bonding status, check the following file:

# cat /proc/net/bonding/bond0

Configuring bonded devices on Red Hat Enterprise Linux 4

Single bonded device on RHEL4

For a detailed manual for bonding configuration on RHEL4 , please refer to,

     

To configure the bond0 device with the network interface eth0 and eth1, perform the following steps,

  1.   Add the following line to /etc/modprobe.conf,

alias bond0 bonding
options bonding mode=1 miimon=100

Note:

       Configure the bonding parameters in the file /etc/modprobe.conf. It is different from the configuration of RHEL5. The configuration on RHEL5 you configure all bonding parameters in the ifcfg-bond<x> by passing them in the BONDING_OPTS= variable, while in RHEL4 you need to pass those in the modprobe.conf using 'install'  syntax.

 

2.   Create the channel bonding interface file in the /etc/sysconfig/network-scripts/ directory, ifcfg-bond0

# cat /etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0
IPADDR=192.168.50.111
NETMASK=255.255.255.0
USERCTL=no
BOOTPROTO=none
ONBOOT=yes

3.   Configure the ethernet interface in the file /etc/sysconfig/network-scripts/ifcfg-eth<N>. In this example, both eth0 and eth1 should look like this:

DEVICE=eth<N>
BOOTPROTO=none
HWADDR=54:52:00:26:90:fc
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no

Note:

       Replace the <N> with the numerical value for the interface, such as 0 and 1 in this example. Replace the HWADDR value with the MAC for the interface.

       Red Hat suggest that you configure the MAC address of the ethernet card into the file /etc/sysconfig/network-scripts/ifcfg-eth<N>.

       The "54:52:00:26:90:fc" is the hardware address (MAC) of the Ethernet Card in the system.

Multiple bonded device on RHEL4

To configure multiple bonding channels on RHEL4, first set up the ifcfg-bond<N> and ifcfg-eth<X> files as you would for a single bonding channel, shown in the previous section.

Configuring multiple channels requires a different setup for /etc/modprobe.conf. If the two bonding channels have the same bonding options, such as bonding mode, monitoring frequency and so on, add the b option. For example:

alias bond0 bonding
alias bond1 bonding
options bonding max_bonds=2 mode=balance-rr miimon=100

If the two bonding channels have different bonding options (for example, one is using round-robin mode and one is using active-backup mode), the bonding modules have to load twice with different options. For example, in /etc/modprobe.conf:

install bond0 /sbin/modprobe --ignore-install bonding -o bonding0 mode=0 miimon=100 primary=eth0
install bond1 /sbin/modprobe --ignore-install bonding -o bonding1 mode=1 miimon=50 primary=eth2

If there are more bonding channels, add one install bond<N> /sbin/modprobe --ignore-install bonding -o bonding<N> options line per bonding channel.

Note: The use of -o bondingX to get different options for multiple bonds was not possible in Red Hat Enterprise Linux 4 GA and 4 Update 1.

After the file /etc/modprobe.conf is modified, restart the network service:

# service network restart

Configuring bonded devices on Red Hat Enterprise Linux 3

Single bonded device on RHEL3

To configure the bond0 device with the network interfaces eth0 and eth1, perform the following steps:

  1.   Add the following lines to /etc/modules.conf:

alias bond<N> bonding
options bonding  mode=1 miimon=100

Note: Replace the <N> with the numerical value for the interface, such as 0 in this example.

  2.   Create the channel bonding interface file ifcfg-bond0 in the /etc/sysconfig/network-scripts/ directory:

# cat /etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0
BOOTPROTO=none
ONBOOT=yes
NETMASK=255.255.255.0
IPADDR=192.168.122.225
USERCTL=no

3. Configure the ethernet interface /etc/sysconfig/network-scripts/ifcfg-eth<N>.  Both eth0 and eth1 should look like the following example:

# cat /etc/sysconfig/network-scripts/ifcfg-eth<N>
DEVICE=eth<N>
BOOTPROTO=none
HWADDR=54:52:00:26:90:fc
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no

Note:

       Replace the <N> with the numerical value for the interface, such as 0 and 1 in this example. Replace the HWADDR value with the MAC for the interface.

       Red Hat suggest that you configure the MAC address of the ethernet card into the file /etc/sysconfig/network-scripts/ifcfg-eth<N>.

4. Restart the network service:

# service network restart

Multiple bonded device on RHEL3

To configure multiple bonding channels on RHEL3, first set up the ifcfg-bond<N> and ifcfg-eth<X> files as you would for a single bonding channel, shown in the previous section.

Configuring multiple channels requires a different setup for /etc/modprobe.conf. If the two bonding channels have different bonding options (for example, one is using round-robin mode and one is using active-backup mode), the bonding modules have to load twice with different options. For example, in /etc/modules.conf:

alias bond0 bonding
options bond0 -o bond0 mode=1 miimon=100
alias bond1 bonding
options bond1 -o bond1 mode=0 miimon=50

After the file /etc/modules.conf is modified, restart the network service:

# service network restart

Configuring bonded devices on Red Hat Enterprise Linux 2.1

Red Hat does not provide the bonding support on Red Hat Enterprise Linux 2.1. Red Hat Enterprise Linux 2.1 is out of the Red Hat Enterprise Linux lifecycle. For more information refer to

Bonding modes on Red Hat Enterprise Linux

For information on the bonding modes supported in Red Hat Enterprise Linux, please refer to the kernel document /usr/share/doc/kernel-doc-{version}/Documentation/networking/bonding.txt
To read the kernel document, you will need to install the RPM package kernel-doc-version.rpm

Red Hat Enterprise Linux 5

Balance-rr (mode 0)

Round-robin policy: transmits packets in sequential order from the first available slave through the last.

       This mode provides load balancing and fault tolerance.

Active-backup (mode 1)

Active-backup policy: only one slave in the bond is active. A different slave becomes active only if the active slave fails. The bond's MAC address is externally visible on only one port (network adapter) to avoid confusing the switch.

In bonding version 2.6.2 or later, when a failover occurs in active-backup mode, bonding will issue one or more gratuitous ARPs on the newly active slave. One gratuitous ARP is issued for the bonding master interface and each VLAN interface configured above it, assuming that the interface has at least one IP address configured. Gratuitous ARPs issued for VLAN interfaces are tagged with the appropriate VLAN id.

       This mode provides fault tolerance.

       The primary option, affects the behavior of this mode.

Balance-xor (mode 2)

XOR policy: transmits based on the selected transmit hash policy. The default policy is a simple ((source MAC address XORd with destination MAC address) modulo slave count) . Alternate transmit policies may be selected via the xmit_hash_policy option, described below.

       This mode provides load balancing and fault tolerance.

Broadcast (mode 3)

Broadcast policy: transmits everything on all slave interfaces.

       This mode provides fault tolerance.

802.3ad (mode 4)

IEEE 802.3ad dynamic link aggregation: this mode creates aggregation groups that share the same speed and duplex settings, and uses all slaves in the active aggregator according to the 802.3ad specification. Slave selection for outgoing traffic is done according to the transmit hash policy, which may be changed from the default simple XOR policy via the xmit_hash_policy option, documented below. Note that not all transmit policies may be 802.3ad compliant, particularly with regard to the packet misordering requirements described in section 43.2.4 of the 802.3ad standard. Differing peer implementations will have varying tolerances for noncompliance.

Prerequisites:

       ethtool support in the base drivers for retrieving the speed and duplex of each slave

       a switch that supports IEEE 802.3ad Dynamic link aggregation.

       Most switches will require some type of configuration to enable 802.3ad mode.

Balance-tlb (mode 5)

Adaptive transmit load balancing: channel bonding that does not require any special switch support. The outgoing traffic is distributed according to the current load (computed relative to the speed) on each slave. Incoming traffic is received by the current slave. If the receiving slave fails, another slave takes over the MAC address of the failed receiving slave.

Prerequisite:

       ethtool support in the base drivers for retrieving the speed of each slave.

Balance-alb (mode 6)

Adaptive load balancing: includes balance-tlb and receive load balancing (rlb) for IPv4 traffic, and does not require any special switch support. The receive load balancing is achieved by ARP negotiation. The bonding driver intercepts the ARP replies sent by the local system on their way out and overwrites the source hardware address with the unique hardware address of one of the slaves in the bond, such that different peers use different hardware addresses for the server.

Receive traffic from connections created by the server is also balanced. When the local system sends an ARP request the bonding driver copies and saves the peer's IP information from the ARP packet. When the ARP reply arrives from the peer, its hardware address is retrieved and the bonding driver initiates an ARP reply to this peer assigning it to one of the slaves in the bond. A problematic outcome of using ARP negotiation for balancing is that each time that an ARP request is broadcast it uses the hardware address of the bond. Hence, peers learn the hardware address of the bond and the balancing of receive traffic collapses to the current slave. This is handled by sending updates (ARP Replies) to all the peers with their individually assigned hardware address such that the traffic is redistributed. Receive traffic is also redistributed when a new slave is added to the bond and when an inactive slave is reactivated. The receive load is distributed sequentially (round-robin) among the group of highest-speed slaves in the bond.

When a link is reconnected or a new slave joins the bond the receive traffic is redistributed among all active slaves in the bond by initiating ARP Replies with the selected MAC address to each of the clients. The updelay parameter (detailed below) must be set to a value equal or greater than the switch's forwarding delay so that the ARP Replies sent to the peers will not be blocked by the switch.

Prerequisites:

       ethtool support in the base drivers for retrieving the speed of each slave

       base driver support for setting the hardware address of a device while it is open. This is required so that there will always be one slave in the team using the bond hardware address (the curr_active_slave) while having a unique hardware address for each slave in the bond. If the curr_active_slave fails its hardware address is swapped with the new curr_active_slave that was chosen.

Red Hat Enterprise Linux 4

The bonding modes supported on RHEL4 is the same with the bonding modes on RHEL5. The detail please refer to the kernel documents, /usr/share/doc/kernel-doc-2.6.9/Documentation/networking/bonding.txt

Red Hat Enterprise Linux 3

Balance-rr (Mode 0)

Round-robin policy: transmits packets in sequential order from the first available slave through the last.

       This mode provides load balancing and fault tolerance.

Active-backup (Mode 1)

Active-backup policy: only one slave in the bond is active. A different slave becomes active if, and only if, the active slave fails. The bond's MAC address is externally visible on only one port (network adapter) to avoid confusing the switch.

In bonding version 2.6.2 or later, when a failover occurs in active-backup mode, bonding will issue one or more gratuitous ARPs on the newly active slave. One gratuitous ARP is issued for the bonding master interface and each VLAN interfaces configured above it, provided that the interface has at least one IP address configured. Gratuitous ARPs issued for VLAN interfaces are tagged with the appropriate VLAN id.

       This mode provides fault tolerance.

       The primary option, affects the behavior of this mode.

Balance-xor (Mode 2)

XOR policy: transmits based on the selected transmit hash policy. The default policy is a simple ((source MAC address XORd with destination MAC address) modulo slave count) . Alternate transmit policies may be selected via the xmit_hash_policy option, described below.

       This mode provides load balancing and fault tolerance.

Bonding parameters in general

It is critical that either the miimon or arp_interval and arp_ip_target parameters be specified, otherwise serious network degradation will occur during link failures. Very few devices do not support at least miimon, so it should always be used.

General bonding parameters

max_bonds: specifies the number of bonding devices to create for this instance of the bonding driver. For example, if max_bonds is 3, and the bonding driver is not already loaded, then bond0, bond1 and bond2 will be created. The default value is 1.

ARP monitoring parameters

       arp_interval: specifies the ARP link monitoring frequency in milliseconds.

       arp_ip_target: specifies the IP addresses to use as ARP-monitoring peers when arp_interval is > 0. Multiple IP addresses must be separated by a comma. At least one IP address must be given for ARP monitoring to function. The maximum number of targets that can be specified is 16.

       arp_validate: specifies whether or not ARP probes and replies should be validated in the active-backup mode. This causes the ARP monitor to examine the incoming ARP requests and replies, and only consider a slave to be up if it is receiving the appropriate ARP traffic. This parameter can have the following values:        

       none (0). This is the default.

       active (1). Validation is performed only for the active slave.

       backup (2). Validation is performed only for backup slaves.

       all (3). Validation is performed for all slaves.

For the active slave, the validation checks ARP replies to confirm that they were generated by an arp_ip_target.  Since backup slaves do not typically receive these replies, the validation performed for backup slaves is on the ARP request sent out via the active slave.  It is possible that some switch or network configurations may result in situations wherein the backup slaves do not receive the ARP requests; in such a situation, validation of backup slaves must be disabled.

MII monitoring parameters

       miimon: specifies the MII link monitoring frequency in milliseconds. This determines how often the link state of each slave is inspected for link failures. A value of 0 disables MII link monitoring. A value of 100 is a good starting point. The use_carrier option, listed below, affects how the link state is determined. The default value is 0.

       updelay: specifies the time, in milliseconds, to wait before enabling a slave after a link recovery has been detected.

       downdelay: specifies the time, in milliseconds, to wait before disabling a slave after a link failure has been detected.

       use_carrier: specifies whether or not miimon should use MII/ETHTOOL ioctls or netif_carrier_ok() to determine the link status. A value of 1 enables the use of netif_carrier_ok() (faster, better, but not always supported), a value of 0 will use the deprecated MII/ETHTOOL ioctls.  The default value is 1