Install NVIDIA Drivers in XEN Kernel

Install NVIDIA Drivers in XEN Kernel

Release:

RedHat Enterprise Linux

Problem:

Need to install Nvidia drivers in XEN Kernel

Solution:

1)Boot the Server to Runlevel 3

# init 3

2)Now copy the Nvidia driver to /tmp directory

# cp /mnt/NVIDIA-Linux-xxx-pkg2.run /tmp

3)Now extract the bin file and add modify to use the XEN kernel

           

# cd /tmp

# ./NVIDIA-Linux-xxx-pkg2.run extract-only

# cd  NVIDIA-Linux-xxx-pkg2/usr/src/nv

# IGNORE_XEN_PRESENCE=y make SYSSRC=/lib/modules/`uname -r`/build module

Note: Will get lot of Warnings, but end with NVIDIA: left KBUILD

4)Now load the new driver to the xen kernel library

# cp -i nvidia.ko /lib/modules/`uname -r`/kernel/drivers/video/nvidia

# depmod -a

# modprobe nvidia

5)Now check with lsmod weather nvidia driver is loaded or not

# lsmod | grep nvidia

6)Reboot the server and boot the server with nonxen kernel

# shutdown -r now

7)Now install the nvidia driver

# cd /tmp

# sh  NVIDIA-Linux-xxx-pkg2.run

8)Allow system to rewrite the “xorg.conf” file

9)Now reboot the server and boot to the xen kernel and check.

Add Verisign Trail Certificate to Tomcat Server

 

Add Verisign Trail Certificate to Tomcat Server

Release:

Apache Tomcat 5.5

Windows Enterprise Server 2003

JDK 1.3.1 or later

Problem:

Need to add Verisign Trial Certificate to Apache Tomcat Server

Solution:

Creating the CSR file:

1. Create a certificate keystore and private key by executing the below command

C:\Program Files\Java\jre1.5.0_12\bin>keytool -genkey -alias tomcat -keyalg RSA -keystore C:\keystore -keysize 2048

Enter keystore password:  sbs@123

What is your first and last name?

  [Unknown]: YOUR DOMAIN NAME

What is the name of your organizational unit?

  [Unknown]:  YOUR ORGANIZATION NAME

What is the name of your organization?

  [Unknown]:  YOUR ORGANIZATION NAME

What is the name of your City or Locality?

  [Unknown]:  CHENNAI

What is the name of your State or Province?

  [Unknown]:  TAMILNADU

What is the two-letter country code for this unit?

  [Unknown]:  IN

Is CN= DOMAIN NAME, OU= ORGANIZATION NAME, O= ORGANIZATION NAME, L=CHENNAI, ST=TAMILNADU, C=IN correct?

  [no]:  YES

Enter key password for

        (RETURN if same as keystore password):  sbs@123

2. Create a  CSR (Certificate Signing Request) using the below command

C:\Program Files\Java\jre1.5.0_12\bin>keytool -certreq -keyalg RSA -alias tomcat -file certreq.csr -keystore c:\keystore

Enter keystore password:  sbs@123

Note: The above command create a file in C drive in a name “certreq.csr”.

Enroll the CSR file:

3. To verify the CSR go to the below link and  check the status

https://ssl-tools.verisign.com/checker/

4. First time to start the enrollment go to the below link and create an account. If you have a login id, login to your account and submit the CSR to Verisign.

https://www.verisign.com/ssl/buy-ssl-certificates/index.html

Install CA Certificate:

5. After submitting your CSR, Verisign will send one mail with  the original certificate.

6. Copy the Primary Intermediate CA from the below link and save it in a notepad as “primary_inter.cer”, also import this to keystore

http://www.verisign.com/support/verisign-intermediate-ca/Trial_Secure_Server_Root/index.html

C:\Program Files\Java\jre1.5.0_12\bin>keytool -import -trustcacerts -alias root -keystore c:\keystore -file c:\primary_inter.cer

7. Copy the Secondary Intermediate CA from the below link and save it in a notepad as “secondary_inter.cer”, also import this to keystore

http://www.verisign.com/support/verisign-intermediate-ca/trial-secure-server-intermediate/index.html

C:\Program Files\Java\jre1.5.0_12\bin>keytool -import -trustcacerts -alias intermediate t -keystore c:\keystore -file c:\secondary_inter.cer

Install the SSL Certificate:

8. Copy and paste the Verisign send certificate to a notepad and save the file as “cert.cer”, also import the SSL Certificates

C:\Program Files\Java\jre1.5.0_12\bin>keytool -import –alias tomcat -keystore c:\keystore -trustcacerts -file c:\cert.cer

Edit server.xml to enable SSL in tomcat 5.5:

9. Open the server.xml using the notepad ( location: C:\Program Files\Apache Software Foundation\Tomcat 5.5\conf ) and edit the below

          

port="80" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" redirectPort="443" acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" />  

    

  

     maxThreads="150" minSpareThreads="25" maxSpareThreads="75"     enableLookups="false" disableUploadTimeout="true" acceptCount="100" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keystoreFile="c:\keystore" keystorePass="sbs@123"/>

10. Now restart the Tomcat application from “Services”  ( Run → services.msc ) and check the application.

Configure SFTP Server using chroot jail in Linux

Configure SFTP Server using chroot jail in Linux

Release:

RedHat Enterprise Linux

Openssh 5.6P1

Problem:

Configure the sftp-server on a per-user-basis (restrict users to their individual home directory) using chroot() jail in RedHat Enterprise Linux

Solution:

1)      Install the OpenSSH latest version that must support the chroot() function

2)      Configure Openssh to use its internal sftp subsystem by editing the sshd_config file

# vi /etc/ssh/sshd_config

Replace

Subsystem sftp /usr/local/libexec/sftp-server

by

Subsystem sftp internal-sftp

3)      Now configure the chroot() by using match rule, add the below entries in the end of the sshd_config file

# vi /etc/ssh/sshd_config

Match group sftponly

ChrootDirectory /home/%u

X11Forwarding no

AllowTcpForwarding no

ForceCommand internal-sftp

Note: Here %u represents username, that means all the users in the sftponly group home directories are chrooted. Also chroot directory must be owned by root.

4)      Add one new group named as sftponly

# groupadd sftponly

5)      Create a new user to use retricted sftp. First create a user's home directory after that add the user

# mkdir /home/test

# useradd -g sftponly test

# usermod -d / test

Note: In here, create a home directory as a root user, while adding the user one warning comes like this, "useradd: warning: the home directory already exists"

6)      Now test the configuration from client side

[root@server Desktop]# sftp test@192.168.1.7

Connecting to 192.168.1.7...

test@192.168.1.7's password:

sftp> ls

IN

sftp> cd IN

sftp> ls

sftp> mput 1.png

Uploading 1.png to /IN/1.png

1.png 100% 90KB 90.4KB/s 00:00

sftp> ls

1.png

sftp> bye

7)      Test the SFTP-Server function from the windows client use the “WinSCP” or “Filezilla”  

Configure vsftpd to use ssl encryption

configure vsftpd to use ssl encryption

 

Release:

RedHat Enterprise Linux 5.0

 

Problem:

Configure  ftp service to use the ssl encription in RhedHat Enterprise Linux 5.0

 

Solution:

 

1) Install the FTP server RPM using the below command

            # yum install vsftpd

 

2) Once installed, start the ftp service 

            # service vsftpd start

 

3) To use ssl encryption, ftp server requires a certificate. To Create a certificate use the below command

            # cd /etc/pki/tls/certs

     # make /etc/vsftpd/vsftpd.pem

 

4) Change the file permission of the certificate (give only access to root)

             # chmod 600 /etc/vsftpd/vsftpd.pem

 

5) Edit the FTP configuration file to use this certifiate

      # vi /etc/vsftpd/vsftpd.conf

        ssl_enable=YES

        allow_anon_ssl=yes

        force_local_data_ssl=NO

        force_local_logins_ssl=YES

        ssl_tlsv1=YES

        ssl_sslv2=NO

        ssl_sslv3=NO

        rsa_cert_file=/etc/vsftpd/vsftpd.pem

 

6) Restart the vsftpd daemon to make the changes take effect

               # service vsftpd restart

Note: Use a client that does support the ftps protocol, for Linux, gftp does this quite well, however it initially rejects self-signed server certificates. This can be fixed by disabling the "Verify SSL Peer" setting in options. When making connections, be sure to select the FTPS protocol.

                 

Cloning the Linux Machine through Network

Cloning the Linux Machine through Network

Release:

Redhat Enterprise Linux

CentOS

Fedora



Problem:

Ghosting the Linux server without third party software



Solution:

Assumption:

a) New server ipaddress 172.16.1.247

b) Running server ipaddress 172.16.1.248



In new machine side Configuration:



1) Booted into the rescue mode

2) Enable the networking option

3) Give the below command to make dd command listening to port 30 for input,

# nc -l -p 30
dd of=/dev/sda



In running server side configuration:



4) Dump the content of the disk to the target pc though port 30 using the following command,

# dd if=/dev/sda
nc 172.16.1.247 30



5) Then to check that traffic is flowing, on the source machine go to another terminal (ALT/F2) and dump the tcp data on the NIC (assuming it's eth0)

# tcpdump -tnli eth0 port 30



Note: Assuming that Network controller driver is available in default OS Kernel.

Shrink EXT3 partition Without Losing Data

Shrink EXT3 partition Without Losing Data

Release:


RedHat Enterprise Linux


Problem:


Resize the ext3 partition without losing data


Solution:


This article shows how to shrink the ext3 partition without losing data. This can be quite useful if you do not use LVM


Note: The partition that is to be resized must be unmounted when we do the resizing


Shrinking an ext3 Partition:


1) Check the disk usage of the server before proceeding


          # df –h


          Filesystem   Size       Used     Avail      Use%       Mounted on
          /dev/sda3    4.4G       2.4G     1.8G       58%          /
          /dev/sda1    99M        14M      80M        15%          /boot
          tmpfs       125M       0        125M        0%          /dev/shm


2) Boot the server into linux rescue mode


Note: If the partition you want to resize doesn't hold any system files, you can do everything from the original system; the steps are the same, just omit booting into rescue system


3) Run the filesystem-specific fsck on the filesystem.


               # fsck –n /dev/sda3


         e2fsck 1.39 (29-May-2006)
         /dev/sda3: clean, 115974/577152 files, 636274/1152640 blocks


4) Remove the journal from /dev/sda3, thus turning it into an ext2 partition


         # tune2fs -O ^has_journal /dev/sda3


         tune2fs 1.39 (29-May-2006)


5) Run fsck on the filesystem


         # e2fsck –f /dev/sda3


         e2fsck 1.39 (29-May-2006)
         Pass 1: Checking inodes, blocks, and sizes
         Pass 2: Checking directory structure
         Pass 3: Checking directory connectivity
         Pass 4: Checking reference counts
         Pass 5: Checking group summary information
         /dev/sda3: clean, 115974/577152 files (0.5% non-contiguous), 636274/1152640 blocks


6) Now resize the filesystem using resize2fs. resize2fs can resize ext2 file systems, but not ext3 file systems


         # resize2fs /dev/sda1 3600M


         resize2fs 1.39 (29-May-2006)
         Resizing the filesystem on /dev/sda3 to 921600 (4k) blocks.
         The filesystem on /dev/sda3 is now 921600 blocks long.


Please take note of the amount of blocks (921600) and their size (4k).


Note: Currently, 2.3 GB are used on /dev/sda3 (see the df -h output above), so it's safe to shrink it from 4.4GB to about 3.6GB (if you make it smaller than 2.3GB, you will lose data!).


7) Now we delete our /dev/sda1 partition (don't be afraid, no data will be lost) and create a new, smaller one (but still big enough to hold our resized file system!).


        # fdisk /dev/sda


        Command (m for help): d
        Partition number (1-4): 3
        Command (m for help): n
        Command action
        l logical (5 or over)
        p primary partition (1-4)
        p
        Partition number (1-4): 3
        First cylinder (79-652, default 79):
        Using default value 79
        Last cylinder or +size or +sizeM or +sizeK (79-652, default 652): +3870720K


        Command (m for help): w
        The partition table has been altered!
        Calling ioctl() to re-read partition table.
        Syncing disks.


Note: We multiply the amount of blocks from the resize2fs output (921600) by the size of a block (4k), and to go sure the partition is big enough, we add 3 to 5% to it (5% was enough for me, but if you want to go sure take 3%)


                   921600 * 4k * 1.05 = 3870720k


8) Now restart the server once and boot into the rescue mode once again


        # exit


9) Once again run the filesystem-specific fsck on the filesystem


        # fsck –n /dev/sda3


        fsck 1.39 (29-May-2006)
        e2fsck 1.39 (29-May-2006)
        /dev/sda3: clean, 115962/464928 files, 599592/921600 blocks


10) Now create the journal on our new /dev/sda3, thus turning it into an ext3 partition again


        # tune2fs -j /dev/sda3


        tune2fs 1.39 (29-May-2006)
        Creating journal inode: done
        This filesystem will be automatically checked every 25 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override.


11) Now restart the server and boot from the harddisk.


        # exit

Sync Data between Two Servers

Sync Data between Two Servers




Release:



RedHat Enterprise Linux



Problem:



Sync the data between two linux servers



Solution:



Assumption:

a) Source server ip address: 192.168.0.151

b) Destination server ip address: 192.168.0.152



Source server - The server we are connecting from to upload the data

Destination server - The server we are connecting to receive the data



Setting the SSH key authentication:


1) Make sure the Destination server have the ability to use key authentication enabled. In the sshd configuration file (usually ‘/etc/ssh/sshd_config’) enable the following options if they are not already set.

# vi /etc/ssh/sshd.conf

RSAAuthentication yes

PubkeyAuthentication yes

AuthorizedKeysFile .ssh/authorized_keys



2) In Source server create the public / private key pair to used for authentication with the following command

# ssh-keygen -t rsa



Note: Do not enter a passphrase for this, just hit enter when prompted.

3) Now two files (public and private key) are created in the home directory of the user. If you are execute this as a root user means the files will be in,

# /root/.ssh/id_rsa.pub (public key file)

#/root/.ssh/id_rsa (private key file)



4) Now upload the public key to the Destination Server

# scp /root/.ssh/id_rsa.pub 192.168.0.152:/root/.ssh



Note: Be sure to keep this private key safe. With it anyone will be able to connect to the Destination Server that contains the public key.



5) In the Destination Server rename the public key file ( id_rsa.pub) to “authorized_keys”

# cd /root/.ssh

# mv id_rsa.pub authorized_keys



6) Change the file permission of that public key as well as ssh folder permission also

# chmod 600 /root/.ssh/authorized_keys

# chmod 700 /root/.ssh



7) Test the keys are working or not , by connecting the Destination Server from the Source Server

# ssh root@192.168.0.152



If all is working it should not be prompted for a password but instead connected directly to a shell on the Destination Server.





Creating rsync script:



8) Create one simple rsync script to sync both the servers and place it into the user’s home directory

# vi /root/rsync.sh

#!/bin/bash

SOURCEPATH=’/home’

DESTPATH=’/home’

DESTHOST=’192.168.0.152′

DESTUSER=’root’

LOGFILE=’rsync.log’

echo $’\n\n’ >> $LOGFILE

rsync -av –rsh=ssh $SOURCEPATH \ $DESTUSER@$DESTHOST:$DESTPATH 2>&1 >> $LOGFILE

echo “Completed at: `/bin/date`” >> $LOGFILE



Note: In this script 4 variables are used

SOURCEPATH - Source path to be synced

DESTPATH - Destination path to be synced

DESTHOST - Destination IP address or host name

DESTUSER - User on the destination server

The script will send all output to the ‘rsync.log’ file specified in the script



9) Give the executable permission for this script

# chmod 700 /root/rsync.sh



10) Now run the script and check, it is connect to the Destination Server, and transfer the files all without your interaction.



Setting up the cron job:



11) Setup a cron job to run the script automatically at a predefined interval.

# crontab –e



0 * * * * /root/rsync.sh



This will run the script once in every hour. Your 2 servers should now be syncing the chosen directory once every hour.

Migrating Redhat XEN Virtual Machine to VMware 1.x

Migrating Redhat XEN Virtual Machine to VMware 1.x


Release:

RedHat Enterprise Linux

VMware 1.x


Problem:

Migrating Redhat Xen virtual machine to VMware Server 1.x


Solution:

Note: Only “Fully Virtualized” Xen virtual machines are able to be migrated to VMware

Configuration changes to be done on Xen virtual machine:

1) Modify /etc/modprobe.conf to add the proper SCSI and network card modules which are configured in Vmware Server.

# vi /etc/modprobe.conf

alias eth0 pcnet32

alias scsi_hostadapter mptbase

alias scsi_hostadapter1 mptspi

alias scsi_hostadapter2 ata_piix

Note: Once modified the kernel modules, you won’t be able to properly start the machine, and you will receive a Kernel panic error message.


Convert VM migration disk:

          To convert a XEN machine in a .vmdk format to be used with VMware, a tool called qemu will be used. QEMU is a generic and open source machine emulator and virtualizer. It is also a fast processor emulator using dynamic translation to achieve good emulation speed.


2) Download qemu from the below link

http://dag.wieers.com/rpm/packages/qemu/


3) Install the downloaded RPM

# rpm –ivh qemu-0.12.4-1.el5.rf.i386.rpm


4) Convert the XEN machine disk to VMware disk

# qemu-img convert -O vmdk


5) Now we have a valid VMware Server 1.xx disk device file. This can be added on onto any VMware Server.


6) Create a new virtual machine. Under Hard disk configuration, select “use existing hard disk”.


Note: If the storage controller and network controllers are not integrated in /etc/modprobe.conf, system might refuse to boot. Hence, it is mandatory to add necessary links to driver modules.

Migrate user accounts from old Linux server to new Linux server

Migrate user accounts from old Linux server to new Linux server

Release:

RedHat Enterprise Linux

 

Problem:

Migrate user accounts from old Linux server to new Linux server

 

Solution:

The below procedure explains how to migrate users from old Linux server to new fresh installation.

 

Required files and directories:

            The following files and directories are required for Linux user account management

/etc/passwd – Contains various information about each user account

/etc/shadow – Contains the encrypted password information for user’s accounts

/etc/group – Defines the groups to which users belong

/etc/gshadow - group shadow file (contains the encrypted password for group)

/var/spool/mail – Generally user emails are stored here

/home – All users home directory and data is stored here

All these files and directories are need to copy from old server to new server.

 

Assumptions:

a)      Users that are added to the Linux system always start with UID and GID values of as specified by Linux distribution or set by admin. In RHEL default is 500 and maximum limit is 65534.

 

b)      The home directory of all the users is kept in /home. If there are different locations, it is mandatory to take separate backup of each location.

c)       There are enough space in /migrate file system to hold the backup of user’s directories.

 

Old Server side Configuration:

 

1)      Create a tar ball of the users home directory and mails

# mkdir /migrate

# cd /migrate

# tar –czvpf home.tar.gz /home

# tar –czvpf mail.tar.gz /var/spool/mail

 

2)      Now copy all the required user account management files from the old server

# export UGIDLIMIT=500

 

# awk –v LIMIT=$UGIDLIMIT –F: ‘($3>=LIMIT) && \               ($3!=655354)’ /etc/passwd > /migrate/passwd.old

 

# awk –v LIMIT=$UGIDLIMIT –F: ‘($3>=LIMIT) && \ ($3!=655354)’ /etc/group > /migrate/group.old

 

# awk –v LIMIT=$UGIDLIMIT –F: ‘($3>=LIMIT) && ($3!=65534) \ {print $1}’ /etc/passwd | tee - | egrep –f - /etc/shadow \ > /migrate/shadow.old

 

# cp /etc/gshadow /migrate/gshadow.old

 

The above three commands to extract only normal user details from /etc/passwd, /etc/group,  /etc/shadow and /etc/gshadow from UID/GUID from 500 (Refer the assumptions).

 

3)      Copy all the files inside the /migrate to the new server using scp or pendrive

 

New Server side Configuration:

 

4)      Take the backup of the user account management files in the new server

# mkdir /backup

# cp /etc/passwd /etc/group /etc/shadow /etc/gshadow /backup

 

5)      Copy all the files copied from the old server in new server within /new directory

# mkdir /new

# cd /new

 

6)      Now restore all the files

# cat passwd.old >> /etc/passwd

# cat group.old >> /etc/group

# cat shadow.old >> /etc/shadow

# cp gshadow.old /etc/gshadow

# chmod 0400 /etc/gshadow

# chown root:root /etc/gshadow

 

7)      Now copy and extract the users home directory and mail backups

# cd /

# tar –zxvf /new/home.tar.gz

# tar –zxvf /new/mail.tar.gz

 

8)      Reboot the server and check

# init 6

 

 

 

 

Mirroring Partitions after Installing RHEL

Mirroring Partitions after Installing RHEL

Release:

RedHat Enterprise Linux Server 3.x, 4.x & 5.x

Problem:

Configuring software mirroring in RHEL after OS installation.

Solution:

1)      On the second disk create partitions exactly the same size as those on the first disk, and set the type as fd (Linux raid autodetect).

# sfdisk -d -f /dev/sda > mirror

# sfdisk /dev/sdb < mirror

# fdisk /dev/sdb

Command (m for help): t

Partition number (1-4): 1

Hex code (type L to list codes): fd

Changed system type of partition 1 to fd (Linux raid autodetect)

Command (m for help): t

Partition number (1-4): 2

Hex code (type L to list codes): fd

Changed system type of partition 2 to fd (Linux raid autodetect)

Command (m for help): t

Partition number (1-4): 3

Hex code (type L to list codes): fd

Changed system type of partition 3 to fd (Linux raid autodetect)

Command (m for help): w

The partition table has been altered!

Calling ioctl() to re-read partition table.

Syncing disks.

# partprobe /dev/sdb

2)      Create the raid devices in a degenerated state (i.e. one disk missing).

#mknod /dev/md1 b 9 1

#mknod /dev/md2 b 9 2

#mdadm –C /dev/md0 –l 1 –n 2 missing /dev/sdb1

#mdadm –C /dev/md1 –l 1 –n 2 missing /dev/sdb2

#mdadm –C /dev/md2 –l 1 –n 2 missing /dev/sdb3

3)      Create a filesystem on the new software raid devices

# mke2fs –j /dev/md0

#mke2fs –j /dev/md1

#mkswap /dev/md2

4)      Rebuild the initrd image to include the software RAID kernel modules

# mkinitrd -f /boot/initrd-`uname -r`.img `uname -r`

5)      Move the data from our existing partitions to the software partitions

# mkdir /mnt/md0

# mount /dev/md0 /mnt/md0

#cp  –axu /boot/* /mnt/md0

#sync

#umount /mnt/md0

# mkdir /mnt/md1

# mount /dev/md1 /mnt/md1

#cp  –axu / /mnt/md1

6)      Now the raid devices are created and the existing data have been manually copied to the new disk. Now fstab within the RAID Devices have to be edited for the new changes in RAID meta devices. Edit the /mnt/md2/etc/fstab file so the system can boot from the new raid devices. In the fstab file change the line for the boot and root file system

Content as follows before editing:

LABEL=/           /     ext3  defaults          1 1

LABEL=/boot       /boot ext3  defaults          1 2

LABEL=SWAP-sda3   swap  swap  defaults          0 0

Content as follows after editing:

/dev/md1          /     ext3  defaults          1 1

/dev/md0          /boot ext3  defaults          1 2

/dev/md2          swap  swap  defaults          0 0

7)      Finally, edit the /boot/grub/grub.conf file

In “HDD” line change root (hd0,0) to root (hd1,0)

In the “kernel" line change root=LABEL=/ to root=/dev/md2.

8)      Reboot the system

# init 6

9)      Add the existing partitions (/dev/sda) to the RAID devices

# fdisk /dev/sda

Command (m for help): t

Partition number (1-4): 1

Hex code (type L to list codes): fd

Changed system type of partition 1 to fd (Linux raid autodetect)

Command (m for help): t

Partition number (1-4): 2

Hex code (type L to list codes): fd

Changed system type of partition 2 to fd (Linux raid autodetect)

Command (m for help): t

Partition number (1-4): 3

Hex code (type L to list codes): fd

Changed system type of partition 3 to fd (Linux raid autodetect)

Command (m for help): w

The partition table has been altered!

Calling ioctl() to re-read partition table.

Syncing disks.

# partprobe /dev/sda

10)  Now, add the existing partitions to the RAID array

# mdadm -a /dev/md0 /dev/sda1

# mdadm -a /dev/md1 /dev/sda2

# mdadm -a /dev/md2 /dev/sda3

11)  To see if the array is rebuilding, run the following command

# watch -n 2 cat /proc/mdstat

Every 2.0s: cat /proc/mdstat                                                 Tue Aug  3 07:45:37 2010

Personalities : [raid1]

md0 : active raid1 sda1[0] sdb1[1]

      104320 blocks [2/2] [UU]

md1 : active raid1 sda2[0] sdb2[1]

      4610560 blocks [2/1] [_U]

      [============>........]  recovery = 61.8% (2853760/4610560) finish=1.1min speed=26390K/sec

md2 : active raid1 sda3[2] sdb3[1]

      522048 blocks [2/2] [UU]

unused devices:

12)  After reboot, RAID status can be confirmed or monitored by following commands,

a.    cat /proc/mdstat

b.    mdadm –D /dev/md0 /dev/md1 /dev/md2