|< Day Day Up >|
10.1 Software Installation and Configuration
The various components of an ACID installation each have their own dependencies on other components. It is important that the components on which they depend are installed first. The instructions below are written in a specific order with this in mind. Here's summary of dependencies for the components:
The Linux distribution used in this chapter for both the management console and sensor is the latest Red Hat Linux. These instructions should work for both Red Hat Enterprise and Fedora Core. Nuances particular to these distributions are explained in greater depth. This does not mean the same explanations cannot also be used on other Linux distributions.
The installation mechanism or package management system on some operating systems may allow you to simply install the latest version of ACID, taking care of all the dependencies automatically. This is an attractive alternative for quick deployments or inexperienced users. FreeBSD, Suse Linux, Debian GNU/Linux, and Gentoo Linux are all examples of operating systems with robust package management systems. From a performance and troubleshooting standpoint, it is usually better to install things from source. The choice is yours—ease of use versus performance.
10.1.1 MySQL Installation and Configuration
The first step is to configure MySQL correctly. To facilitate ease of installation, my recommendation for new users is to use the MySQL release that comes with the Linux distribution CDs. However, you may prefer compiling from source or using the latest binaries. The following instructions are geared toward a Red Hat Linux RPM install, although an explanation for installing MySQL entirely from source also follows. You can download the RPMs, source, or binaries from the MySQL homepage (http://www.mysql.com/).
10.1.1.1 MySQL RPM install
To install MySQL using the RPMs distributed with Red Hat Linux, execute the following rpm command within the directory containing the RPMs. You may want to do this during the initial Linux installation phase; if you do it later, you will have to mount the distribution CD and then change to the directory in which the RPMs are located:
# mount /dev/cdrom /mnt/cdrom # cd /mnt/cdrom/RedHat/RPMS/ # rpm -ivh mysql-*
This command installs three packages: mysql, mysql-devel, and mysql-server. Once the packages are installed, start the MySQL daemon using the start command. Log in and configure the root password for the database server. Also, create the Snort database for later use with the intrusion detection system.
# /sbin/service mysqld start # mysql -u root mysql> set password for \ 'root'@'localhost'=password('your_password_goes_here'); mysql> create database snort; mysql> exit
Some systems may generate the following error:
Can't connect to local MySQL server through socket '/tmp/mysql.sock'
This error message occurs when the database looks for a MySQL socket in the /tmp directory when it really is in /var/lib/mysql/. Execute the following commands to rectify this error:
# cd /tmp/ # ln -s /var/lib/mysql/mysql.sock mysql.sock # cd /var/lib/mysql # touch mysql.sock
Check the permission and path on the /tmp/mysql.sock to verify it is symbolically linked to the main MySQL file using the ls -la command.
In Red Hat Linux, the mysqld service does not automatically start if you boot into run level 3 or the console run level. Enable this service in run level 3 by using the chkconfig command or the serviceconf command within a GUI environment. Here is how you enable the mysqld service in run level 3 using chkconfig.
# /sbin/chkconfig --level 3 mysqld on
You'll be prompted for a root password upon login in order to access the database files. Enter the new password at the prompt.
# mysql -u root -p
10.1.1.2 Performing a MySQL source install
If you are compiling from source, start by uninstalling any precompiled (RPM) versions of Apache, MySQL, and PHP. Execute the following commands if you are certain you wish to run everything from source code you've compiled yourself. Verify which versions of MySQL and Apache are installed.
# rpm -e mysql mysql-server mysql-devel
Remove the installed Apache and PHP versions.
# rpm -e httpd httpd-devel php
If there are any complaints of broken dependencies, remove them as well.
Place the downloaded MySQL source code in a standard location and uncompress the file.
# gunzip -c mysql-4.0.xx.tar.gz | tar xvf -
Next, create a mysql user and group. Most Linux distributions create a group with the same name as that of the user at the same time the user is created. Users of FreeBSD and Solaris should create the group in addition to the user.
# useradd mysql
Add an entry to your /root/.bash_profile file that points to the location of the MySQL binaries and default directory. You may also add this to the /etc/profile file so that it applies to all users. Add a line such as the following:
Change to the uncompressed MySQL directory and run the following commands as root:
# cd /mysql-4.0.xx/ # ./configure --prefix=/usr/local/mysql # make # make install
This compilation process may take some time, depending on the speed of your machine and the size of the latest source release. When the process is complete, run the following script also found in the scripts/ directory within the MySQL source. This creates the default tables and provides additional information on securing and starting the MySQL server. Take careful note of the information displayed. I suggest copying the text to a file for later reference.
Change the permissions on some of the newly created directories and copy over the configuration file to a standard location.
# chown -R root /usr/local/mysql # chown -R mysql /usr/local/mysql/var # chgrp -R mysql /usr/local/mysql # cp support-files/my-medium.cnf/ etc/my.cnf
This setup permits the basic MySQL daemon to run, but you need also make Linux aware of the new libraries. Add the following lines to the /etc/ld.so.conf file.
Run the /sbin/ldconfig script after the file has been changed.
You should be ready to start up the MySQL server. Start the daemon using the example provided:
# /usr/local/mysql/bin/mysqld_safe --user=mysql &
After executing this command, verify that the daemon is running by using the following command, which "greps" out the MySQL process using the ps command. You should see at least one running MySQL process.
# ps -ef | grep mysql
Place the previous startup command in the /etc/rc.d/rc.local file to automate startup of the daemon process upon bootup. Or, do as recommended by the MySQL authors and use their script in place of an addition to the rc.local file. Here is how they suggest automating the MySQL daemon:
# cp /usr/local/src/mysql-4.0.xx/support-files/mysql.server /etc/init.d/mysql # cd /etc/rc3.d/ # ln -s ../init.d/mysql S85mysql # ln -s ../init.d/mysql K85mysql # cd /etc/rc5.d/ # ln -s ../init.d/mysql S85mysql # ln -s ../init.d/mysql K85mysql # cd ../init.d/ # chmod 755 mysql
MySQL should be fully functional. We will now create our tables and configure the web server with PHP.
10.1.1.3 Adding tables and permissions
This section explains how to add the required tables the snort database created in Section 10.1.1. Use the script create_mysql to add the required tables. The latest version of this script is available within the Snort source code in the contrib/ directory. There is also a version of ACID and several other third-party applications and scripts useful for adding functionality to Snort and ACID.
To install this script, place a call to it from the mysql prompt. Remember that you created a Snort database on your MySQL server. If you neglected to perform this step or simply forgot, here is the command once more, along with the call to the create_mysql script using the full path.
# mysql -u root -p mysql> create database snort; mysql> connect snort; mysql> source /usr/local/src/snort-2.1.x/contrib/create_mysql;
After connecting to the database and adding the tables from the included script, grant the correct permissions to the users connecting to the database.
The default administrative user is "snort". When logging in as the Snort user, you have root privileges and may delete any and all data or alerts within the database. Use caution when issuing any commands as "snort" or "admin" or whatever user you decide should have administrative rights.
Some Snort users also recommend installing the file snortdb-extra.gz found in the contrib/ directory. Install this file the same way you would the create_mysql script. Or, if you are feeling adventurous, here is another method that works well:
# zcat /usr/local/src/snort-2.1.x/contrib/snortdb-extra.gz | mysql -p snort Enter password:
A prompt for the Snort user password appears. It may take some time to extract all the information, but when complete, the data helps to make items on the ACID website more readable.
Here are the commands to use the create_mysql script and grant rights to your primary user:
# mysql -u root -p mysql> connect snort; mysql> source create_mysql; mysql> grant CREATE,INSERT,SELECT,DELETE,UPDATE on snort.* to snort; mysql> grant CREATE,INSERT,SELECT,DELETE,UPDATE on snort.* to snort@localhost; mysql> grant CREATE,INSERT,SELECT,DELETE,UPDATE on snort.* to \email@example.com;
Replace the variable "www.mydomain.com" with the Fully Qualified Domain Name (FQDN) of your system. If you later change the name of your machine, you should also update this final variable.
This next step creates a user login that cannot delete alerts from the Snort database, but may only view the database and associated alerts. This user is named "acidviewer" since they may view the ACID web page, but cannot make any changes. This is the suggested login for management, nontechnical users, and others who should not be allowed to remove important alerts before you can review their severity.
mysql> grant CREATE,INSERT,SELECT,UPDATE on snort.* to acidviewer; mysql> grant CREATE,INSERT,SELECT,UPDATE on snort.* to acidviewer@localhost; mysql> grant CREATE,INSERT,SELECT,UPDATE on snort.* to firstname.lastname@example.org;
Set the passwords for the MySQL accounts. You can allow users to connect from as broad or narrow a set of hosts as you prefer. The percentage symbol (%) operates as a wildcard and allows the snort and avidviewer users to connect from virtually any host. Customize the options to limit the locations from where they can connect.
mysql> connect mysql; mysql> set password for 'snort'@'localhost'=password('your_password'); mysql> set password for 'snort'@'www.mydomain.com'=password('your_password'); mysql> set password for 'snort'@'%'=password('your_password'); mysql> set password for 'acidviewer'@'localhost'=password('your_other_password'); mysql> set password for 'acidviewer'@'www.mydomain.com'=password('your_other_ password'); mysql> set password for 'acidviewer'@'%'=password('your_other_password'); mysql> flush privileges; mysql> exit
The MySQL command stating the machine's full name is optional. If you only use the first two options and do not set the FQDN of the system, the SnortCenter configuration may fail when you try to run it, or you may have problems connecting to the MySQL database. Even though the % wildcard should handle this situation, I like to make certain all options work for my particular machine.
Once you have set all the variables, verify who has what permissions. Connect to the mysql database and issue the following command:
# mysql -u root -p mysql> connect mysql; mysql> select user,host from user;
You should have a full table displaying all database users and listing who has access to which database. The formatting may be a bit off, so make your terminal window full screen in order to display as much as possible.
mysql> select user,host from user; +------------+------------------+ | user | host | +------------+------------------+ | acidviewer | % | | snort | % | | | localhost | | acidviewer | localhost | | root | localhost | | snort | localhost | | | www.mydomain.com | | acidviewer | www.mydomain.com | | root | www.mydomain.com | | snort | www.mydomain.com | +------------+------------------+ 10 rows in set (0.01 sec)
According to the previous table, MySQL has blank user accounts. This means anyone can log into the database server. To eliminate this security hole, do the following:
mysql> delete from user where user=""; Query OK, 2 rows affected (0.09 sec) mysql> delete from db where user=""; Query OK, 2 rows affected (0.00 sec) mysql> select user,host from user;
You should now see only the following lines when the same command is executed (the empty accounts have been removed):
mysql> select user,host from user; +------------+------------------+ | user | host | +------------+------------------+ | acidviewer | % | | snort | % | | acidviewer | localhost | | root | localhost | | snort | localhost | | acidviewer | www.mydomain.com | | root | www.mydomain.com | | snort | www.mydomain.com | +------------+------------------+ 8 rows in set (0.00 sec)
This is yet another small security measure to ensure the safety of the network management console machine.
10.1.1.4 Cleaning house or reinstalling
If you later decide that you either want to perform a clean update or start your databases anew, it is easiest to drop the databases you created. To drop all the databases, perform the following:
# mysql -u root -p mysql> show databases; +-------------+ | Database | +-------------+ | mysql | | snort | | snortcenter | | test | +-------------+ 4 rows in set (0.00 sec) mysql> drop database snort; mysql> drop database snortcenter; mysql> exit
This should be done only if you are willing to delete all the information gathered from your network. Once you drop a database, the stored entries are gone. Create the databases again and start over. When updating to a new release of Snort, you may need to create a new database into which you plug the new data.
10.1.2 Installing the Web Server
This section provides a basic rundown on configuring the Apache HTTP server. It is by no means intended to be a comprehensive set of instructions for setting up Apache. Consult a more complete reference guide for additional instructions on customizing this or other web servers.
There are a several methods of installing and configuring Apache. The first is to use the existing Apache RPMs included with your Linux distribution or download the latest RPMs from your Linux distributor or another trusted RPM source. Red Hat Fedora currently ships with the Apache 2.0.x RPMs.
There are two versions of Apache available for production use. I cover only Version 2.0.x using both RPMs and source code. Some people may prefer older, tried and tested Apache releases compiled from source, but it is best to update to the most recent release.
10.1.3 Installing Apache2
Because Apache release 1.3.x will eventually be deprecated and no longer supported by the Apache group, familiarize yourself with the latest Apache2 release. Check the Apache web page (http://www.apache.org) for the most recent code and documentation. This section is intended for Linux users using the default Apache RPMs rather than compiling recent Apache versions from source. Most Linux distributions are releasing Apache Version 2 as well.
10.1.3.1 Installing from RPMs
If you have not already done so during the initial Linux configuration, download the RPMs or install them from the distribution CDs. The latest Apache RPMs for Red Hat Linux can be found at the following location:
Change to the correct directory to reflect your Linux release. There are only a few packages needed for the Apache web server. Here is an example Apache install using RPMs. This example also shows how to verify that the Apache web daemon starts upon bootup. Replace any version numbers that may differ here with the correct ones.
# rpm -ivh httpd-2.0.xx.i386.rpm # rpm -ivh mod_ssl-2.*.i386.rpm # rpm -ivh php*.i386.rpm # chkconfig --level 2345 httpd on # /etc/rc.d/init.d/httpd start
Check that your web server is running by bringing up a web browser either on the local box or on a networked machine and connecting to the default Apache web page. Use any of these variables for connecting to the web server: the machine's fully qualified domain name, its IP address, or localhost if attaching locally.
10.1.3.2 Compiling the latest Apache code from source
Although compiling the latest release of Apache code from source appears more tedious and time-consuming than RPMs, you may soon discover that compiling source code is perhaps one of the most rewarding aspects of Linux and open source applications in general. It not only allows you more flexibility with related applications, but there is something satisfying about creating custom binaries. Besides, it is more secure to access the code first-hand and create your own binaries using source downloaded from a trusted location. It would also be a good idea to verify PGP signatures or MD5 checksums for the downloaded source, to ensure integrity.
A precursor to compiling Apache may be to install OpenSSL from source, particularly if you are going to enable the SSL module. Here are the steps to compile OpenSSL.
# gunzip -c openssl-0.9.6g.tar.gz | tar xvf - # cd openssl-0.9.6g/ # ./config # make # make test # make install
Once all necessary required libraries are installed, place the latest Apache source code in a standard directory. Uncompress the file and change to the new directory. Use the following commands for configuring and compiling the source. In this instance, we use /usr/local/httpd as the default directory. This is the Apache root directory for Version 2.0.x. Only the prefix name and the so module require enabling in the example provided. I have added additional modules should users wish to enable these as well.
# gunzip -c httpd-2.0.xx.tar.gz | tar xvf - # cd httpd-2.0.xx/ # ./configure --prefix=/usr/local/httpd \ --enable-so --enable-cgi --enable-info --enable-rewrite \ --enable-speling --enable-usertrack --enable-deflate \ --enable-mime-magic # make # make install
When this is complete, change to the uncompressed PHP source code located in the same directory. Run the following commands to configure it for integration with Apache2.
# cd ../php-4.3.x/ # ./configure --prefix=/usr/local/httpd/php \ --with-apxs2=/usr/local/httpd/bin/apxs \ --with-config-file-path=/usr/local/httpd/php \ --with-mysql --enable-track-vars \ --enable-force-cgi-redirect --with-zlib \ --with-gettext --with-gdbm --with-gd # make # make install # cp -p .libs/libphp4.so /usr/local/httpd/modules/ # cp php.ini-dist /usr/local/httpd/php/php.ini
Edit the httpd.conf file located in /usr/local/httpd/conf/ and enable the newly installed PHP modules. The following lines are added to the httpd.conf file. These entries may already be present, depending on your installation.
# Make sure there's only **1** line with this directive: LoadModule php4_module modules/libphp4.so # Add index.php to your DirectoryIndex line: DirectoryIndex index.html index.php AddType application/x-httpd-php php
Finally, automate the startup of the new Apache web daemon. This is done in one of two ways: by adding the following lines to /etc/rc.d/rc.local or using the script that comes with the source. Here are the lines to add to the rc.local file.
# Start the Apache web daemon /usr/local/httpd/bin/apachectl start
Follow these steps for integrating the included script into the startup run command directories.
# cd /usr/local/httpd/bin/ # cp apachectl /etc/init.d/httpd # cd /etc/rc3.d/ # ln -s ../init.d/httpd S85httpd # ln -s ../init.d/httpd K85httpd # cd /etc/rc5.d/ # ln -s ../init.d/httpd S85httpd # ln -s ../init.d/httpd K85httpd
10.1.3.3 Testing Apache and PHP
Test the new Apache install to verify PHP has been successfully integrated. Create a file in /usr/local/httpd/htdocs/ called test.php. Place the following line of code in the file:
Finally, start up the new Apache daemon in one of the following ways. You can do this:
# /etc/rc5.d/S85httpd start Starting httpd: [ OK ]
or execute the daemon from the command line using the full path:
# /usr/local/httpd/bin/apachectl start
The web server should now be running. Additional security and optimization items are addressed later in this chapter.
10.1.3.4 Managing dependencies
There are some required applications for both Apache releases. One file that you may consider downloading and installing from source rather than depending on the RPM version is zlib. This file is optimized by PHP. This portion is entirely optional; however, if you want to specify your own binaries rather than use existing ones, download and compile any additional programs.
# wget http://www.zlib.net/zlib-1.2.1.tar.gz # gunzip -c zlib-1.2.1.tar.gz | tar xvf - # cd zlib-1.2.1/ # ./configure ; make test # make install
Again, this application is entirely optional, but if you are relying wholly on source code rather than RPMs, consider installing this and any other application from source.
10.1.3.5 Running a secure web site
Because you do not want to allow others to sniff HTTPD packets or surreptitiously gain entry to your site, enable SSL for web browsing on the IDS box in addition to password-protecting the web page.
If you are creating an IDS machine for another company as part of a consulting project or if others outside your company are reviewing the data, purchase a secure certificate from a Certificate Authority (CA) such as Thawte or Verisign. A security certificate ensures that pages viewed by visitors are secure and encrypted and that the certificate was signed and validated by an outside authority. CAs charge fees ranging anywhere from $150 to $1,000 for a valid certificate. Make certain this is what you want or is required before using an outside authority. Otherwise, use one of the free CAs on the Internet or sign your own certificate. Be certain you can trust a free CA. Otherwise, you will be getting exactly what you pay for—nothing.
The next few steps explain how to create a test certificate for internal use. Remove the fake key and certificate generated during the default Apache RPM installation in the following manner:
# cd /etc/httpd/conf # rm ssl.key/server.key # rm ssl.crt/server.crt
# make genkey
Your system displays a message similar to the following:
umask 77 ; \ /usr/bin/openssl genrsa -des3 1024 > /etc/httpd/conf/ssl.key/server.key Generating RSA private key, 1024 bit long modulus ........++++++ ...........++++++ e is 65537 (0x10001) Enter pass phrase:
The PEM phrase is a password or key phrase that unlocks the secure certificate. Type a secure password where a PEM phrase is required. Choose one that is not used anywhere else and that is associated only with launching the https daemon. For best security, your password should contain at least eight characters, include numbers, special characters and/or punctuation, and not be a dictionary word. Remember that with Linux all passwords are case-sensitive.
Create your own test certificate. You can call it whatever you like, but for the purposes of example, I am calling the certificate testcert.
# make testcert
The following output appears in your terminal window as you are also prompted for the password:
umask 77 ; \ /usr/bin/openssl req -new -key /etc/httpd/conf/ssl.key/server.key \ -x509 -days 365 -out /etc/httpd/conf/ssl.crt/server.crt Enter pass phrase for /etc/httpd/conf/ssl.key/server.key:
After entering the password, you are prompted for additional information. Provide the correct information for your organization and host. You should also take note of the variables entered here in case you wish to re-issue the certificate. You'll see something similar to the following is typical output:
You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [GB]:US State or Province Name (full name) [Berkshire]:Wisconsin Locality Name (eg, city) [Newbury]:Mount Horeb Organization Name (eg, company) [My Company Ltd]:The Xentinel Group Organizational Unit Name (eg, section) :IDS Security Common Name (eg, your name or your server's hostname) :test.xentinel.net Email Address :email@example.com
After you have provided the information pertinent to your site, a self-signed certificate is created and placed in /etc/httpd/conf/ssl.crt/server.crt. Edit the httpd.conf file located in the /etc/httpd/conf directory if you are using the Apache RPMs or in the /usr/local/httpd/conf directory if you are using the configuration file generated from the source code. You need only make a minor editorial change in order for the connection to be on port 443, the secure port, rather than the common HTTP port 80.
Place a pound (#) mark before the Listen 80 variable to comment this feature out. This variable defines port 80 as the default port. The configuration file now uses port 443 as its secure port rather than port 80. Restart the Apache web server. Ensure that any firewalls between the clients and the web server are configured to allow TCP port 443.
# service httpd restart
Before the daemon launches, you will be prompted for the PEM password mentioned earlier. The prompt looks something like this:
Starting httpd: Apache/2.0.40 mod_ssl/2.0.40 (Pass Phrase Dialog) Some of your private key files are encrypted for security reasons. In order to read them you have to provide us with the pass phrases. Server new.host.name:443 (RSA) Enter pass phrase: Ok: Pass Phrase Dialog successful. [ OK ]
If you need to restart the computer or if it is rebooted, you must also restart the httpd service using the previous command. The only way to browse your SnortCenter/ACID console is via https://www.mydomain.com.
When logging into the system the first time, the web server displays a warning message saying it cannot certify the authenticity of this server or that the web site is certified by an unknown authority. Figure 10-1 shows a sample message displayed when connecting to a test server, specto.ksl.com.
Figure 10-1. Warning message regarding unknown Certificate Authority
You can choose to accept this certificate permanently or only for a limited time.
Some people may wish to automate the startup of the secure web server. This is possible, although not recommended. If you want the secure server to start automatically upon bootup, either leave the pass phrase portion empty or automate the pass phrase entry with a custom script. The latter option is also not recommended—it may open up more security holes than the secure server is intended to close. If all else fails, start up the secure server manually or use the standard web server.
Finally, test this web daemon for PHP integration. Create a test.php file in the htdocs/ or web root directory. Access this page and confirm that it works as specified. After confirming that PHP is installed and that Apache recognizes it correctly, delete the test file.
10.1.4 Final Apache Configurations
It is imperative that your Apache installation be as secure as possible. Your IDS is only as safe as your weakest or least-secure program. Modify the following options within your httpd.conf file to improve performance and shore up security holes in your web server.
I prefer having the logfiles be a combination of the access, agent, and referer information. Customize your httpd.conf settings as follows:
#CustomLog /usr/local/httpd/logs/access_log common CustomLog /usr/local/httpd/logs/access_log combined
I also prefer divulging as little information as possible about my server to others. By turning the ServerSignature setting to Off, you avoid telling others what Apache version you are currently running.
This feature is only applicable to web directories that contain static files or lack index files. Your Apache version number does not appear below the shown files.
If the web server also has static files that you wish to display in an empty root directory without an index.html file, use the following option to display the full file name. Apache normally truncates files—so the entire filename, including the suffix at the end, is not always visible. This option in the httpd.conf file corrects that feature.
IndexOptions FancyIndexing NameWidth=*
Apache has the FancyIndexing option on by default, so simply add the NameWidth option to the appropriate line of your httpd.conf file. Restart the Apache web daemon by issuing a /usr/local/httpd/bin/apachectl restart command. All static files in a given directory should now be fully visible. This option is useful if you are using your management console as a repository for other open source software or if you are making the latest source code available for other systems or sensors.
There are other tools that query your web daemon and determine the type and version number. The site http://grc.com/id/idserve.htm provides a small, Windows-based tool that shows not only your Apache web version, but your PHP version and any other compiled-in features. The latest nmap can also determine the Apache release running on your system.
One final safety precaution is to create a default user without a home directory that owns all Apache web processes. The users nobody and httpd are popular names used by the system when the root httpd process forks into child processes. Rather than entrust my security to the default options, I prefer creating a generic user with very limited permissions to own the forked httpd processes. Substitute the default entries with webuser as both the default User and Group in the httpd.conf file. Be sure not to set a password for this user—no one other than root should have access.
Create a generic user without a home directory in the following manner:
# useradd -M webuser
Change the User and Group variables in the httpd.conf file to reflect the new default user. Restart your web server using the following command:
# /usr/local/httpd/bin/apachectl restart
Besides the restart command, you can also use the graceful and configtest options. graceful sends a SIGUSR1 to the running process or starts the daemon if it is not already running. configtest performs a configuration syntax test.
Whatever command you decide to use should be automated, so that upon reboot or startup, the web daemon always launches. Place this command in the /etc/rc.d/rc.local file:
# Start up the Apache web daemon /usr/local/httpd/bin/apachectl start
Verify that all is running as it should by using the ps command.
# ps -ef | grep http root 17675 1 0 13:14 ? 00:00:00 /usr/local/httpd/bin/httpd webuser 17676 17675 0 13:14 ? 00:00:00 /usr/local/httpd/bin/httpd webuser 17677 17675 0 13:14 ? 00:00:00 /usr/local/httpd/bin/httpd webuser 17678 17675 0 13:14 ? 00:00:00 /usr/local/httpd/bin/httpd webuser 17679 17675 0 13:14 ? 00:00:00 /usr/local/httpd/bin/httpd webuser 17680 17675 0 13:14 ? 00:00:00 /usr/local/httpd/bin/httpd root 17682 3648 0 13:14 pts/2 00:00:00 grep http
Verify that your web daemon can now manage PHP files. Make a test file in your ~htdocs/ directory called test.php. Place some sample PHP tags in this file. I suggest using the single tag <?phpinfo( )?> as a test. When accessing this page from a browser, you should see information relating to your Apache daemon and PHP version. If everything appears and works like it should, delete this test file and then move on to the next section. The Apache web site has extensive documentation on getting Apache configured and running. If you have any trouble, it's a good place to look for help.
|< Day Day Up >|