Understanding The Linux Init Process & Different RunLevels

Different Linux systems can be used in many ways. This is the main idea behind operating different services at different operating levels. For example, the Graphical User Interface can only be run if the system is running the X-server; multiuser operation is only possible if the system is in a multiuser state or mode, such as having networking available. These are the higher states of the system, and sometimes you may want to operate at a lower level, say, in the single user mode or the command line mode.

Such levels are important for different operations, such as for fixing file or disk corruption problems, or for the server to operate in a run level where the X-session is not required. In such cases having services running that depend on higher levels of operation, makes no sense, since they will hamper the operation of the entire system.

Each service is assigned to start whenever its run level is reached. Therefore, when you ensure the startup process is orderly, and you change the mode of the machine, you do not need to bother about which service to manually start or stop.

The main run-levels that a system could use are:

RunLevel	Target	Notes
0	runlevel0.target, poweroff.target	Halt the system
1	runlevel1.target,  rescue.target	Single user mode
2, 4	runlevel2.target, runlevel4.target, multi-user.target	User-defined/Site-specific runlevels. By default, identical to 3
3	runlevel3.target,multi-user.target	Multi-user, non-graphical. Users can usually login via multiple consoles or via the network.
5	runlevel5.target, graphical.target	Multi-user, graphical. Usually has all the services of runlevel3 plus a graphical login - X11
6	runlevel6.target, reboot.target	Reboot
Emergency	emergency.target	Emergency shell

The system and service manager for Linux is now “systemd”. It provides a concept of “targets”, as in the table above. Although targets serve a similar purpose as runlevels, they act somewhat differently. Each target has a name instead of a number and serves a specific purpose. Some targets may be implemented after inheriting all the services of another target and adding more services to it.

Backward compatibility exists, so switching targets using familiar telinit RUNLEVEL command still works. On Fedora installs, runlevels 0, 1, 3, 5 and 6 have an exact mapping with specific systemd targets. However, user-defined runlevels such as 2 and 4 are not mapped that way. They are treated similar to runlevel 3, by default.

For using the user-defined levels 2 and 4, new systemd targets have to be defined that makes use of one of the existing runlevels as a base. Services that you want to enable have to be symlinked into that directory.

The most commonly used runlevels in a currently running linux box are 3 and 5. You can change runlevels in many ways.
A runlevel of 5 will take you to GUI enabled login prompt interface and desktop operations. Normally by default installation, this would take your to GNOME or KDE linux environment. A runlevel of 3 would boot your linux box to terminal mode (non-X) linux box and drop you to a terminal login prompt. Runlevels 0 and 6 are runlevels for halting or rebooting your linux respectively.

Although compatible with SysV and LSB init scripts, systemd:

• Provides aggressive parallelization capabilities.
• Offers on-demand starting of daemons.
• Uses socket and D-Bus activation for starting services.
• Keeps track of processes using Linux cgroups.
• Maintains mount and automount points.
• Supports snapshotting and restoring of the system state.
• Implements an elaborate transactional dependency-based service control logic.

Systemd starts up and supervises the entire operation of the system. It is based on the notion of units. These are composed of a name, and a type as shown in the table above. There is a matching configuration file with the same name and type. For example, a unit avahi.service will have a configuration file with an identical name, and will be a unit that encapsulates the Avahi daemon. There are seven different types of units, namely, service, socket, device, mount, automount, target, and snapshot.

To introspect and or control the state of the system and service manager under systemd, the main tool or command is “systemctl”. When booting up, systemd activates the default.target. The job of the default.target is to activate the different services and other units by considering their dependencies. The ‘system.unit=’ command line option parses arguments to the kernel to override the unit to be activated. For example,

systemd.unit=rescue.target is a special target unit for setting up the base system and a rescue shell (similar to run level 1);

systemd.unit=emergency.target, is very similar to passing init=/bin/sh but with the option to boot the full system from there;

systemd.unit=multi-user.target for setting up a non-graphical multi-user system;

systemd.unit=graphical.target for setting up a graphical login screen.

 

How to Enable/Disable Linux Services

Following are the commands used to enable or disable services in CentOS, Redhat Enterprise Linux and Fedora systems:

Activate a service immediately e.g postfix:

[root@gateway ~]# service postfix start
Starting postfix: [  OK  ]

To deactivate a service immediately e.g postfix:

[root@gateway ~]# service postfix stop
Shutting down postfix: [  OK  ]

To restart a service immediately e.g postfix:

[root@gateway ~]# service postfix restart
Shutting down postfix: [FAILED]
Starting postfix: [  OK  ]

You might have noticed the 'FAILED' message. This is normal behavior as we shut down the postfix service with our first command (service postfix stop), so shutting it down a second time would naturally fail!

Determine which Linux Services are Enabled at Boot

 The first column of this output is the name of a service which is currently enabled at boot. Review each listed service to determine whether it can be disabled.
 If it is appropriate to disable a service , do so using the command:

[root@gateway ~]# chkconfig -level servicename off

Run the following command to obtain a list of all services programmed to run in the different Run Levels of your system:

[root@gateway ~]#  chkconfig --list | grep :on
NetworkManager  0:off   1:off   2:on    3:on    4:on    5:on    6:off
abrtd           0:off   1:off   2:off   3:on    4:off   5:on    6:off
acpid           0:off   1:off   2:on    3:on    4:on    5:on    6:off
atd             0:off   1:off   2:off   3:on    4:on    5:on    6:off
auditd          0:off   1:off   2:on    3:on    4:on    5:on    6:off
autofs          0:off   1:off   2:off   3:on    4:on    5:on    6:off
avahi-daemon    0:off   1:off   2:off   3:on    4:on    5:on    6:off
cpuspeed        0:off   1:on    2:on    3:on    4:on    5:on    6:off
crond           0:off   1:off   2:on    3:on    4:on    5:on    6:off
cups            0:off   1:off   2:on    3:on    4:on    5:on    6:off
haldaemon       0:off   1:off   2:off   3:on    4:on    5:on    6:off
httpd           0:off   1:off   2:off   3:on    4:off   5:off   6:off
ip6tables       0:off   1:off   2:on    3:on    4:on    5:on    6:off
iptables        0:off   1:off   2:on    3:on    4:on    5:on    6:off
irqbalance      0:off   1:off   2:off   3:on    4:on    5:on    6:off

Several of these services are required, but several others might not serve any purpose in your environment, and use CPU and memory resources that would be better allocated to applications. Assuming you don't RPC services, autofs or NFS, they can be disabled for all Run Levels using the following commands:

[root@gateway ~]# /sbin/chkconfig –level 0123456 portmap off
[root@gateway ~]# /sbin/chkconfig –level 0123456 nfslock off
[root@gateway ~]# /sbin/chkconfig –level 0123456 portmap off
[root@gateway ~]# /sbin/chkconfig –level 0123456 netfs off
[root@gateway ~]# /sbin/chkconfig –level 0123456 portmap off
[root@gateway ~]# /sbin/chkconfig –level 0123456 rpcgssd off
[root@gateway ~]# /sbin/chkconfig –level 0123456 portmap off
[root@gateway ~]# /sbin/chkconfig –level 0123456 rpcidmapd off
[root@gateway ~]# /sbin/chkconfig –level 0123456 portmap off
[root@gateway ~]# /sbin/chkconfig –level 0123456 autofs off

How to Change Runlevels

You can switch to runlevel 3 by running:    

[root@gateway ~]# systemctl isolate multi-user.target

(or)

[root@gateway ~]# systemctl isolate runlevel3.target

You can switch to runlevel 5 by running:    

[root@gateway ~]# systemctl isolate graphical.target

(or)

[root@gateway ~]# systemctl isolate runlevel5.target

 

How to Change the Default Runlevel using Systemd

The systemd uses symlinks to point to the default runlevel. You have to delete the existing symlink first, before you can create a new one:    [root@gateway ~]# rm /etc/systemd/system/default.target

 

Switch to runlevel 3 by default:

[root@gateway ~]# ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target  

 

Switch to runlevel 5 by default:    

[root@gateway ~]# ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target

 

And just in case you were wondering, systemd does not use the classic /etc/inittab file.

 

How to Change the Default Runlevel using the Inittab file

There's the Systemd way and of course, the Inittab way. In this case, Runlevels are represented by /etc/inittab text file. The default runlevel is always specified from /etc/inittab text file.
To change the default runlevel in fedora ,edit /etc/inittab and find the line that looks like this:  id:5:initdefault:
The number 5 represents a runlevel with X enabled (GNOME/KDE mostly). If you want to change to runlevel 3, simply change this

id:5:initdefault:
to this

id:3:initdefault:
Save and reboot your linux box. Your linux box would now reboot on runlevel 3, a runlevel without X or GUI. Avoid changing the default /etc/iniittab runlevel value to 0 or 6 .

INSTALLING & CONFIGURING VSFTPD FTP SERVER FOR REDHAT ENTERPRISE LINUX, CENTOS & FEDORA

Vsftpd is a popular FTP server for Unix/Linux systems. For thoes unaware of the vsftpd ftp server, note that this is not just another ftp server, but a mature product that has been around for over 12 years in the Unix world. While Vsftpd it is found as an installation option on many Linux distributions, it is not often Linux system administrators are seeking for installation and configuration instructions for it, which is the reason we decide to cover it on Firewall.cx.

This article focuses on the installation and setup of the Vsftpd service on Linux Redhat Enterprise, Fedora and CentOS, however it is applicable to almost all other Linux distributions.  We'll also take a look at a number of great tips which include setting quotas, restricting access to anonymous users, disabling uploads, setting a dedicated partition for the FTP service, configuring the system's IPTable firewall and much more.

VSFTPD FEATURES

Following is a list of vsftpd's features which confirms this small FTP package is capable of delivering a lot more than most FTP servers out there:

• Virtual IP configurations
• Virtual users
• Standalone or inetd operation
• Powerful per-user configurability
• Bandwidth throttling
• Per-source-IP configurability
• Per-source-IP limits
• IPv6
• Encryption support through SSL integration
• and much more....!

INSTALLING THE VSFTPD LINUX SERVER

To initiate the installation of the vsftpd package, simply open your CLI prompt and use the yum command (you need root privileges) as shown below:

# yum install vsftpd

Yum will automatically locate, download and install the latest vsftpd version.

CONFIGURE VSFTPD SERVER

To open the configuration file, type:

# vi /etc/vsftpd/vsftpd.conf

Turn off standard ftpd xferlog log format and turn on verbose vsftpd log format by making the following changes in the vsftpd.conf file:

xferlog_std_format=NO
log_ftp_protocol=YES

Note: the default vsftpd log file is /var/log/vsftpd.log.

Above two directives will enable logging of all FTP transactions.

To lock down users to their home directories:

chroot_local_user=YES

You can create warning banners for all FTP users, by defining the path:

banner_file=/etc/vsftpd/issue

Now you can create the /etc/vsftpd/issue file with a message compliant with the local site policy or a legal disclaimer:

“NOTICE TO USERS - Use of this system constitutes consent to security monitoring and testing. All activity is logged with your host name and IP address”.

 

TURN ON VFSTPD SERVICE

Turn on vsftpd on boot:

# systemctl enable vsftpd@.service

Start the service:

# systemctl start vsftpd@vsftpd.service

You can verify the service is running and listening on the correct port using the following command:

# netstat -tulpn | grep :21

Here's the expected output:

tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      LISTEN 9734/vsftpd

CONFIGURE IPTABLES TO PROTECT THE FTP SERVER

In case IPTables are configured on the system, it will be necessary to edit the iptables file and open the ports used by FTP to ensure the service's operation.

To open file /etc/sysconfig/iptables, enter:

# vi /etc/sysconfig/iptables

Add the following lines, ensuring that they appear before the final LOG and DROP lines for the RH-Firewall-1-INPUT:

-A RH-Firewall-1-INPUT -m state --state NEW -p tcp --dport 21 -j ACCEPT

Next, open file /etc/sysconfig/iptables-config, and enter:

# vi /etc/sysconfig/iptables-config

Ensure that the space-separated list of modules contains the FTP connection-tracking module:

IPTABLES_MODULES="ip_conntrack_ftp"

Save and close the file and finally restart the firewall using the following commands:

# systemctl restart iptables.service
# systemctl restart ip6tables.service

TIP: VIEW FTP LOG FILE

Type the following command:

# tail -f /var/log/vsftpd.log

 

TIP: RESTRICTING ACCESS TO ANONYMOUS USER ONLY

Edit the vsftpd configuration file /etc/vsftpd/vsftpd.conf and add the following:

local_enable=NO

 

TIP: TO DISABLE FTP UPLOADS

Edit the vsftpd configuration file /etc/vsftpd/vsftpd.conf and add the following:

write_enable=NO

TIP: TO ENABLE DISK QUOTA

Disk quota must be enabled to prevent users from filling a disk used by FTP upload services. Edit the vsftpd configuration file. Add or correct the following configuration options to represents a directory which vsftpd will try to change into after an anonymous login:

anon_root=/ftp/ftp/pub

The ftp users are the same users as those on the hosting machine.

You could have a separate group for ftp users, to help keep their privileges down (for example 'anonftpusers'). Knowing that, your script should do:

useradd -d /www/htdocs/hosted/bob -g anonftpusers -s /sbin/nologin bob

echo bobspassword | passwd --stdin bob

echo bob >> /etc/vsftpd/user_list

Be extremely careful with your scripts, as they will have to be run as root.

However, for this to work you will have to have the following options enabled in /etc/vsftpd/vsftpd.conf: 

userlist_enable=YES
userlist_deny=NO

 

SECURITY TIP: PLACE THE FTP DIRECTORY ON ITS OWN PARTITION

Separation of the operating system files from FTP users files may result into a better and secure system. Restricting the growth of certain file systems is possible using various techniques. For example, use /ftp partition to store all ftp home directories and mount ftp with nosuid, nodev and noexec options. A sample /etc/fstab entry:

/dev/sda5  /ftp          ext3    defaults,nosuid,nodev,noexec,usrquota 1 2

 

EXAMPLE FILE FOR VSFTPD.CONF

Following is an example for vsftpd.conf. It allows the users listed in the user_list file to log in, no anonymous users, and quite tight restrictions on what users can do:

# Allow anonymous FTP?

anonymous_enable=NO

#

# Allow local users to log in?

local_enable=YES

#

# Allow any form of FTP write command.

write_enable=YES

#

# To make files uploaded by your users writable by only

# themselves, but readable by everyone and if, through some

# misconfiguration, an anonymous user manages to upload a file, # the file will have no read, write or execute permission. Just to be # safe. 

local_umask=0000

file_open_mode=0644

anon_umask=0777

#

# Allow the anonymous FTP user to upload files?

anon_upload_enable=NO

#

# Activate directory messages - messages given to remote users when they

# go into a certain directory.

dirmessage_enable=NO

#

# Activate logging of uploads/downloads?

xferlog_enable=YES

#

# Make sure PORT transfer connections originate from port 20 (ftp-data)?

connect_from_port_20=YES

#

# Log file in standard ftpd xferlog format?

xferlog_std_format=NO

#

# User for vsftpd to run as?

nopriv_user=vsftpd

#

# Login banner string:

ftpd_banner= NOTICE TO USERS - Use of this system constitutes consent to security monitoring and testing. All activity is logged with your host name and IP address.

#

# chroot local users (only allow users to see their directory)?

chroot_local_user=YES

#

# PAM service name?

pam_service_name=vsftpd

#

# Enable user_list (see next option)?

userlist_enable=YES

#

# Should the user_list file specify users to deny(=YES) or to allow(=NO)

userlist_deny=NO

#

# Standalone (not run through xinetd) listen mode?

listen=YES

#

#

tcp_wrappers=NO

#

# Log all ftp actions (not just transfers)?

log_ftp_protocol=YES

# Initially YES for trouble shooting, later change to NO

#

# Show file ownership as ftp:ftp instead of real users?

hide_ids=YES

#

# Allow ftp users to change permissions of files?

chmod_enable=NO

#

# Use local time?

use_localtime=YES

#

# List of raw FTP commands, which are allowed (some commands may be a security hazard):

cmds_allowed=ABOR,QUIT,LIST,PASV,RETR,CWD,STOR,TYPE,PWD,SIZE,NLST,PORT,SYST,PRET,MDTM,DEL,MKD,RMD

With this config, uploaded files are not readable or executable by anyone, so the server is acting as a 'dropbox'. Change thefile_open_modeoption to change that.

Lastly, it is also advised to have a look at 'man vsftpd.conf' for a full list and description of all options.

IMPLEMENTING VIRTUAL SERVERS AND LOAD BALANCING CLUSTER SYSTEM WITH LINUX

WHAT IS SERVER VIRTUALIZATION?

Server virtualization is the process of apportioning a physical server into several smaller virtual servers. During server virtualization, the resources of the server itself remain hidden. In fact, the resources are masked from users, and software is used for dividing the physical server into multiple virtual machines or environments, called virtual or private servers.

This technology is commonly used in Web servers. Virtual Web servers provide a very simple and popular way of offering low-cost web hosting services. Instead of using a separate computer for each server, dozens of virtual servers can co-exist on the same computer.

There are many benefits of server virtualization. For example, it allows each virtual server to run its own operating system. Each virtual server can be independently rebooted without disturbing the others. Because several servers run on the same hardware, less hardware is required for server virtualization, which saves a lot of money for the business. Since the process utilizes resources to the fullest, it saves on operational costs. Using a lower number of physical servers also reduces hardware maintenance.

In most cases, the customer does not observe any performance deficit and each web site behaves as if it is being served by a dedicated server. However, the resources of the computer being shared, if a large number of virtual servers reside on the same computer, or if one of the virtual servers starts to hog the resources, Web pages will be delivered more slowly.

There are several ways of creating virtual servers, with the most common being virtual machines, operating system-level virtualization, and paravirtual machines.

 

HOW ARE VIRTUAL SERVERS HELPFUL

The way Internet is exploding with information, it is playing an increasingly important role in our lives. Internet traffic is increasing dramatically, and has been growing at an annual rate of nearly 100%. The workload on the servers is simultaneously increasing significantly so that servers frequently become overloaded for short durations, especially for popular web sites.

To overcome the overloading problem of the servers, there are two solutions. You could have a single server solution, such as upgrading the server to a higher performance server. However, as requests increase, it will soon be overloaded, so that it has to be upgraded repeatedly. The upgrading process is complex and the cost is high.

The other is the multiple server solution, such as building a scalable network service system on a cluster of servers. As load increases, you can just add a new server or several new servers into the cluster to meet the increasing requests, and a virtual server running on commodity hardware offers the lowest cost to performance ratio. Therefore, for network services, the virtual server is a highly scalable and more cost-effective for building server cluster system.

VIRTUAL SERVERS WITH LINUX

Highly available server solutions are done by clustering. Cluster computing involves three distinct branches, of which two are addressed by RHEL or Red Hat Enterprise Linux:

Ø    Load balancing clusters using Linux Virtual Servers as specialized routing machines to dispatch traffic to a pool of servers.

Ø    Highly available or HA Clustering with Red Hat Cluster Manager that uses multiple machines to add an extra level of reliability for a group of services.

 

LOAD BALANCING CLUSTER SYSTEM USING RHEL VIRTUAL SERVERS

When you access a website or a database application, you do not know if you are accessing a single server or a group of servers. To you, the Linux Virtual Server or LVS cluster appears as a single server. In reality, there is a cluster of two or more servers behind a pair or redundant LVS routers. These routers distribute the client requests evenly throughout the cluster system.

Administrators use Red Hat Enterprise Linux and commodity hardware to address availability requirements, and to create consistent and continuous access to all hosted services.

In its simplest form, an LVS cluster consists of two layers. In the first layer are two similarly configured cluster members, which are Linux machines. One of these machines is the LVS router and is configured to direct the requests from the internet to the servers. The LVS router balances the load on the real servers, which form the second layer. The real servers provide the critical services to the end-user. The second Linux machine acts as a monitor to the active router and assumes its role in the event of a failure.

The active router directs traffic from the internet to the real servers by making use of Network Address Translation or NAT. The real servers are connected to a dedicated network segment transfer all public traffic via the active LVS router. The outside world sees this entire cluster arrangement as a single entity.

 

LVS WITH NAT ROUTING

The active LVS router has two Network Interface Cards or NICs. One of the NICs is connected to the Internet and has a real IP address on the eth0 and a floating IP address aliased to eth0:1. The other NIC connects to the private network with a real IP address on the eth1, and a floating address aliased to eth1:1.

All the servers of the cluster are located on the private network and use the floating IP for the NAT router. They communicate with the active LVS router via the floating IP as their default route. This ensures their abilities for responding to requests from the inernet are not impaired.

When requests are received by the active LVS router, it routes the request to an appropriate server. The real server processes the request and returns the packets to the LVS router. Using NAT, the LVS router then replaces the address of the real server in the packets with the public IP address of the LVS router. This process is called IP Masquerading, and it hides the IP addresses of the real servers from the requesting clients.

CONFIGURING LVS ROUTERS WITH THE PIRANHA CONFIGURATION TOOL

The configuration file for an LVS cluster follows strict formatting rules. To prevent server failures because of syntax errors in the file lvs.cf, using the Piranha Configuration Tool is highly recommended. This tool provides a structured approach to creating the necessary configuration file for a Piranha cluster. The configuration file is located at /etc/sysconfig/ha/lvs.cf, and the configuration can be done with a web-based tool such as the Apache HTTP Server.

As an example, we will use the following settings:

LVS Router 1: eth0: 192.168.26.201

LVS Router 2: eth0: 192.168.26.202

Real Server 1: eth0: 192.168.26.211

Real Server 2: eth0: 192.168.26.212

VIP: 192.168.26.200

Gateway: 192.168.26.1

You will need to install piranha and ipvsadm packages on the LVS Routers:

# yum install ipvsadm

# yum install piranha

  

Start services on the LVS Routers with:

# chkconfig pulse on

# chkconfig piranha-gui on

# chkconfig httpd on

Set a Password for the Piranha Configuration Tool using the following commands:  # piranha-passwd

Next, turn on Packet Forwarding on the LVS Routers with:

# echo 1 > /proc/sys/net/ipv4/ip_forward

 

STARTING THE PIRANHA CONFIGURATION TOOL SERVICE

First you'll need to modify the mode SELinux in permissive mode with the use of the command:

# setenforce 0

# service httpd start

# service piranha-gui start

If this is not done, the system will most probably show the following error massage when the piranha-gui service is started:

Starting piranha-gui: (13)Permission denied: make_sock: could not bind to address [::]:3636

(13)Permission denied: make_sock: could not bind to address 0.0.0.0:3636
No listening sockets available, shutting down 
Unable to open logs

CONFIGURE THE LVS ROUTERS WITH THE PIRANHA CONFIGURATION TOOL

The Piranha Configuration Tool runs on port 3636 by default. Open http://localhost:3626 or http://192.168.26.201:3636 in a Web browser to access the Piranha Configuration Tool. Click on the Login button and enter piranha for the Username and the administrative password you created, in the Password field:

 Click on the GLOBAL SETTINGS panel, enter the primary server public IP, and click the ACCEPT button:

Click on the REDUNDANCY panel, enter the redundant server public IP, and click the ACCEPT button:

Click on the VIRTUAL SERVERS panel, add a server, edit it, and activate it:

Clicking on the REAL SERVER subsection link at the top of the panel displays the EDIT REAL SERVER subsection. Click the ADDbutton to add new servers, edit them and activate them:

Copy the lvs.cf file to another LVS router:

# scp /etc/sysconfig/ha/lvs.cf root@192.168.26.202:/etc/sysconfig/ha/lvs.cf

Start the pulse services on the LVS Routers with the following command:

# service pulse restart

TESTING THE SYSTEM

You can use the Apache HTTP server benchmarking tool (ab) to simulate a visit by the user.

 

HA CLUSTERING WITH RED HAT CLUSTER MANAGER

When dealing with clusters, single point failures, unresponsive applications and nodes are some of the issues that increase the non-availability of the servers. Red Hat addresses these issues through their High Availability or HA Add-On servers. Centralised configurations and management are some of the best features of the Conga application of RHEL.

For delivering an extremely mature, high-performing, secure and lightweight high-availability server solution, RHEL implements the Totem Single Ring Ordering and Membership Protocol. Corosync is the cluster executive within the HA Add-On.

KERNEL-BASED VIRTUAL MACHINE TECHNOLOGY

RHEL uses the Linux kernel that has the virtualization characteristics built-in and makes use of the kernel-based virtual machine technology known as KVM. This makes RHEL perfectly suitable to run as either a host or a guest in any Enterprise Linux deployment. As a result, all Red Hat Enterprise Linux system management and security tools and certifications are part of the kernel and always available to the administrators, out of the box.

RHEL uses highly improved SCSI-3 PR reservations-based fencing. Fencing is the process for removing resources from the cluster node from being accessed when they have lost contact with the cluster. This prevents uncoordinated modification of shared storage thus protecting the resources.

Improvement in system flexibility and configuration is possible because RHEL allows manual specification of devices and keys for reservation and registration. Ordinarily, after fencing, the unconnected cluster mode would need to be rebooted to rejoin the cluster. RHEL unfencing makes it possible to re-enable access and startup of the node without administrative intervention.

 

IMPROVED CLUSTER CONFIGURATION

LDAP, the Lightweight Directory Access Protocol provides improved cluster configuration system for load options. This provides better manageability and usability across the cluster by easily configuring, validating and synchronizing the reload. Virtualized KVM guests can be run as managed services.

RHEL Web interface to the cluster management and administration runs on TurboGears2 and provides a rich graphical user interface. This enables unified logging and debugging by administrators who can enable, capture and read cluster system logs using a single cluster configuration command.

 

INSTALLING TURBOGEARS2

The method of installing TurboGears2 depends on the platform and the level of experience. It is recommended to install TurboGears2 withing a virtual enviroment as this will prevent interference with the system's installed packages. Prerequisites for installation ofTurboGears2 are Python, Setuptools, Database and Drivers, Virtualenv, Virtualenvwrapper and other dependencies.