[1’c12’1 ovh mr23 redhat]
RESTORING THE PORTA-SWITCH MR23
INSTALLATION ON OVH SERVERS BY COMPILING
AND REPLACING THE KERNEL
Document created on 2012-01-10
Nicolas Bondier, David Gómez
Keywords: Fedora Kernel, Red Hat kernel, Porta One, Porta Switch, Porta SIP, Configurator, OVH.net,
PortaOne.com, grub, grub2, kernel compilation, MR23, billing, VoIP, SIP, LVM, ram disk, boot
[pdf][doc][html]
*
*
*
Copyright © 2011 by Switzernet
Introduction
1 Contents
2
Introduction ..................................................................................................................................... 3
3
Installing Fedora at OVH.................................................................................................................. 4
4
5
3.1
Choose/order a server............................................................................................................. 4
3.2
Install Fedora with a custom partitioning ............................................................................... 4
Adding VLANs interfaces ................................................................................................................. 6
4.1
Add two IP failover to your server........................................................................................... 6
4.2
Configure the VLANs interfaces............................................................................................... 7
4.3
Activate the VLANs interfaces: ................................................................................................ 7
Creating the volume group and its logical partitions .................................................................... 10
5.1
Unmount the partition reserved for LVM ............................................................................. 10
5.2
Preparing the physical hard disk ........................................................................................... 10
5.3
Create the volume group ...................................................................................................... 12
5.4
Create the logical volumes .................................................................................................... 13
6
Formatting Partitions .................................................................................................................... 15
7
Mounting Partitions ...................................................................................................................... 16
8
Download tar files ......................................................................................................................... 17
9
8.1
Downloading the tar files of root1 partition ......................................................................... 17
8.2
Downloading the tar files of root2 partition ......................................................................... 17
8.3
Downloading the tar files of porta partition ......................................................................... 17
Extract the content of tar files ...................................................................................................... 18
10 Configure the network of Porta-Switch server before booting. ................................................... 19
11 Compile the Switzernet custom kernel ......................................................................................... 21
11.1
Download the kernel source ................................................................................................. 21
11.2
Download the OVH template ................................................................................................ 21
11.3
Build the structure................................................................................................................. 22
11.4
Prepare the kernel source tree ............................................................................................. 25
11.5
Copy the OVH configuration template .................................................................................. 27
11.6
Configure kernel options ....................................................................................................... 27
11.7
Prepare build files.................................................................................................................. 32
11.8
Build the new kernel.............................................................................................................. 33
12 Install the new kernel over Fedora................................................................................................ 34
13 Install the new kernel over Red Hat .............................................................................................. 36
Page 1 of 66
Introduction
13.1
Unpack the Fedora kernel ..................................................................................................... 36
13.2
Copy the kernel content in Red Hat ...................................................................................... 36
14 Modify the init ram disk ................................................................................................................ 38
15 Configure GRUB2 ........................................................................................................................... 43
15.1
Add a menu entry .................................................................................................................. 43
15.2
Configure GRUB2 for booting only once on Red Hat ............................................................ 45
15.3
Reboot ................................................................................................................................... 46
16 Post-install configurations ............................................................................................................. 47
16.1
Modules ................................................................................................................................. 47
16.2
SSH connection ...................................................................................................................... 47
16.3
IPv6 Network connection ...................................................................................................... 47
16.4
Hostname .............................................................................................................................. 48
16.5
OVH Real Time Monitoring.................................................................................................... 48
16.6
Modify default booting System from Red Hat ...................................................................... 50
17 Next rebooting............................................................................................................................... 51
18 Install USB over IP server on a local Fedora machine ................................................................... 52
18.1
Compile the kernel ................................................................................................................ 52
18.2
Install USB over IP.................................................................................................................. 53
19 Install USB over IP client on the Configurator ............................................................................... 56
19.1
Install executable files on Fedora .......................................................................................... 56
19.2
Install executables files on Red Hat....................................................................................... 56
19.3
Install USB over IP modules over Red Hat ............................................................................. 57
19.4
Automatically mounting Fedora ............................................................................................ 59
19.5
Automatically load modules at booting. ............................................................................... 59
20 Validate installation with calls ....................................................................................................... 61
21 References ..................................................................................................................................... 62
21.1.1
VLAN ............................................................................................................................ 62
21.1.2
LVM ............................................................................................................................. 62
21.1.3
Kernel .......................................................................................................................... 62
21.1.4
GRUB2 ......................................................................................................................... 62
21.1.5
This document ............................................................................................................. 62
22 Glossary ......................................................................................................................................... 64
Page 2 of 66
Introduction
2 Introduction
In this document, we will describe the procedure of installation of a Porta-Switch MR23 server on a
OVH.net machine using the tar files, a custom kernel and custom init ram disk. Porta-Switch MR23
consists of four servers (billing master, slave, porta-sip and configurator). All the four servers run Red
Hat Enterprise Linux. The procedure described in this document is applicable to any of these four
servers.
This document extends on the Porta-Switch restoring procedure described by Emin Gabrielyan
[100926 i] [100926 ii]. We developed a procedure permitting to remotely install the MR23
installation on OVH.net servers. See our preliminary researches [111116 i] [111104 i] [100926 i]
[100926 ii] [100830 i] [100830 ii].
We already presented how to create backup tar files from an installed and configured Porta-Switch
system. You can directly get these backups from the web [111206 i] (protected) [111206 i] (public).
Step by step, we will explain how to:
- Restore the partition of the Porta-Switch MR23 installation
- Compile/install a new kernel for RedHat distribution on OVH server
- Install a new initial ram disk for Red Hat
- Configure the network of new system with VLANs
- Configure a boot loader (GRUB2)
Once all these steps are carried out, you will be able to boot on an OVH.net server cloned Red Hat OS
of one of the MR23 system server.
Page 3 of 66
Installing Fedora at OVH
3 Installing Fedora at OVH
3.1 Choose/order a server
Go to the OVH manager web interface [go] and choose the server you wish to install.
NB: Pay attention so as to the minimum hardware configuration needed by the server you will install.
3.2 Install Fedora with a custom partitioning
After having chosen the server, go under “Services”, “Réinstaller/Changer d’OS”. Choose “Système
d’exploitation Linux”, “[…]Fedora Core 15 ‘Lovelock’”, “64 bits”. Then opt for a personalised
partitioning.
Through OVH manager, we will prepare a pre-release of our server partitioning. We will need the
following partitioning:

/, for the root of the Fedora OS.

A swap partition for Fedora

/boot, that will contains the GRUB2 manager, various kernels and booting instructions for
grub concerning in particular the choice of Fedora or Red Hat.

An LVM partition that will contain all virtual partitions of the Red Hat Porta-Switch release.
The OVH.net partitioning manager doesn’t allow us to keep an empty space for the LVM partition
that have to be created manually from Fedora.
Page 4 of 66
Installing Fedora at OVH
To bypass the restriction, we will have to create a /tmp mounting point, that we will remove later in
order to allocate the space to the LVM partitions.
The partitioning of the new installation for a 1000000 MB disk (kimsufi) will be as follow:
Disk partitions
8 GB
50 GB
50 GB
[sda1] /boot
[sda2] /
[sda3] /tmp
[sda4] swap
869 GB
Depending on the disk size you have, keep the same values for the sda1, sda2 and sda4 partitions.
Calculate the size of /dev/sda3 disk which has to be the largest partition. Below is an example of
allocation for a 1000000 MB space:
Partition number
1
2
3
4
Partition type
primary
ext3
ext3
ext3
System file
ext3
ext3
ext3
swap
Mounting point
/boot
/
/tmp
none
Total
(/dev/sda3 = – 51200 – 51200 – 8192 + 1000000 = 889408 MB)
Size (MB)
51200
51200
889408
8192
1000000
Once you have finished configuring the
partitioning, you can launch the
installation of Fedora by clicking on
“Lancer la reinstallation”.
The next chapter describes the particular
networking configuration we need to
prepare for operation of MR23.
Page 5 of 66
Adding VLANs interfaces
4 Adding VLANs interfaces
According to the PortaOne requirements, we need a minimum of two Network Interface Controller
on each sever. One is required for communication with the configurator and the second one is
required for services (SIP, MySQL, Radius ...).
To bypass this restriction (second NIC at ovh.com is too much expensive), we tested and decided to
implement two VLAN interfaces for each server with different IP addresses.
Before beginning the installation of the Porta-Switch installation, you have to configure VLANs and
test them. Details of the double interface requirement and our choices are published on a different
document [111116 i].
4.1 Add two IP failover to your server
Go back to the OVH management interface of your server, in the Services category. Choose IP failover
and add two IP failover addresses according to the following diagram:
Page 6 of 66
Adding VLANs interfaces
4.2 Configure the VLANs interfaces
Once the installation of your new server running under Fedora has been completed, you can login
into the server using SSH with the password that you receive automatically by email following your
web request for the installation of Fedora.
By default, OVH servers are equipped with VLAN support, let’s configure our VLAN interfaces.
The configuration of each Network Interface Controller on the Fedora or Red Hat distributions is
based on configuration files stored in the network scripts folder. Each ifcfg-ethx or ifcfg-vlanx file in
/etc/sysconfig/network-scripts/ correspond to the configuration of an individual NIC.
Begin by editing a new configuration file for the vlan5 interface:
[root@server ~]# vi /etc/sysconfig/network-scripts/ifcfg-vlan5
Past the content bellow, and replace the IP address with one IP failover address you configured via
the OVH manager (Section 4.1):
VLAN=yes
VLAN_NAME_TYPE=VLAN_PLUS_VID_NO_PAD
DEVICE=vlan5
PHYSDEV=eth0
BOOTPROTO=static
ONBOOT=yes
TYPE=Ethernet
IPADDR=87.xxx.xxx.xxx
NETMASK=255.xxx.xxx.xxx
Then configure the vlan6 interface with the second IP failover address you ordered via the OVH web
manager (Section 4.1):
[root@server ~]# vi /etc/sysconfig/network-scripts/ifcfg-vlan6
Replace the IP address:
VLAN=yes
VLAN_NAME_TYPE=VLAN_PLUS_VID_NO_PAD
DEVICE=vlan6
PHYSDEV=eth0
BOOTPROTO=static
ONBOOT=yes
TYPE=Ethernet
IPADDR=87.xxx.xxx.xxx
NETMASK=255.xxx.xxx.xxx
4.3 Activate the VLANs interfaces:
VLANs interfaces are now configured; you only need to activate them.
[root@server ~]# service network restart
Restarting network (via systemctl):
Page 7 of 66
[
OK
]
Adding VLANs interfaces
With ifconfig command, you must see the both new VLANs interfaces configured with the right IP
addresses.
[root@server ~]# ifconfig
eth0
Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
inet addr:176.xxx.xxx.xxx Bcast:176.xxx.xxx.255 Mask:255.xxx.xxx.0
inet6 addr: xxxx::xxxx:xxxx:xxxx:xxxx/xx Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1943 errors:0 dropped:0 overruns:0 frame:0
TX packets:2323 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:232448 (227.0 KiB) TX bytes:324708 (317.0 KiB)
Interrupt:44 Base address:0x2000
lo
Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:13 errors:0 dropped:0 overruns:0 frame:0
TX packets:13 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1627 (1.5 KiB) TX bytes:1627 (1.5 KiB)
vlan5
Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
inet addr:87.xxx.xxx.xxx Bcast:87.xxx.xxx.xxx Mask:255.xxx.xxx.xxx
inet6 addr: xxxx::xxxx:xxxx:xxxx:xxxx/xx Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:636 (636.0 b)
vlan6
Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
inet addr:87.xxx.xxx.xxx Bcast:87.xxx.xxx.xxx Mask:255.xxx.xxx.xxx
inet6 addr: xxxx::xxxx:xxxx:xxxx:xxxx/xx Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:476 (476.0 b)
Try to ping the server through its two new interfaces:
Nicolas Bondier@Computer ~
$ ping 87.xxx.xxx.xxx
PING 87.xxx.xxx.xxx (87.xxx.xxx.xxx): 56 data bytes
64 bytes from 87.xxx.xxx.xxx: icmp_seq=0 ttl=53 time=62 ms
64 bytes from 87.xxx.xxx.xxx: icmp_seq=1 ttl=53 time=97 ms
----87.xxx.xxx.xxx PING Statistics---2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip (ms) min/avg/max/med = 62/80/97/80
Nicolas Bondier@Computer ~
$ ping 87.xxx.xxx.xxx
Page 8 of 66
Adding VLANs interfaces
PING 87.xxx.xxx.xxx (87.xxx.xxx.xxx): 56 data bytes
64 bytes from 87.xxx.xxx.xxx: icmp_seq=0 ttl=53 time=53 ms
64 bytes from 87.xxx.xxx.xxx: icmp_seq=1 ttl=53 time=37 ms
----87.xxx.xxx.xxx PING Statistics---2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip (ms) min/avg/max/med = 37/45/53/45
Page 9 of 66
Creating the volume group and its logical partitions
5 Creating the volume group and its logical partitions
Now we will create a new LVM partition on which we are going to restore the Red Had 5.3 MR23.
5.1 Unmount the partition reserved for LVM
Begin by unmounting the temporary partition created for the LVM of Porta-Switch installation.
[root@ks34280 boot]# umount /tmp
By watching the /etc/fstab configuration file (used for mapping the mounting points with the
corresponding devices), you will notice that /dev/sda3 is attached to /tmp directory:
root@server ~]#
# <file system>
/dev/sda2
/dev/sda1
/dev/sda3
/dev/sda4
proc
sysfs
tmpfs
devpts
dev
cat /etc/fstab
<mount point>
<type> <options>
/
ext3
errors=remount-ro
/boot
ext3
errors=remount-ro
/tmp
ext3
defaults
1
swap
swap
defaults
0
/proc
proc
defaults
/sys
sysfs
defaults
/dev/shm
tmpfs
defaults
/dev/pts
devpts defaults
/dev
devtmpfs
rw
0
<dump>
0
0
2
0
0
0
0
0
0
<pass>
1
1
0
0
0
0
Edit and delete the corresponding line from the file, and save your modifications. The /etc/fstab file
must have no reference to /dev/sda3:
[root@server ~]# cat /etc/fstab
# <file system> <mount point>
<type> <options>
/dev/sda2
/
ext3
errors=remount-ro
/dev/sda1
/boot
ext3
errors=remount-ro
/dev/sda4
swap
swap
defaults
0
proc
/proc
proc
defaults
sysfs
/sys
sysfs
defaults
tmpfs
/dev/shm
tmpfs
defaults
devpts
/dev/pts
devpts defaults
dev
/dev
devtmpfs
rw
0
<dump>
0
0
0
0
0
0
0
0
<pass>
1
1
0
0
0
0
5.2 Preparing the physical hard disk
First, begin to display, using the fdisk tool, the partitions of your disk. Pay attention to the start and
end of the /dev/sda3 partition. When we will create the partition again, the default values provided
by the fdisk tool can be wrong.
[root@server ~]# fdisk -l /dev/sda
Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0002bf29
Page 10 of 66
Creating the volume group and its logical partitions
Device Boot
Start
/dev/sda1
*
4096
/dev/sda2
104859649
/dev/sda3
209715201
/dev/sda4
1919963137
End
104859648
209715200
1919963136
1953515520
Blocks
52427776+
52427776
855123968
16776192
Id
83
83
83
82
System
Linux
Linux
Linux
Linux swap / Solaris
Delete and recreate the /dev/sda3 partition:
[root@ks34280 boot]# fdisk /dev/sda
Command (m for help): d
Partition number (1-4): 3
Command (m for help): p
Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0002bf29
Device Boot
Start
/dev/sda1
*
4096
/dev/sda2
104859649
/dev/sda4
1919963137
End
104859648
209715200
1953515520
Blocks
52427776+
52427776
16776192
Id
83
83
82
System
Linux
Linux
Linux swap / Solaris
Command (m for help): n
Command action
e
extended
p
primary partition (1-4)
p
Selected partition 3
First sector (2048-1953525167, default 2048): 209715201
Last sector, +sectors or +size{K,M,G} (209715201-1919963136, default 1919963136):
1919963136
Command (m for help): p
Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0002bf29
Device Boot
Start
/dev/sda1
*
4096
/dev/sda2
104859649
/dev/sda3
209715201
/dev/sda4
1919963137
End
104859648
209715200
1919963136
1953515520
Blocks
52427776+
52427776
855123968
16776192
While still in fdisk, set the type of the 3rd partition to LVM.
Page 11 of 66
Id
83
83
83
82
System
Linux
Linux
Linux
Linux swap / Solaris
Creating the volume group and its logical partitions
Command (m for help): t
Partition number (1-4): 3
Hex code (type L to list codes): 8e
Changed system type of partition 3 to 8e (Linux LVM)
Command (m for help): p
Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0002bf29
Device Boot
Start
/dev/sda1
*
4096
/dev/sda2
104859649
/dev/sda3
209715201
/dev/sda4
1919963137
End
104859648
209715200
1919963136
1953515520
Blocks
52427776+
52427776
855123968
16776192
Id
83
83
8e
82
System
Linux
Linux
Linux LVM
Linux swap / Solaris
Then, you can apply the changes and reboot.
Command (m for help): w
…
Command (m for help): q
[root@server ~]# reboot
5.3 Create the volume group
First, with the pvcreate command, we 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/sda3
Once the device is prepared for the possible usage by the LVM, you can display its status with
pvdisplay command.
[root@server ~]# pvdisplay /dev/sda3
--- NEW Physical volume --PV Name
/dev/sda3
VG Name
PV Size
815.51 GiB
Allocatable
NO
PE Size
0
Total PE
0
Free PE
0
Allocated PE
0
PV UUID
...
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 is the name of the volume group being
created (VolGroup01 for billing4 and VolGroup00 for the others if you take the tar files of this link
Page 12 of 66
Creating the volume group and its logical partitions
[111206 i]). Refer to this chapter [100926 i] [100926 ii] of the precedent documentation if you want
to retrieve the volume group name of any of the tar files you have got.
vgcreate VolGroup01 /dev/sda3
5.4 Create the logical volumes
Once the volume group is created you can find out the space available in the volume group with the
vgdisplay command:
[root@server ~]# vgdisplay VolGroup01
--- Volume group --VG Name
VolGroup01
System ID
Format
lvm2
Metadata Areas
1
Metadata Sequence No 1
VG Access
read/write
VG Status
resizable
MAX LV
0
Cur LV
0
Open LV
0
Max PV
0
Cur PV
1
Act PV
1
VG Size
815.51 GiB
PE Size
4.00 MiB
Total PE
208770
Alloc PE / Size
0 / 0
Free PE / Size
208770 / 815.51 GiB
VG UUID
DS5aad-oBBj-F0va-6upG-snJi-7z0d-JyPeXT
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. The argument of the option –n is the name gived to the volume group.
#
#
#
#
lvcreate
lvcreate
lvcreate
lvcreate
-l
-l
-l
-l
5000 VolGroup01 -n LogVol00
5000 VolGroup01 -n LogVol01
8000 VolGroup01 -n LogVol03
190770 VolGroup01 -n LogVol02
The total number of extents must be equal to the total number of available extents shown by
vgdisplay command: 5000+5000+8000+190770=208770.
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
Page 13 of 66
Creating the volume group and its logical partitions
respectively. Then, 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.
[root@server ~]# vgdisplay VolGroup01
...
Free PE / Size
190770 / 835.08 GiB
...
[root@server ~]# lvcreate -l 190770 VolGroup01 -n LogVol02
After allocation the vgdisplay output shall look as follows:
[root@server ~]# vgdisplay VolGroup01
--- Volume group --VG Name
VolGroup01
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
1
Max PV
0
Cur PV
1
Act PV
1
VG Size
815.51 GiB
PE Size
4.00 MiB
Total PE
208770
Alloc PE / Size
208770 / 815.51 GiB
Free PE / Size
0 / 0
VG UUID
DS5aad-oBBj-F0va-6upG-snJi-7z0d-JyPeXT
Once the logical volumes are created, you will see in the /dev directory a folder with the name of the
volume group (VolGroup01 in our case) containing files (or symbolic links) with the names of logical
volumes (LogVol00, LogVol01, LogVol02, and LogVol03):
[root@server root1]# ls /dev/VolGroup01/
LogVol00 LogVol01 LogVol02 LogVol03
[root@server root1]#
The files in /dev/VolGroup01/ 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.
Page 14 of 66
Formatting Partitions
6 Formatting Partitions
After allocate all the extents of the volume group, we now have a primary disk partition for booting
Fedora or Red Hat , a primary partition for Fedora and four logical volumes (root1, root2, swap, and
porta for Red Hat). They must be formatted. Follow the example below:
[root@server
[root@server
[root@server
[root@server
~]#
~]#
~]#
~]#
mkfs -t ext3 /dev/VolGroup01/LogVol00
mkfs -t ext3 /dev/VolGroup01/LogVol01
mkfs -t ext3 /dev/VolGroup01/LogVol02
mkswap /dev/VolGroup01/LogVol03
Unlike instructions given in the how-to for restoring tar files on local machines [120110 i], DO NOT
format the /dev/sda1 partition. We are going to use the grub installed during the Fedora installation.
The/etc/fstab files of the Porta-Switch servers are the following:
/dev/VolGroup01/LogVol00 /
/dev/VolGroup01/LogVol02 /porta_var
/dev/VolGroup01/LogVol01 /update_root
LABEL=/boot
/boot
tmpfs
/dev/shm
devpts
/dev/pts
sysfs
/sys
proc
/proc
/dev/VolGroup01/LogVol03 swap
ext3
ext3
ext3
ext3
tmpfs
devpts
sysfs
proc
swap
defaults
defaults
defaults
defaults
defaults
gid=5,mode=620
defaults
defaults
defaults
1 1
1 2
1 2
1 2
0 0
0 0
0 0
0 0
0 0
The files 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:
[root@server ]# e2label /dev/sda1 /boot
Page 15 of 66
Mounting Partitions
7 Mounting Partitions
As the partitions are all formatted, you can now mount them as follows:
[root@server
[root@server
[root@server
[root@server
[root@server
[root@server
[root@server
~]# cd /mnt
mnt]# mkdir
mnt]# mkdir
mnt]# mkdir
mnt]# mount
mnt]# mount
mnt]# mount
root1
root2
porta
/dev/VolGroup01/LogVol00 root1
/dev/VolGroup01/LogVol01 root2
/dev/VolGroup01/LogVol02 porta
On a restored system the output of the df command looks as follows:
Filesystem
1K-blocks
rootfs
52014716
/dev/root
52014716
devtmpfs
1016548
tmpfs
1016852
tmpfs
1016852
tmpfs
1016852
tmpfs
1016852
/dev/sda1
52014716
[...]
/dev/mapper/VolGroup01-LogVol00
20158332
/dev/mapper/VolGroup01-LogVol01
20158332
/dev/mapper/VolGroup01-LogVol02
769132592
Used Available Use% Mounted on
2405524 46987804
5% /
2405524 46987804
5% /
0
1016548
0% /dev
0
1016852
0% /dev/shm
1388
1015464
1% /run
232
1016620
1% /sys/fs/cgroup
0
1016852
0% /media
208592 49184736
1% /boot
3465176
15669156
1% /mnt/root1
176200
18958132
1% /mnt/root2
283020 729779876
1% /mnt/porta
Page 16 of 66
Download tar files
8 Download tar files
The simplest way to download the tar files on your server is to get them from the Switzernet NAS
located in the office. It uses a fixed VTX IP address and is accessible by ssh. You can also download it
from the Switzernet.com web server.
The links to all the files can be found here [111206 i].
8.1 Downloading the tar files of root1 partition
In the examples bellow, we use the blowfish cipher, which brings a low encryption and by the way
better download speed and less CPU consumption.
Go on the /mnt/root1 folder and download the content of the root1 partition of the billing4 server
(sip server).
[root@server mnt]# cd /mnt/root1
[root@server root1]# scp -c blowfish admin@212.xxx.xxx.xxx:/share/MD0_DATA/portabilling-mr23/tar/111202,1810,billing4,root1.tar.bzip2 .
8.2 Downloading the tar files of root2 partition
Same here for root2:
[root@server mnt]# cd /mnt/root2
[root@server root2]# scp -c blowfish admin@212.xxx.xxx.xxx:/share/MD0_DATA/portabilling-mr23/tar/111202,1810,billing4,root2.tar.bzip2 .
8.3 Downloading the tar files of porta partition
And finally the same for the porta mounting point:
[root@server mnt]# cd /mnt/porta
[root@server porta]# scp -c blowfish admin@212.xxx.xxx.xxx:/share/MD0_DATA/portabilling-mr23/tar/111202,1810,billing4,porta.tar.bzip2 .
Page 17 of 66
Extract the content of tar files
9 Extract the content of tar files
Extract the tar files into their respective partitions, as shown in the notes below:
[root@server mnt]# cd /mnt/root1
[root@server root1]# tar -xjvf 111202,1810,billing4,root1.tar.bzip2
...
[root@server root1]# cd /mnt/root2
[root@server root2]# tar -xjvf 111202,1810,billing4,root2.tar.bzip2
...
[root@server root2]# cd /mnt/porta
[root@server porta]# tar -xjvf 111202,1810,billing4,porta.tar.bzip2
...
Page 18 of 66
Configure the network of Porta -Switch server before booting.
10 Configure the network of Porta-Switch server before booting.
As we said before, on both Fedora and Red Hat systems, the network interfaces can be configured via
the configuration files of the /etc/sysconfig/network-scripts/ directory. The syntax is identical for
both OS.
Then, the configuration files of both systems will be the same. You just need to copy the interface
configuration scripts of your running Fedora into the corresponding Red Hat directory.
[root@server
[root@server
[root@server
[root@server
mnt]# cd /mnt/root1/etc/sysconfig/network-scripts/
network-scripts]# cp /etc/sysconfig/network-scripts/ifcfg-eth0 .
network-scripts]# cp /etc/sysconfig/network-scripts/ifcfg-vlan5 .
network-scripts]# cp /etc/sysconfig/network-scripts/ifcfg-vlan6 .
When at booting, Red Hat detects that the configuration files have been modified, it renames them
adding ‘.bak’ extension. For example, ifcfg-eth0 is moved to ifcfg-eth0.bak. We did not find out the
reason.
The solution is to create our own temporary script that will move back the ifcfg-eth0.bak to ifcfg-eth0
in order to activate the network interfaces after booting. Otherwise, we will not be able to access the
remote server installed on OVH.net.
Create a new script as below:
# vi /mnt/root1/root/network-reconf-first-boot.sh
And past the following content in the new script.
#!/bin/bash
if [ -f /etc/sysconfig/network-scripts/ifcfg-eth0.bak ]
then
mv /etc/sysconfig/network-scripts/ifcfg-eth0.bak /etc/sysconfig/networkscripts/ifcfg-eth0
/etc/init.d/network restart
fi
exit 0
Make the script executable:
# chmod +x /mnt/root1/root/network-reconf-first-boot.sh
Edit the rc.local file of Red Hat in order to launch our new script at the end of the booting.
# vi /mnt/root1/etc/rc.d/rc.local
And add the new line (in purple) at the end of the rc.local file:
#!/bin/sh
Page 19 of 66
Configure the network of Porta -Switch server before booting.
#
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don't
# want to do the full Sys V style init stuff.
touch /var/lock/subsys/local
/root/network-reconf-first-boot.sh
NB: The above script, and the added line in the rc.local file must be removed later after first boot.
Page 20 of 66
Compile the Switzernet custom kernel
11 Compile the Switzernet custom kernel
Here we describe how-to compile a Fedora kernel that contains the drivers required for the Red Hat
servers of OVH.net. We first compile the kernel under Fedora, then we will replace the kernel of Red
Hat by the one compiled under Fedora.
11.1 Download the kernel source
First of all, create a work folder and change the current directory into that folder.
[root@ks389032
/root
[root@ks389032
[root@ks389032
[root@ks389032
~]# pwd
~]# mkdir kernel
~]# cd kernel/
kernel]#
Now we download the last revision of the Fedora 15 kernel source from Fedora’s site [go].
[root@ks389032 kernel]# wget
http://download.fedora.redhat.com/pub/fedora/linux/updates/15/SRPMS/kernel2.6.41.4-1.fc15.src.rpm
--2011-12-16 11:48:03-http://download.fedora.redhat.com/pub/fedora/linux/updates/15/SRPMS/kernel2.6.41.4-1.fc15.src.rpm
Resolving download.fedora.redhat.com... 209.132.181.25, 209.132.181.26,
209.132.181.27, ...
Connecting to download.fedora.redhat.com|209.132.181.25|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 78059962 (74M) [application/x-rpm]
Saving to: "kernel-2.6.41.4-1.fc15.src.rpm"
100%[==============================================>] 78,059,962
10.8M/s
in 9.1s
2011-12-16 11:48:16 (8.19 MB/s) - "kernel-2.6.41.4-1.fc15.src.rpm" saved
[78059962/78059962]
[root@ks389032 kernel]#
11.2 Download the OVH template
If we try to follow the usual kernel compilation procedure, our custom kernel will have a little chance
to boot. This is because OVH uses its own servers with its own OVH kernel. One particularity of the
OVH native kernel is that doesn’t support modules.
OVH offers a configuration template permitting to build a kernel compatible with the hardware of
OVH.net servers.
First of all, in order to retrieve the OVH.net corresponding kernel, we need to know which kernel
version we are running:
[root@ks389032 SPECS]# uname -r
2.6.38.2-grsec-xxxx-grs-ipv6-64
[root@ks389032 SPECS]#
Page 21 of 66
Compile the Switzernet custom kernel
We then download the kernel compilation template of OVH.net corresponding to the version of the
kernel initially running on the server (OVH provides on the original server only the binaries of the
kernel).
ftp://ftp.ovh.net/made-in-ovh/bzImage/2.6.38.2-2/
[root@ks389032 kernel]# wget ftp://ftp.ovh.net/made-in-ovh/bzImage/2.6.38.2-2/2.6config-xxxx-std-ipv6-64
--2011-12-16 11:46:29-- ftp://ftp.ovh.net/made-in-ovh/bzImage/2.6.38.2-2/2.6config-xxxx-std-ipv6-64
=> "2.6-config-xxxx-std-ipv6-64"
Resolving ftp.ovh.net... 213.186.33.9
Connecting to ftp.ovh.net|213.186.33.9|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.
==> PWD ... done.
==> TYPE I ... done. ==> CWD (1) /made-in-ovh/bzImage/2.6.38.2-2 ... done.
==> SIZE 2.6-config-xxxx-std-ipv6-64 ... 62396
==> PASV ... done.
==> RETR 2.6-config-xxxx-std-ipv6-64 ... done.
Length: 62396 (61K) (unauthoritative)
100%[====================================================>] 62,396 --.-K/s in 0.02s
2011-12-16 11:46:31 (3.35 MB/s) - "2.6-config-xxxx-std-ipv6-64" saved [62396]
[root@ks389032 kernel]#
11.3 Build the structure
At this point we are ready to begin with the kernel compilation procedure, so we install the following
packages:

rpmdevtools

yum-utils (it is a default package)

ncurses-devel
yum install rpmdevtools yum-utils ncurses-devel
Additionally, to avoid the following compilation error:
drivers/scsi/libsas/sas_scsi_host.c: In function 'sas_scsi_task_done':
drivers/scsi/libsas/sas_scsi_host.c:116:3: warning: case value '2' not in
enumerated type 'enum exec_status' [-Wswitch]
drivers/scsi/libsas/sas_ata.c: In function 'sas_to_ata_err':
drivers/scsi/libsas/sas_ata.c:80:3: warning: case value '2' not in enumerated type
'enum exec_status' [-Wswitch]
/bin/sh: lzma: command not found
make[2]: *** [arch/x86/boot/compressed/vmlinux.bin.lzma] Error 1
make[1]: *** [arch/x86/boot/compressed/vmlinux] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [bzImage] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.SpWuR2 (%build)
Page 22 of 66
Compile the Switzernet custom kernel
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.SpWuR2 (%build)
[root@ks389032 SPECS]#
We need to install lzma package (a compression tool used by the kernel compilation utility).
[root@ks389032 SPECS]# yum install lzma
Loaded plugins: langpacks, presto, refresh-packagekit
Setting up Install Process
Package lzma is obsoleted by xz-lzma-compat, trying to install xz-lzma-compat...
Installed:
xz-lzma-compat.x86_64 0:5.0.3-1.fc15
Complete!
[root@ks389032 SPECS]#
Prepare a RPM package building environment in your home directory as follows:
rpmdev-setuptree
[root@ks389032 kernel]# rpmdev-setuptree
[root@ks389032 kernel]# ls -lrt /root/
total 8
drwxr-xr-x 2 root root 4096 Dec 16 11:48 kernel
drwxr-xr-x 7 root root 4096 Dec 16 11:53 rpmbuild
[root@ks389032 kernel]# ls -lrt /root/rpmbuild/
total 20
drwxr-xr-x 2 root root 4096 Dec 16 11:53 SRPMS
drwxr-xr-x 2 root root 4096 Dec 16 11:53 SPECS
drwxr-xr-x 2 root root 4096 Dec 16 11:53 SOURCES
drwxr-xr-x 2 root root 4096 Dec 16 11:53 RPMS
drwxr-xr-x 2 root root 4096 Dec 16 11:53 BUILD
[root@ks389032 kernel]#
This command creates different directories:

/root/rpmbuild/RPMS

/root/rpmbuild/SOURCES

/root/rpmbuild/SPECS

/root/rpmbuild/SRPMS

/root/rpmbuild/BUILD
The /rpmbuild folder will be created inside your home user folder (in our case home folder is /root).
Page 23 of 66
Compile the Switzernet custom kernel
Now we must install “build dependencies” for the kernel source with the yum-builddep command
(root mode is required to install these packages):
yum-builddep kernel-2.6.41.4-1.fc15.src.rpm
[root@ks389032 kernel]# yum-builddep kernel-2.6.41.4-1.fc15.src.rpm
Loaded plugins: langpacks, presto, refresh-packagekit
Getting requirements for kernel-2.6.41.4-1.fc15.src
--> Already installed : module-init-tools-3.12-5.fc15.x86_64
...
...
--> Finished Dependency Resolution
Dependencies Resolved
===================================================================================
=============================================================================
Package
Arch
Version
Repository
Size
===================================================================================
=============================================================================
Installing:
...
updates
83 k
...
Transaction Summary
===================================================================================
=============================================================================
Install
Upgrade
37 Package(s)
9 Package(s)
Total size: 55 M
Total download size: 29 M
Is this ok [y/N]: y
NB: Run the command in the same folder where the source package has been downloaded or run it
with the full path.
Install kernel-2.6.41.4-1.fc15.src.rpm with the following command:
rpm -Uvh kernel-2.6.41.4-1.fc15.src.rpm
[root@ks389032 kernel]# rpm -Uvh kernel-2.6.41.4-1.fc15.src.rpm
1:kernel
warning: user mockbuild does not exist - using ro
warning: group mockbuild does not exist - using root
...
warning: group mockbuild does not exist - using root
########################################### [100%]
warning: group mockbuild does not exist - using root
...
warning: group mockbuild does not exist - using root
[root@ks389032 kernel]#
Page 24 of 66
Compile the Switzernet custom kernel
This command writes the RPM contents into /root/rpmbuild/SOURCES and /root/rpmbuild/SPECS,
always inside our home folder. The messages similar to the following can be safety ignored:
warning: user mockbuild does not exist - using root
warning: group mockbuild does not exist - using root
11.4 Prepare the kernel source tree
The next step expands the source code files of the kernel. A number of system level drivers and
programs are available in for compilation and they require the kernel source for that purpose. One of
such programs is USB over IP, which we can compile and install only if kernel source code is available.
cd /root/rpmbuild/SPECS
rpmbuild -bp --target=x86_64 kernel.spec
[root@ks389032 kernel]# cd ../rpmbuild/SPECS/
[root@ks389032 SPECS]# rpmbuild -bp --target=x86_64 kernel.spec
Building target platforms: x86_64
Building for target x86_64
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.TTWiFr
+ umask 022
+ cd /root/rpmbuild/BUILD
+ LANG=C
+ export LANG
+ unset DISPLAY
+ patch_command='patch -p1 -F1 -s'
++ find /root/rpmbuild/BUILD -maxdepth 1 -type d -name 'kernel-3.*'
++ grep -x -v /root/rpmbuild/BUILD/kernel-2.6.41.fc15
+ sharedirs=
+ :
+ '[' '!' -d kernel-2.6.41.fc15/vanilla-3.1 ']'
+ '[' -d kernel-2.6.41.fc15/vanilla-3.1 ']'
+ rm -f pax_global_header
+ [[ ! -z '' ]]
+ cd /root/rpmbuild/BUILD
+ rm -rf kernel-2.6.41.fc15
+ /bin/mkdir -p kernel-2.6.41.fc15
+ cd kernel-2.6.41.fc15
+ /usr/bin/bzip2 -dc /root/rpmbuild/SOURCES/linux-3.1.tar.bz2
+ /bin/tar -xf -
#
# configuration written to .config
#
+ echo '# x86_64'
+ cat .config
+ for i in '*.config'
+ mv kernel-2.6.41.4-x86_64.config .config
++ head -1 .config
++ cut -b 3+ Arch=x86_64
+ make ARCH=x86_64 listnewconfig
Page 25 of 66
Compile the Switzernet custom kernel
+ grep -E '^CONFIG_'
.config:4678:warning: override: reassigning to symbol DEBUG_BLK_CGROUP
+ true
+ '[' -s .newoptions ']'
+ rm -f .newoptions
+ make ARCH=x86_64 oldnoconfig
scripts/kconfig/conf --oldnoconfig Kconfig
.config:4678:warning: override: reassigning to symbol DEBUG_BLK_CGROUP
#
# configuration written to .config
#
+ echo '# x86_64'
+ cat .config
+ find . '(' -name '*.orig' -o -name '*~' ')' -exec rm -f '{}' ';'
+ find . -name .gitignore -exec rm -f '{}' ';'
+ cd ..
+ exit 0
[root@ks389032 SPECS]#
With the rpmbuild -bp command, we do a partial build of the new kernel (until %prep section inside
the kernel.spec file), in which we apply the kernel official patches and we specified the architecture
the kernel will be build for (option --target)
The kernel source tree is now located in the /root/rpmbuild/BUILD/kernel-2.6.41.fc15/linux2.6.41.x86_64/ directory.
We can start to personalize our new kernel by editing the Makefile file and changing the value of the
EXTRAVERSION parameter:
cd /root/rpmbuild/BUILD/kernel-2.6.41.fc15/linux-2.6.41.x86_64/
vi Makefile
VERSION = 3
PATCHLEVEL = 1
SUBLEVEL = 4
EXTRAVERSION = .4-1.switzernet.fc15.x86_64
NAME = "Divemaster Edition"
#
#
#
#
#
*DOCUMENTATION*
To see a list of typical targets execute "make help"
More info can be located in ./README
Comments in this file are targeted only to the developer, do not
expect to learn how to build the kernel reading this file.
We can find all the generic configuration files in the path /root/rpmbuild/SOURCES:
[root@ks389032 linux-2.6.41.x86_64]# ls /root/rpmbuild/SOURCES/ | grep config
config-arm-generic
config-arm-omap-generic
config-arm-tegra
config-debug
config-generic
config-i686-PAE
Page 26 of 66
Compile the Switzernet custom kernel
config-local
config-nodebug
config-powerpc32-generic
config-powerpc32-smp
config-powerpc64
config-powerpc-generic
config-rhel-generic
config-s390x
config-sparc64-generic
config-x86-32-generic
config-x86_64-generic
config-x86-generic
Makefile.config
When we execute the command rpmbuild, the generic configuration file related with the
architecture that we have specified with the --target field, is copied into the
/root/rpmbuild/BUILD/kernel-2.6.41.fc15/linux-2.6.41.x86_64/configs/ directory with the following
name: kernel-2.6.41.4-x86_64.config.
[root@ks389032 linux-2.6.41.x86_64]# cd configs
[root@ks389032 configs]# ls -lrt
total 136
-rw-r--r-- 1 root root 64292 Dec 16 13:08 kernel-2.6.41.4-x86_64-debug.config
-rw-r--r-- 1 root root 64303 Dec 16 13:08 kernel-2.6.41.4-x86_64.config
[root@ks389032 configs]#
Another copy is saved in the .config file. This file is used to build our new kernel. We have to replace
this file for compliance with OVH. This configuration file is located under
/root/rpmbuild/BUILD/kernel-2.6.41.fc15/linux-2.6.41.x86_64/.config.
11.5 Copy the OVH configuration template
After the steps carried out in previous sections, we can now start configuring the kernel options.
Remember that we want to run this kernel over a Red Hat distribution installed in an OVH server.
In order to run our new Fedora kernel at OVH, we need to replace the Fedora configuration file
(/root/rpmbuild/BUILD/kernel-2.6.41.fc15/linux-2.6.41.x86_64/.config) with the OVH configuration
template:
cp -a /root/kernel/2.6-config-xxxx-std-ipv6-64 /root/rpmbuild/BUILD/kernel2.6.41.fc15/linux-2.6.41.x86_64/.config
[root@ks389032 linux-2.6.41.x86_64]# cp -a /root/kernel/2.6-config-xxxx-std-ipv6-64
.config
cp: overwrite `.config'? y
[root@ks389032 linux-2.6.41.x86_64]#
11.6 Configure kernel options
Change the directory to the kernel source tree directory:
Page 27 of 66
Compile the Switzernet custom kernel
cd /root/rpmbuild/BUILD/kernel-2.6.41.fc15/linux-2.6.41.x86_64/
To perform changes on the default Fedora kernel, we use a configuration tool to edit the OVH .config
file. Run the following command, selecting and saving the desired kernel options from the text-based
UI:
make menuconfig
[root@ks389032 linux-2.6.41.x86_64]# make menuconfig
HOSTCC scripts/kconfig/lxdialog/checklist.o
HOSTCC scripts/kconfig/lxdialog/inputbox.o
HOSTCC scripts/kconfig/lxdialog/menubox.o
HOSTCC scripts/kconfig/lxdialog/textbox.o
scripts/kconfig/lxdialog/textbox.c: In function 'print_line':
scripts/kconfig/lxdialog/textbox.c:323:9: warning: variable 'x' set but not used [Wunused-but-set-variable]
scripts/kconfig/lxdialog/textbox.c:323:6: warning: variable 'y' set but not used [Wunused-but-set-variable]
HOSTCC scripts/kconfig/lxdialog/util.o
Fedora is a distribution that is in a continuous evolution and development (like most of the Linux
distributions). This is not the case of Red Hat. As Red Hat is one of the most stable distributions, it
use old and reliable kernel versions that were tested until the end. As they use old kernel versions,
they use deprecated features and commands. This is the reason why we must select this option for
our future new kernel.
NB: tip ‘Y’ for building the highlighted selection as part of the kernel, ‘M’ for building it as a module
and ‘N’ to exclude the highlighted selection of the kernel.
General setup  [*] Enable deprecated sysfs features to support old userspace tools
General setup  [*] Enable deprecated sysfs features by default
Don’t forget to add module feature to our kernel:
[*] Enable loadable module support
Page 28 of 66
Compile the Switzernet custom kernel
Also, it is a good idea if we compile the Ethernet drivers as part of the kernel instead of as modules.
This way, we can be sure that the Ethernet connection will work without problems (don’t forget to
include the 801.2q protocol as we want work with VLANs, a condition required by MR23).
Networking support  Networking options  <*> 802.1Q VLAN Support
The USB support of our Red Hat distribution is no more used in the recent Linux distributions. It is
deprecated in the kernel and we must reactivate it if we want to enable USB on our Red Hat server. It
is very important for enabling for USB over IP support that we use for Configurator and must be
activated anyway on every servers.
Device drivers  USB support  [*] USB device filesystem <DEPRECATED>
Device drivers  USB support  [*] USB device class.devices <DEPRECATED>
To support USB over IP we need to enable it in the kernel. As you may know, the configurator uses a
USB dongle to validate the Porta One license. As we do not have physical access to the server to plug
the USB dongle, we use USB over IP to remotely connect the USB dongle on the configurator for
activating the license.
USB over IP is currently in the staging drivers, meaning that it is not ready to be merged into the main
portion of the Linux kernel tree at this point in time for various technical reasons. Activate the
features:
Device drivers  Staging drivers  <M> USB/IP support
Page 29 of 66
Compile the Switzernet custom kernel
Device drivers  Staging drivers  <M> VHCI hcd
Device drivers  Staging drivers  <M> Host driver
Device drivers  Staging drivers  [*] Debug messages for USB/IP
After configure all these options, during the booting maybe we have some error messages. Let’s have
a look on how to fix them.
Related with the auditing system we have the following error message during the booting:
it is necessary add the auditing support:
General setup  [*] Auditing support
General setup  [*] Enable system-call auditing support
We have other error messages related with modules. These error messages are caused by the default
OVH configuration template. As we said, the OVH custom kernel doesn’t support the modules and
now we are using their default configuration template. After the activation of the module support
option, the kernel booting process change in some aspects. One of them is that the kernel tries to
load some processes as modules and as by default they are compiled as part of the kernel getting the
following error messages:
Or
To avoid them we only need to compile these options as modules instead of compile them as part of
the kernel.
Page 30 of 66
Compile the Switzernet custom kernel
Processor type and features  <M> /dev/cpu/microcode – microcode support
File systems  Network File Systems  <M> NFS client support
File systems  Network File Systems  [*] NFS client support for NFS version 4
File systems  Network File Systems  [*] NFS client support for NFSv4.1 (EXPERIMENTAL)
File systems  Network File Systems  <M> NFS server support
File systems  Network File Systems  [*] NFS server support for NFS version 3
File systems  Network File Systems  [*] NFS server support for the NFSv3 ACL protocol extension
The changes made before are necessary, but you can perform as many changes as you need. We
save and exit.
Add a new line at the top of the .config file that contains the hardware platform the kernel is built for
(uname -i output). The line is preceded by a # sign. In our case, an x86_64 machine, we have to add
the following line:
Page 31 of 66
Compile the Switzernet custom kernel
# x86_64
Copy the configuration file to /root/rpmbuild/SOURCES/. In order to compile the new kernel it is
necessary to replace /root/rpmbuild/SOURCES/config-x86_64-generic file with the .config file:
cp /root/rpmbuild/BUILD/kernel-2.6.41.fc15/linux-2.6.41.x86_64/.config
/root/rpmbuild/SOURCES/config-x86_64-generic
[root@ks389032 linux-2.6.41.x86_64]# cp .config /root/rpmbuild/SOURCES/configx86_64-generic
cp: overwrite `/root/rpmbuild/SOURCES/config-x86_64-generic'? y
[root@ks389032 linux-2.6.41.x86_64]#
The expression that you should use depends on the name of the destination file. If you have doubts
about which one you should use, run the command in order to find the right name of the destination
file.
ls –lrt /root/rpmbuild/SOURCES/ | grep config
-rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
4016
7226
4015
5253
3742
5716
8194
4077
94
4170
2615
148
205
101717
2043
2117
31261
3397
65075
Nov
Nov
Nov
Nov
Nov
Nov
Nov
Nov
Nov
Nov
Nov
Nov
Nov
Nov
Nov
Nov
Nov
Nov
Jan
29
29
29
29
29
29
29
29
29
29
29
29
29
29
29
29
29
29
6
11:24
11:24
11:24
11:24
11:24
11:24
11:24
11:24
11:24
11:24
11:24
11:24
11:24
11:24
11:24
11:24
11:24
11:24
15:02
Makefile.config
config-x86-generic
config-x86-32-generic
config-sparc64-generic
config-s390x
config-rhel-generic
config-powerpc-generic
config-powerpc64
config-powerpc32-smp
config-powerpc32-generic
config-nodebug
config-local
config-i686-PAE
config-generic
config-debug
config-arm-tegra
config-arm-omap-generic
config-arm-generic
config-x86_64-generic
11.7 Prepare build files
Here we define the name of the custom kernel via the kernel.spec file and it is required for building a
custom kernel.
Change to /root/rpmbuild/SPECS/ directory:
cd /root/rpmbuild/SPECS
Open the kernel.spec file for editing.
Page 32 of 66
Compile the Switzernet custom kernel
Give the kernel a unique name. This is important to ensure the custom kernel is not confused with
any released kernel. Add a unique string to the kernel name by changing the string ‘.local’ in the
buildid line. Change .local by the company name. Optionally add your initials, a bug number, the date
or any other unique string. Change this line:
#% define buildid .local
Into this:
%define buildid .switzernet
NB: Note the extra space is removed in addition to the pound sign.
11.8 Build the new kernel
Now we can compile our kernel.
cd /root/rpmbuild/SPECS
rpmbuild -bb --with baseonly --without debuginfo --target=x86_64 kernel.spec
[root@ks389032 SPECS]# rpmbuild -bb --with baseonly --without debuginfo -target=x86_64 kernel.spec
Checking for unpackaged file(s): /usr/lib/rpm/check-files
/root/rpmbuild/BUILDROOT/kernel-2.6.41.4-1.fc15.x86_64
Wrote: /root/rpmbuild/RPMS/x86_64/kernel-2.6.41.4-1.fc15.x86_64.rpm
Wrote: /root/rpmbuild/RPMS/x86_64/kernel-headers-2.6.41.4-1.fc15.x86_64.rpm
Wrote: /root/rpmbuild/RPMS/x86_64/perf-2.6.41.4-1.fc15.x86_64.rpm
Wrote: /root/rpmbuild/RPMS/x86_64/kernel-devel-2.6.41.4-1.fc15.x86_64.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.ES8Lk5
+ umask 022
+ cd /root/rpmbuild/BUILD
+ cd kernel-2.6.41.fc15
+ rm -rf /root/rpmbuild/BUILDROOT/kernel-2.6.41.4-1.fc15.x86_64
+ exit 0
[root@ks389032 SPECS]#
Finally we have our Fedora custom kernel ready in the following directory:
/root/rpmbuild/RPMS/x86_64/
Page 33 of 66
Install the new kernel over Fedora
12 Install the new kernel over Fedora
Before installing the new kernel, in order to avoid problems with the automatic kernel installation,
we have to install the gettext package, which provides the tools necessaries to write new entries in
the grub’s menu.
yum install gettext
After that, from your Fedora System, type the command below (don’t use -U or --upgrade options):
rpm -ivh --force /root/rpmbuild/RPMS/x86_64/kernel-2.6.41.41.switzernet.fc15.x86_64.rpm
With this command the kernel will be installed in your Fedora system and also it should create a new
initramfs to bootstrap your kernel, and add your new kernel to your GRUB2 boot loader.
Check if the new files have been copied into the proper location under /boot:
[root@ks3093867 ~]# ls -lrt /boot/
-rw-r--r-- 1 root root 237904 May
drwxr-xr-x 3 root root
4096 May
-rw-r--r-- 1 root root 2056069 Aug
-rw-r--r-- 1 root root 5735824 Aug
drwx------ 2 root root
16384 Jan
-rwxr-xr-x 1 root root 5736416 Jan
1.switzernet.fc15.x86_64
-rw------- 1 root root 2739716 Jan
1.switzernet.fc15.x86_64
-rw-r--r-- 1 root root
65065 Jan
1.switzernet.fc15.x86_64
drwxr-xr-x 3 root root
4096 Jan
-rw-r--r-- 1 root root 7217776 Jan
1.switzernet.fc15.x86_64.img
24
24
26
26
5
9
2011
2011
11:51
11:51
12:16
11:07
initrd-plymouth.img
efi
System.map-2.6.38.2-xxxx-grs-ipv6-64
bzImage-2.6.38.2-xxxx-grs-ipv6-64
lost+found
vmlinuz-2.6.41.4-
9 11:07 System.map-2.6.41.49 11:07 config-2.6.41.49 11:28 grub2
9 11:29 initramfs-2.6.41.4-
Check the GRUB2 status, and make sure two new entries are available for the new kernel:
[root@ks3093867 ~]# cat /boot/grub2/grub.cfg
...
### BEGIN /etc/grub.d/09_OVHkernel ###
menuentry "Fedora release 15 (Lovelock), OVH kernel 2.6.38.2-xxxx-grs-ipv6-64" {
insmod ext2
set root='(hd0,1)'
search --no-floppy --fs-uuid --set 08d53654-6fc8-4679-9636-e214489f2cd2
linux
/bzImage-2.6.38.2-xxxx-grs-ipv6-64 root=/dev/sda2 ro quiet rhgb
}
### END /etc/grub.d/09_OVHkernel ###
### BEGIN /etc/grub.d/10_linux ###
menuentry "GNU/Linux, with Linux 2.6.41.4-1.switzernet.fc15.x86_64" --class gnulinux --class gnu --class os {
insmod ext2
set root='(hd0,1)'
Page 34 of 66
Install the new kernel over Fedora
search --no-floppy --fs-uuid --set 08d53654-6fc8-4679-9636-e214489f2cd2
echo
Loading Linux 2.6.41.4-1.switzernet.fc15.x86_64 ...
linux
/vmlinuz-2.6.41.4-1.switzernet.fc15.x86_64 root=UUID=89110d86-f16945ad-acc2-b30bbc88c63d ro quiet rhgb
echo
Loading initial ramdisk ...
initrd /initramfs-2.6.41.4-1.switzernet.fc15.x86_64.img
}
menuentry "GNU/Linux, with Linux 2.6.41.4-1.switzernet.fc15.x86_64 (recovery mode)"
--class gnu-linux --class gnu --class os {
insmod ext2
set root='(hd0,1)'
search --no-floppy --fs-uuid --set 08d53654-6fc8-4679-9636-e214489f2cd2
echo
Loading Linux 2.6.41.4-1.switzernet.fc15.x86_64 ...
linux
/vmlinuz-2.6.41.4-1.switzernet.fc15.x86_64 root=UUID=89110d86-f16945ad-acc2-b30bbc88c63d ro single quiet rhgb
echo
Loading initial ramdisk ...
initrd /initramfs-2.6.41.4-1.switzernet.fc15.x86_64.img
}
### END /etc/grub.d/10_linux ###
...
Page 35 of 66
Install the new kernel over Red Hat
13 Install the new kernel over Red Hat
As we compiled our Fedora kernel for Fedora distribution, we will not be able to install over RedHat
the RPM file that we obtain for Fedora.
An rpm package is a cpio file structure compressed with gzip. To install the Fedora custom kernel we
should use the rpm2cpio command. This tool enables the retrieval of the cpio content from the rpm
package. We only need to copy the recovered structure into the in the /root partition of Red Hat.
As we have installed in the same server a Fedora distribution and a Red Hat distribution. We need to
mount the Red Hat system over /mnt/root1 while Fedora is still running:
mount /dev/VolGroup01/LogVol00 /mnt/root1
Remember that the volume group may change depending on the MR23 server that we are installing.
13.1 Unpack the Fedora kernel
Now we should create a new folder where we will unpack the RPM file and build the cpio structure.
cd /root/kernel
mkdir cpio_kernel
cd cpio_kernel
cp /root/rpmbuild/RPMS/x86_64/kernel-2.6.41.4-1.switzernet.fc15.x86_64.rpm
/root/kernel/
rpm2cpio ../kernel-2.6.41.4-1.switzernet.fc15.x86_64.rpm ¦ cpio –id
root@ks389032 ~]# cd /root/kernel/
[root@ks389032 kernel]# ls
2.6-config-xxxx-std-ipv6-64 cpio_kernel kernel-2.6.41.4-1.fc15.src.rpm kernel2.6.41.4-1.fc15.x86_64.rpm
[root@ks389032 kernel]# cd cpio_kernel/
[root@ks389032 cpio_kernel]# rpm2cpio ../kernel-2.6.41.4-1.fc15.x86_64.rpm | cpio id
16742 blocks
The RPM cpio’s structure will have three folders (/boot, /etc and /lib). These folders (and their
content) should be copied into the Red Hat system.
[root@ks389032 cpio_kernel]# ls
boot etc lib
13.2 Copy the kernel content in Red Hat
As we have only one boot partition that share both systems:
cp –a /root/kernel/cpio_kernel/boot /
And as we have mounted the Red Hat partition in /mnt:
Page 36 of 66
Install the new kernel over Red Hat
cp –a /root/kernel/cpio_kernel/etc /mnt/root1
cp –a /root/kernel/cpio_kernel/lib /mnt/root1
[root@ks389032 cpio_kernel]# ls /mnt/root1
boot dev home lib64 media mnt opt proc sbin srv tftpboot update_root
var
bin core etc lib
lost+found misc
net porta_var root selinux sys tmp
usr
[root@ks389032 cpio_kernel]# cp -a etc /mnt/root1
[root@ks389032 cpio_kernel]# cp -a lib /mnt/root1
[root@ks389032 cpio_kernel]#
At this point we have properly copied our Fedora custom kernel into Red Hat system. We now need
to install the init RAM disk in order to be able to boot Red Hat using this kernel.
Page 37 of 66
Modify the init ram disk
14 Modify the init ram disk
Finally, to boot Red Hat with the Fedora kernel, we need to build an initial RAM disk image that will
pass the control after booting to Red Hat instead of to Fedora. As we wish to boot Red Hat, we can
copy and edit its own initrd file. We copy the file and make a new work folder:
mkdir /root/pb_initrd
cd /root/pb_initrd
scp –c blowfish admin@212.xxx.xxx.xxx:/share/MD0_DATA/porta-billingmr23/tar/111202,1810,billing4,boot.tar.bzip2 .
tar –xjvf 111202,1810,billing4,boot.tar.bzip2
cp initrd-2.6.18-164.0.0.0.1.el5.img initrd-2.6.18-164.0.0.0.1.el5.gz
mkdir cpio_init
[root@ks389032 /]# mkdir /root/pb_initrd
[root@ks389032 pb_initrd]# cd /root/pb_initrd
[root@ks389032 pb_initrd]# scp –c blowfish
admin@212.xxx.xxx.xxx:/share/MD0_DATA/porta-billingmr23/tar/111202,1810,billing4,boot.tar.bzip2 .
[root@ks389032 pb_initrd]# tar –xjvf 111202,1810,billing4,boot.tar.bzip2
[root@ks389032 pb_initrd]# cp initrd-2.6.18-164.0.0.0.1.el5.img initrd-2.6.18164.0.0.0.1.el5.gz
[root@ks389032 pb_initrd]# mkdir cpio_init
Now we should uncompress and make the cpio structure:
gunzip initrd-2.6.18-164.0.0.0.1.el5.gz
cd cpio_init
cpio -id < ../initrd-2.6.18-164.0.0.0.1.el5
[root@ks389032
[root@ks389032
[root@ks389032
16973 blocks
[root@ks389032
bin dev etc
pb_initrd]# gunzip initrd-2.6.18-164.0.0.0.1.el5.gz
pb_initrd]# cd cpio_init/
cpio_init]# cpio -id < ../initrd-2.6.18-164.0.0.0.1.el5
cpio_init]# ls
init lib proc
sbin
sys
sysroot
We need to edit the init file. We do a backup file and proceed to edit it.
cp -a init init.back
vi init
#!/bin/nash
mount -t proc /proc /proc
setquiet
echo Mounting proc filesystem
echo Mounting sysfs filesystem
Page 38 of 66
Modify the init ram disk
mount -t sysfs /sys /sys
echo Creating /dev
mount -o mode=0755 -t tmpfs /dev /dev
mkdir /dev/pts
mount -t devpts -o gid=5,mode=620 /dev/pts /dev/pts
mkdir /dev/shm
mkdir /dev/mapper
echo Creating initial device nodes
mknod /dev/null c 1 3
mknod /dev/zero c 1 5
mknod /dev/urandom c 1 9
mknod /dev/systty c 4 0
mknod /dev/tty c 5 0
mknod /dev/console c 5 1
mknod /dev/ptmx c 5 2
mknod /dev/rtc c 10 135
mknod /dev/tty0 c 4 0
mknod /dev/tty1 c 4 1
mknod /dev/tty2 c 4 2
mknod /dev/tty3 c 4 3
mknod /dev/tty4 c 4 4
mknod /dev/tty5 c 4 5
mknod /dev/tty6 c 4 6
mknod /dev/tty7 c 4 7
mknod /dev/tty8 c 4 8
mknod /dev/tty9 c 4 9
mknod /dev/tty10 c 4 10
mknod /dev/tty11 c 4 11
mknod /dev/tty12 c 4 12
mknod /dev/ttyS0 c 4 64
mknod /dev/ttyS1 c 4 65
mknod /dev/ttyS2 c 4 66
mknod /dev/ttyS3 c 4 67
echo Setting up hotplug.
hotplug
echo Creating block device nodes.
mkblkdevs
echo "Loading ehci-hcd.ko module"
insmod /lib/ehci-hcd.ko
echo "Loading ohci-hcd.ko module"
insmod /lib/ohci-hcd.ko
echo "Loading uhci-hcd.ko module"
insmod /lib/uhci-hcd.ko
mount -t usbfs /proc/bus/usb /proc/bus/usb
echo "Loading jbd.ko module"
insmod /lib/jbd.ko
echo "Loading ext3.ko module"
insmod /lib/ext3.ko
echo "Loading scsi_mod.ko module"
insmod /lib/scsi_mod.ko
echo "Loading sd_mod.ko module"
insmod /lib/sd_mod.ko
echo "Loading libata.ko module"
insmod /lib/libata.ko
echo "Loading ahci.ko module"
insmod /lib/ahci.ko
echo "Loading shpchp.ko module"
insmod /lib/shpchp.ko
echo "Loading usb-storage.ko module"
Page 39 of 66
Modify the init ram disk
insmod /lib/usb-storage.ko
echo Waiting for driver initialization.
stabilized /proc/bus/usb/devices
echo "Loading dm-mod.ko module"
insmod /lib/dm-mod.ko
echo "Loading dm-log.ko module"
insmod /lib/dm-log.ko
echo "Loading dm-mirror.ko module"
insmod /lib/dm-mirror.ko
echo "Loading dm-zero.ko module"
insmod /lib/dm-zero.ko
echo "Loading dm-snapshot.ko module"
insmod /lib/dm-snapshot.ko
echo "Loading dm-mem-cache.ko module"
insmod /lib/dm-mem-cache.ko
echo "Loading dm-region_hash.ko module"
insmod /lib/dm-region_hash.ko
echo "Loading dm-message.ko module"
insmod /lib/dm-message.ko
echo "Loading dm-raid45.ko module"
insmod /lib/dm-raid45.ko
echo Waiting for driver initialization.
stabilized --hash --interval 1000 /proc/scsi/scsi
mkblkdevs
echo Scanning and configuring dmraid supported devices
echo Scanning logical volumes
lvm vgscan --ignorelockingfailure
echo Activating logical volumes
lvm vgchange -ay --ignorelockingfailure VolGroup01
resume /dev/VolGroup01/LogVol03
echo Creating root device.
mkrootdev -t ext3 -o defaults,ro /dev/VolGroup01/LogVol00
echo Mounting root filesystem.
mount /sysroot
echo Setting up other filesystems.
setuproot
echo Switching to new root and running init.
switchroot
We should delete all insmod entries because Red Hat kernel modules are not compatibles with
Fedora kernel. Also we can add a banner.
There is a special issue with one of the device nodes that the initrd creates. The device node is
/dev/rtc and is related with the hardware clock, providing timing information through the command
hwclock. Incase of this device node has a wrong mapping on the system, we can not access to the
hardware clock getting the following error:
[root@ks389032 ~]# hwclock
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.
Instead the normal output that we should get:
[root@ks389032 ~]# hwclock
Tue 17 Jan 2012 10:38:20 AM UTC
-0.920589 seconds
Page 40 of 66
Modify the init ram disk
As the server use the hardware clock, we need to fix this problem deleting the device node from the
/dev init’s folder:
[root@ks389032 ~]# cd /root/pb_initrd/cpio_init/dev
[root@ks389032 ~]# rm rtc
Now, we should remap the device node in the init file changing the default values (10 135) by the
new ones (254 0).
Also, there is an error message related with the USB processes:
To fix it, we should add the following line after the mkblkdevs line in the init file:
mount -t usbfs /proc/bus/usb /proc/bus/usb
Finally, our init file looks as follows:
NB: Pay special attention to the VolGroup and LogVol (it changes between the servers!)
#!/bin/nash
mount -t proc /proc /proc
setquiet
echo Mounting proc filesystem
echo Mounting sysfs filesystem
mount -t sysfs /sys /sys
echo Creating /dev
mount -o mode=0755 -t tmpfs /dev /dev
mkdir /dev/pts
mount -t devpts -o gid=5,mode=620 /dev/pts /dev/pts
mkdir /dev/shm
mkdir /dev/mapper
echo Creating initial device nodes
mknod /dev/null c 1 3
mknod /dev/zero c 1 5
mknod /dev/urandom c 1 9
mknod /dev/systty c 4 0
mknod /dev/tty c 5 0
mknod /dev/console c 5 1
mknod /dev/ptmx c 5 2
mknod /dev/rtc c 254 0
mknod /dev/tty0 c 4 0
mknod /dev/tty1 c 4 1
mknod /dev/tty2 c 4 2
mknod /dev/tty3 c 4 3
mknod /dev/tty4 c 4 4
mknod /dev/tty5 c 4 5
mknod /dev/tty6 c 4 6
Page 41 of 66
Modify the init ram disk
mknod /dev/tty7 c 4 7
mknod /dev/tty8 c 4 8
mknod /dev/tty9 c 4 9
mknod /dev/tty10 c 4 10
mknod /dev/tty11 c 4 11
mknod /dev/tty12 c 4 12
mknod /dev/ttyS0 c 4 64
mknod /dev/ttyS1 c 4 65
mknod /dev/ttyS2 c 4 66
mknod /dev/ttyS3 c 4 67
echo Setting up hotplug.
hotplug
echo Creating block device nodes.
mkblkdevs
mount -t usbfs /proc/bus/usb /proc/bus/usb
echo ""
echo " _______
_______ _______ ____________ _____ _
_ ______ _______ "
echo " / ____\ \
/ /_
_|__
__|___ / ____| __ \| \ | | ____|__
__|"
echo "| (___ \ \ /\ / / | |
| |
/ /| |__ | |__) | \| | |__
| |
"
echo " \___ \ \ \/ \/ /
| |
| |
/ / | __| | _ /| . ` | __|
| |
"
echo " ____) | \ /\ /
_| |_
| |
/ /__| |____| | \ \| |\ | |____
| |
"
echo "|_____/
\/ \/
|_____| |_| /_____|______|_| \_\_| \_|______| |_|
"
echo ""
echo ""
echo Waiting for driver initialization.
stabilized /proc/bus/usb/devices
echo Waiting for driver initialization.
stabilized --hash --interval 1000 /proc/scsi/scsi
mkblkdevs
echo Scanning and configuring dmraid supported devices
echo Scanning logical volumes
lvm vgscan --ignorelockingfailure
echo Activating logical volumes
lvm vgchange -ay --ignorelockingfailure VolGroup01
resume /dev/VolGroup01/LogVol03
echo Creating root device.
mkrootdev -t ext3 -o defaults,ro /dev/VolGroup01/LogVol00
echo Mounting root filesystem.
mount /sysroot
echo Setting up other filesystems.
setuproot
echo Switching to new root and running init.
switchroot
We must rebuild the initrd package (the name doesn’t matter) so we run:
cd /root/kernel/cpio_init
find . | cpio --quiet -o -H newc | gzip -9 > /boot/initrd-2.6.41.41.switzernet.fc15.x86_64.img
The last step is to edit GRUB2. Refer to the next section to do that.
Page 42 of 66
Configure GRUB2
15 Configure GRUB2
Note that as we installed the /boot partition with Fedora, the GRUB2 configuration files refer to
/dev/sda2 as root.
15.1 Add a menu entry
We will now modify the entries in the /boot/grub2/grub.cfg file for permitting Red Hat to boot with
the new kernel and the corresponding RAM disk.
First, modify /etc/default/grub in order to delete some useless entries (the Linux recovery entries)
and options (partition named by UUIDs instead of by devices).
Add the highlighted lines bellow:
[root@ks389032 /]# vi /etc/default/grub
GRUB_CMDLINE_LINUX="quiet rhgb"
GRUB_TIMEOUT=10
GRUB_TERMINAL=console
GRUB_DISABLE_LINUX_UUID=true
GRUB_DISABLE_LINUX_RECOVERY="true"
Save the file, and execute the following command, which will auto generate the new
/boot/grub2/grub.cfg file.
grub2-mkconfig -o /boot/grub2/grub.cfg
From now, you should have two entries (instead three) in your /boot/grub2/grub.cfg file:
### BEGIN /etc/grub.d/09_OVHkernel ###
menuentry "Fedora release 15 (Lovelock), OVH kernel 2.6.38.2-xxxx-grs-ipv6-64" {
insmod ext2
set root='(hd0,1)'
search --no-floppy --fs-uuid --set b1162496-bcb8-4297-8158-79b71d6d7a3a
linux
/bzImage-2.6.38.2-xxxx-grs-ipv6-64 root=/dev/sda2 ro quiet rhgb
}
### END /etc/grub.d/09_OVHkernel ###
### BEGIN /etc/grub.d/10_linux ###
menuentry "GNU/Linux, with Linux 2.6.41.4-1.switzernet.fc15.x86_64" --class gnulinux --class gnu --class os {
insmod ext2
set root='(hd0,1)'
search --no-floppy --fs-uuid --set b1162496-bcb8-4297-8158-79b71d6d7a3a
echo
Loading Linux 2.6.41.4-1.switzernet.fc15.x86_64 ...
linux
/vmlinuz-2.6.41.4-1.switzernet.fc15.x86_64 root=/dev/sda2 ro quiet
rhgb
echo
Loading initial ramdisk ...
initrd /initrd-2.6.41.4-1.switzernet.fc15.x86_64.img
}
### END /etc/grub.d/10_linux ###
Page 43 of 66
Configure GRUB2
NB: notice that the second entry’s initial RAM disk image (initramfs) has changed by the custom
initrd that we have built so in case of we try to boot the second entry the system will crash.
Both of these entries have /dev/sda2 (Fedora partition) as root partition which is normal; Fedora
tries to make its own GRUB2 entries with the new kernel.
For the Fedora custom kernel installation in the Red Hat’s partition, we have to add manually the
menu entry.
We need to use the data generated in the “### BEGIN /etc/grub.d/10_linux ###” section of
/boot/grub2/grub.cfg, and change the root partition from /dev/sda2 to /dev/VolGroup01/LogVol00.
Our manual entry will be set up in the GRUB2 /etc/grub.d/40_custom file. Past the content of the
“### BEGIN /etc/grub.d/10_linux ###” section in /etc/grub.d/40_custom file, and modify the root to
/dev/VolGroup01/LogVol00 as we see below:
[root@ks389032 /]# vi /etc/grub.d/40_custom
#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
menuentry "PortaOne, with Linux 2.6.41.4-1.switzernet.fc15.x86_64" --class gnulinux --class gnu --class os {
savedefault
insmod ext2
set root='(hd0,1)'
search --no-floppy --fs-uuid --set b1162496-bcb8-4297-8158-79b71d6d7a3a
echo
Loading Linux 2.6.41.4-1.switzernet.fc15.x86_64 ...
linux
/vmlinuz-2.6.41.4-1.switzernet.fc15.x86_64
root=/dev/VolGroup01/LogVol00 ro quiet rhgb
echo
Loading initial ramdisk ...
initrd /initrd-2.6.41.4-1.switzernet.fc15.x86_64.img
}
Take care of braces, volume groups, initial RAM disk image and partitions when defining the entry.
Save, exit and update the grub.cfg file:
grub2-mkconfig -o /boot/grub2/grub.cfg
Check that the grub2-mkconfig command has updated your /boot/grub2/grub.cfg file:
cat /boot/grub2/grub.cfg
Your custom entry should be present under the “### BEGIN /etc/grub.d/40_custom ###” menu
entry.
Page 44 of 66
Configure GRUB2
15.2 Configure GRUB2 for booting only once on Red Hat
At this point, we have our new menu entry. But as we do not have physical access to the machine,
we have to set a default OS before rebooting. If we made an error and Red Hat doesn’t boot, we
need to be able to boot on the Fedora partition again after perform a hard reboot at OVH.net web
manager.
Here is the method how-to recover the server even if Red Hat crashes with our new kernel.
First, edit /etc/default/grub. Add the following lines to the /etc/default/grub file (highlighted line is
the line for using the grub2-set-default and grub2-reboot):
[root@ks389032 /]# vi /etc/default/grub
GRUB_CMDLINE_LINUX="quiet rhgb"
GRUB_TIMEOUT=10
GRUB_TERMINAL=console
GRUB_DISABLE_LINUX_UUID=true
GRUB_DISABLE_LINUX_RECOVERY="true"
GRUB_DEFAULT=saved
GRUB_SAVEDEFAULT=true
Update the grub.cfg file:
grub2-mkconfig -o /boot/grub2/grub.cfg
At this point we need to stop and think which entries will be useful in the future. As we said before,
the second entry (new Fedora kernel installed in Fedora partition) doesn’t works and we only need
the first and the third ones (original Fedora and Red Hat installation, respectively), so to avoid
problems in the future we are going to delete the second entry.
chmod -x /etc/grub.d/10_linux
grub2-mkconfig -o /boot/grub2/grub.cfg
Now, to know which entries we have in the menu (starting from 0) and their order, we run the
following command:
grep menuentry /boot/grub2/grub.cfg
Once we know which entry correspond to the original Fedora installation, we set it as default and if
we want to boot another entry we only need to set it with the grub2-reboot command.
[root@ks389032 /]# cat /boot/grub2/grub.cfg | grep -B4 "menuentry" | egrep
"menuentry|BEGIN" | sed 's/.*"\(.*\)".*/\1\t\n/'
### BEGIN /etc/grub.d/09_OVHkernel ###
Fedora release 15 (Lovelock), OVH kernel 2.6.38.2-xxxx-grs-ipv6-64
### BEGIN /etc/grub.d/40_custom ###
GNU/Linux, with Linux 2.6.41.4-1.switzernet.fc15.x86_64
Page 45 of 66
Configure GRUB2
As we can see, the first entry corresponds to the Fedora’s original installation and the second one to
the custom kernel installation in Red Hat.
Set the default boot entry:
[root@ks389032 /]# grub2-set-default 0
And set the next-only reboot entry:
[root@ks389032 /]# grub2-reboot 1
15.3 Reboot
Now we are ready to make our first reboot.
[root@ks389032 /]# reboot
You will be disconnected of the server, which will attempt to reboot on the Red Hat distribution. Ping
your server until it is reachable.
$ ping 213.xxx.xxx.xxx
PING 213.xxx.xxx.xxx (213.xxx.xxx.xxx): 56
(~ 1 min 15 s before pinging)
64 bytes from 213.xxx.xxx.xxx: icmp_seq=77
64 bytes from 213.xxx.xxx.xxx: icmp_seq=78
64 bytes from 213.xxx.xxx.xxx: icmp_seq=79
data bytes
ttl=51 time=172 ms
ttl=51 time=213 ms
ttl=51 time=241 ms
----213.xxx.xxx.xxx PING Statistics---80 packets transmitted, 3 packets received, 96.2% packet loss
round-trip (ms) min/avg/max/med = 172/209/241/213
At this point the server should be rebooting. In case of any problem (you cannot ping for more than 3
minutes), we only need to hard reboot the server from the OVH management interface. Grub will fall
back to the default OS, which is the native Fedora binary image of OVH.
Page 46 of 66
Post-install configurations
16 Post-install configurations
16.1 Modules
After first reboot, our kernel is renamed by the system, so we need to rename its module library:
uname -r
[root@ks389032 /]# uname -r
2.6.41.4-1.switzernet.fc15.x86_64-xxxx-std-ipv6-64
mv /lib/modules/2.6.41.4-1.switzernet.fc15.x86_64 /lib/modules/2.6.41.41.switzernet.fc15.x86_64-xxxx-std-ipv6-64
Once we have renamed the library, we can build the modules:
depmod -a
16.2 SSH connection
To avoid the time out when we connect to the server via ssh, we should edit the following file:
/etc/ssh/sshd_config
And replace the line:
#UseDNS yes
By this other one:
UseDNS no
NB: Note that the pound sing is removed
16.3 IPv6 Network connection
OVH provide an IPv6 special configuration that causes the following message in the dmesg:
IPv6 addrconf: prefix with wrong length 56
If we check our network configuration we can see that OVH assign the IPv6 address with /64 instead
of /56, so to prevent this message we have to options: reconfigure the IPv6 address with /56 or avoid
the IPv6 automatic configuration editing the /etc/sysctl.conf file:
vi /etc/sysctl.conf
Page 47 of 66
Post-install configurations
Adding these lines at the end of it:
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.eth0.autoconf = 0
And reload the configuration with the command:
sysctl -p /etc/sysctl.conf
We should have an output like this:
[root@ks389032 ~]# sysctl -p /etc/sysctl.conf
net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
error: "kernel.sysrq" is an unknown key
net.ipv4.tcp_syncookies = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
kernel.panic = 20
fs.suid_dumpable = 2
kernel.core_uses_pid = 0
kernel.core_pattern = /var/tmp/%e.core
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.eth0.autoconf = 0
16.4 Hostname
At first boot, the displayed hostname is the OVH server hostname. Fix that hostname by editing
/etc/sysconfig/network and replace HOSTNAME=localhost.localdomain with the name you wish to
see for your server. This will only be effective at next boot.
vi /etc/sysconfig/network
NETWORKING=yes
NETWORKING_IPV6=no
HOSTNAME=sip1.switzernet.com
16.5 OVH Real Time Monitoring
OVH.net provides, through its web manager interface, a real time monitoring service. It allow you to
monitor a lot of data concerning your running server like the distribution, CPU usage, Hard disk
usage, Memory usage ... and permit to configure alerts if needed. Information about Real Time
Monitoring is available under this link [go].
Page 48 of 66
Post-install configurations
At this point, no data is available through this web interface. Under ‘Etat du serveur’, ‘Real Time
Monitoring’, you should see something like the screenshot bellow:
In order to display the server state, we need to install the RTM (for Real Time Monitoring) package
provided by OVH.net.
On your server, download and install the RTM package with the following commands:
wget ftp://ftp.ovh.net/made-in-ovh/rtm/install_rtm.sh -O install_rtm.sh
sh install_rtm.sh
[root@sip1 ~]# wget ftp://ftp.ovh.net/made-in-ovh/rtm/install_rtm.sh -O install_
rtm.sh
--2012-01-09 09:53:01-- ftp://ftp.ovh.net/made-in-ovh/rtm/install_rtm.sh
=> `install_rtm.sh'
...
2012-01-09 09:53:16 (3.63 MB/s) - `install_rtm.sh' saved [70097]
[root@sip1 ~]# sh install_rtm.sh
--2012-01-09 09:53:27-- ftp://ftp.ovh.net/made-in-ovh/rtm/hddtemp.db
=> `/usr/share/misc/hddtemp.db'
Resolving ftp.ovh.net... 213.186.33.9
Connecting to ftp.ovh.net|213.186.33.9|:21... connected.
...
rtm hINFO_HDD_sda_SMART_offline-uncorrectable|0
[root@sip1 ~]#
Everything will be automatically configured; you can directly reload the OVH.net web manager
interface to display details about your server:
Page 49 of 66
Post-install configurations
16.6 Modify default booting System from Red Hat
Now, from the Red Hat system, we have to modify the default boot because in case we reboot the
system it will be booted the Fedora partition (option selected previously by default).
NB: GRUB2 have always to be configured from the scripts and configuration files that are located
under the Fedora Partition. DO NOT TRY to modify the GRUB2 from Red Hat, just only the following
file.
Edit following file and replace 0 with 1:
[root@sip1 ~]# vi /boot/grub2/grubenv
# GRUB Environment Block
saved_entry=0
prev_saved_entry=
##########################
An explanation further detailed here [go].
Next and future reboots will be performed over our Red Hat system.
Page 50 of 66
Next rebooting
17 Next rebooting
By
default,
next
reboot
will
be
on
the
entry
defined
in
/boot/grub2/grubenv.
If you are on Fedora use grub2-reboot command to change the default booting:
[root@ks389032 /]# grub2-reboot 1
[root@ks389032 /]# reboot
If you are on Red Hat, edit /boot/grub2/grubenv to change the default booting:
[root@sip1 ~]# vi /boot/grub2/grubenv
# GRUB Environment Block
saved_entry=0
prev_saved_entry=
##########################
Page 51 of 66
Install USB over IP server on a local Fedora machine
18 Install USB over IP server on a local Fedora machine
In order to activate the license of the PortaOne MR23 installation, we need to plug the USB dongle
on the configurator. Then only, the configurator will authorize the Master radius to activate his
services and authenticate the VoIP devices.
As we do not have physical access to the server, we use USB over IP to share the USB dongle over
internet and permit to connect it as if it was directly connected to the configurator.
Install a new machine from a Fedora live CD. As the USB over IP is in the staging kernel drivers, it is
not installed by default and is subject to change between two kernel versions. We are going to
compile kernel with the USB over IP support. You should take the same Fedora distribution and
kernel version that you installed on the OVH.net server.
18.1 Compile the kernel
We do not detail here the complete kernel compilation as we had ever done it before. There is no
needing of the OVH.net patch or renaming the kernel.
You just need to execute the commands provided bellow:
su root
cd /root
yum install rpmdevtools yum-utils gettext
rpmdev-setuptree
yumdownloader --source kernel
yum-builddep kernel-2.6.41.4-1.fc15.src.rpm
rpm -Uvh kernel-2.6.41.4-1.fc15.src.rpm
cd ~/rpmbuild/SPECS
rpmbuild -bp --target=$(uname -m) kernel.spec
cd ~/rpmbuild/BUILD/kernel-2.6.41.fc15/linux-2.6.41.x86_64/
cp ./configs/kernel-2.6.41.4-x86_64.config .config
make oldconfig
make menuconfig
In the configuration menu, activate the USB over IP support, as you did for the Configurator, save and
exit.
Device drivers  Staging drivers  <M> USB/IP support
Device drivers  Staging drivers  <M> VHCI hcd
Device drivers  Staging drivers  <M> Host driver
Device drivers  Staging drivers  [*] Debug messages for USB/IP
Page 52 of 66
Install USB over IP server on a local Fedora machine
Then copy your new configuration file to the SOURCES directory:
cp .config ~/rpmbuild/SOURCES/config-`uname -m`-generic
You do not need to rename your kernel; it will be faster to install it later. Just compile it with the
following command:
rpmbuild -bb --with baseonly --without debuginfo --target=`uname -m` kernel.spec
And install it:
rpm -ivh --force ~/rpmbuild/RPMS/`uname -m`/kernel-2.6.41.4-1.fc15.x86_64.rpm
Your kernel is installed; reboot on this kernel.
18.2 Install USB over IP
Go into the USB over IP kernel staging driver directory:
cd ./rpmbuild/BUILD/kernel-2.6.41.fc15/linux2.6.41.x86_64/drivers/staging/usbip/userspace/
Install the needed packages:
[root@212-147-8-107 userspace]# yum install sysfsutils gcc glib-devel libsysfs
libsysfs-devel glib2-devel libtool automake
...
Then you can install the USB over IP binaries with the provided installation packages of the current
directory:
[root@212-147-8-107 userspace]# ./autogen.sh
...
[root@212-147-8-107 userspace]# ./configure
...
[root@212-147-8-107 userspace]# make install
...
Page 53 of 66
Install USB over IP server on a local Fedora machine
Load the modules needed by the USB over IP server:
[root@212-147-8-107 userspace]# depmod -a
[root@212-147-8-107 userspace]# insmod /lib/modules/2.6.41.41.fc15.x86_64/kernel/drivers/staging/usbip/usbip-core.ko
[root@212-147-8-107 userspace]# insmod /lib/modules/2.6.41.41.fc15.x86_64/kernel/drivers/staging/usbip/usbip-host.ko
Check they have loaded correctly:
[root@212-147-8-107 linux-2.6.41.x86_64]# lsmod | grep usbip
usbip_host
15648 0
usbip_core
14273 1 usbip_host
Launch the USB over IP demon server:
[root@212-147-8-107 userspace]# usbipd –D
You can now see all the devices you can bind to the USB over IP server by listing them with the usbip
list -l command. The dongle key (that must be directly plugged into the local server) is displayed as an
unknown device:
[root@212-147-8-107 linux-2.6.41.x86_64]# usbip list -l
Local USB devices
=================
- busid 1-1 (8087:0024)
1-1:1.0 -> hub
- busid 2-1 (8087:0024)
2-1:1.0 -> hub
- busid 2-1.3 (07f2:0001)
2-1.3:1.0 -> unknown
- busid 2-1.4 (046d:c05a)
2-1.4:1.0 -> usbhid
- busid 2-1.6 (05e3:0716)
2-1.6:1.0 -> usb-storage
You can view more details about this device with lsusb:
[root@212-147-8-107
Bus 001 Device 001:
Bus 002 Device 001:
Bus 001 Device 002:
Bus 002 Device 002:
Bus 002 Device 008:
Bus 002 Device 004:
Bus 002 Device 006:
Reader/Writer
~]# lsusb
ID 1d6b:0002
ID 1d6b:0002
ID 8087:0024
ID 8087:0024
ID 07f2:0001
ID 046d:c05a
ID 05e3:0716
Linux Foundation 2.0 root hub
Linux Foundation 2.0 root hub
Intel Corp. Integrated Rate Matching Hub
Intel Corp. Integrated Rate Matching Hub
Microcomputer Applications, Inc. KEYLOK II
Logitech, Inc. Optical Mouse M90
Genesys Logic, Inc. USB 2.0 Multislot Card
Page 54 of 66
Install USB over IP server on a local Fedora machine
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bind the dongle to the USB over IP server with the following command, using its bus id:
[root@212-147-8-107 userspace]# usbip bind --busid 2-1.3
Using usbip list -l again, you can see that your dongle passed from the unknown to usbip-host state:
[root@212-147-8-107 ~]# usbip list -l
Local USB devices
=================
- busid 1-1 (8087:0024)
1-1:1.0 -> hub
- busid 2-1 (8087:0024)
2-1:1.0 -> hub
- busid 2-1.3 (07f2:0001)
2-1.3:1.0 -> usbip-host
- busid 2-1.4 (046d:c05a)
2-1.4:1.0 -> usbhid
- busid 2-1.6 (05e3:0716)
2-1.6:1.0 -> usb-storage
Your server is now ready to share the MR23 dongle with an USB over IP client which we will configure
in the next section.
Page 55 of 66
Install USB over IP client on the Configurator
19 Install USB over IP client on the Configurator
During the kernel configuration and compilation, you should have compiled a kernel with the USB
over IP drivers.
19.1 Install executable files on Fedora
As USB over IP for our kernel is quite recent, it is impossible to install it from Red Hat. We have to
install it on Fedora and execute them later from the Red Hat operating system. Reboot on Fedora.
[root@billing1 ~]# reboot
Install the required packages:
[root@ks3094763 ~]# yum install sysfsutils gcc glib-devel libsysfs libsysfs-devel
glib2-devel libtool
Go to the USB over IP build directory:
[root@ks3094763 ~]# cd /root/rpmbuild/BUILD/kernel-2.6.41.fc15/linux2.6.41.x86_64/drivers/staging/usbip/userspace
And proceed with the installation:
[root@ks3094763 ~]# ./autogen.sh
[root@ks3094763 ~]# ./configure
[root@ks3094763 ~]# make install
The executable binary file should have been installed under /usr/local/sbin. Check:
[root@ks3094763 ~]# ls /usr/local/sbin/usbip
/usr/local/sbin/usbip
Then you can reboot to Red Hat:
[root@ks3094763 ~]# grub2-reboot 1
[root@ks3094763 ~]# reboot
19.2 Install executables files on Red Hat
On Red Hat, install the required packages:
[root@billing1 ~]# yum install sysfsutils gcc glib-devel libsysfs libsysfs-devel
glib2-devel libtool
Download the package usbip-0.1.7.tar.gz from the web site of the USB-IP project:
Page 56 of 66
Install USB over IP client on the Configurator
http://sourceforge.net/projects/usbip/files/usbip/0.1.7/
Unzip the package and install it:
[root@billing1
[root@billing1
[root@billing1
[root@billing1
~]#
~]#
~]#
~]#
tar -xzvf usbip-0.1.7.tar.gz
./autogen.sh
./configure
make install
After the installation, you should check the path /usr/local/lib and make sure you have the following
files:
[root@billing1 ~]# ls -lrt /usr/local/lib
libusbip.a
libusbip.la
libusbip.so -> libusbip.so.0.0.1
libusbip.so.0 -> libusbip.so.0.0.1
libusbip.so.0.0.1
19.3 Install USB over IP modules over Red Hat
According to our new kernel installation on Red Hat, the USB over IP drivers are located under the
new kernel module directory.
USB over IP consist on 3 modules to install:
- vhci_hcd
- usbip_core
- usbip_host
Load the first and the second modules in memory with the insmod command (keep this order
because of dependencies):
[root@billing1 ~]#insmod /lib/modules/2.6.41.4-1.switzernet.fc15.x86_64-xxxx-stdipv6-64/kernel/drivers/staging/usbip/usbip-core.ko
[root@billing1 ~]#insmod /lib/modules/2.6.41.4-1.switzernet.fc15.x86_64-xxxx-stdipv6-64/kernel/drivers/staging/usbip/vhci-hcd.ko
Once you activated the module, you can check if the loading has been performed using the lsmod
command:
[root@billing1 ~]# lsmod
Module
Size
vhci_hcd
21175
usbip_host
15789
usbip_core
12253
[root@billing1 ~]#
Used by
-
Page 57 of 66
Install USB over IP client on the Configurator
The executable binary file of USB over IP is located under the Fedora partition. We have to mount
this partition:
[root@billing1 ~]# mkdir /root/root_fedora
[root@billing1 ~]# mount /dev/sda2 /root/root_fedora
You can then execute the USB over IP command to list the USB devices shared by the local server
providing its IP address:
/root/root_fedora/usr/local/sbin/usbip list --remote=212.xxx.xxx.xxx
[root@billing1 ~]# /root/root_fedora/usr/local/sbin/usbip list --remote=212.xxxxxx.xxx
Exportable USB devices
======================
- 212.xxx.xxx.xxx
2-1.3: unknown vendor : unknown product (07f2:0001)
: /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.3
: (Defined at Interface level) (00/00/00)
: 0 - (Defined at Interface level) (00/00/00)
[root@billing1 ~]#
And bind the new USB device this way:
/root/root_fedora/usr/local/sbin/usbip attach --host=212.xxx.xxx.xxx --busid=2-1.3
[root@billing1 ~]# /root/root_fedora/usr/local/sbin/usbip attach -host=212.xxx.xxx.xxx --busid=2-1.3
8 ports available
port 0 attached
Write down the port number; it will be the id to use when you wish to detach the dongle with this
command:
/root/root_fedora/usr/local/sbin/usbip detach --port=0
When the dongle is attached, lsusb show a new connected device:
[root@billing1
Bus 005 Device
Bus 005 Device
Bus 003 Device
Bus 004 Device
Bus 002 Device
Bus 001 Device
/]# lsusb
004: ID 07f2:0001
001: ID 1d6b:0002
001: ID 1d6b:0001
001: ID 1d6b:0001
001: ID 1d6b:0001
001: ID 1d6b:0002
Linux
Linux
Linux
Linux
Linux
Foundation
Foundation
Foundation
Foundation
Foundation
2.0
1.1
1.1
1.1
2.0
root
root
root
root
root
hub
hub
hub
hub
hub
And the PortaOne MR23 command checkdongle display the following output:
[root@billing1 /]# checkdongle
Page 58 of 66
Install USB over IP client on the Configurator
DONGLE OK - key expires on: Thu Mar
1 00:00:00 2012
19.4 Automatically mounting Fedora
It is required to automatically mount Fedora’s partition in the MR23 Configurator server as Red Hat
needs Fedora’s binaries to launch the USB over IP client. It can be done manually but it is safer to
automatically mount it in case of forget it.
Edit the /etc/fstab file and add a mounting point at the end of the file:
vi /etc/fstab
/dev/VolGroup00/LogVol00 /
/dev/VolGroup00/LogVol01 /update_root
/dev/VolGroup00/LogVol02 /porta_var
LABEL=/boot
/boot
tmpfs
/dev/shm
devpts
/dev/pts
sysfs
/sys
proc
/proc
/dev/VolGroup00/LogVol03 swap
/dev/sda2
/root/root_fedora
ext3
ext3
ext3
ext3
tmpfs
devpts
sysfs
proc
swap
ext3
defaults
defaults
defaults
defaults
defaults
gid=5,mode=620
defaults
defaults
defaults
defaults
1 1
1 2
1 2
1 2
0 0
0 0
0 0
0 0
0 0
0 0
19.5 Automatically load modules at booting.
Red hat and Fedora use a special sysconfig directory where they can find shell scripts that load the
modules at booting.
Create your own script under the /etc/sysconfig/modules directory. It will load the USB over IP
drivers needed at booting.
[root@billing1 /]# vi /etc/sysconfig/modules/usbip.modules
Add the following lines:
#!/bin/sh
insmod /lib/modules/2.6.41.4-1.switzernet.fc15.x86_64-xxxx-std-ipv664/kernel/drivers/staging/usbip/usbip-core.ko
insmod /lib/modules/2.6.41.4-1.switzernet.fc15.x86_64-xxxx-std-ipv664/kernel/drivers/staging/usbip/vhci-hcd.ko
And make this script executable:
[root@billing1 /]# chmod +x /etc/sysconfig/modules/usbip.modules
At this point, the installation is finished, we can continue by connecting to the Configurator web
interface in order to update the IP address of each one of the server using the following doc [120110
i].
Page 59 of 66
Install USB over IP cli ent on the Configurator
Page 60 of 66
Validate installation with calls
20 Validate installation with calls
After configuring the interconnection gateways with our new sip server [100512 i], registering our SIP
phone to the SIP server, we are able to pass calls to the external network.
Page 61 of 66
References
21 References
21.1.1 VLAN
Configure VLANs on Red Hat with Cisco Switch:
http://switzernet.com/3/public/111104-vlan-cisco-conf/
Configure VLANs at OVH:
http://switzernet.com/3/public/111116-vlans-conf/
21.1.2 LVM
Restore the Porta-Switch from clone tar files on LVM partitions:
http://switzernet.com/3/public/100926-mr21-tar-lvm/
Backup, restore, and clone the Porta-Switch installation with tar files:
http://switzernet.com/2/public/100830-tar-pb-mr21/
21.1.3 Kernel
Compile a kernel for OVH:
http://fr.wikitwist.com/ovh-compiler-kernel-personnalise/#axzz1hepC0hi5
How to build a Fedora custom kernel:
http://fedoraproject.org/wiki/Building_a_custom_kernel
Download Fedora’s source kernel:
http://download.fedora.redhat.com/pub/fedora/linux/releases/
How to compile a kernel for Cent OS:
http://mattiasgeniar.be/2011/02/19/building-your-own-kernel-based-on-centos-switchroot-mountfailed-kernel-panic/
How to work with initial ram disk:
http://www.ibm.com/developerworks/linux/library/l-initrd/index.html
21.1.4 GRUB2
GRUB2’s how-to for Ubuntu:
https://help.ubuntu.com/community/Grub2
Reboot Ubuntu with GRUB2 saved entries:
http://ubuntuforums.org/archive/index.php/t-1377754.html
Notes concerning rebooting Red Hat with GRUB2 saved entries:
https://bugzilla.redhat.com/show_bug.cgi?id=732058
GNU GRUB Manual 1.99:
http://www.gnu.org/software/grub/manual/grub.html
21.1.5 This document
Word document:
http://switzernet.com/3/public/120110-install-mr23-redhat-ovh/index.doc
Page 62 of 66
References
PDF document:
http://switzernet.com/3/public/120110-install-mr23-redhat-ovh/
Html document:
http://switzernet.com/3/public/120110-install-mr23-redhat-ovh/index.htm
Page 63 of 66
Glossary
22 Glossary
CPIO
It refers to a general file archive utility and its associated file format. Its name is derived from CoPy In
and Out, because the program performs standard inputs and standard outputs in its operations.
FEDORA
Formerly Fedora Core, is an operating system based on the Linux kernel that use RPM packages. The
Fedora operating system is completely free of cost and it is developed by the community-supported
Fedora Project and sponsored by Red Hat.
GRUB
Acronym of GRand Unifier Bootloader is the first program that loads after BIOS. Grub allows you to
have different OS, also different versions of them in the same hard disk and allows you to choose
which one you want to boot.
INITRD & INITRAMFS
Both of them are differents schemes to load a temporary file system into memory during the boot
process of the Linux kernel. They are commonly used to make preparations before the real root file
system can be mounted.
As the initrd is an old initial RAM disk image scheme, it is necessary to compile statically its driver
into the kernel.
IP FAILOVER
Feature provided by OVH.net is an IP address that can be moved from one server to another. When
you have an IP failover basically you have an IP address redirected to your server fix IP address, so in
case you want to reach other server using this same IP you only have to redirect the IP failover
address.
LVM
It is the acronym of Logical Volume Manager. LVM is an intermediary layer between the disk and the
file system that manages disk drives and similar mass-storage devices, in particular large ones.
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 resizable into logical volumes.
Page 64 of 66
Glossary
NAS
Acronym for Network-Attached Storage. This dedicated storage technology shares the storage
capacity of one computer or server with other computers through a network connection. It uses an
optimized operating system to provide access with protocols as NFS, FTP or TFTP.
NIC
Also known as Network Interface Controller, NIC is a computer hardware component as a network
adapter that provides network connection to a station. It can be a card module or be integrated on
other card as the motherboard.
OVH
OVH is a French privately owned web hosting service company that provides dedicated servers,
mutual hosting, domain names and VOIP telephony services.
Porta-Switch MR23
Porta-Switch is a subscriber management software provided by PortaOne company. This software is
focused on telecommunication services providers and it allows to unify different kind of network
traffic (like voice, data,...) in a single converged network.
RHEL
Abbreviation of Red Hat Enterprise Linux, RHEL is a commercial Linux-based operating system
developed by Red Hat and based on RPM packages.
RPM
RPM Package Manager (RPM) is a package management system. The name RPM variously refers to
the .rpm file format, files in this format, software packaged in such files, and the package manager
itself. The file format is the baseline package format of the Linux Standard Base.
SSH
Network protocol (Secure SHell) for secure data communication, remote shell services or command
execution and other secure network services between two networked computers connected via a
secure channel over an insecure network
SWAP
This name refers to the disk exchange area that is used to keep the processes that shouldn't or
couldn't be kept in physical memory.
VLAN
This acronym of Virtual LAN is a method that allows to create independent logical computer
networks regardless of their physical location.
Page 65 of 66
Glossary
*
*
*
Copyright © 2011 by Switzernet
Page 66 of 66