Shell Script to create mirrors of Physical Volumes

#!/bin/sh
#******* DISK:
# create LVM mirrors for VolGroup
for x in `ls /dev/VolGroup`; do
        lvconvert -m 1 /dev/VolGroup/$x `pvdisplay | grep "PV Name" | awk '{printf $3" "}'` &
        if [ $? -ne 0 ]; then logError DISK: $x; fi
done

Server is not coming up after we patched and rebooted it

We have a RHEL 6 (64 bits) Virtual Machine in vSphere 5.0. Today when we rebooted the server after Linux patching the server could not come up and following message is showing on the screen:

/dev/fd/8: 8: Syntax Error: Bad fd number
/dev/fd/8: 1: Syntax Error: Bad fd number
init: readahead-collector main process(364) terminated with status 2
init: rcS pre-start process(365) terminated  with status 2
init: readahead main process(366) terminated with status 2
init: readahead-collector post process(367) terminated with status 2
/dev/fd/8: 11: Syntax Error: Bad fd number
init: rcS post-stop process(368) terminated with status 2
init: readahead-disable-services main process(369) terminated with status 2.

The screen is stuck with this message and the server is not coming up.

To resolve the issue we have restored the server from backup. 

hpacucli is not getting installed through yum install

We have our red Hat satellite server and all other servers are getting patched with these satellite servers on regular basis. But today when i tried to install hpacucli i am getting the following message:

root@lxe1129 [~] # yum install hpacucli
Loaded plugins: product-id, rhnplugin, security, subscription-manager
This system is receiving updates from RHN Classic or RHN Satellite.
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package hpacucli.x86_64 0:9.40-12.0 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package Arch Version Repository Size
================================================================================
Installing:
 hpacucli x86_64 9.40-12.0 prod-hp-sys-tools 6.5 M

Transaction Summary
================================================================================
Install 1 Package(s)

Total download size: 6.5 M
Installed size: 0
Is this ok [y/N]: y
Downloading Packages:
hpacucli-9.40-12.0.x86_64.rpm | 6.5 MB 00:00
warning: rpmts_HdrFromFdno: Header V3 DSA/SHA1 Signature, key ID 2689b887: NOKEY

Public key for hpacucli-9.40-12.0.x86_64.rpm is not installed

And after that when i checked with rpm -qa | grep hpacucli, it is not showing any output. 

Resolution:
For installing these software from HP we need to download the rpm package from HP site. And then do rpm -ivh.

We have downloaded the following packages:
hpacucli-9.20-9.0.x86_64.rpm
hp-ams-1.2.0-781.36.rhel5.x86_64.rpm
hp-health-9.20-1528.19.rhel5.x86_64.rpm
hp-snmp-agents-9.20-2350.17.rhel5.x86_64.rpm

and made the following script to install them:

for PKG in `ls *.rpm`
do
rpm -ivh $PKG
done

# Disable HP ASR
hpasmcli -s "disable asr"

What is Backporting Security fixes in RHEL

Recently while the whole Unix world was shocked by the Shell Shock bug in bash , like everyone we were also scheduled to patch our servers(all of those having RHEL 5.6 Tikanga installed). We upgrade the bash through the following command:

rpm -U bash-3.2-33.el5_11.4.x86_64.rpm

And then we checked whether the new package is get installed or not through the following command:

rpm -qa | grep bash

This one confirmed that new bash package i.e  bash-3.2-33.el5_11.4.x86_64.rpm is get installed. But when we run the following command it was still showing the older version installed:

bash --version

GNU bash, version 3.2.25(1)-release (x86_64-redhat-linux-gnu)

Copyright (C) 2005 Free Software Foundation, Inc.

Then i found that on the Red Hat Site that is a default behavior of RHEL OS. This phenomenon is called  Backporting Security fixes.

Backporting can be described as follows:

When a security flaw is fixed in the  most recent version of an upstream software package and that fix get applied to an older version of the package we distribute it is called Backporting Security Fix.

So the software version will not change but the changes made in the recent version would get integrated in the older version through upgrade and thus make it vulnerable free.

Installing Apache through tar ball

Installation of httpd 2.4.9

I got the tar ball of the mentioned version of apache from the httpd site. After untrar the file when i run the ./configure file i got the following message with an error:
root@vikash-Vostro-2520:/home/vikash/httpd-2.4.9# ./configure
checking for chosen layout... Apache
checking for working mkdir -p... yes
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
configure:
configure: Configuring Apache Portable Runtime library...
configure:
checking for APR... no
configure: error: APR not found.  Please read the documentation.

Then i read in  the install file that we need to put the path where we want the apache to be installed while running the configure command, the command should be run like this:
./configure --prefix=/usr/local/apache2
But running this also gives me the same error.


From Wiki:

The Apache Portable Runtime (APR) is a supporting library for the Apache web server. It provides a set of APIs that map to the underlying operating system (OS). Where the OS does not support a particular function, APR will provide an emulation. Thus programmers can use the APR to make a program truly portable across platforms.

APR originally formed a part of Apache HTTP Server, but the Apache Software Foundation spun it off into a separate project. Other applications can use it to achieve platform independence.

The range of platform-independent functionality provided by APR includes:

• Memory allocation and memory pool functionality
• Atomic operations
• Dynamic library handling
• File I/O
• Command-argument parsing
• Locking
• Hash tables and arrays
• Mmap functionality
• Network sockets and protocols
• Thread, process and mutex functionality
• Shared memory functionality
• Time routines
• User and group ID services

Even after installing Apache Portable Runtime Library, i was getting the same error.

Then i install APR and APR-util and again tried to run the configure utility to install apache this time it stuck due to unavailabiilty of  

root@vikash-Vostro-2520:/home/vikash/httpd-2.4.9# ./configure --prefix=/usr/local/apache2 --with-apr=/usr/local/apache2 --with-apr-util=/usr/local/apache2
checking for chosen layout... Apache
checking for working mkdir -p... yes
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
configure: 
configure: Configuring Apache Portable Runtime library...
configure: 
checking for APR... yes
  setting CC to "gcc"
  setting CPP to "gcc -E"
  setting CFLAGS to " -g -O2 -pthread"
  setting CPPFLAGS to " -DLINUX -D_REENTRANT -D_GNU_SOURCE"
  setting LDFLAGS to " "
configure: 
configure: Configuring Apache Portable Runtime Utility library...
configure: 
checking for APR-util... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -E
checking for gcc option to accept ISO C99... -std=gnu99
checking for pcre-config... false

configure: error: pcre-config for libpcre not found. PCRE is required and available from http://pcre.org/

The PCRE(Perl Compatible Regular Expressions) library is a set of functions that implement regular expression pattern matching using the same syntax and semantics as Perl 5. PCRE has its own native API, as well as a set of wrapper functions that correspond to the POSIX regular expression API. The PCRE library is free, even for building proprietary software.

After the installation of PCRE, apache was installed completely through the following commands:

i. ./configure --prefix=/usr/local/apache2 --with-apr=/usr/local/apache2 --with-apr-util=/usr/local/apache2 --with-pcre=/usr/local/pcre

ii. make

iii. make install

When you miss that common thing: The php configuration

I do not remember how many times in last five years i have decided to learn LAMP and made all the configuration and after few days/week i lost the track.

This time i have started it all over again on my Ubuntu 12, with the Apache 2.2.22, MySQL 5.5.31 and PHP 5.4.6.

I have completed the installation of all the four components of the LAMP and started to run my first php script. Yes that legendary "Hello World", but i could not able to show anything on my mozilla firefox browser.

Then after few days i open the pdf which i am referring for the LAMP study and started it from the first page. Under the chapter which contains the installation and configuration of php i have found the following line of code which needs to be added in the apache configuration file. So i have opened my apache2.conf file which lies in /etc/apache2  and added the following line of code and restarted the apache.

AddType application/x-httpd-php .php

This statement will ensure that the php engine will parse the file that end with .php extension. The AddType directive binds a MIME type to a particular extension or extensions,

Linux Boot Process

The linux boot process can be divided in the following steps:

1) System Start up(BIOS/Boot Monitor)
2) Stage 1 Bootloader (MBR)
3) Stage 2 Bootloader (LILO, GRUB etc)
4) Kernel (Linux)
5) Init (User-Space)


1) System Start Up 

The process of system start up depends on the hardware on which the Linux is being booted. Booting process starts in the BIOS at the address 0xFFFF0. 

There are two sub-components of BIOS: 

                                                                       a) POST code

                                                                        b) Runtime Services

First the POST code check the hardware (RAM, CPUs,Video Card, Hard Drive and other Mother Board Components). After the POST is done it is flushed from the memory. But the runtime services remain there and searches for devices that are both active and bootable and it searches in order of the preference defined by CMOS(Complimentary Metal Oxide Semiconductor) settings.  MBR which resides in the HDD contains the primary bootloader getting loaded in the RAM and then BIOS yields the control to it.

3) MBR: 
Master Boot Recorder is of 512 bytes where the first 446 bytes contains the information of the boot loaded, the next 64 bytes contains the information of the
partition tables and the last 2 bytes are used for the validation check of the MBR. MBR which has the information of the primary boot loader i.e. GRUB load and executes the GRUB.

4) Kernel

Kernel image which get loaded is in compressed form. At the head of this kernel image there is routine that does some hardware set up and then decompressed the kernel and place it in the high memory. If initrd is present this routine moves the initrd in to memory and notes it for later use. The routine then calls the kernel and  kernel boot begins. During the boot of the kernel, the initial RAM disk that is loaded in to the memory is copied in to the memory and then mounted. The initrd serves as a temporary root file system in RAM and allows the kernel to fully boot without having to mount any physical hard disk.  Since the necessary modules needed to interface with peripherals can be part of the initrd, the kernel can be very small, but still support a large number of possible hardware configurations. After the kernel is booted, the root file system is pivoted (via pivot_root) where the initrd root file system is unmounted and the real root file system is mounted.

The initrd function allows you to create a small Linux kernel with drivers compiled as loadable modules. These loadable modules give the kernel the means to access disks and the file systems on those disks, as well as drivers for other hardware assets. Because the root file system is a file system on a disk, the initrd function provides a means of bootstrapping to gain access to the disk and mount the real root file system. In an embedded target without a hard disk, the initrd can be the final root file system, or the final root file system can be mounted via the Network File System (NFS).

5) Init:

After the kernel is booted and initialized, the kernel starts the first user-space application. This is the first program invoked that is compiled with the standard C library.Init is the first process running on your system. It reads the /etc/inittab file, executes /etc/rc.d/rc.sysinit, then boots into the runlevel as defined in /etc/inittab.

Init starts out with a Process ID (PID) of 1. In the image above, there's a line saying "INIT: version 2.86 booting"; this is /sbin/init taking over at this point in the boot process. On the line right after that one, you see the messages being displayed by the /etc/rc.d/rc.sysinit shell script; as a matter of fact, the entire screen contains messages from that script, so you can get an idea of some of the functions it performs. Init will also normally start several instances of /sbin/getty or /sbin/mingetty, which are your virtual terminals. This is why you can hit <Ctrl> + <Alt> + < F1> through <F6> and come up with a virtual terminal.

Depending on what Init is doing, you may see typical Init script verification messages getting printed to the screen, i.e., [ OK ] or [Failed] to aid in troubleshooting. You may see a message like "Press 'I' to enter interactive startup" (on Red Hat-based systems); this is an indication of rc.sysinit executing, and allows the operator a certain level of control over the still-booting system. rc.sysinit ends with your default runlevel (as defined in /etc/inittab) being started. This is another common place for errors, because servers will usually have the "id:5:initdefault:" line set to 3, so the machine boots to runlevel 3 instead of runlevel 5. Another common place for errors is the line pertaining to "ca::ctrlaltdel:/sbin/shutdown -t3 -r now" commented out to prevent the 3-finger salute (<Ctrl> + <Alt> + <Del>) from restarting the server. People are human and make mistakes; I have seen typographical errors in both places that can cause problems. Unlike the "mount -a" command, which will alert you if errors exist in your mount points in the /etc/fstab file, executing the command "init q" will reread your /etc/inittab, but will not check for errors in the runlevels themselves; the best way to know if errors exist is to learn this file and to be very, very careful if you decide to modify any of the /etc/rc*/* files.

When you enter your runlevel, you will see further Init messages being printed to the screen (depending if your machine is configured to do so), again ending with a [ OK ] or [Failed] depending on whether it started successfully or not. These are your startup services within your runlevels. When you look at your /etc/inittab file, you will see a line like "id:5:initdefault:"; this is your default runlevel. The default runlevel on most servers will be set to 3; on desktops, of course, it's set to 5, so we can have an X Window System session start as soon as the system boots up.

To get an overview of what processes get started or stopped for any particular runlevel, we should look within the /etc/rcX.d (where X is your runlevel) directory. Inside these directories, you will see symbolic links to the files in your /etc/init.d/ directory. The file names will be prefixed with either a 'K' or an 'S' (signifying kill or start) for the given daemon at that runlevel. The number immediately after the letter positions the script in the start order, because the processes are started alphabetically. With Red Hat-based systems, the "chkconfig" command will alter the symbolic links to start or stop the daemon in a desired runlevel; the 'S' or 'K' will change appropriately and the number will most likely change as well.