Restore the Porta-Switch from tar files installation on LVM partitions
[]
Emin Gabrielyan
Table of contents:
Restore the Porta-Switch from tar files installation on LVM partitions
3. Partitioning the physical disk
4. Creating the volume group and its logical partitions
4.2. Choice of the Volume Group name depending on the server
4.3. Creating the logical volumes
7. Configure the network on Live CD system
8.1. Downloading the tar file of the boot partition
8.2. Downloading the tar file of the root1 partition
8.3. Downloading the tar files of the root2 and porta partitions
9. Extract the contents of tar files
11. Replace the initial ram disk files of the boot partition
11.1. Download and replace initrd files of the kernel
11.2. The initrd files of 4 servers
11.3. Dismount the partitions and reboot
12. After booting from the hard drive
12.1. Porta-SIP services do not start
12.2. Check the swap allocation
13.3. Local FTP server on 192.168.1.17
13.4. Initial RAM disk files for the LVM version
15. Annex: Glossary of conventions
16. Annex: the field formulas used in this document
16.1. Auto-incrementing reference numbers
16.2. Deleting the auto-incrementing bookmark before printing
We already presented how to create backup tar files from an installed and configured porta-switch system consisting of several servers [101] [102] [103]. The porta-switch system installed from DVD installers [104] is not functional immediately. A post-install configuration and upgrade procedure must be carried out by the porta-one team. Once a functional system is obtained, a full backup is mandatory. The porta-switch system consists of 4 machines, configurator, billing master, slave, and porta-sip. The system which we backed up into tar files (see section 13) was installed on an 8 IP address subnet 212.147.8.104/29 with a default gateway 212.147.8.105. The IP addresses are associated to the 4 servers as follows [105] [106] [107]:
· 212.147.8.106 billing1.switzernet.com, configurator
· 212.147.8.108 billing2.switzernet.com, billing master
· 212.147.8.109 billing3.switzernet.com, billing web server
· 212.147.8.110 billing4.switzernet.com, SIP server
In our previous document we showed how to create primary partitions using the fdisk tool and then how-to restore the contents of the tar files onto these partitions. Each of the porta-one servers uses originally 5 partitions: boot, root1, root2, porta, and swap. On the other hand, the hard disk supports at most 4 primary partitions. The previous installation method was based on the idea that the root1 partition can be skipped as porta-one uses two root partitions uniquely for its upgrade and rollover procedures [108]. As far as no upgrades are assumed, the system is functional with only one root partition. For a full and long-term functionality however, all 5 partitions are required. In this document we mimic the disk management used in the original RHEL installations of porta-one servers [109]. In the initial version of RHEL, the disks are partitioned using the Logical Volume Manager (LVM) [110]. The LVM, being an intermediary layer between the disk and the file system, permits a more flexible and manageable partitioning. With LVM it is possible to have more than 4 partitions, one can create a large virtual data volume spanned over more than one physical drive, and the partitions are resizable on the fly.
The rest of this document contains step-by-step instructions on how to prepare and restore a system on a brand new computer, and boot from it.
When using an LVM, instead of dealing with a physical hard drive, we work with a uniform volume group. Such a single uniform volume group can be formed in fact from one or several hard drives, or from one or several partitions of the same or different hard drives. Once the volume group is created, irrespectively of its underlying complexity, it can be considered as a single and uniform virtual drive. It can be partitioned flexibly and resizably into logical volumes.
The following printout of the vgdisplay command shows the state of the LVM of a restored system. Here we see one volume group VolGroup00 which is partitioned into 4 logical volumes, LogVol00, LogVol01, LogVol02, and LogVol03. In this installation the VolGroup00 occupies one large primary partition of the physical hard drive.
[root@billing4 ~]# vgdisplay -v 2> /dev/null | egrep "^ *(LV|VG) (Size|Name)"
VG Name VolGroup00
VG Size 463.75 GB
LV Name /dev/VolGroup00/LogVol00
VG Name VolGroup00
LV Size 19.53 GB
LV Name /dev/VolGroup00/LogVol01
VG Name VolGroup00
LV Size 19.53 GB
LV Name /dev/VolGroup00/LogVol03
VG Name VolGroup00
LV Size 31.25 GB
LV Name /dev/VolGroup00/LogVol02
VG Name VolGroup00
LV Size 393.44 GB
[root@billing4 ~]#
Here are notes on the volume group taken from the original installation:
LV Name /dev/VolGroup00/LogVol00
VG Name VolGroup00
LV Size 20.00 GiB
LV Name /dev/VolGroup00/LogVol01
VG Name VolGroup00
LV Size 20.00 GiB
LV Name /dev/VolGroup00/LogVol02
VG Name VolGroup00
LV Size 402.91 GiB
LV Name /dev/VolGroup00/LogVol03
VG Name VolGroup00
LV Size 2.75 GiB
The command pvdisplay shows the details of the drive participating in a formation of a logical volume. The following printout is obtained on a restored system.
[root@billing4 ~]# pvdisplay /dev/hda2
--- Physical volume ---
PV Name /dev/hda2
VG Name VolGroup00
PV Size 463.75 GB / not usable 2.34 MB
Allocatable yes (but full)
PE Size (KByte) 4096
Total PE 118720
Free PE 0
Allocated PE 118720
PV UUID pEXlFJ-twpP-ozv3-8H0j-7IzI-H6Qg-DwdZUL
[root@billing4 ~]#
The following record shows that on the original system the PE Size was different. This parameter, standing for Physical Extent) [111], specifies the granularity of the volume and for our purposes, does not play any significant role.
# pvdisplay /dev/sda2
PV Name /dev/sda2
VG Name VolGroup00
PE Size 32.00 MiB
In all our current installations the single physical disk is partitioned into two primary partitions. The first physical partition is small and is reserved for booting. The second primary disk partition occupying the rest of the space, is allocated to one logical volume group, hosting 4 logical volumes dedicated for root1, root2, swap, and porta partitions respectively.
[root@billing4 ~]# fdisk /dev/hda
Command (m for help): p
Disk /dev/hda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/hda1 * 1 262 2104483+ 83 Linux
/dev/hda2 263 60801 486279517+ 8e Linux LVM
Command (m for help): q
[root@billing4 ~]#
In this section we show how to start the preparation of a computer hard drive on which a clone of a system must be restored from a set of its tar files. Note, that after the completion of instructions of this section, all data on the host computer will be definitively lost.
Boot from Fedora 13 Live CD [112] [113]. Open a terminal window and enter into root mode.
The following notes will guide you how to delete the existing partitions (if any), and create two new partitions, one small for the boot, and a single large one for LVM. You must find the name of the device file corresponding to the hard drive of your computer. In this example the device file name of the hard drive is /dev/sda which must not be necessarily the same also for your computer.
# fdisk /dev/sda
p
d
d
...
n (new)
p (primary)
1 (partition)
First cylinder...: <return>
Last cylinder...: +2G
p
n (new)
p (primary)
2 (partition)
First cylinder...: <return>
Last cylinder...: <return> (full space)
p
While still in fdisk tool alter the first partition into a bootable one:
a
1
p
While still in fdisk set the type of the 2nd partition to LVM
t
2
8e
p
Write/apply the changes, exit from fdisk tool, and reboot the system (boot back from Live CD)
w
# reboot
If you got warning the first time when writing and exiting from the fdisk tool, after the reboot (again from the Live CD), you must not have warnings anymore when entering into the fdisk tool and exiting from it with the w command.
# fdisk /dev/sda
p
w
#
The output of your fdisk command shall look similarly to the printout shown below with possible exceptions concerning the exact sizes and the dive file names.
[root@billing4 ~]# fdisk /dev/hda
...
Command (m for help): p
...
Device Boot Start End Blocks Id System
/dev/hda1 * 1 262 2104483+ 83 Linux
/dev/hda2 263 60801 486279517+ 8e Linux LVM
Command (m for help): q
[root@billing4 ~]#
You are now ready to allocate the device file of the 2nd partition of the hard drive to the logical volume manager (LVM).
First, with the pvcreate command, allow the device for a possible usage by the LVM. You can prepare several such devices, but in our example the volume group will use only one device.
# pvcreate /dev/sda2
Once the device is prepared for the possible usage by the LVM, you can display its status with pvdisplay command.
# pvdisplay /dev/sda2
--- NEW Physical volume ---
PV Name /dev/sda2
VG Name
PV Size 463.75 GiB
Allocatable NO
PE Size 0
Total PE 0
Free PE 0
Allocated PE 0
PV UUID ...
#
For the moment the physical device is not yet allocated to a volume group. When the physical device is allocated to a volume group, the output of pvdisplay looks as follows:
[root@billing4 ~]# pvdisplay /dev/hda2
--- Physical volume ---
PV Name /dev/hda2
VG Name VolGroup00
PV Size 463.75 GB / not usable 2.34 MB
Allocatable yes (but full)
PE Size (KByte) 4096
Total PE 118720
Free PE 0
Allocated PE 118720
PV UUID pEXlFJ-twpP-ozv3-8H0j-7IzI-H6Qg-DwdZUL
[root@billing4 ~]#
Now create a volume group with vgcreate command listing as arguments all physical devices. In our example, we use only one physical device. The first argument (VolGroup00 in the below note) is the name of the volume group being created.
# vgcreate VolGroup00 /dev/sda2
Volume group "VolGroup00" successfully created
#
Depending on the server being restored (billing1, billing2, billing3, or billing4), a different name might be indicated while creating the volume group. The name must match the Volume Group name used in /etc/fstab file of the system being restored (see the section 4.2 that comes next).
In order to correctly choose the name of the volume group, we show in this section the fstab files extracted from tar files of each root partition of each server:
$ for b in 1 2 3 4; do for r in 1 2; do tar -C b$b-r$r -xjvf …data1/*billing$b,root$r.tar.bzip2 ./etc/fstab; done; done
./etc/fstab
./etc/fstab
./etc/fstab
./etc/fstab
./etc/fstab
./etc/fstab
./etc/fstab
./etc/fstab
$ ls b?-r?/etc/fstab
b1-r1/etc/fstab b2-r1/etc/fstab b3-r1/etc/fstab b4-r1/etc/fstab
b1-r2/etc/fstab b2-r2/etc/fstab b3-r2/etc/fstab b4-r2/etc/fstab
$ u2d b?-r?/etc/fstab
b1-r1/etc/fstab: done.
b1-r2/etc/fstab: done.
b2-r1/etc/fstab: done.
b2-r2/etc/fstab: done.
b3-r1/etc/fstab: done.
b3-r2/etc/fstab: done.
b4-r1/etc/fstab: done.
b4-r2/etc/fstab: done.
$
The fstab file of the root1 partition of each server shows that the billing1, billing2, and billing3 servers use the name VolGroup01, while billing4 server uses VolGroup00 as the name of its LVM volume group:
$ for f in b?-r1/etc/fstab; do echo; echo [$f]; cat $f; done
[b1-r1/etc/fstab]
/dev/VolGroup01/LogVol00 / ext3 defaults 1 1
/dev/VolGroup01/LogVol02 /porta_var ext3 defaults 1 2
/dev/VolGroup01/LogVol01 /update_root ext3 defaults 1 2
LABEL=/boot /boot ext3 defaults 1 2
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
/dev/VolGroup01/LogVol03 swap swap defaults 0 0
[b2-r1/etc/fstab]
/dev/VolGroup01/LogVol00 / ext3 defaults 1 1
/dev/VolGroup01/LogVol02 /porta_var ext3 defaults 1 2
/dev/VolGroup01/LogVol01 /update_root ext3 defaults 1 2
LABEL=/boot /boot ext3 defaults 1 2
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
/dev/VolGroup01/LogVol03 swap swap defaults 0 0
[b3-r1/etc/fstab]
/dev/VolGroup01/LogVol00 / ext3 defaults 1 1
/dev/VolGroup01/LogVol02 /porta_var ext3 defaults 1 2
/dev/VolGroup01/LogVol01 /update_root ext3 defaults 1 2
LABEL=/boot /boot ext3 defaults 1 2
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
/dev/VolGroup01/LogVol03 swap swap defaults 0 0
[b4-r1/etc/fstab]
/dev/VolGroup00/LogVol00 / ext3 defaults 1 1
/dev/VolGroup00/LogVol01 /update_root ext3 defaults 1 2
/dev/VolGroup00/LogVol02 /porta_var ext3 defaults 1 2
LABEL=/boot /boot ext3 defaults 1 2
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
/dev/VolGroup00/LogVol03 swap swap defaults 0 0
$
The same naming of volume groups appears also in the /etc/fstab files of the root2 partition of each server (billing1, billing2, billing3, and billing4). The root2 partition is the one used currently by all servers as the main root / directory.
The only difference between the /etc/fstab files of the root1 and root2 partitions is that the logical volumes behind the root / and the /update_root directories are swapped. The fstab of VolGroup00 mounts itself as root /, and similarly the fstab of VolGroup01 mounts itself as root / and VolGroup00 as /update_root. Whether the system at its boot will switch the control to LogVol00 or to LogVol01 depends only on the data accompanying the kernel in the boot partition. The boot partition is backed up in the set of the tar files, so the booting comportment of the original system will be restored without changes.
$ for f in b?-r2/etc/fstab; do echo; echo [$f]; cat $f; done
[b1-r2/etc/fstab]
/dev/VolGroup01/LogVol01 / ext3 defaults 1 1
/dev/VolGroup01/LogVol02 /porta_var ext3 defaults 1 2
/dev/VolGroup01/LogVol00 /update_root ext3 defaults 1 2
LABEL=/boot /boot ext3 defaults 1 2
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
/dev/VolGroup01/LogVol03 swap swap defaults 0 0
[b2-r2/etc/fstab]
/dev/VolGroup01/LogVol01 / ext3 defaults 1 1
/dev/VolGroup01/LogVol02 /porta_var ext3 defaults 1 2
/dev/VolGroup01/LogVol00 /update_root ext3 defaults 1 2
LABEL=/boot /boot ext3 defaults 1 2
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
/dev/VolGroup01/LogVol03 swap swap defaults 0 0
[b3-r2/etc/fstab]
/dev/VolGroup01/LogVol01 / ext3 defaults 1 1
/dev/VolGroup01/LogVol02 /porta_var ext3 defaults 1 2
/dev/VolGroup01/LogVol00 /update_root ext3 defaults 1 2
LABEL=/boot /boot ext3 defaults 1 2
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
/dev/VolGroup01/LogVol03 swap swap defaults 0 0
[b4-r2/etc/fstab]
/dev/VolGroup00/LogVol01 / ext3 defaults 1 1
/dev/VolGroup00/LogVol00 /update_root ext3 defaults 1 2
/dev/VolGroup00/LogVol02 /porta_var ext3 defaults 1 2
LABEL=/boot /boot ext3 defaults 1 2
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
/dev/VolGroup00/LogVol03 swap swap defaults 0 0
$
Examine the /etc/fstab files shown above to create your volume group with a correct name. This doc is continued on the example of billing4 server.
Once the volume group is created you can find out the space available in the volume group with the vgdisplay command:
# vgdisplay VolGroup00
VG Name VolGroup00
Format lvm2
VG Size 463.75 GiB
PE Size 4.00 MiB
Total PE 118720
#
Create now the logical volumes for root1, root2, porta, and swap partitions by allocating about 20GB per root1 (LogVol00) and root2 (LogVol01) respectively, about 32GB to swap (LogVol03), and the rest to porta partition (LogVol02). The argument of the option -l is the number of physical extents. The number of available physical extents is displayed as “Total PE” in the output of vgdisplay command shown above. The same output shows also that the size of physical extent is of 4 MB (see PE Size). Therefore, 5000 extents will give us approximately 20 GB of space and 8000 extents, approximately 32 GB.
# lvcreate -l 5000 VolGroup00 -n LogVol00
# lvcreate -l 5000 VolGroup00 -n LogVol01
# lvcreate -l 8000 VolGroup00 -n LogVol03
# lvcreate -l 100720 VolGroup00 -n LogVol02
The total number of extents must be equal to the total number of available extents shown by vgdisplay command: 5000+5000+8000+100720=118720.
Instead of computing the extents in advance, you can first allocate the spaces of 20GB, 20GB, and 32GB of all small partitions (root1, root2, and swap) to LogVol00, LogVol01, and LogVol03 respectively. Then only, you can check with vgdisplay the number of remaining extents (Free PE) in order to allocate all of them to LogVol02, for the largest partition porta.
# vgdisplay VolGroup00
...
Free PE / Size 100720 / 393.44 GiB
...
# lvcreate -l 100720 VolGroup00 -n LogVol02
After allocation the vgdisplay output shall look as follows:
[root@billing4 ~]# vgdisplay VolGroup00
--- Volume group ---
VG Name VolGroup00
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 5
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 4
Open LV 4
Max PV 0
Cur PV 1
Act PV 1
VG Size 463.75 GB
PE Size 4.00 MB
Total PE 118720
Alloc PE / Size 118720 / 463.75 GB
Free PE / Size 0 / 0
VG UUID S3x5DA-93re-2h6a-m6y7-ToJe-6buA-3bJRoJ
[root@billing4 ~]#
Once the logical volumes are created, you will see in the /dev directory a folder of the name of the volume group (VolGroup00 in our case) containing files (or symbolic links) with the names of logical volumes (LogVol00, LogVol01, LogVol02, and LogVol03):
[root@billing4 ~]#
[root@billing4 ~]# ls /dev/VolGroup00/
LogVol00 LogVol01 LogVol02 LogVol03
[root@billing4 ~]#
[root@billing4 ~]#
The files /dev/VolGroup00/LogVol00, etc, are block devices (or links to block devices) and can be treated (for example by disk formatting tools) similarly to a hard disk partition device.
After allocation of the extents of the volume group, we now have a primary disk partition for boot and four logical volumes (for root1, root2, swap, and porta). They must be formatted. Follow the example below:
# mkfs –t ext3 /dev/VolGroup00/LogVol00
# mkfs –t ext3 /dev/VolGroup00/LogVol01
# mkfs –t ext3 /dev/VolGroup00/LogVol02
# mkswap /dev/VolGroup00/LogVol03
# mkfs –t ext3 /dev/sda1
The /etc/fstab files provided in section 4.2 show that the boot partition is mounted using the label “LABEL=/boot /boot” instead of the device file name such as “/dev/sda1 /boot”. The use of labels makes the /etc/fstab file less dependent from the names of the device files (a subject of change from machine to machine).
Associate the label “/boot” to the boot partition with the following command:
# e2label /dev/sda1 /boot
As the partitions are all formatted, you can now mount them as follows:
# cd /mnt
# mkdir boot
# mkdir root1
# mkdir root2
# mkdir porta
# mount /dev/sda1 boot
# mount /dev/VolGroup00/LogVol00 root1
# mount /dev/VolGroup00/LogVol01 root2
# mount /dev/VolGroup00/LogVol02 porta
# df
On a restored system the output of the df command looks as follows:
[root@billing4 ~]# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol01
20158332 2896332 16238000 16% /
/dev/mapper/VolGroup00-LogVol00
20158332 2798968 16335364 15% /update_root
/dev/mapper/VolGroup00-LogVol02
406074960 2427000 383020504 1% /porta_var
/dev/hda1 2071384 81464 1884696 5% /boot
tmpfs 1011792 0 1011792 0% /dev/shm
[root@billing4 ~]#
While still running within the OS of the Live CD, use the spare IP address 212.147.8.107 of the subnet to configure the network. The use of the spare IP address will avoid any eventual conflicts with running servers billing1, billing2, billing3, and billing4. Refer to section 1 for the IP addresses of the backed up porta-switch servers. The following commands must be typed in super user mode.
# ifconfig eth0 212.147.8.107 netmask 255.255.255.248
# route add default gw 212.147.8.105
# echo nameserver 192.168.1.2 >> /etc/resolv.conf
# echo nameserver 208.67.220.220 >> /etc/resolv.conf
# ping google.com
Upon this setup you must be able to ping Google by its name.
If you are planning to download from the local LAN’s ftp server, you must enable the FTP port in the firewall of the Live CD system, because the local FTP server (192.168.1.17) does not work in passive mode. Type system-config-firewall in su mode.
# system-config-firewall
A GUI panel will appear where you must enable the FTP port and apply changes. Make sure that you can ping the local FTP server 192.168.1.17. If not, you must fix the routing on the FTP server itself (see section 13.3). Consult also the section “Direct routing without NAT” in [114] [115] [116].
Note that all examples below correspond to the billing4 server (the SIP server). You must adapt your execution to the server currently being installed by yourself.
Follow the example of with interactive commands at the ncftp prompt (below), or the examples with all parameters in a single command line (shown in sections 8.2 and 8.3), and download the tar file of the boot partition into your currently empty boot partition.
# cd /mnt/boot
# ncftp –u toto –p **** 192.168.1.17
> passive
Passive on
> passive
Passive off
> dir
> cd data1
> bin
> get *,billing4,boot.*
> quit
# ls -l
# cd /mnt/
# ncftpget -E –u toto –p **** 192.168.1.17 root1 data1/*,billing4,root1.tar.bzip2
# ls –l root1
Note that the -E option forces ncftpget to enter into PORT 21 mode.
Continue downloading the tar files into the respective local partitions:
# cd /mnt/
# ncftpget -E –u toto –p **** 192.168.1.17 root2 data1/*,billing4,root2.tar.bzip2
# ls –l root2
# ncftpget -E –u toto –p **** 192.168.1.17 porta data1/*,billing4,porta.tar.bzip2
# ls –l porta
#
Extract the tar files into their respective partitions, as shown in the notes below:
# cd /mnt/boot
# tar –xjvf 100830,1925,billing4,boot.tar.bzip2
#
# cd /mnt/root1
# tar –xjvf 100830,1925,billing4,root1.tar.bzip2
#
# cd /mnt/root2
# tar –xjvf 100830,1925,billing4,root2.tar.bzip2
#
# cd /mnt/porta
# tar –xjvf 100830,1925,billing4,porta.tar.bzip2
#
Install the grub boot loader. Pay attention to use device filenames corresponding to your hard drive and its boot partition. In this example the device /dev/sda corresponds to the entire hard disk and /dev/sda1 to its boot partition.
# cd /mnt/boot
# grub-install --root-directory=/mnt/boot /dev/sda
# grub-install --root-directory=/mnt/boot /dev/sda1
Follow the notes below:
# cd /mnt/boot
# grub
grub> root
grub> root (hd0,0)
grub> setup (hd0,0)
grub> setup (hd0)
grub> quit
#
Create a hard link:
# ln /mnt/boot/grub/grub.conf /mnt/boot/boot/grub/grub.conf
#
You can shuffle the computers when restoring the system. The computer where the system is being restored can be different from the computer where it was originally installed. Your computer risks to not boot, if the current computer’s hard disk controller driver is missing in the restored kernel.
To avoid the risk of a missing driver, we included the RAID controller driver in all initial ram disks for all servers [117]. The extended initrd files are available on the web (see section 13.4 for a complete list of locations).You have to download these files and replace the original initrd files before booting from the hard disk:
# cd /mnt/boot/
# wget http://www.switzernet.com/3/public/100926-mr21-tar-lvm/data1/100926,1740,billing4,initrd.gz
# mv initrd-2.6.18-164.0.0.0.1.el5.img initrd-2.6.18-164.0.0.0.1.el5.img.bak
# cp 100926,1740,billing4,initrd.gz initrd-2.6.18-164.0.0.0.1.el5.img
#
The next section 11.2 describes how the initrd files are created. You do not need this section for restoring and can jump directly to section 11.3 for the next step. However it is recommended to read and understand the procedure of section 11.2.
First of all we need to examine all differences between the initrd files of each of 4 servers (billing1, billing2, billing3, and billing4). For this purpose the boot partitions of each server is downloaded:
bash-3.2$ ls -F -1
100829,2000,billing1,boot.tar.bzip2
100830,1845,billing3,boot.tar.bzip2
100830,1925,billing4,boot.tar.bzip2
100830,2130,billing2,boot.tar.bzip2
b1/
b2/
b3/
b4/
bash-3.2$
The initrd image files of each server’s boot partition are extracted:
bash-3.2$ for b in 1 2 3 4; do tar -C b$b -xvf *,*,billing$b,boot.tar.bzip2 ./initrd-2.6.18-164.0.0.0.1.el5.img; done
./initrd-2.6.18-164.0.0.0.1.el5.img
./initrd-2.6.18-164.0.0.0.1.el5.img
./initrd-2.6.18-164.0.0.0.1.el5.img
./initrd-2.6.18-164.0.0.0.1.el5.img
bash-3.2$
The initrd image files of each server is extracted in a respective folder.
bash-3.2$
bash-3.2$ ls -F -1 b*
b1:
initrd-2.6.18-164.0.0.0.1.el5.img
b2:
initrd-2.6.18-164.0.0.0.1.el5.img
b3:
initrd-2.6.18-164.0.0.0.1.el5.img
b4:
initrd-2.6.18-164.0.0.0.1.el5.img
bash-3.2$
bash-3.2$
Now the RAM disk hierarchy is extracted from each image file into an rd subfolder.
bash-3.2$ for b in 1 2 3 4; do cd b$b; mkdir rd; cd rd; zcat ../initrd-2.6.18-164.0.0.0.1.el5.img | cpio -i; cd ..; cd ..; done
17005 blocks
17005 blocks
16743 blocks
16743 blocks
bash-3.2$
bash-3.2$
A text file init, in each RAM disk contains the initial instructions of the temporary OS that the kernel of the server will mount first of all, before mounting the root system and all partitions of the hard drive.
The following printout shows the differences between the init file of initial ram disks of billing1 compared to the corresponding init files of billing2, billing3, and billing4. There is no difference between init files of billing1 and billing2, as both of them were installed on the same type of HP Proliant DL120 G5 blade servers, both with E200 RAID controller [118]. We see also, that the two servers, billing3 and billing4, do not load the cciss.ko driver (that corresponds to the RAID controller) as they were installed on conventional computers. Finally, in the server billing4, we see another difference (remember section 4.2). The OS of the initial ram disk mounts the hard disk partitions using a volume group name VolGroup00 in contrast to VolGroup01 used by the other three servers (billing1, billing2, and billing3). This difference, seen also in section 4.2 for fstab files, requires an attention when naming the volume groups on the empty system (section 4.1).
bash-3.2$
bash-3.2$ for b in 2 3 4; do echo; echo [b1 vs b$b]; echo; diff b1/rd/init b$b/rd/init; done
[b1 vs b2]
[b1 vs b3]
59,60d58
< echo "Loading cciss.ko module"
< insmod /lib/cciss.ko
[b1 vs b4]
59,60d58
< echo "Loading cciss.ko module"
< insmod /lib/cciss.ko
94,95c92,93
< lvm vgchange -ay --ignorelockingfailure VolGroup01
< resume /dev/VolGroup01/LogVol03
---
> lvm vgchange -ay --ignorelockingfailure VolGroup00
> resume /dev/VolGroup00/LogVol03
97c95
< mkrootdev -t ext3 -o defaults,ro /dev/VolGroup01/LogVol00
---
> mkrootdev -t ext3 -o defaults,ro /dev/VolGroup00/LogVol00
bash-3.2$
We must examine and compare not only the init files, but also all other files of each of the 4 initial RAM disks. By comparing the MD5 checksums, we discover that the only difference between these four temporary file systems consists in the content of their init files (already discussed) and in the presence and absence of one driver cciss.ko corresponding to the RAID controller.
bash-3.2$
bash-3.2$ for b in 1 2 3 4; do cd b$b/rd; /bin/find . -type f -exec md5sum {} \; ; cd ../..; done | sort | uniq -c | egrep -v "^ *4 "
1 4a660c0ede47b7130c86bb4f5b0762fb *./init
2 6c0051b1cf195c350f32e8094b8ae164 *./init
2 906232f8795752b71a58e070f1e11392 *./lib/cciss.ko
1 e916de6b697ab8b43e31fa410866a4e5 *./init
bash-3.2$
To make the initrd disk images portable across the set of our servers, we must edit the init files so as to load the RAID controller driver, add the cciss.ko file in the library, and compress the hierarchy back into initial ram disk image format.
bash-3.2$ cd rd1
bash-3.2$ ls -F
bin/ dev/ etc/ init* init.bak* lib/ proc/ sbin@ sys/ sysroot/
bash-3.2$ /bin/find . | cpio -o -H newc > ../100926,1740,billing1,initrd
17013 blocks
bash-3.2$ cd ..
bash-3.2$ cd rd4
bash-3.2$ ls -F
bin/ dev/ etc/ init* init.bak* lib/ proc/ sbin@ sys/ sysroot/
bash-3.2$ /bin/find . | cpio -o -H newc > ../100926,1740,billing4,initrd
17013 blocks
bash-3.2$ cd ..
bash-3.2$ ls -1 -F
100926,1740,billing1,initrd
100926,1740,billing4,initrd
initrd-2.6.18-164.0.0.0.1.el5.img*
rd1/
rd4/
bash-3.2$ gzip 100926,1740,billing1,initrd
bash-3.2$ gzip 100926,1740,billing4,initrd
bash-3.2$ ls -1 -F
100926,1740,billing1,initrd.gz
100926,1740,billing4,initrd.gz
initrd-2.6.18-164.0.0.0.1.el5.img*
rd1/
rd4/
bash-3.2$
The initrd image files of billing2, billing3 are the copies of the initrd file of billing1. The image file of billing3 is different due to a different volume group name. These image files are uploaded to the web server (see section 13.4) and must replace the default image files when the boot partition is restored.
# cd /mnt
# umount boot
# umount root1
# umount root2
# umount porta
# reboot
Remove the Live CD from the drive.
If the system successfully booted and you got the login prompt on the console, you deserve congratulations. First of all you need to shut down the other clone running the same installation to avoid IP address conflicts.
As soon as the previous clone is down, login as root to the newly installed server in order to configure its network. As you changed the server and its network card, the interface will not come up automatically at the boot.
Login: root
...
# cd /etc/sysconfig/network-scripts/
# vi ifcfg-eth0
Add empty lines at the end of the file, go to the end of the file, and insert the original file, renamed to ifcfg-eth0.bak by the system at the boot time.
:r ifcfg-eth0.bak
The present BAK file contains the original correct network setting, but it was ignored and consequently renamed into a BAK, as the HWADDR parameter in this file containing the MAC address of the card, did not match the hardware address of the card actually installed in the computer. In the block inserted from the BAK file, replace the value of HWADDR parameter by the current value present at the beginning of the file already before the insertion. In the inserted block, replace also the first commented line by the corresponding line of the current file before insertion (for accuracy only). These two replacements are the only changes to do in the inserted block. The original content of the file can be deleted and only the inserted and modified block must be kept. Write and exit.
:w
:q
Reboot the system. If the restored server is billing4 (porta-SIP server) or billing2 (master), insert also the security dongle. Take out the dongle from the stopped clone. The dongles of the master (billing2) and SIP (billing4) servers are identical.
If the services porta-sip (billing4) do not come up, login as root, and follow the notes below:
# cd /porta_var/sipenv-212.147.8.110/etc/rc.d/
# ./sip.sh status
# ./sip.sh restart
# ./sip.sh stop
# reboot
After this procedure, the Porta-SIP services must come up after the reboot. The slave server must also show that everything is fine with the porta-sip server. If not, restart the services from the console once more, or do in two steps, by first stopping then starting the service with the ./sip.sh utility.
Follow the printout below to make sure that everything is fine with the swap space.
[root@billing4 ~]#
[root@billing4 ~]# cat /proc/swaps
Filename Type Size Used Priority
/dev/mapper/VolGroup00-LogVol03 partition 32767992 0 -1
[root@billing4 ~]#
[root@billing4 ~]# cat /proc/meminfo | grep Swap
SwapCached: 0 kB
SwapTotal: 32767992 kB
SwapFree: 32767992 kB
[root@billing4 ~]#
The tar files of all partitions of all servers can be downloaded via HTTP from the following web locations. More help for downloading can be found in our previous publication [119] [120] [121]. The tar files of partitions are not available in the public version of this document.
http://unappel.ch/2/company/100830-tar-pb-mr21/data1/
In the below table the columns represent the servers and the rows represent the partitions. For each partition on each server there is one tar file compressed with bzip2 method.
|
billing1 212.147.8.106 Configurator |
billing2 212.147.8.108 Billing Master |
billing3 212.147.8.109 Billing Slave (web) |
billing4 212.147.8.110 SIP Server |
Boot |
billing1,boot.tar.bzip2 (5.5M) |
billing2,boot.tar.bzip2 (5.5M) |
billing3,boot.tar.bzip2 (5.5M) |
billing4,boot.tar.bzip2 (5.5M) |
Porta |
billing1,porta.tar.bzip2 (589M) |
billing2,porta.tar.bzip2 (11M) |
billing3,porta.tar.bzip2 (596M) |
billing4,porta.tar.bzip2 (3.6M) |
Root #1 |
billing1,root1.tar.bzip2 (542M) |
billing2,root1.tar.bzip2 (528M) |
billing3,root1.tar.bzip2 (543M) |
billing4,root1.tar.bzip2 (527M) |
Root #2 |
billing1,root2.tar.bzip2 (550M) |
billing2,root2.tar.bzip2 (553M) |
billing3,root2.tar.bzip2 (552M) |
billing4,root2.tar.bzip2 (550M) |
The same files are available also on the main server and its mirror.
http://switzernet.com/3/company/100830-tar-pb-mr21/data1/
|
billing1 212.147.8.106 Configurator |
billing2 212.147.8.108 Billing Master |
billing3 212.147.8.109 Billing Slave (web) |
billing4 212.147.8.110 SIP Server |
Boot |
billing1,boot.tar.bzip2 (5.5M) |
billing2,boot.tar.bzip2 (5.5M) |
billing3,boot.tar.bzip2 (5.5M) |
billing4,boot.tar.bzip2 (5.5M) |
Porta |
billing1,porta.tar.bzip2 (589M) |
billing2,porta.tar.bzip2 (11M) |
billing3,porta.tar.bzip2 (596M) |
billing4,porta.tar.bzip2 (3.6M) |
Root #1 |
billing1,root1.tar.bzip2 (542M) |
billing2,root1.tar.bzip2 (528M) |
billing3,root1.tar.bzip2 (543M) |
billing4,root1.tar.bzip2 (527M) |
Root #2 |
billing1,root2.tar.bzip2 (550M) |
billing2,root2.tar.bzip2 (553M) |
billing3,root2.tar.bzip2 (552M) |
billing4,root2.tar.bzip2 (550M) |
The mirror’s location is:
http://mirror2.switzernet.com/3/company/100830-tar-pb-mr21/data1/
A temporary ftp server is installed in the office. This FTP server does not support the passive mode. It also has a shortcut routing entry for bypassing the NAT when communicating with our LAN 212.147.8.104/29. As this server is running on windows XP, the routing entry may disappear on the server at each automatic upgrade. If you cannot ping 192.168.1.17 from the subnet 212.147.8.104/29, check on the server whether the routing exists or not with route print command, and if necessary add the entry manually (note that you can always ping in the inverse direction even without shortcut routing entry).
C:\> route print
C:\> route add 212.147.8.104 mask 255.255.255.248 192.168.1.22
C:\> route print
Refer to our office LAN architecture for routing details [122] [123]. For the FTP server on Windows XP machine refer to our previous document [124] [125] [126].
The printout below shows the files and their location available on our local FTP server:
bash-3.2$ ftp 192.168.1.17
Connected to 192.168.1.17.
220 Microsoft FTP Service
User (192.168.1.17:(none)): toto
331 Password required for toto.
Password:
230 User toto logged in.
ftp> cd data1
250 CWD command successful.
ftp> dir
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
08-27-10 08:40PM 5809944 100829,2000,billing1,boot.tar.bzip2
08-26-10 10:07PM 617833923 100829,2000,billing1,porta.tar.bzip2
08-26-10 09:27PM 567890331 100829,2000,billing1,root1.tar.bzip2
08-26-10 09:43PM 576437989 100829,2000,billing1,root2.tar.bzip2
08-30-10 10:51PM 5809434 100830,1845,billing3,boot.tar.bzip2
08-30-10 10:51PM 624991413 100830,1845,billing3,porta.tar.bzip2
08-30-10 10:52PM 569147738 100830,1845,billing3,root1.tar.bzip2
08-30-10 10:52PM 578991246 100830,1845,billing3,root2.tar.bzip2
08-30-10 11:27PM 5787581 100830,1925,billing4,boot.tar.bzip2
08-30-10 11:27PM 3826157 100830,1925,billing4,porta.tar.bzip2
08-30-10 11:27PM 552913171 100830,1925,billing4,root1.tar.bzip2
08-30-10 11:28PM 576843940 100830,1925,billing4,root2.tar.bzip2
08-31-10 01:39AM 5807171 100830,2130,billing2,boot.tar.bzip2
08-31-10 01:39AM 11315019 100830,2130,billing2,porta.tar.bzip2
08-31-10 01:39AM 553421884 100830,2130,billing2,root1.tar.bzip2
08-31-10 01:40AM 579733447 100830,2130,billing2,root2.tar.bzip2
09-02-10 01:05AM 2785 md5.txt
09-02-10 01:03AM 3453142 switzegrade.tar.bzip2
226 Transfer complete.
ftp: 1338 bytes received in 0.01Seconds 89.20Kbytes/sec.
ftp> quit
221
bash-3.2$
As the server does not support the passive mode, you need to enable the FTP port on the client side (i.e. in the OS of the Live CD) to permit communication in the active mode. On Fedora 13 Live CD system, type system-config-firewall at the root prompt. A GUI panel will appear where you shall enable FTP and apply changes.
The Initial RAM disk files for the LVM version are available under these locations:
http://www.switzernet.com/3/public/100926-mr21-tar-lvm/data1/
http://mirror2.switzernet.com/3/public/100926-mr21-tar-lvm/data1/
http://www.unappel.ch/2/public/100926-mr21-tar-lvm/data1/
The files can be downloaded via HTTP (a browser or a command line tool):
An example of downloading session with a command line tool is shown below. Other alternatives to wget tool exist.
bash-3.2$
bash-3.2$ wget http://www.switzernet.com/3/public/100926-mr21-tar-lvm/data1/100926,1740,billing1,initrd.gz
--18:20:37-- http://www.switzernet.com/3/public/100926-mr21-tar-lvm/data1/100926,1740,billing1,initrd.gz
=> `100926,1740,billing1,initrd.gz'
Resolving www.switzernet.com... 94.23.49.17
Connecting to www.switzernet.com|94.23.49.17|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3,441,690 (3.3M) [application/x-gzip]
100%[====================================================================================================================>] 3,441,690 667.94K/s ETA 00:00
18:20:42 (638.28 KB/s) - `100926,1740,billing1,initrd.gz' saved [3441690/3441690]
bash-3.2$ ls
100926,1740,billing1,initrd.gz
bash-3.2$
These initrd files are extended versions of original images. They contain a driver for HP E200 RAID controllers. If servers are shuffled, you need to download and replace the original initrd file with these files. Section 11.1 shows when and how these files must be downloaded and used. Section 11.2 describes why and how these updated files are created.
Restoring the Porta-Switch installation from tar files on LVM partitions [this page]
http://switzernet.com/3/public/100926-mr21-tar-lvm/
http://mirror2.switzernet.com/3/public/100926-mr21-tar-lvm/
http://www.unappel.ch/2/public/100926-mr21-tar-lvm/
Restoring the porta-switch installation on primary disk partitions using tar files
http://unappel.ch/2/company/100830-tar-pb-mr21/
http://www.unappel.ch/2/public/100830-tar-pb-mr21/
http://switzernet.com/2/public/100830-tar-pb-mr21/
Upgrades and rollbacks of porta-switch system:
http://portaone.com/news/news_detail.php?ID=1642
Set up Logical Volume Manager in Linux
http://articles.techrepublic.com.com/5100-10878_11-6166001.html
Red Hat Enterprise Linux
http://fr.wikipedia.org/wiki/Red_Hat_Enterprise_Linux
Fedora 13 Live CD:
http://fedoraproject.org/get-fedora
http://unappel.ch/2/company/100822-g4l-pb/data1/
http://unappel.ch/2/company/100822-g4l-pb/data1/Fedora-13-i686-Live.iso
The original installation disk of MR21 (without post-install and configuration):
http://unappel.ch/2/company/100811-portabilling-mr21-iso/
Static routing for the 212.147.8.104/29 subnet:
http://switzernet.com/public/090717-vtx-pse-lan/
http://switzernet.com/2/public/100730-vtx-pse-lan/
Codes:
The text appearing in this format represents a printout or file content.
Hand notes:
The text appearing in this format represents a note on commands or on an output made by hand (misspellings are not excluded).
Important:
Pay special attention on a text highlighted as this one.
Commands, device names, file names:
The text appearing in-line with the paragraph in this format is usually a command.
This section is not related to the porta-switch system and is not required for the installation. Refer to this section only for editing and creating similar documents.
For auto-incrementing reference numbers, we use in this document MS Word field codes. The following is an example of a link to Google [127]. There is a set function at the beginning of the document for initializing the counter to 100. Further on, there is an auto-increment before each use of the bookmark variable refnum.
The text to display for a hyperlink is refnum.
However when toggling the field codes it is not possible to see this text. If you press Ctrl-K on the link, the text to display will indicate on a non-editable field:
The text to display will be visible only if you remove the hyperlink (by pressing on Ctrl-K or by using the right click pop-up menu):
Then you can put the hyperlink back by selecting the { refnum \* mergeformat } and pressing on Ctrl-K. Associate to it the same hyperlink.
Before printing the document, select the document from the definition square brackets down to the end (Ctrl-Shift-End). Right click on the selection and choose Update Field from the pop-up menu. Such an update will reinitialize the counter, and renumber the references in the right order.
You do not have to worry about the numbering, when inserting the references. During the documentation, at insertion of a reference, you need to copy-paste another reference, including the surrounding square brackets, and change only the link location by using the Edit Hyperlink pane that appears when pressing on Ctrl-K. The numbering throughout the document will be corrected, when you update all fields as described.
When the numbering is updated, before printing, delete the bookmark refnum using the Bookmark pane (Alt-I-K).
If you do not delete the bookmark, all displaying field codes will be refreshed again when you click on the print button. The last value of refnum will be used for all occurrences of refnum resulting in the same reference number throughout the doc.
The styles used in this document are limited uniquely by the list shown below.
No other styles must be generated when updating this document.
* * *
Copyright © 2010 by Switzernet