Your SlideShare is downloading. ×
INSTALLING AND CONFIGURING APACHE TOOLKIT FOR SERVICEGUARD ...
INSTALLING AND CONFIGURING APACHE TOOLKIT FOR SERVICEGUARD ...
INSTALLING AND CONFIGURING APACHE TOOLKIT FOR SERVICEGUARD ...
INSTALLING AND CONFIGURING APACHE TOOLKIT FOR SERVICEGUARD ...
INSTALLING AND CONFIGURING APACHE TOOLKIT FOR SERVICEGUARD ...
INSTALLING AND CONFIGURING APACHE TOOLKIT FOR SERVICEGUARD ...
INSTALLING AND CONFIGURING APACHE TOOLKIT FOR SERVICEGUARD ...
INSTALLING AND CONFIGURING APACHE TOOLKIT FOR SERVICEGUARD ...
INSTALLING AND CONFIGURING APACHE TOOLKIT FOR SERVICEGUARD ...
INSTALLING AND CONFIGURING APACHE TOOLKIT FOR SERVICEGUARD ...
INSTALLING AND CONFIGURING APACHE TOOLKIT FOR SERVICEGUARD ...
INSTALLING AND CONFIGURING APACHE TOOLKIT FOR SERVICEGUARD ...
INSTALLING AND CONFIGURING APACHE TOOLKIT FOR SERVICEGUARD ...
INSTALLING AND CONFIGURING APACHE TOOLKIT FOR SERVICEGUARD ...
INSTALLING AND CONFIGURING APACHE TOOLKIT FOR SERVICEGUARD ...
INSTALLING AND CONFIGURING APACHE TOOLKIT FOR SERVICEGUARD ...
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

INSTALLING AND CONFIGURING APACHE TOOLKIT FOR SERVICEGUARD ...

745

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
745
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
22
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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

×