SlideShare ist ein Scribd-Unternehmen logo
1 von 16
Downloaden Sie, um offline zu lesen
INSTALLING AND CONFIGURING APACHE TOOLKIT
FOR SERVICEGUARD FOR LINUX




Executive Summary ......................................................................................................................... 2
Intended Audience.......................................................................................................................... 2
Introduction to the High Availability Apache Toolkit .............................................................................. 2
STORAGE CONFIGURATIONS......................................................................................................... 3
SETTING UP THE APACHE WEB SERVER APPLICATION FOR AN SG/LX CLUSTER.................................... 4
  Setting Up the Apache Web Server ............................................................................................... 4
  Installing the High Availability Apache Toolkit.................................................................................. 5
CONFIGURING APACHE WEB SERVER PACKAGES IN AN SG/LINUX ENVIRONMENT........................... 6
 Configuring a Single Instance....................................................................................................... 6
 Configuring Multiple Instances.................................................................................................... 11
 Maintenance Mode ................................................................................................................... 13
SECURITY POLICIES IN LINUX.................................................................................................... 14
  SELinux .................................................................................................................................. 14
  AppArmor................................................................................................................................ 15
CONCLUSION ............................................................................................................................ 16
Executive Summary
This document describes how to configure and run an Apache Web Server using the High
Availability Apache Toolkit in the HP Serviceguard for Linux environment.
This white paper introduces you to the High Availability Apace toolkit and outlines the procedures
and tasks that you need to complete to install and configure the toolkit in your Linux environment
with Serviceguard. In addition, this whitepaper also discusses security policies that have an impact
on your Linux environment.


Intended Audience
This document is intended for system or network administrators who need to configure and run an
Apache Web Server using the High Availability Apache Toolkit on a Serviceguard Linux cluster.
Users must be familiar with the following topics:
    •   Serviceguard Configuration
    •   Apache Web Server Concepts
    •   Apache Server Installation and Configuration Procedures


Introduction to the High Availability Apache Toolkit
HP provides Serviceguard for Linux Apache toolkit for customers to integrate the Apache Web
Server application with HP Serviceguard. Using Serviceguard for Linux toolkit simplifies application
integration, and eases deployment and maintenance of applications in a cluster environment.

The High Availability Apache toolkit consists of a set of shell scripts that are used by the package
control script to start, stop and monitor the Apache Web Server application. This toolkit contains
files that are installed in specific locations, corresponding to the respective distributions. These files
enable you to manage your environment. Table 1 describes the files that are part of this toolkit.

                            Table 1 Files in the High Availability Toolkit


                  File Name                                 Description


                toolkit.sh                The Toolkit Interface Script. It interfaces
                                          between the package control script and the
                                          main toolkit script.


               hahttp.conf                The Toolkit Configuration File. It contains a list
                                          of pre-defined variables that you can modify to
                                          suit your environment.


                hahttp.mon                The Toolkit Monitoring Script. Use this script
                                          to monitor the health of the server application.


                 hahttp.sh                The Toolkit Main Script. It contains the list of
                                          internal functions that you can use to start or
                                          stop the Apache Web Server instance in your
                                          environment.


                   README                 A text file that contains information that you
                                          must read before using the Apache toolkit.
To use the Apache Web Server application in your environment, the Apache web server must be
installed on all cluster nodes configured to run an Apache package. A typical configuration of an
Apache Web Server application is one where one node is configured as a primary node and the
others are configured as standby or secondary nodes. The Apache Web Server application runs on
the primary node and accepts (HTTP/S) requests and serves clients. If the primary node fails, a
standby node takes over the server activities. This take over is seamless and does not interrupt any
of the processes in the environment. For this seamless transition to occur, all configuration
information of all nodes must be identical and all resources must be available to all nodes.

Apache Web Server supports multiple instances of server daemons that are running on a node
simultaneously. For each instance of an Apache Server, an Apache package is created with its own
server root directory, toolkit files and configuration information. Each instance may support one or
more websites, depending on whether or not an instance has been configured to use "virtual hosts".

The server root directory contains the appropriate configuration file that specifies how an Apache
server instance is configured. The Apache configuration directives within this file determine the
location of the log files, web documents, and the domain name address for the specific Apache
server instance.


NOTE: If you have a Red Hat Enterprise Linux system in your environment, then the configuration
file resides in the conf/httpd.conf file in the server root directory. If you have a SUSE Linux
Enterprise Server, the configuration file resides in the httpd.conf in the server root directory.



STORAGE CONFIGURATIONS
You can configure the Apache toolkit using either one of the following storage configuration options:

    •   Local configuration
        In this configuration, place the configuration files and the other website files on a single
        node, and replicate them on all other nodes in the cluster.

    •   Shared configuration
        In this configuration, place the configuration files and the other Web site files on a shared
        file system. All the nodes in the cluster will access these files from the shared file system.

The following sections discuss these configuration options in detail.

Local Configuration
In a typical local configuration, files are not shared among nodes. Identical copies of the Apache
server configuration file and web documents must reside in exactly the same locations on each
node. If you update the information in a file on a single node, you must update the files on all other
nodes with the same changes. The administrator needs to ensure that all the files on all the nodes
are identical and always up-to-date. This local configuration setup is more useful in scenarios where
the information on the Web page is static and does not change very often.

Shared Configuration
In a typical shared configuration, the document root directories reside on a shared file system. You
can also place the server root directory in this shared file system. However, this is optional. By
placing the files and directories on a shared file system, the information automatically becomes
accessible to all the nodes in the cluster. You need not have to maintain copies of all the files and
directories on every node in the cluster. However, you must ensure that the mount point of the
shared file system is identical across all Apache package nodes.

HP recommends that you use the shared configuration option for configuring this toolkit because
you do not have to maintain identical copies of the files and directories on all nodes. In addition, with
this option, all information is automatically accessible to all nodes.
SETTING UP THE APACHE WEB SERVER APPLICATION FOR AN SG/LX
CLUSTER

Once you decide on the storage configuration option, you can install the High Availability Apache
Web Server Toolkit. However, before you start installing the toolkit, ensure that your environment
meets the following prerequisites:
   • HP Serviceguard for Linux must be installed on all nodes that need to be configured in the
        cluster
   • The toolkit is installed on all the target nodes of the cluster
   • Apache Web Server is installed and configured on all target nodes
            o The same version of the server must be installed and configured on all target
                nodes.
            o Identical copies of the server root directory must be available on all nodes.
            o Each node must have the same document root directory that contains identical
                copies of the Web documents for a particular instance.

For this white paper, the environment is assumed to be that of a cluster with two nodes with a
shared storage device and a quorum server for the cluster. However, these instructions are
applicable for a cluster that has more than two nodes, provided the prerequisites are met.

NOTE: The installation instructions illustrate commands for a Red Hat environment. If your
environment has SUSE Linux Enterprise Servers, then replace all occurrences of /usr/local with
/opt.

Installing and setting up the Apache toolkit involves the following tasks:

    •   Set up the Apache Web Server
    •   Install the Toolkit
    •   Configure the Apache Web Server Packages

The following sections describe these tasks in detail.


Setting Up the Apache Web Server
To manage an Apache Web Server using Serviceguard, you need to modify the default Apache
configuration information. Before you create and configure the Serviceguard packages, ensure that
the configurations listed later in this section are completed for the Apache Web Server application
on all other cluster nodes.

    1) Disable the automatic start-up of the default instance of the Apache Server.
       After installing the Apache Server, you can configure it to automatically start at system start
       up time by using the runlevel (rc) scripts in the /etc/rc.d directory. However, you must
       disable the automatic start-up of this default instance in an SG/Linux environment, because
       it can affect the behavior of the Serviceguard or Apache packages. For more information on
       configuring the Apache Server, see the Apache Documentation that comes along with the
       Apache installation.

    2) Customize an Apache instance to run on a node by using the httpd.conf file. This
       httpd.conf file is associated with the default Apache instance and has a Listen directive
       "Listen 80", which is equivalent to listening for all IP addresses at port 80. Following is the
       default location of this file:

        Red Hat: /etc/httpd/conf/httpd.conf
        SLES: /etc/apache2/httpd.conf

        If an Apache instance needs to be configured so that it listens to specific IP Addresses, the
        LISTEN directive has to be changed to "Listen <IP Address> :<Port>".
        NOTE: The httpd.conf file of SLES distribution has several include directives. One of
        them includes the file /etc/apache2/sysconfig.d/include.conf which does not
exist by default. This file is used to define any user defined parameters. The Apache server
        fails to start if this file is not present. To start Apache successfully, either use the touch
        command to create a file or comment out the Include parameter in the httpd.conf file.

    3) Create a separate, distinct server root directory and server configuration file for each
       Apache SG/Linux package. This server root directory corresponds to the Apache
       ServerRoot directive specified in the configuration file. Each package corresponds to a
       unique Apache instance with its associated configuration and server root directory.

    4) Configure all Apache instances to listen to a package re-locatable IP address using ‘Listen’
       directives. For more information on configuring virtual hosts, see to the Apache Web Server
       documentation.

        For example, the configuration files for an Apache instance that combines IP-based and
        name-based virtual hosts includes the following directive:

        Listen 192.168.0.1:80
        Listen 192.168.0.2:80
        NameVirtualHost 192.168.0.2:80

        <VirtualHost web.site1.url:80>
        ServerName web.site1.url
        DocumentRoot /shared/httpd/www-site1
        </VirtualHost>

       <VirtualHost web.site2.url:80>
       ServerName web.site2.url
       DocumentRoot /shared/httpd/www-site2
       </VirtualHost>
These steps enable you to customize the way the Apache instance starts using the Apache toolkit
on a node. After completing this procedure, you can install the Apache toolkit and configure the
Apache Web Server package in the Serviceguard environment.

Installing the High Availability Apache Toolkit
The Linux Apache toolkit is available at http://www.software.hp.com/ as ‘Serviceguard for Linux
Apache Toolkit’ that comes bundled within the ‘Serviceguard for Linux Contributed Toolkit Suite’.
The Linux Apache toolkit has to be installed on all the nodes of the cluster that have been
configured to run the apache web server package. Before you install this version of the toolkit, you
must remove previous versions from your system. To remove the previous version, complete the
following procedure:

    1. Enter the following command to check the version of the toolkit:
       #rpm –qa | grep apache

        The previous versions of the toolkit, if any, are listed in the output.

   2.   Enter the following command to remove the previous version of the toolkit:
        #rpm –e apache-<release_version>.product.redhat.noarch.rpm

To ensure that the toolkit has been removed from all the configured nodes of the cluster, the ‘rpm –
qa’ command can be executed again as mentioned above on all the nodes configured to run the
Apache Web Server package.

After the previous versions of the toolkit have been removed, one can proceed with the installation
of the Linux Apache toolkit. Upgradation of the Linux Apache toolkit without removing its previous
version or a forceful installation of the toolkit is not recommended. To install the Apache Web
server complete the following:

On Red Hat systems:
#rpm –i apache-toolkit-<release_version>.product.redhat.noarch.rpm
This command installs the Apache toolkit. By default, the Apache toolkit directory is created in the
following location:
#/usr/local/cmcluster/apachetoolkit

On SUSE Linux Enterprise Server:
Change to your rpm package directory and enter the following command:
#rpm –i apache-toolkit-<release_version>.product.suse.noarch.rpm

This command installs the Apache toolkit. By default, the Apache toolkit directory is created in the
following location
opt/cmcluster/apachetoolkit

In order to verify the Linux Apache toolkit installation, you can either run the ‘rpm –qa | grep apache’
command or you can ensure the presence of all the toolkit scripts in the toolkit installation directory
/usr/local/cmcluster/apachetoolkit .



CONFIGURING APACHE WEB SERVER PACKAGES IN AN SG/LINUX
ENVIRONMENT

After installing the Apache Web Server, you need to configure the packages. Apache Web Server is
a multi-instance application. This implies that multiple instances of the Apache Web Server can run
on the same node simultaneously. This multi-instance feature of this package ensures that the
package is always up and running. For example, if two nodes are each running an instance of
Apache and one node fails, the Apache instance on the failed node can fail over to the healthy
node. In addition, the healthy node can continue to run its own instance of the Apache Server.

You can configure multiple instances of Apache using either the local or shared storage
configuration or a combination of both. The subsequent sections explain how to configure Apache
Web Server as a single instance package and as a multiple instance package using the High
Availability Apache Toolkit. These sections also describe how to configure the Apache package in
maintenance mode.


Configuring a Single Instance
For easy comprehension, the following naming conventions have been used in this section:

    •   A Serviceguard Apache packages is referred to as APACHE1. The corresponding service
        name is referred to as apache1_service.
    •   The Apache instance listens to a relocatable IP address of 15.70.191.6.

It assumed that you have already configured the Serviceguard cluster, including details such as
configuring the cluster name and the node names, determining the heartbeat IP address and so on.
The following node names are used in this section:

    •   photon3
    •   photon4

For more information on configuring a Serviceguard cluster, refer the Managing HP Serviceguard
for Linux user guide.

To configure a volume, you can select one of the following methods:

Local Configuration
With this method, you configure volumes on the local file system. The server root directory and the
document root directory are maintained in the local file system.

Shared Configuration:
In this method, the server root directory and the document root directory are maintained on a
volume group that is shared among nodes of the cluster.
Following is a sample procedure that indicates the steps that you must complete to configure an
Apache instance that uses shared storage for all Apache instance data. It is assumed that you will
configure all Apache instance files on a shared file system /mnt/vgtry1/apache directory, which
resides on a logical volume lvol from a shared volume group /dev/vgtry1.

    1.   Create a Volume Group vgtry1 on shared storage.
    2.   Create a Logic Volume lvol in vgtry1.
    3.   Create a filesystem on the above created logical volume lvol.
    4.   Create a directory /mnt/vgtry1/apache on local disk.
    5.   Mount device /dev/vgtry1/lvol to the /mnt/vgtry1/apache
    6.   Copy all files from the server root to /mnt/vgtry1/apache.
         In a SUSE Linux environment, use the -c option to preserve security contexts.

The steps for configuring a local volume group remain the same except that for the shared storage
configuration, you need to execute these steps on a shared storage device. In case of a local
storage configuration, you must execute these steps on a local storage device.

Note: The default server root directory is located at the following location:

   Red Hat: /etc/httpd
   SLES: /etc/apache2

Complete the following procedure to configure a single instance:

1. To create the apache package directory.
   Before starting the package configuration, you must create a directory (for example
   /usr/local/cmcluster/pkg/apache1) for this Apache package to run.
   This directory must belong to a single Apache package. To create an Apache Package
   directory, complete the following steps:

         a. Copy all Apache toolkit scripts from /usr/local/cmcluster/apachetoolkit to
            /usr/local/cmcluster/pkg/apache1.

              Example:
                 # mkdir /usr/local/cmcluster/pkg/apache1
                 # cd /usr/local/cmcluster/pkg/apache1
                 # cp /usr/local/cmcluster/apachetoolkit/* .

         b. To create the package configuration file (pkg.conf) and package control script
            (pkg.cntl), you must be in the package directory.

              Example:
              #cd /usr/local/cmcluster/pkg/apache1

         c.   To create the package configuration file and the package control script, enter the
              following commands:

              To create the package configuration file:
              #cmmakepkg -p pkg.conf

              To create the package control script:
              #cmmakepkg -s pkg.cntl

    After you have completed these steps, the package directory consists of the following files:

    README               The Readme file
    hahttp.conf          User defined variables
    hahttp.sh            The main shell script
    hahttp.mon           Script that monitors the health of the server application
toolkit.sh         Script that acts as an Interface between the package control script and
                      main script (hahttp.sh)
   pkg.conf           The package configuration file
   pkg.cntl           The package control script

2. Edit the package configuration file.
   Enter the following command to open the package configuration file:

   #vi /usr/local/cmcluster/pkg/apache1/pkg.conf

   You can edit the following variables in the package configuration file.

              PACKAGE_NAME                                 APACHE1
              PACKAGE_TYPE                                 FAILOVER
              FAILOVER_POLICY                              CONFIGURED_NODE
              FAILBACK_POLICY                              MANUAL
              NODE_NAME                                    photon3
              NODE_NAME                                    photon4
              AUTO_RUN                                     YES
              NODE_FAIL_FAST_ENABLED                       NO

   The package configuration file contains variables that characterize the package. The package
   name and the service name mentioned must be unique.

   Initialize the RUN_SCRIPT and the HALT_SCRIPT in the package control script. You can edit
   these variables based the requirement of your environment.

              RUN_SCRIPT   /usr/local/cmcluster/pkg/apache1/pkg.cntl
              RUN_SCRIPT_TIMEOUT              NO_TIMEOUT
              HALT_SCRIPT /usr/local/cmcluster/pkg/apache1/pkg.cntl
              HALT_SCRIPT_TIMEOUT             NO_TIMEOUT
              PRIORITY                        NO_PRIORITY
              SUCCESSOR_HALT_TIMEOUT          0
              SERVICE_NAME                    apache1_service
              SERVICE_FAIL_FAST_ENABLED       NO
              SERVICE_HALT_TIMEOUT            300

3. Edit the package control script.

   Edit the package control script (pkg.cntl) to customize it to the environment.


   IMPORTANT: HP recommends that you configure the server root directory and the document
   root directory on a shared storage.


   In these examples, the volume group, /dev/vgtry1 is used as the server root directory and
   the document root directory.

       a. Mount the logical volume lvol on vgtry1 under the mount point
          /mnt/vgtry1/apache. Use an IP address that is not being used by any other
          application. In this example, 15.70.191.6.You can edit the following variables in the
          package control script.

              GFS="NO"
              DATA_REP="none"
              RAIDSTART="raidstart -c ${RAIDTAB}"
              RAIDSTOP="raidstop -c ${RAIDTAB}"
              VGCHANGE="vgchange -a y"
              VG[0]="/dev/vgtry1"
              LV[0]="/dev/vgtry1/lvol"; FS[0]="/mnt/vgtry1/apache";
              FS_TYPE[0]="ext2"; FS_MOUNT_OPT[0]="-o rw"
FS_UMOUNT_OPT[0]=""; FS_FSCK_OPT[0]=""
               FS_UMOUNT_COUNT=1
               FS_MOUNT_RETRY_COUNT=0
               CONCURRENT_FSCK_OPERATIONS=1
               CONCURRENT_MOUNT_AND_UMOUNT_OPERATIONS=1
               IP[0]="15.70.191.6"
               SUBNET[0]="15.70.191.0"
               SERVICE_NAME[0]="apache1_service"
               SERVICE_CMD[0]="/usr/local/cmcluster/pkg/apache1/toolkit.sh
monitor"
               SERVICE_RESTART[0]=""

        b. Add the following line to the customer_defined_run_cmds function of the control
           script to start the Apache package:

               function customer_defined_run_cmds
                 {
                   /usr/local/cmcluster/pkg/apache1/toolkit.sh start
                   test_return 51

        c.   Add the following line to the customer_defined_halt_cmds function of the control
             script to halt the package:

               function customer_defined_halt_cmds
                 {
                   /usr/local/cmcluster/pkg/apache1/toolkit.sh stop
                    test_return 52
                 }


NOTE: You must select a package IP address that is not used by any other application.
Serviceguard cannot start a package if the IP address corresponding to the package is already in
use.


4. Edit the Apache toolkit configuration file.

Edit the apache toolkit configuration file, hahttp.conf. In this example, we have considered
/mnt/vgtry1/apache as the server root directory. It is also assumed that the pid file is placed in
the package directory. Edit the hahttp.conf file.

        a. Set the path for httpd.conf file which is the apache configuration file
           For example:

             HTTPD_CONFIG_FILE="/mnt/vgtry1/apache/httpd.conf"
             In the Red Hat environment, set the directive ServerRoot and DocumentRoot
             directive in the hahttp.conf file,

        b.   This variable holds the Process ID file path of the Apache server
             instance.
             PID_FILE="/usr/local/cmcluster/pkg/apache1/httpd_s1.pid"

        c    Select one of the following options based on your requirement. For example, on the
             basis of which criterion you want the package to fail over, such as the absence of the
             Parent process only, or any one of the processes or all the processes.
             (
               FAIL_CRITERIA="Parent_Process_Only"
               FAIL_CRITERIA="Each_Process"
               FAIL_CRITERIA="All_Processes"                     )

              FAIL_CRITERIA="Parent_Process_Only"
d   Set the maintenance flag depending on whether you configure the package in the
           maintenance mode or not. If the maintenance flag is set, the package enters the
           maintenance mode when the file apache.debug is present in the package directory.

           MAINTENANCE_FLAG="no"

       e   Set the rest of the parameters based on the requirement of your environment.

            MONITOR_INTERVAL=5
            RETRY_TIMES=2

5. Edit the Listen parameter.

       •   On a Red Hat system:
           This parameter is specified in httpd.conf file available in the server root directory.
           Listen <port_number>

       •   In SLES:
           Edit the Listen parameter in the corresponding listen.conf file
           Listen <port_number>

            The port number specified should not be in use by any other application


6. Edit other Apache configuration files.

       a. Edit other parameters if required in the httpd.conf file present in the server root
          directory.
       b. Update all the Apache configuration files and change the Apache instance
          configurations to suit your requirement.
       c. Provide the required values for server root directory and the document directory.

   If the environment is Red Hat, the configuration files are present in the
   /mnt/vgtry1/apache/conf directory.

   If the environment is SLES, the configuration files are present in the /mnt/vgtry1/apache
   directory.

7. Copy the package directory to all other package nodes.
   You must copy the package directory to the other nodes.
   For example:

   Copy to the parent directory of the package directory and enter the following command:
   #rcp -r –p /usr/local/cmcluster/pkg/apache1 photon4:$PWD/

8. Applying the package configuration file.
   Enter the following command to apply the package configuration:
   #cmapplyconf -P         pkg.conf

   Enter the following command to view the package details:
   #cmviewcl

   If the AUTORUN parameter has disabled as the value, you must change it to enable. Enter the
   following command to enable the AUTORUN parameter:
   For example:
   #cmmodpkg –e APACHE1

   If switching is disabled for any node, enable it using the cmmodpkg command as follows:
   For example:
   #cmmodpkg –e –n <node_name> APACHE1
Once the package starts, it starts an Apache server instance comprising of the Apache daemon,
httpd, which spawns a number of sub-processes to handle numerous http requests. It also
launches the Apache monitor script.

Configuring Multiple Instances

This section describes how to integrate multiple Apache Web Server instances using the High
Availability Apache Web Server toolkit. Before integrating the instances, you must first create an
instance of the Apache server. For more information on creating a single Apache instance, see
Configuring a Single Instance.

After you create an instance of the Apache server, you must create another instance using the
following procedure. All instances of the Apache server must be configured in the same way.

Following are the naming conventions that are used in this procedure:

        •    The Serviceguard Apache package is named as APACHE2. The corresponding service
             name is apache2_service.
        •    The Apache package is assumed to be listening to a relocatable IP address
             15.70.191.7. Ensure that this IP address is not used by any other application.

1. Create a volume group.
    You must configure volume group(s) for each Apache instance. This procedure describes how
    to create a volume groups that is applicable for a shared configuration as well as a local
    configuration.

        a. Create another volume group.
           For example:
           vgtry2

        b. Create a logical volume lvol in the volume group that you just created.

        c.   Create a file system on this logical volume and mount it.
             For example:
             /mnt/vgtry2/apache.

        d. Copy all files from server root directory to /mnt/vgtry2/apache.

2. Create a package directory.
    Create another package directory, as described in Configuring a Single Instance.
    For example, for the second instance, consider /usr/local/cmcluster/pkg/apache2 as
    the package directory of the second apache instance.

3. Edit the package configuration script.
   Edit the package configuration file pkg.conf.
   You must specify the following parameters to integrate multiple instances of the Apache server.
   The remaining parameters in the file must be configured as per the instructions for configuring a
   single instance package.

        •    Specify another name for this package. For example: APACHE2
        •    Specify another name for the corresponding server. For example: apache2_service.
             This service name must be unique.

              PACKAGE_NAME                  APACHE2
              RUN_SCRIPT /usr/local/cmcluster/pkg/apache2/pkg.cntl
              HALT_SCRIPT /usr/local/cmcluster/pkg/apache2/pkg.cntl
              SERVICE_NAME                  apache2_service
4. Edit the package control script.
   You must specify the following parameters to integrate multiple instances of the Apache server.
   The remaining parameters in the file must be configured as per the instructions for configuring a
   single instance package.

             VG[0]="/dev/vgtry2"
             LV[0]="/dev/vgtry2/lvol"; FS[0]="/mnt/vgtry2/apache";
             IP[0]="15.70.191.7"
             SUBNET[0]="15.70.191.0"
             SERVICE_NAME[0]="apache2_service"
             SERVICE_CMD[0]="/usr/local/cmcluster/pkg/apache2/toolkit.sh
monitor"


             function customer_defined_run_cmds
             {
               /usr/local/cmcluster/pkg/apache2/toolkit.sh start
                  test_return 51
             }

             function customer_defined_halt_cmds
             {
               /usr/local/cmcluster/pkg/apache2/toolkit.sh stop
                  test_return 52
             }

5. Edit the Apache toolkit configuration file.
   Edit the apache toolkit configuration file hahttp.conf. You must specify the following
   parameters to integrate multiple instances of the Apache server. The remaining parameters in
   the file must be configured as per the instructions for configuring a single instance package.

     HTTPD_CONFIG_FILE="/mnt/vgtry2/apache/httpd.conf"

    Configure the PID_FILE parameter with the path for pid file for the corresponding instance.
    For example:
    PID_FILE="/usr/local/cmcluster/pkg/apache2/httpd_s1.pid"

6. Edit the listen parameter.
   Edit the listen parameter in the httpd.conf file if Red Hat and in the listen.conf file if SLES
   such that the specified port is not being listened to by any other application.
   Listen <port_number>.

7. Edit the other Apache configuration files.
   Edit the corresponding httpd.conf file and other Apache configuration files placed in the
   server root directory, based on the requirements of your environment. For more information on
   editing the configuration files, see Configuring a Single Instance.

8. Copy the package directory to all other package nodes.
   Copy the package directory to the other nodes in the cluster.
   For example. Change to the parent directory of the package directory and enter the following
   command:
   #rcp -r –p /usr/local/pkg/cmcluster/apache2 photon4:$PWD/

9. Applying the package configuration file.
   Apply the package configuration on any node. For example, node photon3.
   Enter the following command to apply the configuration file:
   #cmapplyconf -P        pkg.conf

    Enter the following command to view the package details:
    #cmviewcl
If the AUTORUN parameter has disabled as the value, you must change it to enable. Run the
    following command to enable the AUTORUN parameter:
    For example:
    #cmmodpkg –e APACHE2

    If switching is disabled for any node, enable it using the cmmodpkg command:
    For example:
    #cmmodpkg –e –n <node_name> APACHE2

On completing this procedure, you would have created multiple Apache packages for multiple
Apache instances that will be running on the cluster.


Maintenance Mode

In any environment, you may need to bring down the systems for maintenance. Similarly, there may
be situations where you need to bring down the Apache Web Server for maintenance. For example,
you might have to change configuration information without migrating the instance from one node to
another node.

Following is the naming convention in this procedure:

    •   Package name is APACHE1
    •   Package directory is /usr/local/cmcluster/pkg/apache1


To bring down the Apache Web Server for maintenance, complete the following steps.


NOTE: The maintenance mode feature is enabled only when the configuration variable
MAINTENANCE_FLAG is set to yes in the apache toolkit configuration file
/usr/local/cmcluster/pkg/apache1/hahttp.conf.


1. Enter the following command to disable the failover of the package:

    #cmmodpkg -d APACHE1

2. Pause the monitor script and create an empty file,
   /usr/local/cmcluster/pkg/apache1/apache.debug, as shown below:

    #touch /usr/local/cmcluster/pkg/apache1/apache.debug

    The toolkit monitor script which continuously monitors the Apache daemons will now stop
    monitoring these daemons. The following message is logged in the package control script:

    Apache toolkit pausing monitoring and entering maintenance mode

    If required, enter the following command to stop the Apache application:

    #/usr/local/cmcluster/pkg/apache1/toolkit.sh stop

3. Perform the maintenance actions. For example, you can change the configuration of the
   Apache instance, or make changes to the toolkit configuration file, hahttp.conf to start the
   Apache web server application in secure mode. If you make changes to this file, you must
   distribute the new file to all the nodes in the cluster.

4. Start the apache instance again if you stopped it by using the following command:
   #/usr/local/cmcluster/pkg/apache1/toolkit.sh start
5. Enter the following command to start the monitoring process:
   # rm -f /usr/local/cmcluster/pkg/apache1/apache.debug

    The following message is recorded in the Serviceguard package control script log:

    Starting Apache toolkit monitoring again after maintenance.

6. Enter the following command to enable package failover:
   #cmmodpkg -e APACHE1


NOTE: If the package fails during maintenance, the package does not automatically failover to an
adoptive node. You need to manually start the package on the adoptive node. For more information
on manually starting package on an adoptive node, see Managing HP Serviceguard.

SECURITY POLICIES IN LINUX

SELinux and AppArmor are security tools that are delivered with Red Hat and SLES, respectively.
One of the functions of these tools is to protect some applications based on security policies. These
policies define default access control for the applications. If there is any change to the application
configuration, for example, change in binaries or file locations, then appropriate access controls
must be redefined in the security policy for that application.


NOTE: The following sections are applicable only when security policies have been enforced on
applications using either SELinux or AppArmor.


SELinux

SELinux (Security-Enhanced Linux) is an implementation of mandatory access control in the Linux
kernel, using the Linux Security Modules (LSM) framework. SELinux is turned on by default in Red
Hat. All the Apache files and directories are protected by SELinux security policy. All of these files
must be associated with a security context defined for Apache. SELinux protection allows Apache
processes to access only those files with the context defined in the security policy for Apache. The
default policies of SELinux are defined so that the default directories of Apache have the right
contexts. If any changes are made, such as moving the DocumentRoot or ServerRoot of Apache
from local to a non-default location, ensure that these new directories and all files in the directory
have the same security context as the default installation. Configuring the context is mandatory if
anything other than the default file locations is used.

Note: All the files accessed by Apache processes must have the right context as defined in the
security policy. For more information on configuring SELinux with Apache, see the Red Hat
documentation website.

For Example:
To place the Web pages in directories other than Apache defaults, user 'root' creates a new
directory /home/www/site1 in which the pages for a new Web site are located. A default security
context ‘root:object_r:user_home_t' is assigned to the new directory and its files. Use ls -Z
command as follows to find the context assigned.

   # mkdir /home/www/site1
   # ls -Z /home/www/
      drwxr-xr-x root      root    root:object_r:user_home_t                             site1
   # touch /home/www/site1/index.html
   # ls -Z /home/www/site1/index.html
     -rw-r--r-- root root root:object_r:user_home_t

     /home/www/site1/index.html
Access to the newly created directory or file is denied to Apache as the default Apache's security
policy does not allow access to the file with the above set security context user_home_t.
To make these new directories and files accessible to Apache processes, modify the security
context of the directory /home/www/site1 to Apache's default security context using chcon
utility, as shown below.

The following example defines the steps to change the context for the Document Root. Similar
method has to be adopted to set context to other directories or files of Apache.

1. Determine the default security context of the Document Root, /var/www/html as follows:
   #ls -aZ /var/www/html
   drwxr-xr-x root root               system_u:object_r:httpd_sys_content_t .
   drwxr-xr-x root root               system_u:object_r:httpd_sys_content_t .

2. Change the security context of /home/www/site1 and its subdirectories and files to the same
   security context of the default, using the chcon utility as follows:

    #chcon -R ssystem_u:object_r:httpd_sys_content_t /home/www/site1

    You must set the right security context for all directories and files accessed by the Apache
    processes.

    When you copy Apache files from the default location to any other shared location, you must
    use the cp –c to preserve the security context. In this case, you need not change the security
    context for the files, because these files inherit the security context from the source.


Note: You must set the appropriate security contexts for a package to be up and running. You must
the right contexts related to SELinux to bring up the package successfully. View the SELinux audit
log, /var/log/messages, and ensure that there are no avc denial messages. These denial
messages are sometimes triggered by changes in the application. To fix these messages, you may
have to change the security policy apache.te, located at its default location.


For more information on security related topics while setting up the package, see the Red Hat
documentation website.

AppArmor

Novell AppArmor is an access control system that enables you to specify per program, which files
the program may read, write, and execute. AppArmor achieves mandatory access control by
assigning a profile per application, that is, a security policy that completely defines what system
resources an application can access, and with what privileges. Novell AppArmor is an integral part
of SLES10.

AppArmor profiles are human-readable text files that mediate access to files and directories as well
as determine what POSIX capabilities an application is allowed to have. Profiles are traditionally
stored in files in /etc/apparmor.d/ under filenames with the convention of replacing the / in
pathnames with (except for the root /) so profiles are easier to manage (for example the
/usr/sbin/httpd2-prefork profile would be named usr.sbin.httpd2-prefork). For more
information on using profiles, see the Novell documentation site.

AppArmor profile for Apache is shipped with the SLES. By default, the AppArmor profile for Apache
has permissions for accessing only the default file locations of Apache. If any change is made, such
as moving the DocumentRoot or ServerRoot of Apache from local to a non-default location, then
Apache AppArmor profile needs to be updated with permissions for accessing these new directories
and all of the files in the directory.

For Example:
To place the ServerRoot directory on a shared file system /shared/apache_1, copy all the files
from /etc/apache2/* to /shared/apache_1.
Access to the shared directory and files is denied to Apache because the default Apache's
                                   AppArmor profile does not allow access to these files.

                                   To grant access to the shared directory, complete the following steps:

                                   1. To make the shared directory and files accessible by Apache, edit the Apache’s AppArmor
                                      profile (/etc/apparmor.d/usr.sbin.httpd2-prefork) by adding entries to grant access
                                      to the shared directory and files. For this, use a text editor or the YaST interface (Edit AppArmor
                                      Profile).

                                         For example, to grant read access to all the configuration files in the shared directory
                                         (/shared/apache_1) to Apache, add the following line to the file
                                         /etc/apparmor.d/usr.sbin.httpd2-prefork.
                                         /shared/apache_1/*.conf r

                                   2. Add such entries for all other directories or files that will be accessed by Apache.

                                   3. Reload the profile into the kernel by entering the following command:
                                      apparmor_parser -r usr.sbin.httpd2-prefork

                                   4. Run the Apache package. If the package fails to start, then check AppArmor audit log for
                                      REJECT messages to Apache. If there are any, then use the method specified above to update
                                      the profile. You can also use the update wizards-YaST (Update Profiles Wizard) or logprof

                                   For more information on updating profiles using YAST or logprof, see the Novell documentation site.

                                   CONCLUSION

                                   By setting up the Apache Web Server and integrating it with the Serviceguard for Linux environment
                                   using the High Availability Apache toolkit, you can avail many benefits, such as reduction in
                                   application integration effort and ease of deployment of the Apache Web Server. In addition,
                                   maintenance and upgrading of the Apache Web Server becomes simpler. You can also choose
                                   among various criterions for the Apache Server to fail over.


                                   Note: Unless otherwise stated, the High Availability Apache toolkit runs on all distributions and
                                   hardware supported by Serviceguard for Linux.




© 2007 Hewlett-Packard Development Company, L.P. The information contained
herein is subject to change without notice. The only warranties for HP products and
services are set forth in the express warranty statements accompanying such
products and services. Nothing herein should be construed as constituting an
additional warranty. HP shall not be liable for technical or editorial errors or
omissions contained herein.

Itanium is a trademark or registered trademark of Intel Corporation or its
subsidiaries in the United States and other countries.
August 2007

Weitere ähnliche Inhalte

Was ist angesagt?

MySQL Webinar 2/4 Performance tuning, hardware, optimisation
MySQL Webinar 2/4 Performance tuning, hardware, optimisationMySQL Webinar 2/4 Performance tuning, hardware, optimisation
MySQL Webinar 2/4 Performance tuning, hardware, optimisationMark Swarbrick
 
Apache Ambari: Simplified Hadoop Cluster Operation & Troubleshooting
Apache Ambari: Simplified Hadoop Cluster Operation & TroubleshootingApache Ambari: Simplified Hadoop Cluster Operation & Troubleshooting
Apache Ambari: Simplified Hadoop Cluster Operation & TroubleshootingJayush Luniya
 
SCALE12X Build a Cloud Day: Chef: The Swiss Army Knife of Cloud Infrastructure
SCALE12X Build a Cloud Day: Chef: The Swiss Army Knife of Cloud InfrastructureSCALE12X Build a Cloud Day: Chef: The Swiss Army Knife of Cloud Infrastructure
SCALE12X Build a Cloud Day: Chef: The Swiss Army Knife of Cloud InfrastructureMatt Ray
 
Guide to alfresco monitoring
Guide to alfresco monitoringGuide to alfresco monitoring
Guide to alfresco monitoringMiguel Rodriguez
 
HBase replication
HBase replicationHBase replication
HBase replicationwchevreuil
 
Spring Hibernate with Ehcache
Spring Hibernate with EhcacheSpring Hibernate with Ehcache
Spring Hibernate with EhcacheInnovationM
 
APC PowerChute Shutdown Utility for Apache Web Server -- User ...
APC PowerChute Shutdown Utility for Apache Web Server -- User ...APC PowerChute Shutdown Utility for Apache Web Server -- User ...
APC PowerChute Shutdown Utility for Apache Web Server -- User ...webhostingguy
 
Puppet camp london nov 2014 slides (1)
Puppet camp london nov 2014   slides (1)Puppet camp london nov 2014   slides (1)
Puppet camp london nov 2014 slides (1)Puppet
 
Upgrade EBS DB from 11g to 12c.
Upgrade EBS DB from 11g to 12c.Upgrade EBS DB from 11g to 12c.
Upgrade EBS DB from 11g to 12c.Osama Mustafa
 
Velocity 2011 Chef OpenStack Workshop
Velocity 2011 Chef OpenStack WorkshopVelocity 2011 Chef OpenStack Workshop
Velocity 2011 Chef OpenStack WorkshopChef Software, Inc.
 
Introducing Apache Mesos
Introducing Apache MesosIntroducing Apache Mesos
Introducing Apache MesosMatthias Furrer
 
Oracle Database 11g Product Family
Oracle Database 11g Product FamilyOracle Database 11g Product Family
Oracle Database 11g Product FamilyN/A
 
Pluggable database tutorial
Pluggable database tutorialPluggable database tutorial
Pluggable database tutorialOsama Mustafa
 
Colvin exadata and_oem12c
Colvin exadata and_oem12cColvin exadata and_oem12c
Colvin exadata and_oem12cEnkitec
 
Native support of Prometheus monitoring in Apache Spark 3
Native support of Prometheus monitoring in Apache Spark 3Native support of Prometheus monitoring in Apache Spark 3
Native support of Prometheus monitoring in Apache Spark 3Dongjoon Hyun
 
Log grid root
Log grid rootLog grid root
Log grid rootopenmi
 

Was ist angesagt? (19)

MySQL Webinar 2/4 Performance tuning, hardware, optimisation
MySQL Webinar 2/4 Performance tuning, hardware, optimisationMySQL Webinar 2/4 Performance tuning, hardware, optimisation
MySQL Webinar 2/4 Performance tuning, hardware, optimisation
 
Apache Ambari: Simplified Hadoop Cluster Operation & Troubleshooting
Apache Ambari: Simplified Hadoop Cluster Operation & TroubleshootingApache Ambari: Simplified Hadoop Cluster Operation & Troubleshooting
Apache Ambari: Simplified Hadoop Cluster Operation & Troubleshooting
 
Rac&asm
Rac&asmRac&asm
Rac&asm
 
12c on RHEL7
12c on RHEL712c on RHEL7
12c on RHEL7
 
SCALE12X Build a Cloud Day: Chef: The Swiss Army Knife of Cloud Infrastructure
SCALE12X Build a Cloud Day: Chef: The Swiss Army Knife of Cloud InfrastructureSCALE12X Build a Cloud Day: Chef: The Swiss Army Knife of Cloud Infrastructure
SCALE12X Build a Cloud Day: Chef: The Swiss Army Knife of Cloud Infrastructure
 
Guide to alfresco monitoring
Guide to alfresco monitoringGuide to alfresco monitoring
Guide to alfresco monitoring
 
HBase replication
HBase replicationHBase replication
HBase replication
 
Spring Hibernate with Ehcache
Spring Hibernate with EhcacheSpring Hibernate with Ehcache
Spring Hibernate with Ehcache
 
APC PowerChute Shutdown Utility for Apache Web Server -- User ...
APC PowerChute Shutdown Utility for Apache Web Server -- User ...APC PowerChute Shutdown Utility for Apache Web Server -- User ...
APC PowerChute Shutdown Utility for Apache Web Server -- User ...
 
Chef
ChefChef
Chef
 
Puppet camp london nov 2014 slides (1)
Puppet camp london nov 2014   slides (1)Puppet camp london nov 2014   slides (1)
Puppet camp london nov 2014 slides (1)
 
Upgrade EBS DB from 11g to 12c.
Upgrade EBS DB from 11g to 12c.Upgrade EBS DB from 11g to 12c.
Upgrade EBS DB from 11g to 12c.
 
Velocity 2011 Chef OpenStack Workshop
Velocity 2011 Chef OpenStack WorkshopVelocity 2011 Chef OpenStack Workshop
Velocity 2011 Chef OpenStack Workshop
 
Introducing Apache Mesos
Introducing Apache MesosIntroducing Apache Mesos
Introducing Apache Mesos
 
Oracle Database 11g Product Family
Oracle Database 11g Product FamilyOracle Database 11g Product Family
Oracle Database 11g Product Family
 
Pluggable database tutorial
Pluggable database tutorialPluggable database tutorial
Pluggable database tutorial
 
Colvin exadata and_oem12c
Colvin exadata and_oem12cColvin exadata and_oem12c
Colvin exadata and_oem12c
 
Native support of Prometheus monitoring in Apache Spark 3
Native support of Prometheus monitoring in Apache Spark 3Native support of Prometheus monitoring in Apache Spark 3
Native support of Prometheus monitoring in Apache Spark 3
 
Log grid root
Log grid rootLog grid root
Log grid root
 

Andere mochten auch

Windows Hosting Service-Level Description
Windows Hosting Service-Level DescriptionWindows Hosting Service-Level Description
Windows Hosting Service-Level Descriptionwebhostingguy
 
Q3 2009 Hardware Teleconference
Q3 2009 Hardware TeleconferenceQ3 2009 Hardware Teleconference
Q3 2009 Hardware Teleconferencewebhostingguy
 
Web Server Technologies I: HTTP
Web Server Technologies I: HTTP Web Server Technologies I: HTTP
Web Server Technologies I: HTTP webhostingguy
 
Shared Oracle Hosting (Linux)
Shared Oracle Hosting (Linux)Shared Oracle Hosting (Linux)
Shared Oracle Hosting (Linux)webhostingguy
 
Apache Manager Table of Contents
Apache Manager Table of ContentsApache Manager Table of Contents
Apache Manager Table of Contentswebhostingguy
 
Quick Reference Guide: Shared Hosting
Quick Reference Guide: Shared HostingQuick Reference Guide: Shared Hosting
Quick Reference Guide: Shared Hostingwebhostingguy
 
Apache2 BootCamp : Understanding Apache Internals
Apache2 BootCamp : Understanding Apache InternalsApache2 BootCamp : Understanding Apache Internals
Apache2 BootCamp : Understanding Apache InternalsWildan Maulana
 
Configuring Apache Web Server For Single Sign-On with Likewise
Configuring Apache Web Server For Single Sign-On with LikewiseConfiguring Apache Web Server For Single Sign-On with Likewise
Configuring Apache Web Server For Single Sign-On with Likewisewebhostingguy
 
Utosc2007_Apache_Configuration.ppt
Utosc2007_Apache_Configuration.pptUtosc2007_Apache_Configuration.ppt
Utosc2007_Apache_Configuration.pptwebhostingguy
 
Apache thrift
Apache thriftApache thrift
Apache thriftducdv
 
APACHE WEB SERVER FOR LINUX
APACHE WEB SERVER FOR LINUXAPACHE WEB SERVER FOR LINUX
APACHE WEB SERVER FOR LINUXwebhostingguy
 
Configuring the Apache Web Server
Configuring the Apache Web ServerConfiguring the Apache Web Server
Configuring the Apache Web Serverwebhostingguy
 
Apache web server tutorial for linux
Apache web server tutorial for linuxApache web server tutorial for linux
Apache web server tutorial for linuxSahad Sali
 

Andere mochten auch (20)

Windows Hosting Service-Level Description
Windows Hosting Service-Level DescriptionWindows Hosting Service-Level Description
Windows Hosting Service-Level Description
 
US07FFT-mod_ftp.ppt
US07FFT-mod_ftp.pptUS07FFT-mod_ftp.ppt
US07FFT-mod_ftp.ppt
 
Q3 2009 Hardware Teleconference
Q3 2009 Hardware TeleconferenceQ3 2009 Hardware Teleconference
Q3 2009 Hardware Teleconference
 
Web Server Technologies I: HTTP
Web Server Technologies I: HTTP Web Server Technologies I: HTTP
Web Server Technologies I: HTTP
 
Shared Oracle Hosting (Linux)
Shared Oracle Hosting (Linux)Shared Oracle Hosting (Linux)
Shared Oracle Hosting (Linux)
 
Apache Manager Table of Contents
Apache Manager Table of ContentsApache Manager Table of Contents
Apache Manager Table of Contents
 
Quick Reference Guide: Shared Hosting
Quick Reference Guide: Shared HostingQuick Reference Guide: Shared Hosting
Quick Reference Guide: Shared Hosting
 
Installing and configuring apache
Installing and configuring apacheInstalling and configuring apache
Installing and configuring apache
 
Apache
ApacheApache
Apache
 
Apache2 BootCamp : Understanding Apache Internals
Apache2 BootCamp : Understanding Apache InternalsApache2 BootCamp : Understanding Apache Internals
Apache2 BootCamp : Understanding Apache Internals
 
Configuring Apache Web Server For Single Sign-On with Likewise
Configuring Apache Web Server For Single Sign-On with LikewiseConfiguring Apache Web Server For Single Sign-On with Likewise
Configuring Apache Web Server For Single Sign-On with Likewise
 
Its3 Drupal
Its3 DrupalIts3 Drupal
Its3 Drupal
 
Utosc2007_Apache_Configuration.ppt
Utosc2007_Apache_Configuration.pptUtosc2007_Apache_Configuration.ppt
Utosc2007_Apache_Configuration.ppt
 
Css
CssCss
Css
 
Apache thrift
Apache thriftApache thrift
Apache thrift
 
Apache ppt
Apache pptApache ppt
Apache ppt
 
APACHE WEB SERVER FOR LINUX
APACHE WEB SERVER FOR LINUXAPACHE WEB SERVER FOR LINUX
APACHE WEB SERVER FOR LINUX
 
Configuring the Apache Web Server
Configuring the Apache Web ServerConfiguring the Apache Web Server
Configuring the Apache Web Server
 
Apache http server
Apache http serverApache http server
Apache http server
 
Apache web server tutorial for linux
Apache web server tutorial for linuxApache web server tutorial for linux
Apache web server tutorial for linux
 

Ähnlich wie INSTALLING AND CONFIGURING APACHE TOOLKIT FOR SERVICEGUARD ...

APACHE
APACHEAPACHE
APACHEARJUN
 
Introducing Chef | An IT automation for speed and awesomeness
Introducing Chef | An IT automation for speed and awesomenessIntroducing Chef | An IT automation for speed and awesomeness
Introducing Chef | An IT automation for speed and awesomenessRamit Surana
 
How to installation and configure apache2
How to installation and configure apache2How to installation and configure apache2
How to installation and configure apache2VCP Muthukrishna
 
Nadhiya lamp
Nadhiya lampNadhiya lamp
Nadhiya lampNadhi ya
 
Deepa ppt about lamp technology
Deepa ppt about lamp technologyDeepa ppt about lamp technology
Deepa ppt about lamp technologyDeepa
 
lamp technology
lamp technologylamp technology
lamp technologyDeepa
 
Configuration of Apache Web Server On CentOS 8
Configuration of Apache Web Server On CentOS 8Configuration of Apache Web Server On CentOS 8
Configuration of Apache Web Server On CentOS 8Kaan Aslandağ
 
Apache windows
Apache windowsApache windows
Apache windowsmexxixxo
 
How to Use NDS eDirectory to Secure Apache Web Server for NetWare
How to Use NDS eDirectory to Secure Apache Web Server for NetWareHow to Use NDS eDirectory to Secure Apache Web Server for NetWare
How to Use NDS eDirectory to Secure Apache Web Server for NetWarewebhostingguy
 
APC PowerChute Shutdown Utility for Apache Web Server -- User ...
APC PowerChute Shutdown Utility for Apache Web Server -- User ...APC PowerChute Shutdown Utility for Apache Web Server -- User ...
APC PowerChute Shutdown Utility for Apache Web Server -- User ...webhostingguy
 
Lamp technology
Lamp technologyLamp technology
Lamp technology2tharan21
 

Ähnlich wie INSTALLING AND CONFIGURING APACHE TOOLKIT FOR SERVICEGUARD ... (20)

Apache
Apache Apache
Apache
 
Introduction to chef
Introduction to chefIntroduction to chef
Introduction to chef
 
APACHE
APACHEAPACHE
APACHE
 
Introducing Chef | An IT automation for speed and awesomeness
Introducing Chef | An IT automation for speed and awesomenessIntroducing Chef | An IT automation for speed and awesomeness
Introducing Chef | An IT automation for speed and awesomeness
 
How to installation and configure apache2
How to installation and configure apache2How to installation and configure apache2
How to installation and configure apache2
 
Nadhiya lamp
Nadhiya lampNadhiya lamp
Nadhiya lamp
 
Chef
ChefChef
Chef
 
iac.pptx
iac.pptxiac.pptx
iac.pptx
 
Deepa ppt about lamp technology
Deepa ppt about lamp technologyDeepa ppt about lamp technology
Deepa ppt about lamp technology
 
lamp technology
lamp technologylamp technology
lamp technology
 
Appache.ppt
Appache.pptAppache.ppt
Appache.ppt
 
Chef: Smart infrastructure automation
Chef: Smart infrastructure automationChef: Smart infrastructure automation
Chef: Smart infrastructure automation
 
Appache.ppt
Appache.pptAppache.ppt
Appache.ppt
 
Configuration of Apache Web Server On CentOS 8
Configuration of Apache Web Server On CentOS 8Configuration of Apache Web Server On CentOS 8
Configuration of Apache Web Server On CentOS 8
 
Apache windows
Apache windowsApache windows
Apache windows
 
How to Use NDS eDirectory to Secure Apache Web Server for NetWare
How to Use NDS eDirectory to Secure Apache Web Server for NetWareHow to Use NDS eDirectory to Secure Apache Web Server for NetWare
How to Use NDS eDirectory to Secure Apache Web Server for NetWare
 
Chef fundamentals
Chef fundamentalsChef fundamentals
Chef fundamentals
 
APC PowerChute Shutdown Utility for Apache Web Server -- User ...
APC PowerChute Shutdown Utility for Apache Web Server -- User ...APC PowerChute Shutdown Utility for Apache Web Server -- User ...
APC PowerChute Shutdown Utility for Apache Web Server -- User ...
 
Apache Web Server Setup 2
Apache Web Server Setup 2Apache Web Server Setup 2
Apache Web Server Setup 2
 
Lamp technology
Lamp technologyLamp technology
Lamp technology
 

Mehr von webhostingguy

Running and Developing Tests with the Apache::Test Framework
Running and Developing Tests with the Apache::Test FrameworkRunning and Developing Tests with the Apache::Test Framework
Running and Developing Tests with the Apache::Test Frameworkwebhostingguy
 
MySQL and memcached Guide
MySQL and memcached GuideMySQL and memcached Guide
MySQL and memcached Guidewebhostingguy
 
Novell® iChain® 2.3
Novell® iChain® 2.3Novell® iChain® 2.3
Novell® iChain® 2.3webhostingguy
 
Load-balancing web servers Load-balancing web servers
Load-balancing web servers Load-balancing web serversLoad-balancing web servers Load-balancing web servers
Load-balancing web servers Load-balancing web serverswebhostingguy
 
SQL Server 2008 Consolidation
SQL Server 2008 ConsolidationSQL Server 2008 Consolidation
SQL Server 2008 Consolidationwebhostingguy
 
Master Service Agreement
Master Service AgreementMaster Service Agreement
Master Service Agreementwebhostingguy
 
PHP and MySQL PHP Written as a set of CGI binaries in C in ...
PHP and MySQL PHP Written as a set of CGI binaries in C in ...PHP and MySQL PHP Written as a set of CGI binaries in C in ...
PHP and MySQL PHP Written as a set of CGI binaries in C in ...webhostingguy
 
Dell Reference Architecture Guide Deploying Microsoft® SQL ...
Dell Reference Architecture Guide Deploying Microsoft® SQL ...Dell Reference Architecture Guide Deploying Microsoft® SQL ...
Dell Reference Architecture Guide Deploying Microsoft® SQL ...webhostingguy
 
Managing Diverse IT Infrastructure
Managing Diverse IT InfrastructureManaging Diverse IT Infrastructure
Managing Diverse IT Infrastructurewebhostingguy
 
Web design for business.ppt
Web design for business.pptWeb design for business.ppt
Web design for business.pptwebhostingguy
 
IT Power Management Strategy
IT Power Management Strategy IT Power Management Strategy
IT Power Management Strategy webhostingguy
 
Excel and SQL Quick Tricks for Merchandisers
Excel and SQL Quick Tricks for MerchandisersExcel and SQL Quick Tricks for Merchandisers
Excel and SQL Quick Tricks for Merchandiserswebhostingguy
 
Parallels Hosting Products
Parallels Hosting ProductsParallels Hosting Products
Parallels Hosting Productswebhostingguy
 
Microsoft PowerPoint presentation 2.175 Mb
Microsoft PowerPoint presentation 2.175 MbMicrosoft PowerPoint presentation 2.175 Mb
Microsoft PowerPoint presentation 2.175 Mbwebhostingguy
 

Mehr von webhostingguy (20)

File Upload
File UploadFile Upload
File Upload
 
Running and Developing Tests with the Apache::Test Framework
Running and Developing Tests with the Apache::Test FrameworkRunning and Developing Tests with the Apache::Test Framework
Running and Developing Tests with the Apache::Test Framework
 
MySQL and memcached Guide
MySQL and memcached GuideMySQL and memcached Guide
MySQL and memcached Guide
 
Novell® iChain® 2.3
Novell® iChain® 2.3Novell® iChain® 2.3
Novell® iChain® 2.3
 
Load-balancing web servers Load-balancing web servers
Load-balancing web servers Load-balancing web serversLoad-balancing web servers Load-balancing web servers
Load-balancing web servers Load-balancing web servers
 
SQL Server 2008 Consolidation
SQL Server 2008 ConsolidationSQL Server 2008 Consolidation
SQL Server 2008 Consolidation
 
What is mod_perl?
What is mod_perl?What is mod_perl?
What is mod_perl?
 
What is mod_perl?
What is mod_perl?What is mod_perl?
What is mod_perl?
 
Master Service Agreement
Master Service AgreementMaster Service Agreement
Master Service Agreement
 
Notes8
Notes8Notes8
Notes8
 
PHP and MySQL PHP Written as a set of CGI binaries in C in ...
PHP and MySQL PHP Written as a set of CGI binaries in C in ...PHP and MySQL PHP Written as a set of CGI binaries in C in ...
PHP and MySQL PHP Written as a set of CGI binaries in C in ...
 
Dell Reference Architecture Guide Deploying Microsoft® SQL ...
Dell Reference Architecture Guide Deploying Microsoft® SQL ...Dell Reference Architecture Guide Deploying Microsoft® SQL ...
Dell Reference Architecture Guide Deploying Microsoft® SQL ...
 
Managing Diverse IT Infrastructure
Managing Diverse IT InfrastructureManaging Diverse IT Infrastructure
Managing Diverse IT Infrastructure
 
Web design for business.ppt
Web design for business.pptWeb design for business.ppt
Web design for business.ppt
 
IT Power Management Strategy
IT Power Management Strategy IT Power Management Strategy
IT Power Management Strategy
 
Excel and SQL Quick Tricks for Merchandisers
Excel and SQL Quick Tricks for MerchandisersExcel and SQL Quick Tricks for Merchandisers
Excel and SQL Quick Tricks for Merchandisers
 
OLUG_xen.ppt
OLUG_xen.pptOLUG_xen.ppt
OLUG_xen.ppt
 
Parallels Hosting Products
Parallels Hosting ProductsParallels Hosting Products
Parallels Hosting Products
 
Microsoft PowerPoint presentation 2.175 Mb
Microsoft PowerPoint presentation 2.175 MbMicrosoft PowerPoint presentation 2.175 Mb
Microsoft PowerPoint presentation 2.175 Mb
 
Reseller's Guide
Reseller's GuideReseller's Guide
Reseller's Guide
 

INSTALLING AND CONFIGURING APACHE TOOLKIT FOR SERVICEGUARD ...

  • 1. INSTALLING AND CONFIGURING APACHE TOOLKIT FOR SERVICEGUARD FOR LINUX Executive Summary ......................................................................................................................... 2 Intended Audience.......................................................................................................................... 2 Introduction to the High Availability Apache Toolkit .............................................................................. 2 STORAGE CONFIGURATIONS......................................................................................................... 3 SETTING UP THE APACHE WEB SERVER APPLICATION FOR AN SG/LX CLUSTER.................................... 4 Setting Up the Apache Web Server ............................................................................................... 4 Installing the High Availability Apache Toolkit.................................................................................. 5 CONFIGURING APACHE WEB SERVER PACKAGES IN AN SG/LINUX ENVIRONMENT........................... 6 Configuring a Single Instance....................................................................................................... 6 Configuring Multiple Instances.................................................................................................... 11 Maintenance Mode ................................................................................................................... 13 SECURITY POLICIES IN LINUX.................................................................................................... 14 SELinux .................................................................................................................................. 14 AppArmor................................................................................................................................ 15 CONCLUSION ............................................................................................................................ 16
  • 2. Executive Summary This document describes how to configure and run an Apache Web Server using the High Availability Apache Toolkit in the HP Serviceguard for Linux environment. This white paper introduces you to the High Availability Apace toolkit and outlines the procedures and tasks that you need to complete to install and configure the toolkit in your Linux environment with Serviceguard. In addition, this whitepaper also discusses security policies that have an impact on your Linux environment. Intended Audience This document is intended for system or network administrators who need to configure and run an Apache Web Server using the High Availability Apache Toolkit on a Serviceguard Linux cluster. Users must be familiar with the following topics: • Serviceguard Configuration • Apache Web Server Concepts • Apache Server Installation and Configuration Procedures Introduction to the High Availability Apache Toolkit HP provides Serviceguard for Linux Apache toolkit for customers to integrate the Apache Web Server application with HP Serviceguard. Using Serviceguard for Linux toolkit simplifies application integration, and eases deployment and maintenance of applications in a cluster environment. The High Availability Apache toolkit consists of a set of shell scripts that are used by the package control script to start, stop and monitor the Apache Web Server application. This toolkit contains files that are installed in specific locations, corresponding to the respective distributions. These files enable you to manage your environment. Table 1 describes the files that are part of this toolkit. Table 1 Files in the High Availability Toolkit File Name Description toolkit.sh The Toolkit Interface Script. It interfaces between the package control script and the main toolkit script. hahttp.conf The Toolkit Configuration File. It contains a list of pre-defined variables that you can modify to suit your environment. hahttp.mon The Toolkit Monitoring Script. Use this script to monitor the health of the server application. hahttp.sh The Toolkit Main Script. It contains the list of internal functions that you can use to start or stop the Apache Web Server instance in your environment. README A text file that contains information that you must read before using the Apache toolkit.
  • 3. To use the Apache Web Server application in your environment, the Apache web server must be installed on all cluster nodes configured to run an Apache package. A typical configuration of an Apache Web Server application is one where one node is configured as a primary node and the others are configured as standby or secondary nodes. The Apache Web Server application runs on the primary node and accepts (HTTP/S) requests and serves clients. If the primary node fails, a standby node takes over the server activities. This take over is seamless and does not interrupt any of the processes in the environment. For this seamless transition to occur, all configuration information of all nodes must be identical and all resources must be available to all nodes. Apache Web Server supports multiple instances of server daemons that are running on a node simultaneously. For each instance of an Apache Server, an Apache package is created with its own server root directory, toolkit files and configuration information. Each instance may support one or more websites, depending on whether or not an instance has been configured to use "virtual hosts". The server root directory contains the appropriate configuration file that specifies how an Apache server instance is configured. The Apache configuration directives within this file determine the location of the log files, web documents, and the domain name address for the specific Apache server instance. NOTE: If you have a Red Hat Enterprise Linux system in your environment, then the configuration file resides in the conf/httpd.conf file in the server root directory. If you have a SUSE Linux Enterprise Server, the configuration file resides in the httpd.conf in the server root directory. STORAGE CONFIGURATIONS You can configure the Apache toolkit using either one of the following storage configuration options: • Local configuration In this configuration, place the configuration files and the other website files on a single node, and replicate them on all other nodes in the cluster. • Shared configuration In this configuration, place the configuration files and the other Web site files on a shared file system. All the nodes in the cluster will access these files from the shared file system. The following sections discuss these configuration options in detail. Local Configuration In a typical local configuration, files are not shared among nodes. Identical copies of the Apache server configuration file and web documents must reside in exactly the same locations on each node. If you update the information in a file on a single node, you must update the files on all other nodes with the same changes. The administrator needs to ensure that all the files on all the nodes are identical and always up-to-date. This local configuration setup is more useful in scenarios where the information on the Web page is static and does not change very often. Shared Configuration In a typical shared configuration, the document root directories reside on a shared file system. You can also place the server root directory in this shared file system. However, this is optional. By placing the files and directories on a shared file system, the information automatically becomes accessible to all the nodes in the cluster. You need not have to maintain copies of all the files and directories on every node in the cluster. However, you must ensure that the mount point of the shared file system is identical across all Apache package nodes. HP recommends that you use the shared configuration option for configuring this toolkit because you do not have to maintain identical copies of the files and directories on all nodes. In addition, with this option, all information is automatically accessible to all nodes.
  • 4. SETTING UP THE APACHE WEB SERVER APPLICATION FOR AN SG/LX CLUSTER Once you decide on the storage configuration option, you can install the High Availability Apache Web Server Toolkit. However, before you start installing the toolkit, ensure that your environment meets the following prerequisites: • HP Serviceguard for Linux must be installed on all nodes that need to be configured in the cluster • The toolkit is installed on all the target nodes of the cluster • Apache Web Server is installed and configured on all target nodes o The same version of the server must be installed and configured on all target nodes. o Identical copies of the server root directory must be available on all nodes. o Each node must have the same document root directory that contains identical copies of the Web documents for a particular instance. For this white paper, the environment is assumed to be that of a cluster with two nodes with a shared storage device and a quorum server for the cluster. However, these instructions are applicable for a cluster that has more than two nodes, provided the prerequisites are met. NOTE: The installation instructions illustrate commands for a Red Hat environment. If your environment has SUSE Linux Enterprise Servers, then replace all occurrences of /usr/local with /opt. Installing and setting up the Apache toolkit involves the following tasks: • Set up the Apache Web Server • Install the Toolkit • Configure the Apache Web Server Packages The following sections describe these tasks in detail. Setting Up the Apache Web Server To manage an Apache Web Server using Serviceguard, you need to modify the default Apache configuration information. Before you create and configure the Serviceguard packages, ensure that the configurations listed later in this section are completed for the Apache Web Server application on all other cluster nodes. 1) Disable the automatic start-up of the default instance of the Apache Server. After installing the Apache Server, you can configure it to automatically start at system start up time by using the runlevel (rc) scripts in the /etc/rc.d directory. However, you must disable the automatic start-up of this default instance in an SG/Linux environment, because it can affect the behavior of the Serviceguard or Apache packages. For more information on configuring the Apache Server, see the Apache Documentation that comes along with the Apache installation. 2) Customize an Apache instance to run on a node by using the httpd.conf file. This httpd.conf file is associated with the default Apache instance and has a Listen directive "Listen 80", which is equivalent to listening for all IP addresses at port 80. Following is the default location of this file: Red Hat: /etc/httpd/conf/httpd.conf SLES: /etc/apache2/httpd.conf If an Apache instance needs to be configured so that it listens to specific IP Addresses, the LISTEN directive has to be changed to "Listen <IP Address> :<Port>". NOTE: The httpd.conf file of SLES distribution has several include directives. One of them includes the file /etc/apache2/sysconfig.d/include.conf which does not
  • 5. exist by default. This file is used to define any user defined parameters. The Apache server fails to start if this file is not present. To start Apache successfully, either use the touch command to create a file or comment out the Include parameter in the httpd.conf file. 3) Create a separate, distinct server root directory and server configuration file for each Apache SG/Linux package. This server root directory corresponds to the Apache ServerRoot directive specified in the configuration file. Each package corresponds to a unique Apache instance with its associated configuration and server root directory. 4) Configure all Apache instances to listen to a package re-locatable IP address using ‘Listen’ directives. For more information on configuring virtual hosts, see to the Apache Web Server documentation. For example, the configuration files for an Apache instance that combines IP-based and name-based virtual hosts includes the following directive: Listen 192.168.0.1:80 Listen 192.168.0.2:80 NameVirtualHost 192.168.0.2:80 <VirtualHost web.site1.url:80> ServerName web.site1.url DocumentRoot /shared/httpd/www-site1 </VirtualHost> <VirtualHost web.site2.url:80> ServerName web.site2.url DocumentRoot /shared/httpd/www-site2 </VirtualHost> These steps enable you to customize the way the Apache instance starts using the Apache toolkit on a node. After completing this procedure, you can install the Apache toolkit and configure the Apache Web Server package in the Serviceguard environment. Installing the High Availability Apache Toolkit The Linux Apache toolkit is available at http://www.software.hp.com/ as ‘Serviceguard for Linux Apache Toolkit’ that comes bundled within the ‘Serviceguard for Linux Contributed Toolkit Suite’. The Linux Apache toolkit has to be installed on all the nodes of the cluster that have been configured to run the apache web server package. Before you install this version of the toolkit, you must remove previous versions from your system. To remove the previous version, complete the following procedure: 1. Enter the following command to check the version of the toolkit: #rpm –qa | grep apache The previous versions of the toolkit, if any, are listed in the output. 2. Enter the following command to remove the previous version of the toolkit: #rpm –e apache-<release_version>.product.redhat.noarch.rpm To ensure that the toolkit has been removed from all the configured nodes of the cluster, the ‘rpm – qa’ command can be executed again as mentioned above on all the nodes configured to run the Apache Web Server package. After the previous versions of the toolkit have been removed, one can proceed with the installation of the Linux Apache toolkit. Upgradation of the Linux Apache toolkit without removing its previous version or a forceful installation of the toolkit is not recommended. To install the Apache Web server complete the following: On Red Hat systems: #rpm –i apache-toolkit-<release_version>.product.redhat.noarch.rpm
  • 6. This command installs the Apache toolkit. By default, the Apache toolkit directory is created in the following location: #/usr/local/cmcluster/apachetoolkit On SUSE Linux Enterprise Server: Change to your rpm package directory and enter the following command: #rpm –i apache-toolkit-<release_version>.product.suse.noarch.rpm This command installs the Apache toolkit. By default, the Apache toolkit directory is created in the following location opt/cmcluster/apachetoolkit In order to verify the Linux Apache toolkit installation, you can either run the ‘rpm –qa | grep apache’ command or you can ensure the presence of all the toolkit scripts in the toolkit installation directory /usr/local/cmcluster/apachetoolkit . CONFIGURING APACHE WEB SERVER PACKAGES IN AN SG/LINUX ENVIRONMENT After installing the Apache Web Server, you need to configure the packages. Apache Web Server is a multi-instance application. This implies that multiple instances of the Apache Web Server can run on the same node simultaneously. This multi-instance feature of this package ensures that the package is always up and running. For example, if two nodes are each running an instance of Apache and one node fails, the Apache instance on the failed node can fail over to the healthy node. In addition, the healthy node can continue to run its own instance of the Apache Server. You can configure multiple instances of Apache using either the local or shared storage configuration or a combination of both. The subsequent sections explain how to configure Apache Web Server as a single instance package and as a multiple instance package using the High Availability Apache Toolkit. These sections also describe how to configure the Apache package in maintenance mode. Configuring a Single Instance For easy comprehension, the following naming conventions have been used in this section: • A Serviceguard Apache packages is referred to as APACHE1. The corresponding service name is referred to as apache1_service. • The Apache instance listens to a relocatable IP address of 15.70.191.6. It assumed that you have already configured the Serviceguard cluster, including details such as configuring the cluster name and the node names, determining the heartbeat IP address and so on. The following node names are used in this section: • photon3 • photon4 For more information on configuring a Serviceguard cluster, refer the Managing HP Serviceguard for Linux user guide. To configure a volume, you can select one of the following methods: Local Configuration With this method, you configure volumes on the local file system. The server root directory and the document root directory are maintained in the local file system. Shared Configuration:
  • 7. In this method, the server root directory and the document root directory are maintained on a volume group that is shared among nodes of the cluster. Following is a sample procedure that indicates the steps that you must complete to configure an Apache instance that uses shared storage for all Apache instance data. It is assumed that you will configure all Apache instance files on a shared file system /mnt/vgtry1/apache directory, which resides on a logical volume lvol from a shared volume group /dev/vgtry1. 1. Create a Volume Group vgtry1 on shared storage. 2. Create a Logic Volume lvol in vgtry1. 3. Create a filesystem on the above created logical volume lvol. 4. Create a directory /mnt/vgtry1/apache on local disk. 5. Mount device /dev/vgtry1/lvol to the /mnt/vgtry1/apache 6. Copy all files from the server root to /mnt/vgtry1/apache. In a SUSE Linux environment, use the -c option to preserve security contexts. The steps for configuring a local volume group remain the same except that for the shared storage configuration, you need to execute these steps on a shared storage device. In case of a local storage configuration, you must execute these steps on a local storage device. Note: The default server root directory is located at the following location: Red Hat: /etc/httpd SLES: /etc/apache2 Complete the following procedure to configure a single instance: 1. To create the apache package directory. Before starting the package configuration, you must create a directory (for example /usr/local/cmcluster/pkg/apache1) for this Apache package to run. This directory must belong to a single Apache package. To create an Apache Package directory, complete the following steps: a. Copy all Apache toolkit scripts from /usr/local/cmcluster/apachetoolkit to /usr/local/cmcluster/pkg/apache1. Example: # mkdir /usr/local/cmcluster/pkg/apache1 # cd /usr/local/cmcluster/pkg/apache1 # cp /usr/local/cmcluster/apachetoolkit/* . b. To create the package configuration file (pkg.conf) and package control script (pkg.cntl), you must be in the package directory. Example: #cd /usr/local/cmcluster/pkg/apache1 c. To create the package configuration file and the package control script, enter the following commands: To create the package configuration file: #cmmakepkg -p pkg.conf To create the package control script: #cmmakepkg -s pkg.cntl After you have completed these steps, the package directory consists of the following files: README The Readme file hahttp.conf User defined variables hahttp.sh The main shell script hahttp.mon Script that monitors the health of the server application
  • 8. toolkit.sh Script that acts as an Interface between the package control script and main script (hahttp.sh) pkg.conf The package configuration file pkg.cntl The package control script 2. Edit the package configuration file. Enter the following command to open the package configuration file: #vi /usr/local/cmcluster/pkg/apache1/pkg.conf You can edit the following variables in the package configuration file. PACKAGE_NAME APACHE1 PACKAGE_TYPE FAILOVER FAILOVER_POLICY CONFIGURED_NODE FAILBACK_POLICY MANUAL NODE_NAME photon3 NODE_NAME photon4 AUTO_RUN YES NODE_FAIL_FAST_ENABLED NO The package configuration file contains variables that characterize the package. The package name and the service name mentioned must be unique. Initialize the RUN_SCRIPT and the HALT_SCRIPT in the package control script. You can edit these variables based the requirement of your environment. RUN_SCRIPT /usr/local/cmcluster/pkg/apache1/pkg.cntl RUN_SCRIPT_TIMEOUT NO_TIMEOUT HALT_SCRIPT /usr/local/cmcluster/pkg/apache1/pkg.cntl HALT_SCRIPT_TIMEOUT NO_TIMEOUT PRIORITY NO_PRIORITY SUCCESSOR_HALT_TIMEOUT 0 SERVICE_NAME apache1_service SERVICE_FAIL_FAST_ENABLED NO SERVICE_HALT_TIMEOUT 300 3. Edit the package control script. Edit the package control script (pkg.cntl) to customize it to the environment. IMPORTANT: HP recommends that you configure the server root directory and the document root directory on a shared storage. In these examples, the volume group, /dev/vgtry1 is used as the server root directory and the document root directory. a. Mount the logical volume lvol on vgtry1 under the mount point /mnt/vgtry1/apache. Use an IP address that is not being used by any other application. In this example, 15.70.191.6.You can edit the following variables in the package control script. GFS="NO" DATA_REP="none" RAIDSTART="raidstart -c ${RAIDTAB}" RAIDSTOP="raidstop -c ${RAIDTAB}" VGCHANGE="vgchange -a y" VG[0]="/dev/vgtry1" LV[0]="/dev/vgtry1/lvol"; FS[0]="/mnt/vgtry1/apache"; FS_TYPE[0]="ext2"; FS_MOUNT_OPT[0]="-o rw"
  • 9. FS_UMOUNT_OPT[0]=""; FS_FSCK_OPT[0]="" FS_UMOUNT_COUNT=1 FS_MOUNT_RETRY_COUNT=0 CONCURRENT_FSCK_OPERATIONS=1 CONCURRENT_MOUNT_AND_UMOUNT_OPERATIONS=1 IP[0]="15.70.191.6" SUBNET[0]="15.70.191.0" SERVICE_NAME[0]="apache1_service" SERVICE_CMD[0]="/usr/local/cmcluster/pkg/apache1/toolkit.sh monitor" SERVICE_RESTART[0]="" b. Add the following line to the customer_defined_run_cmds function of the control script to start the Apache package: function customer_defined_run_cmds { /usr/local/cmcluster/pkg/apache1/toolkit.sh start test_return 51 c. Add the following line to the customer_defined_halt_cmds function of the control script to halt the package: function customer_defined_halt_cmds { /usr/local/cmcluster/pkg/apache1/toolkit.sh stop test_return 52 } NOTE: You must select a package IP address that is not used by any other application. Serviceguard cannot start a package if the IP address corresponding to the package is already in use. 4. Edit the Apache toolkit configuration file. Edit the apache toolkit configuration file, hahttp.conf. In this example, we have considered /mnt/vgtry1/apache as the server root directory. It is also assumed that the pid file is placed in the package directory. Edit the hahttp.conf file. a. Set the path for httpd.conf file which is the apache configuration file For example: HTTPD_CONFIG_FILE="/mnt/vgtry1/apache/httpd.conf" In the Red Hat environment, set the directive ServerRoot and DocumentRoot directive in the hahttp.conf file, b. This variable holds the Process ID file path of the Apache server instance. PID_FILE="/usr/local/cmcluster/pkg/apache1/httpd_s1.pid" c Select one of the following options based on your requirement. For example, on the basis of which criterion you want the package to fail over, such as the absence of the Parent process only, or any one of the processes or all the processes. ( FAIL_CRITERIA="Parent_Process_Only" FAIL_CRITERIA="Each_Process" FAIL_CRITERIA="All_Processes" ) FAIL_CRITERIA="Parent_Process_Only"
  • 10. d Set the maintenance flag depending on whether you configure the package in the maintenance mode or not. If the maintenance flag is set, the package enters the maintenance mode when the file apache.debug is present in the package directory. MAINTENANCE_FLAG="no" e Set the rest of the parameters based on the requirement of your environment. MONITOR_INTERVAL=5 RETRY_TIMES=2 5. Edit the Listen parameter. • On a Red Hat system: This parameter is specified in httpd.conf file available in the server root directory. Listen <port_number> • In SLES: Edit the Listen parameter in the corresponding listen.conf file Listen <port_number> The port number specified should not be in use by any other application 6. Edit other Apache configuration files. a. Edit other parameters if required in the httpd.conf file present in the server root directory. b. Update all the Apache configuration files and change the Apache instance configurations to suit your requirement. c. Provide the required values for server root directory and the document directory. If the environment is Red Hat, the configuration files are present in the /mnt/vgtry1/apache/conf directory. If the environment is SLES, the configuration files are present in the /mnt/vgtry1/apache directory. 7. Copy the package directory to all other package nodes. You must copy the package directory to the other nodes. For example: Copy to the parent directory of the package directory and enter the following command: #rcp -r –p /usr/local/cmcluster/pkg/apache1 photon4:$PWD/ 8. Applying the package configuration file. Enter the following command to apply the package configuration: #cmapplyconf -P pkg.conf Enter the following command to view the package details: #cmviewcl If the AUTORUN parameter has disabled as the value, you must change it to enable. Enter the following command to enable the AUTORUN parameter: For example: #cmmodpkg –e APACHE1 If switching is disabled for any node, enable it using the cmmodpkg command as follows: For example: #cmmodpkg –e –n <node_name> APACHE1
  • 11. Once the package starts, it starts an Apache server instance comprising of the Apache daemon, httpd, which spawns a number of sub-processes to handle numerous http requests. It also launches the Apache monitor script. Configuring Multiple Instances This section describes how to integrate multiple Apache Web Server instances using the High Availability Apache Web Server toolkit. Before integrating the instances, you must first create an instance of the Apache server. For more information on creating a single Apache instance, see Configuring a Single Instance. After you create an instance of the Apache server, you must create another instance using the following procedure. All instances of the Apache server must be configured in the same way. Following are the naming conventions that are used in this procedure: • The Serviceguard Apache package is named as APACHE2. The corresponding service name is apache2_service. • The Apache package is assumed to be listening to a relocatable IP address 15.70.191.7. Ensure that this IP address is not used by any other application. 1. Create a volume group. You must configure volume group(s) for each Apache instance. This procedure describes how to create a volume groups that is applicable for a shared configuration as well as a local configuration. a. Create another volume group. For example: vgtry2 b. Create a logical volume lvol in the volume group that you just created. c. Create a file system on this logical volume and mount it. For example: /mnt/vgtry2/apache. d. Copy all files from server root directory to /mnt/vgtry2/apache. 2. Create a package directory. Create another package directory, as described in Configuring a Single Instance. For example, for the second instance, consider /usr/local/cmcluster/pkg/apache2 as the package directory of the second apache instance. 3. Edit the package configuration script. Edit the package configuration file pkg.conf. You must specify the following parameters to integrate multiple instances of the Apache server. The remaining parameters in the file must be configured as per the instructions for configuring a single instance package. • Specify another name for this package. For example: APACHE2 • Specify another name for the corresponding server. For example: apache2_service. This service name must be unique. PACKAGE_NAME APACHE2 RUN_SCRIPT /usr/local/cmcluster/pkg/apache2/pkg.cntl HALT_SCRIPT /usr/local/cmcluster/pkg/apache2/pkg.cntl SERVICE_NAME apache2_service
  • 12. 4. Edit the package control script. You must specify the following parameters to integrate multiple instances of the Apache server. The remaining parameters in the file must be configured as per the instructions for configuring a single instance package. VG[0]="/dev/vgtry2" LV[0]="/dev/vgtry2/lvol"; FS[0]="/mnt/vgtry2/apache"; IP[0]="15.70.191.7" SUBNET[0]="15.70.191.0" SERVICE_NAME[0]="apache2_service" SERVICE_CMD[0]="/usr/local/cmcluster/pkg/apache2/toolkit.sh monitor" function customer_defined_run_cmds { /usr/local/cmcluster/pkg/apache2/toolkit.sh start test_return 51 } function customer_defined_halt_cmds { /usr/local/cmcluster/pkg/apache2/toolkit.sh stop test_return 52 } 5. Edit the Apache toolkit configuration file. Edit the apache toolkit configuration file hahttp.conf. You must specify the following parameters to integrate multiple instances of the Apache server. The remaining parameters in the file must be configured as per the instructions for configuring a single instance package. HTTPD_CONFIG_FILE="/mnt/vgtry2/apache/httpd.conf" Configure the PID_FILE parameter with the path for pid file for the corresponding instance. For example: PID_FILE="/usr/local/cmcluster/pkg/apache2/httpd_s1.pid" 6. Edit the listen parameter. Edit the listen parameter in the httpd.conf file if Red Hat and in the listen.conf file if SLES such that the specified port is not being listened to by any other application. Listen <port_number>. 7. Edit the other Apache configuration files. Edit the corresponding httpd.conf file and other Apache configuration files placed in the server root directory, based on the requirements of your environment. For more information on editing the configuration files, see Configuring a Single Instance. 8. Copy the package directory to all other package nodes. Copy the package directory to the other nodes in the cluster. For example. Change to the parent directory of the package directory and enter the following command: #rcp -r –p /usr/local/pkg/cmcluster/apache2 photon4:$PWD/ 9. Applying the package configuration file. Apply the package configuration on any node. For example, node photon3. Enter the following command to apply the configuration file: #cmapplyconf -P pkg.conf Enter the following command to view the package details: #cmviewcl
  • 13. If the AUTORUN parameter has disabled as the value, you must change it to enable. Run the following command to enable the AUTORUN parameter: For example: #cmmodpkg –e APACHE2 If switching is disabled for any node, enable it using the cmmodpkg command: For example: #cmmodpkg –e –n <node_name> APACHE2 On completing this procedure, you would have created multiple Apache packages for multiple Apache instances that will be running on the cluster. Maintenance Mode In any environment, you may need to bring down the systems for maintenance. Similarly, there may be situations where you need to bring down the Apache Web Server for maintenance. For example, you might have to change configuration information without migrating the instance from one node to another node. Following is the naming convention in this procedure: • Package name is APACHE1 • Package directory is /usr/local/cmcluster/pkg/apache1 To bring down the Apache Web Server for maintenance, complete the following steps. NOTE: The maintenance mode feature is enabled only when the configuration variable MAINTENANCE_FLAG is set to yes in the apache toolkit configuration file /usr/local/cmcluster/pkg/apache1/hahttp.conf. 1. Enter the following command to disable the failover of the package: #cmmodpkg -d APACHE1 2. Pause the monitor script and create an empty file, /usr/local/cmcluster/pkg/apache1/apache.debug, as shown below: #touch /usr/local/cmcluster/pkg/apache1/apache.debug The toolkit monitor script which continuously monitors the Apache daemons will now stop monitoring these daemons. The following message is logged in the package control script: Apache toolkit pausing monitoring and entering maintenance mode If required, enter the following command to stop the Apache application: #/usr/local/cmcluster/pkg/apache1/toolkit.sh stop 3. Perform the maintenance actions. For example, you can change the configuration of the Apache instance, or make changes to the toolkit configuration file, hahttp.conf to start the Apache web server application in secure mode. If you make changes to this file, you must distribute the new file to all the nodes in the cluster. 4. Start the apache instance again if you stopped it by using the following command: #/usr/local/cmcluster/pkg/apache1/toolkit.sh start
  • 14. 5. Enter the following command to start the monitoring process: # rm -f /usr/local/cmcluster/pkg/apache1/apache.debug The following message is recorded in the Serviceguard package control script log: Starting Apache toolkit monitoring again after maintenance. 6. Enter the following command to enable package failover: #cmmodpkg -e APACHE1 NOTE: If the package fails during maintenance, the package does not automatically failover to an adoptive node. You need to manually start the package on the adoptive node. For more information on manually starting package on an adoptive node, see Managing HP Serviceguard. SECURITY POLICIES IN LINUX SELinux and AppArmor are security tools that are delivered with Red Hat and SLES, respectively. One of the functions of these tools is to protect some applications based on security policies. These policies define default access control for the applications. If there is any change to the application configuration, for example, change in binaries or file locations, then appropriate access controls must be redefined in the security policy for that application. NOTE: The following sections are applicable only when security policies have been enforced on applications using either SELinux or AppArmor. SELinux SELinux (Security-Enhanced Linux) is an implementation of mandatory access control in the Linux kernel, using the Linux Security Modules (LSM) framework. SELinux is turned on by default in Red Hat. All the Apache files and directories are protected by SELinux security policy. All of these files must be associated with a security context defined for Apache. SELinux protection allows Apache processes to access only those files with the context defined in the security policy for Apache. The default policies of SELinux are defined so that the default directories of Apache have the right contexts. If any changes are made, such as moving the DocumentRoot or ServerRoot of Apache from local to a non-default location, ensure that these new directories and all files in the directory have the same security context as the default installation. Configuring the context is mandatory if anything other than the default file locations is used. Note: All the files accessed by Apache processes must have the right context as defined in the security policy. For more information on configuring SELinux with Apache, see the Red Hat documentation website. For Example: To place the Web pages in directories other than Apache defaults, user 'root' creates a new directory /home/www/site1 in which the pages for a new Web site are located. A default security context ‘root:object_r:user_home_t' is assigned to the new directory and its files. Use ls -Z command as follows to find the context assigned. # mkdir /home/www/site1 # ls -Z /home/www/ drwxr-xr-x root root root:object_r:user_home_t site1 # touch /home/www/site1/index.html # ls -Z /home/www/site1/index.html -rw-r--r-- root root root:object_r:user_home_t /home/www/site1/index.html
  • 15. Access to the newly created directory or file is denied to Apache as the default Apache's security policy does not allow access to the file with the above set security context user_home_t. To make these new directories and files accessible to Apache processes, modify the security context of the directory /home/www/site1 to Apache's default security context using chcon utility, as shown below. The following example defines the steps to change the context for the Document Root. Similar method has to be adopted to set context to other directories or files of Apache. 1. Determine the default security context of the Document Root, /var/www/html as follows: #ls -aZ /var/www/html drwxr-xr-x root root system_u:object_r:httpd_sys_content_t . drwxr-xr-x root root system_u:object_r:httpd_sys_content_t . 2. Change the security context of /home/www/site1 and its subdirectories and files to the same security context of the default, using the chcon utility as follows: #chcon -R ssystem_u:object_r:httpd_sys_content_t /home/www/site1 You must set the right security context for all directories and files accessed by the Apache processes. When you copy Apache files from the default location to any other shared location, you must use the cp –c to preserve the security context. In this case, you need not change the security context for the files, because these files inherit the security context from the source. Note: You must set the appropriate security contexts for a package to be up and running. You must the right contexts related to SELinux to bring up the package successfully. View the SELinux audit log, /var/log/messages, and ensure that there are no avc denial messages. These denial messages are sometimes triggered by changes in the application. To fix these messages, you may have to change the security policy apache.te, located at its default location. For more information on security related topics while setting up the package, see the Red Hat documentation website. AppArmor Novell AppArmor is an access control system that enables you to specify per program, which files the program may read, write, and execute. AppArmor achieves mandatory access control by assigning a profile per application, that is, a security policy that completely defines what system resources an application can access, and with what privileges. Novell AppArmor is an integral part of SLES10. AppArmor profiles are human-readable text files that mediate access to files and directories as well as determine what POSIX capabilities an application is allowed to have. Profiles are traditionally stored in files in /etc/apparmor.d/ under filenames with the convention of replacing the / in pathnames with (except for the root /) so profiles are easier to manage (for example the /usr/sbin/httpd2-prefork profile would be named usr.sbin.httpd2-prefork). For more information on using profiles, see the Novell documentation site. AppArmor profile for Apache is shipped with the SLES. By default, the AppArmor profile for Apache has permissions for accessing only the default file locations of Apache. If any change is made, such as moving the DocumentRoot or ServerRoot of Apache from local to a non-default location, then Apache AppArmor profile needs to be updated with permissions for accessing these new directories and all of the files in the directory. For Example: To place the ServerRoot directory on a shared file system /shared/apache_1, copy all the files from /etc/apache2/* to /shared/apache_1.
  • 16. Access to the shared directory and files is denied to Apache because the default Apache's AppArmor profile does not allow access to these files. To grant access to the shared directory, complete the following steps: 1. To make the shared directory and files accessible by Apache, edit the Apache’s AppArmor profile (/etc/apparmor.d/usr.sbin.httpd2-prefork) by adding entries to grant access to the shared directory and files. For this, use a text editor or the YaST interface (Edit AppArmor Profile). For example, to grant read access to all the configuration files in the shared directory (/shared/apache_1) to Apache, add the following line to the file /etc/apparmor.d/usr.sbin.httpd2-prefork. /shared/apache_1/*.conf r 2. Add such entries for all other directories or files that will be accessed by Apache. 3. Reload the profile into the kernel by entering the following command: apparmor_parser -r usr.sbin.httpd2-prefork 4. Run the Apache package. If the package fails to start, then check AppArmor audit log for REJECT messages to Apache. If there are any, then use the method specified above to update the profile. You can also use the update wizards-YaST (Update Profiles Wizard) or logprof For more information on updating profiles using YAST or logprof, see the Novell documentation site. CONCLUSION By setting up the Apache Web Server and integrating it with the Serviceguard for Linux environment using the High Availability Apache toolkit, you can avail many benefits, such as reduction in application integration effort and ease of deployment of the Apache Web Server. In addition, maintenance and upgrading of the Apache Web Server becomes simpler. You can also choose among various criterions for the Apache Server to fail over. Note: Unless otherwise stated, the High Availability Apache toolkit runs on all distributions and hardware supported by Serviceguard for Linux. © 2007 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. Itanium is a trademark or registered trademark of Intel Corporation or its subsidiaries in the United States and other countries. August 2007