Restore the Porta-Switch Mr23 Installation on Ovh Servers

[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]

Contents

of 6566 Install USB over IP client on the Configurator

1 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.

2 Installing Fedora at OVH

2.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.

2.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.

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:

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 Partition type System file Mounting point Size (MB) 1 primary ext3 /boot 51200 2 ext3 ext3 / 51200 3 ext3 ext3 /tmp 889408 4 ext3 swap none 8192 Total 1000000 (/dev/sda3 = – 51200 – 51200 – 8192 + 1000000 = 889408 MB)

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.

3 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].

3.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:

3.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

3.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): [ OK ]

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 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

4 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.

4.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 ~]# cat /etc/fstab # /dev/sda2 / ext3 errors=remount-ro 0 1 /dev/sda1 /boot ext3 errors=remount-ro 0 1 /dev/sda3 /tmp ext3 defaults 1 2 /dev/sda4 swap swap defaults 0 0 proc /proc proc defaults 0 0 sysfs /sys sysfs defaults 0 0 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts defaults 0 0 dev /dev devtmpfs rw 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 # /dev/sda2 / ext3 errors=remount-ro 0 1 /dev/sda1 /boot ext3 errors=remount-ro 0 1 /dev/sda4 swap swap defaults 0 0 proc /proc proc defaults 0 0 sysfs /sys sysfs defaults 0 0 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts defaults 0 0 dev /dev devtmpfs rw 0 0

4.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

Device Boot Start End Blocks Id System /dev/sda1 * 4096 104859648 52427776+ 83 Linux /dev/sda2 104859649 209715200 52427776 83 Linux /dev/sda3 209715201 1919963136 855123968 83 Linux /dev/sda4 1919963137 1953515520 16776192 82 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

Device Boot Start End Blocks Id System /dev/sda1 * 4096 104859648 52427776+ 83 Linux /dev/sda2 104859649 209715200 52427776 83 Linux /dev/sda4 1919963137 1953515520 16776192 82 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

Device Boot Start End Blocks Id System /dev/sda1 * 4096 104859648 52427776+ 83 Linux /dev/sda2 104859649 209715200 52427776 83 Linux /dev/sda3 209715201 1919963136 855123968 83 Linux /dev/sda4 1919963137 1953515520 16776192 82 Linux swap / Solaris

While still in fdisk, set the type of the 3rd partition to LVM.

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)

Device Boot Start End Blocks Id System /dev/sda1 * 4096 104859648 52427776+ 83 Linux /dev/sda2 104859649 209715200 52427776 83 Linux /dev/sda3 209715201 1919963136 855123968 8e Linux LVM /dev/sda4 1919963137 1953515520 16776192 82 Linux swap / Solaris

Then, you can apply the changes and reboot.

Command (m for help): w … Command (m for help): q

[root@server ~]# reboot

4.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

of 6566 Install USB over IP client on the Configurator created (VolGroup01 for billing4 and VolGroup00 for the others if you take the tar files of this link [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

4.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 -l 5000 VolGroup01 -n LogVol00 # lvcreate -l 5000 VolGroup01 -n LogVol01 # lvcreate -l 8000 VolGroup01 -n LogVol03 # lvcreate -l 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 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.

5 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 ~]# mkfs -t ext3 /dev/VolGroup01/LogVol00 [root@server ~]# mkfs -t ext3 /dev/VolGroup01/LogVol01 [root@server ~]# mkfs -t ext3 /dev/VolGroup01/LogVol02 [root@server ~]# 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 / ext3 defaults 1 1 /dev/VolGroup01/LogVol02 /porta_var ext3 defaults 1 2 /dev/VolGroup01/LogVol01 /update_root ext3 defaults 1 2 LABEL=/boot /boot ext3 defaults 1 2 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0 /dev/VolGroup01/LogVol03 swap swap defaults 0 0

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

6 Mounting Partitions As the partitions are all formatted, you can now mount them as follows:

[root@server ~]# cd /mnt [root@server mnt]# mkdir root1 [root@server mnt]# mkdir root2 [root@server mnt]# mkdir porta [root@server mnt]# mount /dev/VolGroup01/LogVol00 root1 [root@server mnt]# mount /dev/VolGroup01/LogVol01 root2 [root@server mnt]# mount /dev/VolGroup01/LogVol02 porta

On a restored system the output of the df command looks as follows:

Filesystem 1K-blocks Used Available Use% Mounted on rootfs 52014716 2405524 46987804 5% / /dev/root 52014716 2405524 46987804 5% / devtmpfs 1016548 0 1016548 0% /dev tmpfs 1016852 0 1016852 0% /dev/shm tmpfs 1016852 1388 1015464 1% /run tmpfs 1016852 232 1016620 1% /sys/fs/cgroup tmpfs 1016852 0 1016852 0% /media /dev/sda1 52014716 208592 49184736 1% /boot [...] /dev/mapper/VolGroup01-LogVol00 20158332 3465176 15669156 1% /mnt/root1 /dev/mapper/VolGroup01-LogVol01 20158332 176200 18958132 1% /mnt/root2 /dev/mapper/VolGroup01-LogVol02 769132592 283020 729779876 1% /mnt/porta

7 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].

7.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 [email protected]:/share/MD0_DATA/porta- billing-mr23/tar/111202,1810,billing4,root1.tar.bzip2 .

7.2 Downloading the tar files of root2 partition Same here for root2:

[root@server mnt]# cd /mnt/root2 [root@server root2]# scp -c blowfish [email protected]:/share/MD0_DATA/porta- billing-mr23/tar/111202,1810,billing4,root2.tar.bzip2 .

7.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 [email protected]:/share/MD0_DATA/porta- billing-mr23/tar/111202,1810,billing4,porta.tar.bzip2 .

8 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 ...

9 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 mnt]# cd /mnt/root1/etc/sysconfig/network-scripts/ [root@server network-scripts]# cp /etc/sysconfig/network-scripts/ifcfg-eth0 . [root@server network-scripts]# cp /etc/sysconfig/network-scripts/ifcfg-vlan5 . [root@server 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/network- scripts/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 # # 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.

10 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.

10.1 Download the kernel source First of all, create a work folder and change the current directory into that folder.

[root@ks389032 ~]# pwd /root [root@ks389032 ~]# mkdir kernel [root@ks389032 ~]# cd kernel/ [root@ks389032 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/kernel- 2.6.41.4-1.fc15.src.rpm --2011-12-16 11:48:03-- http://download.fedora.redhat.com/pub/fedora/linux/updates/15/SRPMS/kernel- 2.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]#

10.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]#

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.6- config-xxxx-std-ipv6-64 --2011-12-16 11:46:29-- ftp://ftp.ovh.net/made-in-ovh/bzImage/2.6.38.2-2/2.6- config-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]#

10.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)

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).

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 37 Package(s) Upgrade 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 ...

of 6566 Install USB over IP client on the Configurator warning: group mockbuild does not exist - using root [root@ks389032 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

10.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 + 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/linux- 2.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

of 6566 Install USB over IP client on the Configurator 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.

10.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/kernel- 2.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]#

10.6 Configure kernel options Change the directory to the kernel source tree directory:

of 6566 Install USB over IP client on the Configurator 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

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 Device drivers  USB support  [*] USB device class.devices

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  USB/IP support Device drivers  Staging drivers  VHCI hcd Device drivers  Staging drivers  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:

To avoid them we only need to compile these options as modules instead of compile them as part of the kernel.

Processor type and features  /dev/cpu/microcode – microcode support

File systems  Network File Systems  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  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:

# 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/config- x86_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-- 1 root root 4016 Nov 29 11:24 Makefile.config -rw-r--r-- 1 root root 7226 Nov 29 11:24 config-x86-generic -rw-r--r-- 1 root root 4015 Nov 29 11:24 config-x86-32-generic -rw-r--r-- 1 root root 5253 Nov 29 11:24 config-sparc64-generic -rw-r--r-- 1 root root 3742 Nov 29 11:24 config-s390x -rw-r--r-- 1 root root 5716 Nov 29 11:24 config-rhel-generic -rw-r--r-- 1 root root 8194 Nov 29 11:24 config-powerpc-generic -rw-r--r-- 1 root root 4077 Nov 29 11:24 config-powerpc64 -rw-r--r-- 1 root root 94 Nov 29 11:24 config-powerpc32-smp -rw-r--r-- 1 root root 4170 Nov 29 11:24 config-powerpc32-generic -rw-r--r-- 1 root root 2615 Nov 29 11:24 config-nodebug -rw-r--r-- 1 root root 148 Nov 29 11:24 config-local -rw-r--r-- 1 root root 205 Nov 29 11:24 config-i686-PAE -rw-r--r-- 1 root root 101717 Nov 29 11:24 config-generic -rw-r--r-- 1 root root 2043 Nov 29 11:24 config-debug -rw-r--r-- 1 root root 2117 Nov 29 11:24 config-arm-tegra -rw-r--r-- 1 root root 31261 Nov 29 11:24 config-arm-omap-generic -rw-r--r-- 1 root root 3397 Nov 29 11:24 config-arm-generic -rw-r--r-- 1 root root 65075 Jan 6 15:02 config-x86_64-generic

10.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.

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.

10.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/

11 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.4- 1.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 24 2011 initrd-plymouth.img drwxr-xr-x 3 root root 4096 May 24 2011 efi -rw-r--r-- 1 root root 2056069 Aug 26 11:51 System.map-2.6.38.2-xxxx-grs-ipv6-64 -rw-r--r-- 1 root root 5735824 Aug 26 11:51 bzImage-2.6.38.2-xxxx-grs-ipv6-64 drwx------2 root root 16384 Jan 5 12:16 lost+found -rwxr-xr-x 1 root root 5736416 Jan 9 11:07 vmlinuz-2.6.41.4- 1.switzernet.fc15.x86_64 -rw------1 root root 2739716 Jan 9 11:07 System.map-2.6.41.4- 1.switzernet.fc15.x86_64 -rw-r--r-- 1 root root 65065 Jan 9 11:07 config-2.6.41.4-1.switzernet.fc15.x86_64 drwxr-xr-x 3 root root 4096 Jan 9 11:28 grub2 -rw-r--r-- 1 root root 7217776 Jan 9 11:29 initramfs-2.6.41.4- 1.switzernet.fc15.x86_64.img

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 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-f169-45ad- 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-f169-45ad- 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 ### ...

12 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.

12.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 kernel- 2.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

12.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:

of 6566 Install USB over IP client on the Configurator 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.

13 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 [email protected]:/share/MD0_DATA/porta-billing- mr23/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 [email protected]:/share/MD0_DATA/porta-billing- mr23/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.18- 164.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 pb_initrd]# gunzip initrd-2.6.18-164.0.0.0.1.el5.gz [root@ks389032 pb_initrd]# cd cpio_init/ [root@ks389032 cpio_init]# cpio -id < ../initrd-2.6.18-164.0.0.0.1.el5 16973 blocks [root@ks389032 cpio_init]# ls bin dev etc 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

of 6566 Install USB over IP client on the Configurator 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 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

of 6566 Install USB over IP client on the Configurator echo "Loading usb-storage.ko module" 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

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

of 6566 Install USB over IP client on the Configurator 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 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.4- 1.switzernet.fc15.x86_64.img

The last step is to edit GRUB2. Refer to the next section to do that.

14 Configure GRUB2 Note that as we installed the /boot partition with Fedora, the GRUB2 configuration files refer to /dev/sda2 as root.

14.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 gnu- linux --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 ###

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 gnu- linux --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.

14.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

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

14.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 data bytes (~ 1 min 15 s before pinging) 64 bytes from 213.xxx.xxx.xxx: icmp_seq=77 ttl=51 time=172 ms 64 bytes from 213.xxx.xxx.xxx: icmp_seq=78 ttl=51 time=213 ms 64 bytes from 213.xxx.xxx.xxx: icmp_seq=79 ttl=51 time=241 ms

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.

15 Post-install configurations

15.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.4- 1.switzernet.fc15.x86_64-xxxx-std-ipv6-64

Once we have renamed the library, we can build the modules: depmod -a

15.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

15.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

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

15.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

15.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].

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:

15.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.

16 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= ##########################

17 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.

17.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  USB/IP support Device drivers  Staging drivers  VHCI hcd

Device drivers  Staging drivers  Host driver Device drivers  Staging drivers  [*] Debug messages for USB/IP

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.

17.2 Install USB over IP Go into the USB over IP kernel staging driver directory: cd ./rpmbuild/BUILD/kernel-2.6.41.fc15/linux- 2.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

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.4- 1.fc15.x86_64/kernel/drivers/staging/usbip/usbip-core.ko

[root@212-147-8-107 userspace]# insmod /lib/modules/2.6.41.4- 1.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 ~]# lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub

Bus 002 Device 008: ID 07f2:0001 Microcomputer Applications, Inc. KEYLOK II Bus 002 Device 004: ID 046d:c05a Logitech, Inc. Optical Mouse M90 Bus 002 Device 006: ID 05e3:0716 Genesys Logic, Inc. USB 2.0 Multislot Card Reader/Writer 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.

18 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.

18.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/linux- 2.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

18.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:

of 6566 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 ~]# tar -xzvf usbip-0.1.7.tar.gz [root@billing1 ~]# ./autogen.sh [root@billing1 ~]# ./configure [root@billing1 ~]# 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

18.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-std- ipv6-64/kernel/drivers/staging/usbip/usbip-core.ko

[root@billing1 ~]#insmod /lib/modules/2.6.41.4-1.switzernet.fc15.x86_64-xxxx-std- ipv6-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 Used by vhci_hcd 21175 - usbip_host 15789 - usbip_core 12253 - [root@billing1 ~]#

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.xxx- xxx.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 /]# lsusb Bus 005 Device 004: ID 07f2:0001 Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

And the PortaOne MR23 command checkdongle display the following output:

[root@billing1 /]# checkdongle DONGLE OK - key expires on: Thu Mar 1 00:00:00 2012

18.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 / ext3 defaults 1 1 /dev/VolGroup00/LogVol01 /update_root ext3 defaults 1 2 /dev/VolGroup00/LogVol02 /porta_var ext3 defaults 1 2 LABEL=/boot /boot ext3 defaults 1 2 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0 /dev/VolGroup00/LogVol03 swap swap defaults 0 0 /dev/sda2 /root/root_fedora ext3 defaults 0 0

18.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-ipv6- 64/kernel/drivers/staging/usbip/usbip-core.ko insmod /lib/modules/2.6.41.4-1.switzernet.fc15.x86_64-xxxx-std-ipv6- 64/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].

19 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.

20 References

20.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/

20.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/

20.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-mount- failed-kernel-panic/

How to work with initial ram disk: http://www.ibm.com/developerworks/linux/library/l-initrd/index.html

20.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

20.1.5 This document Word document: http://switzernet.com/3/public/120110-install-mr23-redhat-ovh/index.doc

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

21 Glossary

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.

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.

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.

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.

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 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.

Abbreviation of Red Hat Enterprise Linux, RHEL is a commercial Linux-based operating system developed by Red Hat and based on RPM packages.

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.

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

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.

This acronym of Virtual LAN is a method that allows to create independent logical computer networks regardless of their physical location.

of 6566