Reinstall GRUB Bootloader on md0

After a power outage, an RHEL 4 server was stuck with nothing on the screen but "GRUB" at the top left. Rebooting had the same result. My bootloader was toast.

I put in the RHEL 4 install disc, and at the boot prompt selected the rescue option.

boot: linux rescue

Once the rescue image booted, scanned the system and mounted read/write, I attempted to reinstall grub:

# chroot /mnt/sysimage/
# grub-install /dev/sda
/dev/md0 does not have any corresponding BIOS drive
# grub-install --recheck /dev/sda
/dev/md0 does not have any corresponding BIOS drive
#
An error. The md0 mirror, which is composed of sda and sdb, was complicating things. I though maybe I could fudge the device map by adding an entry to /boot/grub/device.map:

(fd0)   /dev/fd0
(hd0)   /dev/sda
(hd1)   /dev/sdb
(hd2)   /dev/md0

# grub-install /dev/sda
The file /boot/grub/stage1 not read correctly.
Fixed. I then also installed the bootloader on sdb (hd1), just in case.
That was no good either. Finally, I had to run grub manually.
# grub
grub> root (hd0,0)        
root (hd0,0)
 Filesystem type is ext2fs, partition type 0xfd
grub> setup (hd0)
setup (hd0)
 Checking if "/boot/grub/stage1" exists... no
 Checking if "/grub/stage1" exists... yes
 Checking if "/grub/stage2" exists... yes
 Checking if "/grub/e2fs_stage1_5" exists... yes
 Running "embed /grub/e2fs_stage1_5 (hd0)"...  16 sectors are embedded.
succeeded
 Running "install /grub/stage1 (hd0) (hd0)1+16 p (hd0,0)/grub/stage2 /grub/grub.conf"... succeeded
Done.
grub> quit
# reboot

Fixed. I then also installed the bootloader on sdb (hd1), just in case.

Setting up a new LAN CARD (Ethernet) network device

If you added a new network device, but upon reboot, CentOS did not represent the card in the /etc/sysconfig/network-scripts/ifcfg-eth*, you may have to manually make aware the device to the OS. 

Step 1: Make sure that the OS has detected the new card. From the example below, it detected my 2nd card. If you are unable to detect, you may want to reinstall or check the driver.

#  lspci |grep -i ethernet
   0b:00.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
   14:00.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)

Step 2: Launch the system-config-network and fill up the necessary information.
# system-config-network
You will see that the system-config-network create an entry at /etc/sysconfig/network-scripts/ifcfg-eth1.
Restart the network
# service network restart

How DNS Works (Domain Name System)

In any network, the hosts primarily communicate between each other through IP addresses. For example, if my computer is doing a google search, my computer is actually communicating with the IP address of one of the web servers of google.com. However, even if the computer is efficient with numbers, humans on the other hand work better with names. For this reason, the TCP/IP protocol includes the Domain Name System (DNS)  to link between IPs and computer names i.e. hostnames. The DNS is a distributed database of computers that is responsible for resolving hostnames against IP addresses and vice-versa.

Any DNS query involves two parts.
The Resolver: The resolver forms up or initiates the query. The resolver itself does not run as a program. /etc/resolv.conf is an example of a resolver.
Name Server: The Name Server is the service running in the server that responds to the DNS query generated by the resolver i.e. answers to the question of the resolver.

Fully Qualified Domain Name

The fully qulified domain name is the full name of any server. Just like any human needs a full name in the real world, every server on the Internet also need a full name to work. The structure of a FQDN- host.domain.tld. For example, in www.qwe.net “www” is the hostname of the web server, “qwe” is the name of the domain and “net” is the top level domain (TLD). Other examples of TLD are .com, .in,.net, .org, .gov,.oc.in, .mil and so on.

The Root-Servers

As mentioned earlier, the DNS works as a distributed database. If a DNS server does not know the answer to a query, it forwards the query to another server upper in the hierarchy. The query keeps going upwards until it reaches the root. There are 13 root servers responsible for all DNS in the world. The root servers are named as a.root-servers.net to m.root-servers.net. These root servers continuously keep communicating with each other and update each other about what they know. Here is an interesting article about the root DNS server numbers: http://blog.icann.org/2007/11/there-are-not-13-root-servers/

Authoritative Name Servers

The authoritative name servers are servers that are responsible for a domain. For example, if we host the DNS for a domain qwe.net, then the domain requires at least 2 authoritative DNS servers i.e. ns1.qwe.net & ns2.qwe.net.

These two authoritative DNS servers are responsible for any DNS query about the qwe.net domain and should be able to answer any query regarding this domain. The root servers store only the records for the authoritative name servers for different domains.

How DNS Works

I found this step-by-step image in the web, and thought it's worth sharing. Here is the link to the full article- http://www.communityguy.ca/resources/cira-2009-elections-and-an-overview-of-how-dns-works/

How DNS works (Reference)

And now for the step-by-step analysis.

The client initiates a query to find techsmb.ca. The client sends the query to the DNS server of the ISP. (The DNS Server IP in the client computer is set as the IP address of the DNS Server of the ISP)
The DNS Server of the ISP first checks it's own cache to check whether it already knows the answer. But as the answer is not present, it generates another query. As the TLD of techsmb.ca is .ca, so the DNS server queries CIRA to find who is responsible for techsmb.ca.

The CIRA responds to the ISP by answering the query.

Once the ISP DNS Server knows the authoritative name servers, it contacts the authoritative name servers to find out the IP address for www.techsmb.ca. i.e. the IP address of host www in the domain techsmb.ca.
techsmb.ca responds to the ISP DNS Server by answering the query and providing the IP address of the web server i.e. www
The ISP DNS Server stores the answer in it's cache for future use and answers to the client by sending the IP address of the www server.
The client may store the answer to the DNS query in it's own cache for future use. Then the client communicates directly with the www server of domain techsmb.ca using the IP address.
The www server responds by sending the index.html page.

Reducing.. Kernel Page cache, Inode and dentry caches.

Kernel 2.6 never provide a mechanism to have the kernel drop the page cache and/or inode and dentry caches on command, which can help free up a lot of memory.

Writing to this will cause the kernel to drop clean caches, dentries and inodes from memory, causing that memory to become free.

To free pagecache:
#  echo 1 > /proc/sys/vm/drop_caches

To free dentries and inodes:
#  echo 2 > /proc/sys/vm/drop_caches

To free pagecache, dentries and inodes:
#  echo 3 > /proc/sys/vm/drop_caches

As this is a non-destructive operation, and dirty objects are not free-able, the user should run "sync" first in order to make sure all cached objects are freed.

How to speed up SSH login?

Whenever I login to my Centos Server using SSH, it takes about 6 seconds for me to get the prompt for password, however when I login to my web hosting server it takes about 1 second. What can I do to speed this up?

If you run a lot of terminal tabs or scripts that all need to make OpenSSH connections to the same server, you can speed them all up with multiplexing: making the first one act as the master and letting the others share its TCP connection to the server.

If you don't already have a config file in the .ssh directory in your home directory, create it with permissions 600: readable and writeable only by you.
Speed up SSH 

Step 1 -Add below to /etc/ssh/sshd_config

The number one reason I've seen for this is a configuration option in SSHD UseDNS this option (enabled by default) causes the server to perform DNS resolution on the incoming requests. A time consuming operation. I've seen logins go from one minute plus waiting for password 

#  vi /etc/ssh/sshd_config

UseDNS no

Step 2- Setting up ssh client with compression 

#  vi /etc/ssh/ssh_config

Host *
Ciphers arcfour,blowfish-cbc
Compression yes
AddressFamily inet
ControlMaster auto
ControlPath ~/.ssh/socket-%r@%h:%p

Save and exit !
Step 3- Restart the SSH daemon with service sshd restart

You should see an improvement next time you connect.