Friday 8 February 2013

Adding Ubuntu 12.04 KVM host to Cloudstack 4.0

Adding an Ubuntu 12.04 LTS  KVM host to a CloudStack cloud can be quite tricky. The simple script described in this post takes care of the pitfalls and documents the process of installing a host that can be added to an existing Cloudstack Zone / Pod.

The script assumes a basic installation of Ubuntu 12.04 LTS server (I used the 64bit version) with only OpenSSH installed during the installation. The script is only really suitable for simple network configuration. But can of course be used as a basis for something more sophisticated (see also the function: make_interfaces_bridges).

The script looks after the following:
  • enables root account (needs passwords) - function: enable_root
  • create the interface settings based on a simple network configuration (watch out this is not very well described in the Cloudstack KVM installation manual) - function: make_interfaces
  • set the hostname - function:  set_hosts_hostname
  • restarts the network to implement the new network configuration - function: restart_network
  • prepares the firewall - function: set_firewall
  • adds CloudStack repositories, updates and upgrades the system and installs openntpd and tcpdump - function: ubuntu_update
  • performs some pre-installation checks - function:  pre_install_checks
  • installs CloudStack agent and system ISO - function: install_cloudstack
  • edits libvirt configuration - function: prepare_libvirt
  • edits qemu configuration - function: prepare_qemu
  • prepares Ubuntu's app armor - function: prepare_apparmor
  • summarizes the network configuration once again: list_addresses
At the top of the script (function: init_vars)  several variables must be adjusted to fit the desired network configuration.

The script is provided "as-is", does not do any error checking and is written to document the process and speed up the (re-)installation of KVM hosts for inclusion in CloudStack.

#!/bin/bash
# Script to prepare a virgin installation of Ubuntu 12.04 server for Cloudstack
# KVM node deployment
#
# Version 0.4, Gerry Havinga, January 2013
#
# 0.1 - first attempt, not complete
# 0.2 - added extra echo statements to make output more eligible (still a mess)
# 0.3 - Fixed wrong sed match
# 0.4 - added function to edit qemu.conf and enable VNC console access from anywhere
#
# Ubuntu installed with defaults, "Basic Ubuntu server" and "OpenSSH server" software installed.

function init_vars ()
{
    # Date
    date=`date +%Y%m%d%H%M%S`
    # Will only run on
    SUPPORTED_UBUNTU=12.04TLS
    # For basic netorking all hosts can be in the same subnet. Networks are isolated
    # by specifying non-overlapping ranges of IP addresses.
    # Set IP addressing:
    # Assuming management to run between IPs 32 and 64
    MANAGER_IP=10.128.0.32
    MANAGER_NAME=cloudstack
    MANAGER_FQDN_NAME=cloudstack.acme.com
    # Assuming nodes to run between IPs 65 and 94
    # Node
    KVM_NODE_IP=10.128.0.48
    KVM_NODE_MASK=255.255.255.0
    KVM_NODE_NW=10.128.0.0
    KVM_NODE_GW=10.128.0.1
    KVM_NODE_BC=10.128.0.255
    KVM_NODE_NAME=node01leusden
    KVM_FQDN_NODE_NAME=node01leusden.acme.com
    # Management network (KVM host must be able to see Cloudstack manager)
    MGMT_NET=10.128.0.0
    MGMT_MASK=255.255.255.0
    MGMT_GW=10.128.0.1
    # Public network - addresses associated with Internet accessible hosts
    # In basic networking the guest and public networks are the same
    # Assuming public network range from IPs 95 till 126
    PUBLIC_NET=10.128.0.95
    PUBLIC_MASK=255.255.255.0
    PUBLIC_GW=10.128.0.1
    # Guest network, tenant network to which instances are attached
    # In basic networking the guest and public networks are the same
    # Assuming guest network range from IPs 95 till 126
    GUEST_NET=10.128.0.95
    GUEST_MASK=255.255.255.0
    GUEST_GW=10.128.0.1
    # Privat (storage) network - must be accessible by system VMs and KVM host
    # Assuming from IPs 65 and 94
    PRIVAT_NET=10.128.0.65
    PRIVAT_MASK=255.255.255.0
    PRIVAT_GW=10.128.0.1
    # Name servers
    DNS_PRIMARY=10.0.0.1
    DNS_SECONDARY=8.8.8.8
    DNS_SEARCH=acme.com
    echo "Script $0 for setting up an $SUPPORTED_UBUNTU KVM host for inclusion in a Cloudstack POD."
    echo "IP settings will be:"
    echo "This host: [$KVM_NODE_IP] [$KVM_NODE_MASK] [$KVM_NODE_GW]"
    echo "Management network: [$MGMT_NET] [$MGMT_MASK] [$MGMT_GW]"
    echo "Public network: [$PUBLIC_NET] [$PUBLIC_MASK] [$PUBLIC_GW]"
    echo "Guest network (for VMs): [$GUEST_NET] [$GUEST_MASK] [$GUEST_GW]"
    echo "Privat (storage) network: [$PRIVAT_NET] [$PRIVAT_MASK] [$PRIVAT_GW]"
    read -p "Do you wish to continue [ynq]?" yn
    case $yn in
        [Yy]* ) return; echo " ";;
        [NnQq]* ) exit;;
        * ) echo "Please answer y or n.";;
    esac
}

function enable_root ()
{
    echo "Enabling root, please specify a new root password."
    sudo passwd root
    echo " "
}

function make_interfaces_bridges ()
{
    echo "Trying to install Cloudstack for KVM once again ...."
    echo "With pre-configured bridges."
    echo "KVM node IP addres and mask: $KVM_NODE_IP $KVM_NODE_MASK"
    echo "Management network, mask and gateway: $MGMT_NET $MGMT_GW"
    echo "Public network, mask and gateway: $PUBLIC_NET $PUBLIC_MASK $PUBLIC_GW"
    echo "Guest network, mask and gateway: $GUEST_NET $GUEST_MASK $GUEST_GW"
    echo "Privat (storage) network, mask and gateway: $PRIVAT_NET $PRIVAT_MASK $PRIVAT_GW"
    echo "Making backup of interfaces... to /etc/network/interfaces.backup.$date"
    cp /etc/network/interfaces /etc/network/interfaces.backup.$date
    cat > /etc/network/interfaces << _EOF_
# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
    address $KVM_NODE_IP
    netmask $KVM_NODE_MASK
    network $KVM_NODE_NW
    broadcast $KVM_NODE_BC
    gateway $KVM_NODE_GW
    # dns-* options are implemented by the resolvconf package, if installed
    dns-nameservers $DNS_PRIMARY $DNS_SECONDARY
    dns-search $DNS_SEARCH

# Public network
auto cloudbr0
iface cloudbr0 inet manual
    bridge_ports eth0.200
    bridge_fd 5
    bridge_stp off
    bridge_maxwait 1

# Private network
auto cloudbr1
iface cloudbr1 inet manual
    bridge_ports eth0.300
    bridge_fd 5
    bridge_stp off
    bridge_maxwait 1
_EOF_
    echo " "
}

function make_interfaces ()
{
    echo "Trying to install Cloudstack for KVM once again ...."
    echo "Without pre-configured bridges."
    echo "KVM node IP addres and mask: $KVM_NODE_IP $KVM_NODE_MASK"
    echo "Management network, mask and gateway: $MGMT_NET $MGMT_GW"
    echo "Public network, mask and gateway: $PUBLIC_NET $PUBLIC_MASK $PUBLIC_GW"
    echo "Guest network, mask and gateway: $GUEST_NET $GUEST_MASK $GUEST_GW"
    echo "Privat (storage) network, mask and gateway: $PRIVAT_NET $PRIVAT_MASK $PRIVAT_GW"
    echo "Making backup of interfaces... to /etc/network/interfaces.backup.$date"
    cp /etc/network/interfaces /etc/network/interfaces.backup.$date
    cat > /etc/network/interfaces << _EOF_
# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
    address $KVM_NODE_IP
    netmask $KVM_NODE_MASK
    network $KVM_NODE_NW
    broadcast $KVM_NODE_BC
    gateway $KVM_NODE_GW
    # dns-* options are implemented by the resolvconf package, if installed
    dns-nameservers $DNS_PRIMARY $DNS_SECONDARY
    dns-search $DNS_SEARCH

_EOF_
    echo " "
}

function set_hosts_hostname ()
{
    echo "Setting hostname and hosts file."
    echo "Making backup of hostname file to /etc/hostname.backup.$date."
    cp /etc/hostname /etc/hostname.backup.$date
    cat > /etc/hostname << _EOF_
$KVM_NODE_NAME
_EOF_
    echo "Making backup of hosts file to /etc/hosts.backup.$date."
    cp /etc/hosts /etc/hosts.backup.$date
    cat > /etc/hosts << _EOF_
127.0.0.1    localhost
$KVM_NODE_IP    $KVM_FQDN_NODE_NAME    $KVM_NODE_NAME
$MANAGER_IP    $MANAGER_FQDN_NAME    $MANAGER_NAME

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
_EOF_
    hostname -b -F /etc/hostname
    echo " "
}

function restart_network ()
{
    echo "Restarting network..."
    /etc/init.d/networking restart
    echo " "
}

function set_firewall ()
{
    echo "Setting up Ubuntu's simple firewall..."
    ufw allow proto tcp from any to any port 22
    ufw allow proto tcp from any to any port 1798
    ufw allow proto tcp from any to any port 16509
    ufw allow proto tcp from any to any port 5900:6100
    ufw allow proto tcp from any to any port 49152:49216
    ufw enable
    echo " "
}

function ubuntu_update ()
{
    echo "Prepare the Cloudstack repository."
    cat > /etc/apt/sources.list.d/cloudstack.list << _EOF_
deb http://cloudstack.apt-get.eu/ubuntu precise 4.0
_EOF_
    wget -O - http://cloudstack.apt-get.eu/release.asc|apt-key add -
    echo "Update and upgrade."
    apt-get -y update
    apt-get -y upgrade
    echo "Install openntpd (update/upgrade first because of a bug in 12.10)"
    apt-get -y install openntpd
    echo "In case we need it."
    apt-get -y install tcpdump
    echo " "
}

function pre_install_checks ()
{
    echo "Does hostname resolve fully?"
    hostname --fqdn
    echo "Can we reach the outside world?"
    ping -c 4 www.cloudstack.org
    echo "Can we ping the management?"
    ping -c 4 $MANAGER_IP
    echo "*************************************************************"
    echo "Warning check the above two tests have worked as you expected."
    echo "Only continue if both FQDN and outside world tests succeeded."
    echo "*************************************************************"
    read -p "Do you wish to continue?" yn
    case $yn in
        [Yy]* ) return; echo " ";;
        [Nn]* ) exit;;
        * ) echo "Please answer y or n.";;
    esac
}

function install_cloudstack ()
{
    echo "Installing cloudstack agent and system iso."
    apt-get -y install cloud-agent
    apt-get -y install cloud-system-iso
}

function prepare_libvirt ()
{
    echo "Updating the libvirt configuration (appending)..."
    cp /etc/libvirt/libvirtd.conf /etc/libvirt/libvirtd.conf.backup.$date
    cat >> /etc/libvirt/libvirtd.conf << _EOF_
listen_tls = 0
listen_tcp = 1
tcp_port = 16059
auth_tcp = "none"
mdns_adv = 0
_EOF_
    echo "Adjusting startup parameters for libvirt deamon."
    cp /etc/init/libvirt-bin.conf /etc/init/libvirt-bin.conf.backup.$date
    sed -i 's/libvirtd_opts="-d"/libvirtd_opts="-d -l"/g' /etc/init/libvirt-bin.conf
    echo "Restarting libvirt service..."
    service libvirt-bin restart
    echo " "
}

function prepare_qemu ()
{
    echo "Adjusting vnc_listen = 0.0.0.0 in /etc/libvirt/qemu.conf. "
    cp /etc/libvirt/qemu.conf /etc/libvirt/qemu.conf.backup.$date
    sed -i 's/# vnc_listen = "0.0.0.0"/vnc_listen = "0.0.0.0"/g' /etc/libvirt/qemu.conf
    service libvirt-bin restart
}


function prepare_apparmor ()
{
    dpkg --list 'apparmor'
    echo "Prepare Ubuntu's application armor to be nice to libvirt."
    ln -s /etc/apparmor.d/usr.sbin.libvirtd /etc/apparmor.d/disable/
    ln -s /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper /etc/apparmor.d/disable/
    apparmor_parser -R /etc/apparmor.d/usr.sbin.libvirtd
    apparmor_parser -R /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper
    echo " "
}

function list_addresses ()
{
    echo " "
    echo "IP settings:"
    echo "This host: [$KVM_NODE_IP] [$KVM_NODE_MASK] [$KVM_NODE_GW]"
    echo "Management network: [$MGMT_NET] [$MGMT_MASK] [$MGMT_GW]"
    echo "Public network: [$PUBLIC_NET] [$PUBLIC_MASK] [$PUBLIC_GW]"
    echo "Guest network (for VMs): [$GUEST_NET] [$GUEST_MASK] [$GUEST_GW]"
    echo "Privat (storage) network: [$PRIVAT_NET] [$PRIVAT_MASK] [$PRIVAT_GW]"
    echo " "
}

# Main part
init_vars
enable_root
make_interfaces
# make_interfaces_bridges
set_hosts_hostname
restart_network
set_firewall
ubuntu_update
pre_install_checks
install_cloudstack
prepare_libvirt
prepare_qemu
prepare_apparmor
list_addresses
echo "Recommend to re-boot the system."
echo "Now add the KVM host to the Cloud manager."
echo "End of script."










Wednesday 13 July 2011

Using OpenLDAP to authenticate HP-UX users

Introduction
This page describes how to configure the HP-UX LDAP client services to authenticate against OpenLDAP. For the OpenLDAP configuration see: LDAP server configuration RHEL 5.
The OpenLDAP directory server must be prepared and configured in advance before the HP-UX LDAP clients can be configured and the HP-UX system will authenticate against the directory. LDAP-UX can be configured to bind to the directory using a proxy. This is in principle more secure. The standard software is used, all authentication and password management is done by the directory. To make sure HP-UX reacts properly when a password has expired or a password reset has occurred (user must at next logon choose his/her own password) the pam_authz library is used.
To configure HP-UX the following must be done:

  • Installation of the LDAP packages
  • Import the certificate of the relevant CA - only if the secure LDAP protocol (SSL) is used
  • Run /opt/ldapux/config/setup
  • Provide DN of the system profile entry (as installed in the directory)
  • Check the ldapclientd daemon is running
  • Adjust the nsswitch.conf file
  • Configure pam to use the LDAP (in /etc/pam.conf
  • Copy provided pam.ldap example to pam.conf
  • Adjust pam.conf to enable pam_authz.policy for password policy effects
  • Configure /etc/opt/ldapux/pam_authz.policy file
  • Enable and configure the proxy settings
More information can be found in the HP_UX LDAP-UX client services administration guide. Be aware this document describes the process of getting LDAP-UX to work against Netscape Directory Services 6.x. Officially this is the only (non-Microsoft) directory service supported under HP-UX. OpenLDAP works very well though when configured properly.

Thursday 27 March 2008

Getting XUbuntu 8.04 beta to work on an old Dell Latitude CPi's

Visit Xubuntu.org
It has been a while since our last post. But two days ago we started work on an interesting, though perhaps a bit weird, challenge: to get xubuntu 8.04 Beta to work on an old Dell Latitude CPi. This is the trouble we get into when we boast about how great Linux is and that it is more than ready for the desktop ;-). We choose xubuntu because of it's claim to be light and easy on the hardware.

We have two old Dell Latitude spare laptops. One of them had the keys partly ripped of a few years ago, by a diligent, very creative 2 year old. The other was left abandoned by it's previous owner because of a failed hard drive. They are not completely identical, but they have enough in common to use one of them as a spare for the other. Eventually we ended up with the with the following configuration:
  • Dell Latitude CPi
  • Pentium-II 400Mhz
  • 160MB system memory
  • 4 MB Neomagic 2360 video controller
  • 12,073 MB hard drive
  • CD-ROM installed in modular bay
  • external Trust USB keyboard (USB legacy mode enable in BIOS)
  • PCMCIA Xircom RealPortRBE-100 10/100Mbs ethernet card
  • Single primary partition occupying the whole disk with a FAT32 file system
First we would like to share the things that went wrong, before we figured out how to get xubuntu to work (yes we did after two days of fiddling):
  • Slow boot because of xubuntu insisting on checking for non-existent floppy drives
  • Extremely slow boot after the second installation menu
  • Problems with ext3 formatting caused by the fix for the previous problem
  • Network interface card not getting an IP address
Slow boot because of floppy trouble.
The first problem was easily resolved by setting the floppy "Diskette reconfig" to "At Reboot Only" in the BIOS. This makes a big difference in boot time. As we didn't have a floppy drive installed in one of the spare bays, disabling this option, saves minutes in boot time.
Extremely slow boot after second installation menu.
The installation and live cd boot both fail, well not quite, but after 10 hours of churning on the CD we considered it failed ;-). The installer seems to be getting itself stuck after the second menu (Welcome - installation language), looking at F8 the last message displayed by the system is: "* Starting Ubiquity...". No response from the mouse, the animated cursor has stopped animating and the CD is continuously active with occasional hard drive activity. Originally we thought the trick would be to find the right kernel parameter to solve this problem. But this was not the case. But after some deeper digging and running top in one of the consoles (we had to do this immediately after we clicked on "Forward" at the second install menu, while the system was in the process of responding). Using F1 we managed to get a slow terminal prompt and top showed the system was waiting for I/O more than 85% (%WA) of the time (5th field from the left in 3rd line from the top):



This gave us the idea that actually all we needed to do was to enable a small (twice the size of internal memory) swap partition on the hard drive. After we did that the difference in response time was remarkable .... but now we created a new problem.
ext3 formatting failed.
As we now claimed the drive, the Linux kernel couldn't dynamically load the partition table after we choose "Guided partitioning", manually partitioning the system didn't work either of course. This was caused by
mkfs -t ext3 /dev/sda1 failing with a "could not stat /dev/sda1". Happily the fix to this wasn't difficult, a reboot and the new partition table was picked up and so was the swap partition.
Network interface card not getting an IP address.
After login it turned out the network wasn't running, after some investigation it turned out to be the network interface was set into "roaming" mode. After taking that out and enabling DHCP we could surf the Internet usingFirefox.

Actual procedure on how to get xubuntu 8.04 beta to work on the Latitude.
First things first, having learned our lesson, we adjusted the BIOS setting such that the "Diskette reconfig" only can be done at boot time. Then after obtaining the download ISO image from one of the xubuntu mirrors and burning a CD we booted the Latitude from the CD, the boot menu looks like this (yes it jumps straight into the F2 menu to select the language):



We decided to install directly to the hard drive, after selecting the language the first option was highlighted, we didn't want that:



We needed to select the second option and choose F6 "Other Options" to switch of quite mode. it is a good idea if the installation doesn't go according to plan to make the system a bit more chatty:



Removing the "quiet" kernel option:



Press enter and the system will start churning. While it is doing this have a look at the boot messages under F1. You will see some message scroll across the screen giving some indication of the kernel's process of working out what hardware it is running on:



To get back to the graphical installation choose F7:



After a while the system will show the, quite stunning, bird (is it a firebird?) wallpaper:



The first of 8 installation windows will now prompt you:



To go to the next screen click "Forward", at this stage, while the following menu (language choice) was displayed the excessive delay and CD activity started (when we tried this first time):



Here we chose the language of the installation and the default language used for running the system. Also here we got stuck so we needed to divert away from the installation process and create a swap partition. As quickly as possible at this menu or even better the menu before using cntl-alt-F1 open a terminal and enable swap.

First use fdisk to delete any old partition that was still present on the drive and create a new
empty partition of about twice the size of internal memory (the installation process will redo this, so the actual location and size isn't that important):

sudo fdisk /dev/sda

When fdisk starts (this can take a while), use the following commands as your guide:



The example above will create a partition of 320MBytes with a type of 82 (Linux Swap). Confirm this using (fdisk again):



At the prompt the new partition must now be enabled for swap, this will dramatically speed up the rest of the installation:

sudo mkswap /dev/sda1

sudo swapon /dev/sda1 (is not necessary as we need to reboot here)

We did try to continue from here and got stuck (see above). Here a reboot is required to go back to the installation menu. The system will now pick up the swap partition and use it. We went through the same menus (1 and 2 of eight and eventually got to the next step "Where are you" without to much delay):



The zoom feature used when the mouse hovers over the picture of the world map is a bit fanatic. The zooming is rather sensitive, amplifying the slightest mouse movement into a fast hunt for the home location! Quite a nice game, but not intended as such, we believe. After we hit the right spot (the drop down menu can also be used ;-). The next menu will come quickly:



As our laptop has an external USB international keyboard we choose the "USA-With EuroSign on 5 setting". This turned out to be the right choice.

Step 5 out of 8 is the process of setting up the disk partitioning. As the kernel now has the correct partition table loaded, using the Guided (full disk) partitioning worked beautifully:



A (quickly disappearing) message that it is reading the hard disk partition table is displayed and then the system responds reasonably quickly with the next menu, where the main login must be created:



Now the system has enough information to continue (on it's own) with the installation:



After clicking on "Install" several messages are displayed:



We thought at this stage it was safe
to leave the office, go to home and to bed. Unfortunately leaving xubuntu unattended after the last step wasn't such a good idea. It spontaneously went into hibernation and didn't finish the installation (this was over night at about 15% in the "Installing System" stage). The next morning we had to go over the same steps again ..... while every so often keep clicking the mouse button to keep the system awake .....

In addition to that at about 61% the status display disappeared completely. After about 30 minutes the system came back with an installation ready status message, reboot and remove the CD and the system booted into xubuntu. But we were sailing blind for a while.

Eventually the system asked for a re-boot and yes when it came back up we were greeted with the login screen!

Before we could surf the Net we had to setup the ethernet interface as the system had installed it by default with "roaming" enabled. We're not quite sure what is meant with that on a wired network, any ideas please feel free to leave a comment. It's fairly easy to rectify this problem, on the left top menu Applications under the drop down menu System, Network the network manager can be found:




When the "Network Settings" application starts up, unlock the access to the ability to make any changes and enable DHCP:



First impressions are very positive (after we recovered from the installation ....). The system is responsive, very similar to Windows XP on the same laptop. In a later post we will share our experience using xubuntu on this laptop.

Thursday 31 May 2007

Using Hewlett Packard blade systems for iLO installation of RHEL 4.

Two weeks ago we had the opportunity to do some work for a customer in Brussels, Belgium and to use a Hewlett Packard blade system. The HP blade rack was stored in a separate computer room from the training room and we used full remote access to install Red Hat Enterprise Linux 4 from a USB key attached to a laptop running SuSE Linux. The USB key contained ISO images from the 4 RHEL 4 installation CDs.

A (not very good mobile phone) picture of the naked front of the blades:



Another picture of the front of the actual blade boards. You can see clearly the hard drives attached to the motherboards and the cable attaching the management and diagnostics console to the system:



The management console sits in a sliding tray, nicely tucked in at the top of the rack. It can be pulled out, the screen lifted and a keyboard becomes available from underneath (in this picture it shows running a non-open source operating environment, sorry):



A final image of a blade server "tray". The (very noisy) fans are clearly visible doing their job keeping the dual core CPUs at the right temparature:

b

The purpose of the exercise was to provide a classroom server, running RHEL 4 with Apache, LDAP and DNS and to install it without any interaction with the physical blade hardware.

The installation did take some time of course as the installation ISOs had to be accessed from the USB (2.0) key, over the network to the blade (it was part of the fun getting that to work). We used the HP's "Integrated Lights Out" iLO console to "mount" the USB key as if it was a locally attached CD/DVD drive. Click here for a Wikipedia link to find out what iLO really is.

First we needed to identify ourselves to the iLO console through login as the administrator:



After successful login the iLO console displays the status summary menu from where several tasks can be performed:



To access the ISO images on the memory stick click on "Virtual Devices" and in the dialogue point the virtual CD-Rom to the local image file (in our case it was on the memory stick on /media/ISO-STICK/:



We connected (virtually) the first RHEL4 ISO on the memory stick and now the system can boot from it.

To be able to see the installation process and answer the questions asked by Anaconda we enabled the "Remote Console" from the iLO main menu (see previous screenshot above). iLO will launch a Java application with a view on the virtual console:



The above screenshot shows the installation halfway during the Red Hat packages copy and install process. The reason the remaining time is high is caused by us "removing" the virtual CD-Rom at one point at the end of the day. Allowing the system to generate an error message (with a retry option to re-read the CD-Rom), leaving the building for the evening and night, returning back the next morning, remounting the ISO image to the virtual CD-Rom and allowing Anaconda to retry reading the CD-Rom. Amazingly enough it worked and the installation did continue where it had stopped although the timing was confused of course.

The following sceen shows the dialogue to insert another CD-Rom (disk 4), using the "Virtual Media" menu just umount the existing ISO image, point to the next ISO image and re-mount the file as a virtual CD-Rom:



The timing eventually manage to correct itself, 35 minutes left!

Eventually we were rewarded with RHEL4' login menu through the virtual console:



The power of the Integrated Lights Out technology is clearly demonstrated. We installed a complete Red Hat Enterprise 4 installation without touching the actual hardware at any time. The installation worked very well over the network, using a standard laptop running SuSE 10.0 with a USB memory stick containing the RHEL 4 ISO images mounted as a virtual CD-Rom. Not bad, not bad at all. Can we have 10 please ;-).

Powered by ScribeFire.

Sunday 6 May 2007

Installation tutorial: Red Hat Enterprise Linux 4, introduction - part 3 (final)



This is the third (and final) part of the RHEL 4 installation tutorial, You can find the first part here and the second part here.

4.1 First boot (setup agent)
When the system comes back up after you have asked it to reboot, login using the root account (remember the root password) and the system will present you with the "first boot" welcome menu:



Click "Next" to move on to the next menu where you will be asked to agree with Red Hat's licensing scheme:



It is important to notice here that this license in many cases refers to licenses included with the source code of each software component that has been shipped with the Red Hat media. Most of the components adhere to the GNU Public License version 2, click here to learn more about what that means.

If you agree tick the "Yes, I agree to the License Agreement" and click "Next".



Here you can set the date and time at your location or alternatively allow the system clock to be set using the Network Time Protocol (NTP) by referring to time servers scattered around the Internet (we won't cover this, if you want to know more about NTP click here).

Set the correct date and time for your system and click "Next". This will bring you to the graphics display configuration menu:



The system assumes a "safe" resolution setting (800x600) and will have attempted to detect the monitor you are using. We will configure the resolution to a more sensible setting, but before we can do that the system need to be made aware of the capabilities of your monitor. To set the monitor type click "Configure":



Depending on what you are using choose the monitor model closest matching your monitor type (if the monitor is not a latest model there is a chance the settings are correct and there won't be a need to change them).

Click "OK" and you will see a menu similar to (if you have chosen a different monitor model the values might differ):





The next menu will give you an opportunity to enable the additional Red Hat subscription service:





You can choose and existing subscription (you must provide a login and password), or at this point you can create a new Red Hat login id and you can skip the dialogue (but you willhave to go past a "why is this important" screen". In this tutorial we will choose the "Tell me why I need to register ....." option so if you have made another choice the next menu will be different:



As we won't be making a registration here make sure to tick the "I can not complete ...." option and click "Next" to continue to the next step:



Here you have an option to create an additional (system) user. It is strongly recommended not to use the system administrator user (root) for day to day tasks (such as surfing the Net, writing reports and so on). The sudo or su commands provide the possibility to run a command as root (once in the case of sudo) or from within a new root shell (with su). Many of the GUI administrative tools provided with RHEL will ask for the root password when invoked by a non-priviliged user.

Create a new user here by specifying a login name (the username field), an optional full name and a (secure) password (you need to confirm this in case of typos). When you're done click "Next" to continue:







If you have any additional software you desire to install here you can insert the extra CDs and install additional documentation, software and plugins. We will skip this step, click "Next":



You have reached the final menu after which you can use the system!

From here you can start exploring the system menus, administration tools, the shell and many other aspects of the installed system.

If you want to review the previous sections, click here for the first part and here for the second part of this tutorial.

Congratulations you have installed Red Hat Enterprise Linux version 4.

Powered by ScribeFire.

Tuesday 1 May 2007

Installation tutorial: Red Hat Enterprise Linux 4, introduction - part 2


This is the second part of the RHEL 4 installation tutorial. You can find the first part here

3.2 Graphical installation: network
The next menus you will encounter are designed to assist you installing the network card and network characteristics of the Red Hat system being build:



Here you can choose a dynamic TCP/IP configuration or a static. In the next part you will setup a static configuration, this allows a more thorough review of the installation menus. If your LAN network configuration allows for it, there is no reason to just leave the default settings.
For the purpose of this tutorial click the "Edit" button, this will bring up the "Edit Interface eth0" dialogue box:



If they don't conflict with your local network addressing scheme choose the settings as shown above and click "OK" to continue to the next menu:



Notice the menu has been updated to reflect your choice of manual (fixed) IP address configuration. Finalise the network configuration as shown above (using your own values) and move on to the next section by clicking

3.3 Graphical installation: firewall and security enhanced Linux
The next menu will ask if you want to have the firewall installed and what level of security enhanced Linux you want to deploy. If this is a standalone, server system within a protected privat network you probably won't need the firewall enabled. It is very likely the kernel filters (using iptables rules) might interfere with the services you are trying to deliver. For the purpose of this tutorial you will disable the firewall.
Security enhanced Linux (SELinux), the code originally added by the United States government National Security Agency, provides a mandatory security implementation to Linux. In addition to the traditional Linux (Unix) style security, based on ownership, SELinux adds mandatory access controls (rules based) to the Linux kernel. SELinux uses rule sets to control who and what can be done to any object within the system. For the purpose of this tutorial you will set the SELinux level to "warn" only. This provides a good way to learn about SELinux without it being in the way of your day to day operation of the system:



Make sure you switch off the firewall and select "Warn" for SELinux and click "Next" to continue.
A warning will be displayed making sure you really, really want the firewall to be switched off:



Click to continue

3.4 Languages, timezones and root password settings
The next few menus deal with the default system language, if you desire to do so, the installation of additional language support, what timezone your system is operating in and the system administrator, root, password. The menus are self explanatory, if you want to know more don't forget to scroll through and read the help window pane on the left side of the main menu.



Make sure you select the correct default language for your system. If you select any additional languages Anaconda, the installer, will add the appropriate dictionaries and language support files to your system but the default language is what you will use on a daily basis while interacting with the system. To continue click



As you can see overhere on this screenshot, London is the centre of the planet ...... not that we are biased overhere. You can use the map to "zoom" in on areas and select a city as close as possible to your location (make sure it is in the same time zone). You can also scroll down the list in the bottom window pane (that actually might be quicker and more accurate). When you're done click the "Next" button.



This menu asks you to provide the system "root" user password. As you undoubtedly are aware, the "root" user (on a non SELinux enhanced system) is able to access every file, process, system memory location, kernel driver and so on. A malicious non-priviliged user with bad intentions (even with good intentions) will try to elevate his/her privilege to the super user "root" as soon as possible (and then follows on to wipe out any traces of such an act). Choose the "root" user password with care. Strong passwords have a minimum length (8 characters), use upper and lower case characters, use punctuation characters and numbers but are relatively easy to remember and are not found in dictionaries. Some examples are (you can use normal words mixed with other characters): safe4Me+U, build2Strength!. Of course random characters are best but you might not be able to remember them. Whatever password you choose, type it into the appropriate menu field, make sure you remember, and click

3.5 Package selection
The following setup menu builds your final system to become a workstation or server or any other combination of software packages that Red Hat has included on the installation medium. Modern Linux distributions consist out of pre-selected and pre-configured package files that contain software, libraries, configuration and text files and many others together with the information where they need to be installed with what kind of security settings. If you have an opportunity when the system is running we suggest you have a look at the directory structure of one of the installation CDs and you will find within one of the directories a large amount of files with an ".rpm" file extention. These are the files that are used to create your system. Each ".rpm" file is a self contained unit and can be upgraded, removed or re-installed using simple command line or GUI tools.
To continue you need to decide what you want your system to be:



At this stage you will customise the installation by fine tuning what you want to have installed. Of course any selections you make overhere can be changed when the system is up and running. Choose the second option "Customize software packages to be installed" and click "Next".



The "Package Group Selection" menu shows the groups of packages, as selected by Red Hat, you can install on your system. You can further tune what you want to have installed by clicking the "Details" button, wherever available, to the right of the package selections. Red Hat for many years now has made this process very easy by using sensible package group names that are self explanatory (really!).
You can leave the defaults if you want or select your choice of packages. When you are done click "Next" which will bring you to the "About to Install" screen:



This menu as informational only and of course you have the option to return to the previous menus. Interesting is the mention of two files the system creates in the "/root" (i.e. the super user's home directory):
  • /root/install.log
  • /root/anaconda-ks.cfg
The first file contains a detailed log of the package installation process (the first view lines):
Installing 614 packages

Installing hwdata-0.146.10.EL-1.noarch.
Installing indexhtml-4-2.noarch.
Installing libgcc-3.4.3-22.1.i386.
Installing redhat-logos-1.1.25-1.noarch.
Installing rootfiles-8-1.noarch.
Installing setup-2.5.37-1.1.noarch.
Installing filesystem-2.3.0-1.i386.
Installing basesystem-8.0-4.noarch.
Installing termcap-5.4-3.noarch.
Installing tzdata-2005f-1.EL4.noarch.
Installing glibc-common-2.3.4-2.9.i386.
Installing glibc-2.3.4-2.9.i686.
Installing audit-0.5-1.i386.
Installing beecrypt-3.1.0-6.i386.
Installing bzip2-libs-1.0.2-13.i386.
Installing chkconfig-1.3.13.2-1.i386.
Installing device-mapper-1.01.01-1.RHEL4.i386.
Installing dmraid-1.0.0.rc6.1-3_RHEL4_U1.i386.
.....................

The second file contains, in simple text format, the choices you have made during the installation as interpreted by Anaconda, the Red Hat installer. In the more advanced installation tutorial you will learn how to use this file in unattended installations.
Continue with the installation, click
The system will let you know which installation media it requires:



Just click the "Continue" button and make sure you have the other media handy. The next information boxes will inform you about respectively the start of the installation process and the status of it (the behaviour of the progress bar is uncannily similar to the Microsoft version at installation time .....):




When done with the first CD the system will ask for the next (and so on):







When the system has asked for all the media it will perform some post installation tasks. You can see this in the final menu before the reboot:







Click the "Reboot" button and this part of the installation is complete.
After the reboot (don't forget to remove the last CD) the system will run a first boot script that will ask you for some final questions in configuring the system. This third and final part will be a subject of the next post, which you can find here.

Powered by ScribeFire.