Софт

Apache web server

Рейтинг: 4.8/5.0 (580 проголосовавших)

Категория: Windows: Web серверы

Описание

Несколько сайтов на одном веб-сервере

Первая версия статьи опубликована в журнале "Системный администратор" №12, 2005г. (samag.ru )

Установив, веб-сервер Apache и предоставив через него на всеобщее обозрение свой сайт, некоторые и не подозревают, каким мощным инструментом они владеют. С его помощью можно управлять сотнями сайтов с разными именами и уровнями доступа. Денежная стоимость и временные затраты на добавление каждого сайта минимальны.

Веб-сервер Apache, популярный благодаря своей прозрачности для программистов и администраторов и не в последнюю очередь благодаря бесплатности, реализован под все более-менее популярные операционные системы. Его настройки для всех ОС одинаковы, различаются только пути, где хранятся конфигурационные файлы. На одном сервере может быть запущено несколько экземпляров Apache, прослушивающих разные адреса и/или порты. Один экземпляр может обслуживать несколько сайтов (подробнее об этом ниже). Проект настолько популярен, что постоянно обрастает новой функциональностью. О степени популярности можно судить либо по статистике, что, на мой взгляд, довольно опрометчиво, либо по конкретным фактам. Фактов популярности Apache мы приведём два. Во-первых, его наличие в качестве веб-сервера по умолчанию в большинстве UNIX-подобных операционных систем. Во-вторых, такой гигант в области ИТ как компания Oracle приняла его в состав своего продукта Oracle Application Server 10g, где он играет одну из ключевых ролей.

3) Адрес сервера в локальной сети: 192.168.100.18

4) Несколько сайтов.

5) Несколько имён для одного сайта

1) Разместить все сайты на одном сервере

2) Сделать доступ к каждому сайту по отдельному URL

3) Ограничить доступ к некоторым сайтам

4) Сделать перенаправление нескольких имён на один сайт

Пойдём от простого к сложному. Для начала рассмотрим случай, когда у нас два сайта и два имени teo.mynetwork.ru и logos.mynetwork.ru. Эти имена должны быть доступны, т.е. держатель зоны mynetwork.ru должен прописать в ней узлы teo и logos

- Для каждого сайта создаём каталог в корневом каталоге документов Apache (teo и logos, соответственно). Для Linux это по умолчанию /var/www/html. но чтобы убедиться, где он расположен на нашем сервере, смотрим значение директивы DocumentRoot в /etc/httpd/conf/httpd.conf. Итак, создаём:

# mkdir /var/www/html/teo /var/www/html/logos

- Мы будем разделять журналы для каждого сайта, поэтому создадим соответствующие каталоги:

# mkdir /var/log/httpd/teo /var/log/httpd/logos

- Если у нас уже был создан сайт, то всё его содержимое переносим в созданный для него каталог, т.е. из /var/www/html в /var/www/html/teo. Новый сайт logos.mynetwork.ru размещаем в /var/www/html/logos .

Теперь настраиваем Apache. Добавляем в конец файла /etc/httpd/conf/httpd.conf :

NameVirtualHost 10.0.10.15

<VirtualHost teo.mynetwork.ru>

DocumentRoot /var/www/html/teo

ServerName teo.mynetwork.ru

ErrorLog /var/log/httpd/teo/error_log

CustomLog /var/log/httpd/teo/access_log combined

</VirtualHost>

<VirtualHost logos.mynetwork.ru>

DocumentRoot /var/www/html/logos

ServerName logos.mynetwork.ru

ErrorLog /var/log/httpd/logos/error_log

CustomLog /var/log/httpd/logos/access_log combined

</VirtualHost>

Все настройки не заданные для сайта явным образом в директиве VirtualHost, наследуются от глобальных настроек Apache, указанных выше в этом же файле.

- Перезапускаем Apache:

# /etc/init.d/httpd restart

- Теперь, обращаясь по DNS именам, мы будем получать разные сайты. Если обратиться по IP адресу, то получим сайт teo.mynetwork.ru, т.к. он подключен первым.

Создаём ссылки с нескольких DNS адресов на один сайт

Это можно осуществить двумя способами: созданием синонимов, или перенаправлением всех обращений с другого сайта.

1) Синонимы задаются директивой ServerAlias, могут содержать маску, и разделяются пробелом. Вот несколько примеров создания синонимов:

ServerAlias www.teo.mynetwork.ru

ServerAlias *.teo.mynetwork.ru

ServerAlias www.teo.mynetwork.ru god.mynetwork.ru pantheon.ru

Синоним - это DNS-имя. Имена могут быть абсолютно любыми, в том числе и из разных доменов, но все они должны разрешаться в IP-адреса, то есть их предварительно нужно зарегистрировать в DNS.

2) Перенаправление задаётся директивой Redirect. Создаём новый пустой сайт pantheon.ru. Как и для предыдущих сайтов, это делается в три шага: создание каталога для документов, для журналов и добавление конфигурации в httpd.conf :

<VirtualHost pantheon.ru>

DocumentRoot /var/www/html/pantheon

ServerName pantheon.ru

ErrorLog /var/log/httpd/pantheon/error_log

CustomLog /var/log/httpd/pantheon/access_log combined

Redirect / http://teo.mynetwork.ru

</VirtualHost>

Можно перенаправлять не со всего сайта, а только с определённого каталога или даже документа:

Redirect /samag http://samag.ru

Redirect /ftp/ ftp://citkit.ru/pub/

Redirect /find/ya.htm http://yandex.ru

При этом Apache воспринимает первый параметр директивы Redirect не как URL, а как набор символов, при совпадении с которым происходит перенаправление. Отсюда следует, что он НЕ проверяет наличие указанных каталогов и файлов, а ссылки /samag и /samag/ НЕ считает одинаковыми.

Ограничиваем доступ к сайтам

Теперь, если пользователь обратится к нам по IP-адресу, либо по имени, на которые наш сервер откликается (см. Приложение ), то Apache сначала определяет, не удовлетворяет ли запрос описанным директивами VirtualHost сайтам и если не находит ни один из них, то выдаёт сайт по умолчанию, который находится в каталоге, заданном глобальной директивой DocumentRoot, т.е. уровнем выше остальных. Таким образом, получается, что пользователь может попасть на любой из виртуальных сайтов не тем путём, какой мы для него приготовили, т.е. http://logos.mynetwork.ru/. Например, набрав в адресной строке браузера «http://192.168.100.18/logos/», он получит сайт logos.mynetwork.ru. Правда в этом случае документы, использующие ссылки на ресурсы этого же сайта, будут некорректно отображаться, потому что ссылки делаются относительно корня сайта и, если это была ссылка /img/picture.jpg, то во втором случае этот же файл уже нужно искать по ссылке /logos/img/picture.jpg, этого же браузер не знает. Таким образом, здесь все зависит от того, догадывается ли пользователь, в каких каталогах мы храним наши сайты. В принципе, в этом нет ничего плохого, ведь мы в любом случае выложили сайты, чтобы их посещали (правила по ограничению доступа к ресурсу всё равно будут действовать, о них мы поговорим чуть позже), но как-то это выглядит не красиво (для того и двери, чтоб в окна не лазить). Чтобы устранить эту некрасивость можно поместить сайт по умолчанию на тот же уровень, что и остальные сайты, т.е. создать каталог /var/www/html/default и указать его в двух директивах глобальных настроек (т.е. до описания виртуальных сайтов)

DocumentRoot "/var/www/html/default"

# This should be changed to whatever you set DocumentRoot to.

<Directory "/var/www/html/default">

Теперь перейдём непосредственно к раздаче прав доступа. Существует два способа указания прав доступа к каталогу веб-сайта средствами Apache:

1) поместить в каталог файл .htaccess,

2) использовать директиву <Directory> в файле конфигурации.

В обоих случаях правила распространяются и на вложенные каталоги.

1) Перечислим преимущества использования файла .htaccess :

а) при его изменении не нужно перезапускать Apache;

б) при одинаковом уровне доступа к разным ресурсам можно пользоваться ссылками на один файл .htaccess ;

в) можно предоставить пользователю право редактирования этого файла, что удобно, если у нас сервер с множеством клиентских сайтов.

Есть и недостатки:

а) для того, чтобы ответить на вопрос: «какие ограничения доступа существуют на сайте?» - администратору необходимо помнить, в каких каталогах лежат эти файлы и ссылки;

б) если сайт будет переноситься на другой сервер, и, что очень вероятно, будет размещён в другом каталоге, то для корректировки ссылок уйдёт много времени;

в) повышается нагрузка сервера, т.к. при каждом запросе на ресурс он обращается к .htaccess в этом каталоге и всех верхних по иерархии, наследуя их настройки т.е. запрос на ресурс http://teo.mynetwork.ru/olimp/staff/zeus.htm

инициирует проверку .htaccess файлов в каталогах

/olimp/staff/

2) Определяя настройки доступа к каталогам сайта с помощью директивы <Directory> в одном конфигурационном файле всего сайта, мы получим следующие преимущества:

а) можно быть уверенным, что ничего не пропустим, если вдруг нужно изменить уровень доступа к какому-нибудь ресурсу;

б) повышаем скорость реакции сервера на запросы, т.к. все настройки загружаются при старте Apache.

Ну а мириться придётся с тем, что для каждого каталога необходимо описывать права отдельно (помним, что для подкаталогов права наследуются), даже если они одинаковые. Правда, есть поддержка масок, например:

<Directory

"^/www/.*/[0-9]<3>">

будет соответствовать именам каталогов в /www/ состоящим из трёх цифр, но это не всегда может облегчить ситуацию.

Мы рассмотрим оба способа и изменим права доступа к двум каталогам сайта logos.

1) Предоставим права с помощью файлов .htaccess. нужно создать соответственно файл /var/www/html/logos/info1/.htaccess :

Options +Indexes

Order deny,allow

Allow from 192.168.100.11

Allow from 192.168.100.17

и файл /var/www/html/logos/info2/.htaccess :

AuthType Basic

AuthName "Boss"

AuthUserFile "/var/www/main_users"

Require valid-user

2) Описываем те же права в главном конфигурационном файле Apache httpd.conf или в файле настройки виртуального хоста:

<Directory /var/www/html/logos/info2>

AuthType Basic

AuthName "Boss"

AuthUserFile "/var/www/main_users"

Require valid-user

</Directory>

</VirtualHost>

Оба варианта настройки равноправны и создают следующие ограничения:

Доступ к ресурсу http://logos.mynetwork.ru/info1/ смогут получить только два пользователя из локальной сети с указанными IP адресами (хотя такие ресурсы лучше хранить на внутренних веб-серверах), ещё мы дали разрешение Apache, в случае отсутствия в каталоге начальной страницы, генерировать html документ с содержимым каталога.

Для доступа к ресурсу http://logos.mynetwork.ru/info2/ будут запрошены имя пользователя и пароль, которые будут сверены с данными в файле /var/www/main_users. Создадим этот файл:

# touch /var/www/main_users

# chown root.webmaster /var/www/main_users

Добавим в него пользователя chef:

# /usr/bin/htpasswd2 /var/www/main_users chef

Остальных пользователей добавляем аналогичным способом. Такие файлы создаём для каждой группы пользователей с одинаковыми правами доступа к ресурсу. Одни и те же группы можно использовать во всех сайтах.

Для удаления пользователя chef из списка, используем комманду:

# /usr/bin/htpasswd2 -D /var/www/main_users chef

- Если возникли проблемы, то смотрим в логах /var/log/apache2/error_log. Можно их сделать более детальными указав в /etc/httpd/conf/httpd.conf или в конфигурации определённого виртуального хоста:

LogLevel debug

Последние штрихи.

В заключении можно для изящности выделить настройку каждого сайта в отдельный файл, и подключить их в httpd.conf :

Include /etc/httpd/conf/vhosts/teo.conf

Include /etc/httpd/conf/vhosts/logos.conf

Include /etc/httpd/conf/vhosts/pantheon.conf

Кроме изящности мы получаем удобство в быстром подключении и отключении сайта, путём добавления/снятия символа комментария “#” в начале строки. Это особенно актуально, когда настройка каждого сайта раздувается на несколько десятков строк.

Также нелишне будет настроить ротацию журналов с помощью logrotate.

Приложение. Особенности директив Listen и NameVirtualHost

Директива Listen имеет больший приоритет чем, NameVirtualHost. Она говорит, откуда принимать запросы. В то время как последняя определяет, как обрабатывать полученный запрос. Это значит, что если указано значение

то Apache будет прослушивать порт 80 на всех IP адресах и директива

NameVirtualHost 10.0.10.15

не ограничивает запросы, пришедшие на другие адреса, и они будут обрабатываться наравне с указанным адресом, а если указано значение

Listen 10.0.10.15:80

NameVirtualHost 192.168.100.18

не возымеет действия, и сайт будет не доступен из локальной сети.

Некоторые рецепты

> Я использую на своём сайте форум на основе phpBB3, который написан в кодировке utf-8. Но отображается он постоянно не в той кодировке - приходится постоянно менять вид.

Значит на сервере использутся другая кодировка. Пропишите в .htaccess строку:

CharsetDisable on

> Выложил подготовленный и протестированный на Денвере сайт на Joomla! и выяснил что не работает авторизация с фронтэнда (с административной страницы работает). В журнале обнаружил ошибку:

[Tue Dec 16 02:09:11 2008] [error] PHP Warning: cannot yet handle MBCS in html_entity_decode()! in /home/resht/www/site2/public_html/modules/mod_customFooter/helper.php on line 39

Необходимо подключить php версии 5. Поместите следующие строки в файл .htaccess:

AddType php5-script .php

Action php5-script /cgi-php/php5

> У клиента в Internet Explorer ссылки на файлы MS Excel 2007 открываются как zip-архивы в архиваторе, вместо того чтоб отрывать их непостредственно в Excel

Файлы *.xlsx по сути и есть архивы. Но чтобы вразумить браузер, достаточно добавить описание этого MIME типа в конфигурацию Apache. Обычно это делают в отдельном файле, например /etc/httpd2/conf/mime.types. Добавим/отредактируем строку:

application/vnd.ms-excel xls xlm xla xlc xlt xlw xlsx

http://httpd.apache.org/docs/2.0/vhosts/ - другая версия этой же документации для версии Apache 2.0. Отличия, на мой взгляд, коснулись только формы самой документации.

Apache web server:

  • скачать
  • скачать
  • Другие статьи, обзоры программ, новости

    Apache Web Server

    Apache Web Server

    Итак, перед Вами по тем или иным причинам встала задача сделать WEB-сервер. Скорее всего, начальству надоело Ваше ежедневное сидение в Internet, и оно решило, что раз уж платит за пользование сетью, то из этого надо попытаться извлечь прибыль. Или Вы просто решили прославиться во всемирной сети, заработать кучу денег, купить последнюю модель Mersedes. так или иначе - но WEB-сервер делать надо.

    Первое, о чем надо позаботиться ( после того, как решены вопросы с арендой каналов у провайдера, закупки и установки операционной системы на компьютер, который будет использоваться в качестве WEB-сервера ), это о самой программе WEB-сервера. То есть той самой программе, которая будет принимать запросы у WEB-броузеров Ваших клиентов и отсылать им с любовью подготовленные Вами WEB-странички, картинки, открытки, рекламки, значки и все, что Вам подскажет фантазия.

    Как всегда в мире Открытых Систем перед Вами две альтернативы. купить WEB-сервер или использовать свободно-распространяемую прогамму аналогичной функциональности. Перввый путь в данной статье не рассматривается ( возможно, Ваше начальство еще не созрело до того, что программы надо покупать. может, Вы сами еще не заработали денег для покупки подобной программы, да и автор пока не имел дело с покупными системами ), поэтому рассморим второй путь.

    На сегодняшний день автору известны как минимум три подобнх WEB-сервера. CERN. NCSA и Apache. Однако на сегодняшний день сервер CERN морально устарел и не развивается, про NCSA ходят подобные слухи - поэтому для рассмотрения в данной статье выбран сервер Apache. базирующийся на ранней версии NCSA и по настойке и функциональным возможностям сильно схож с ним.

    Еще одна проблема для создателя русскоязычного WEB-сайта - проблема русской кодировки. На сегодняшний день их как-минимум четыре. Koi-8. CP-1251. ibm866 и iso8859-5. Можно, конечно, весь сервер хранить в кои - и точка. Однако, на взгляд автора, это неуважение к пользователям программы Windows. Наоборот, сервер, видный только в CP-1251 будет недоступен пользователям открытых систем. И именно Apache поможет Вам в решении этой проблемы.

    Инициативная группа под руководством Дмитрия Крюкова взяла одну из ранних версий Apache. и пользуясь возможностью включения в код сервера внешних модулей, начала разработку так называемого RussianApache. позволяющего разработчику WEB-сайта не заботиться о кодировках, а сосредоточиться на разработке содержимого сайта, переложив заботу о кодировках на Вас ( как на администратора WEB-сервера ). И, отмечю, RussianApache Вам в этом очень сильно поможет. Где взять?

    Итак, Вам нужен WEB-сервер, причем именно RussianApache. Самый простой способ его достать - открыть любой WEB-броузер или воспользовавшись программой ftp зайти по адресу ftp://apache.lexa.ru/pub/apache-rus и взять последнюю версию WEB-сервера ( на момент написания статьи это 1.2.5rusPL21.4. файл ' apache_1.2.5rusPL21.4.tar.gz ' ).

    Далее необходимо определиться, в какой директории будет находиться програмное обеспечение сервера. Группа разработчиков Apache считает, что это будет /usr/local/etc/httpd. автор предпочитает /usr/httpd ( чтобы далеко не лазить ). Оба этих решения абсолютно идентичны с точки зрения функционирования Apache. поэтому, чтобы не заострять на этом внимания, опишем переменную окружения

    www% setenv HTTP_HOME /usr/httpd

    и в дельнейшем будем пользоваться этой переменной для именования файлов Apache.

    Теперь нужно собрать Apache. У вас в $ лежит файл apache_1.2.4rusPL21.3.tar.gz. представляющий собой последнюю версию сервера. Перейдем в директорию /tmp и дадим комманду.

    www% gzip -c -d $/apache_1.2.5rusPL21.4.tar.gz | tar xvf -

    Если у Вас в системе все настоено правильно, то у Вы увидете кучу файлов, которые развернутся в директории apache_1.2.5rusPL21.4.

    Зайдите в директорию apache_1.2.5rusPL21.4/src и отредактируйте файл httpd.h. найдите в нем строчку

    #define HTTPD_ROOT "/usr/local/etc/httpd"

    и замените этот путь, где будет стоять Ваш Apache ( например, /usr/httpd ).

    После этого необходимо применить стандартную процедуру сборки свободно-распростаняемых программ. Для этого в текущей директории ( apache_1.2.5rusPL21.4/src ) дайте последовательность команд.

    www% ./Configure

    Если Вы все проделали правильно, то по экрану побегут радующие глаз сообщения об успешной компиляции - а Вы пока можете пойти сделать себе кофе. Процесс может длиться от 5 до 30 минут, поэтому не стоит переутомлять свои глаза глядением в монитор за строчками, которые вряд-ли дадут Вам какую-нибудь полезную информацию.

    В результате вышеописанных действий у Вас должен получиться исполняемый файл, называющийся httpd. Это и есть Apache. который Вы так долго собирали. Но расслабляться рано - Apache. как и всякая нетривиальная программа ( а тривиальной программой можно считать программу, вычисляющую 2 плюс 2 ) для своей работы требует настройки.

    Но, прежде чем приступать к настройке, скопируем Apache в его рабочую директорию.

    www% cp httpd $

    www% cp -r LICENSE README conf htdocs icons support $. Настройка.

    Итак, вспомним, что же у нас есть на настоящий момент.
    1. Определенная переменная окружения HTTP_HOME ;
    2. файл $/httpd. представляющий собой собранный Apache ;
    3. директория $/conf/. в которй будут лежать файлы конфигурации;
    этого набора достаточно для успешной работы Apache. Создайте еще директорию $/logs для лог-файлов Apache - и в путь. Первый файл, который нужен для работы Apache - $/conf/httpd.conf. В поставку входит пример такого файла ( $/conf/httpd.conf-dist ), но для того, чтобы хорошо научиться настраивать Apache. мы создадим его сами.

    Итак, создайте этот файл и загрузите его в любой редактор ( автор использует textedit. но Вы можете воспользоваться любым другим, включая vi ). Первое, что нужно определить, это режим работы Apache.

    Издавна повелось, что многие UNIX-севисы запускались специальным демоном, который называют суперсервером Internet ( inetd ). Это демон слушал порты соответствующих сервисов, и при запросе определнного типа сервиса ( например, telnet или ftp ) запускал програму-демона, определенную для этого сервиса. Сделано это было в те времена, когда памяти в компьютерах было мало - и чтобы не держать в памяти множество сложных демонов, сеть слушал достаточно простой inetd.

    Apache тоже является одним из сервисов Internet, и, в принцпе, может пускаться под управлением inetd. Однако такой механизм работы не рекомендуется для использования даже разработчиками Apache. Причина в том, что при старте Apache должен прочитать несколько конфигурационных файлов - что сказывается не лучшим образом на его производительности. Кроме того, время необходимо и на запуск программы.

    Итак, первой строчкой нашего файла httpd.conf будет строка, задающая режим его функционирования.

    ServerType standalone

    Далее нужно задать порт, на котором Apache будет слушать запросы. По-умолчанию, это порт 80. и при стандартном обращении к Вашему серверу программа Netscape использует этот порт. Поэтому следующая наша строчка имеет вид.

    Считается, что все стандартные сервисы UNIX имеют номера портов меньшие 1024. Поэтому порты с номерами меньшими 1024 называют привилегированными портами. и открывать их позволено только суперпользователю. Сделано это для того, чтобы программа злоумышленника не смогла замаскироваться под стандартный сервис. Поэтому, задав для Apache 80 -й порт, тем самым Вы обязали себя запускать его из-под суперпользоваетлся. Однако для нормального функционирования Apache вовсе не нужны привилегии суперпользвотеля. Более того, такой режим функционирования является достаточно опасным для системы, на которой работает Apache.

    Привилегии суперпользователя нужны Apache только при старте - чтобы открыть 80 -й порт - а далее он может функционировать под именем другого пользователя. Мы советуем Вам завести для него специального пользователя http. входящего в группу http и максимально уменьшить права этого пользователя в системе. В идеале, этот пользователь должен иметь доступ только к тем директориям, которые Вы хотите сделать видимыми через Ваш WEB-сервер. Создав пользователя, добавим в httpd.conf строчки.

    Group http

    обязав тем самым Apache работать от имени этого безправного пользователя.

    Далее надо задать имя сервера, на которое будет откликаться Вас сервер. Делается это директивой

    ServerName www.your-domain .ru

    Теперь необходимо задать расположение файлов, которые Вы хотите показывать на Вашем сервере. Apache имеет богатые возможности по конфигурированию ресурсов такого рода ( ибо основная задача Apache как HTTP-сервера - выдавать документы, то есть файлы, хранящиеся на Вашем диске ) - однако сейчас мы продположим, что все Ваши файлы собраны в одной директории и имеют иерархическую структуру. Apache нужно сказать, где расположена эта директория.

    DocumentRoot /usr/httpd/htdocs

    ( здесь предполагается, что все Ваши документы находятся в директории /usr/httpd/htdocs. Мы так-же рекомендуем задать имеено эту директорию, если у Вас еще нет никаких докуметов - в /usr/httpd/htdocs находится стандартное руководство в HTML-формате, поставляемое с дистрибутивом Apache ).

    В принципе, этого было бы достаточно, если бы не одна тонкость. Разработчики Apache. понимая, что при существующих порядка 150-ти директивах указание их в одном файле сделало бы его плохочитаемым, решили упростить жизнь пользователям. Они предполагают, использование 3-й файлов. httpd.conf ( общие директивы конфигурации сервера ), srm.conf ( конфигурация ресурсов сервера - информация о том, где расположены документы, как их обрабатывать и подобная информация ) и access.conf ( конфигурация доступа к серверу - пароли, права на определенные директории ) - однако при запуске Apache определяет только положение файла httpd.conf. По-умолчанию, это $/conf/httpd.conf. имеется возможность переопределение местоположения этого файла. А вот расположение остальных 2-х файлов Apache ищет в httpd.conf. Но так как в нашей конфигурации эти файлы не нужны ( мы всю работу Apache опишем в httpd.conf. то мы просто отключим остальные файлы.

    AccessConfig /dev/null

    ResourceConfig /dev/null

    Все, у нас получился работающий WEB-сервер. Запускаем ( в этом месте необходимо воспользоваться правами пользователя root.

    www# /usr/httpd/httpd

    У Вас получился работающий WEB-сервер. Можете запустить Netscape и набрать в нем адрес сервера http://www.your-domain .ru - и Вы увидете свои документы.

    Однако это, конечно, не все. Мы освоили тока простейшую настройку Apache. О подробном конфигурировании WEB-сервера Apache мы поговорим в следующей статье.

    Установка Apache http server

    Установка Apache http server

    В данной статье мы научимся устанавливать web-сервер на компьютер. В качестве web-сервера мы будем использовать Apache http server версии 2.2.25. На момент написания статьи уже доступна версия 2.4.9, но только в исходных кодах, т.е. если Вы умеете их компилировать, то вперед, эта статья не для Вашего уровня, тут мы обсудим базовые сведенья по установке, так сказать для чайников.

    Установку будем производить на Windows 7 64bit, но она ничем не будет отличаться и для других систем.

    Первым делом решаем ребус со скачиванием дистрибутива Apache.

    Для этого заходим на http://apache.org .  Переходим в верхнем меню в раздел Download. Листаем вниз до списка продуктов и выбираем Projects -> HTTP Server. Попадаем на страницу http://httpd.apache.org/.

    Тут мы видим блоки, в подзаголовках которых написаны названия версий. А в нижней части каждого блока есть ссылка Download.

    Открою секрет, все они ведут на одну и ту же страницу, соответственно, жмем на любую понравившуюся. На следующей странице с названием «Download - The Apache HTTP Server Project» мы опять видим блоки, каждый из которых отвечает за версию Apache. Внутри блока мы видим по нескольку ссылок на исходные коды в разных форматах и бинарные файлы.

    Жмем на ссылку Binaries, как на рисунке выше. Попадаем на зеркало, которое сайт apache.org посчитал наиболее близким к Вам.

    Тут Вы жмете на ссылку с названием Win32 и попадаем на страницу, на которой есть ссылки на установщики всех доступных версий и 2.0.65 и 2.2.25 (версии указаны на момент написания статьи).

    Выбираем самую последнюю и скачиваем дистрибутив. Дистрибутив поставляется в формате стандартного пакету установки от Microsoft – MSI.

    Далее нам надо стать администраторами на машине, на которую мы устанавливаем программу. Если Вы таковым не являетесь, то перелогиньтесь под учетной записью локального администратора, или позовите Вашего системного администратора на помощь.

    Запускаем установщик скаченный ранее.

    Нам говорят, что именно мы собираемся установить. Мы жмем NEXT.

    На следующей странице нам предлагают согласиться с лицензионным соглашением. Ставим переключаетель в «I accept the terms in the license agreement» и жмем NEXT.

    Нам говорят об авторах этой замечательной программы. Жмем NEXT.

    На этом этапе с нас попросят ввести данные о нашем сервере. Вводим localhost в первые два поля, а в третье вводи Ваш почтовый ящик. Переключатель выставляем в «For all users». Указанный почтовый ящик будет отображаться в браузере, когда пользователи запросят несуществующую страницу, так что если Вы боитесь за дальнейший поток спама, то укажите не существующий адрес.

    На следующем этапе оставляем «типичную» установку. И жмем NEXT.

    Далее нас спросят о каталоге для установки программы. Поскольку я лично за поряднок, то почти никогда не меняю пути установки программы, чего и вам советую. Исключение могут составить случаи, когды Вы не являетесь локальным админом на компьютере. Ведь в дальнейшем Вы сто процентов будите править конфигурационный файл apache сервера httpd.conf, а он будет лежать в каталоге программы, куда у Вас может не оказаться прав.

    После этого начнется установка. Если Вы локальный администратор компьютера, в системе отключен контроль учетных записей и не установлен антивирус, то все пройдет, как по маслу. В противном случае в процессе установки Вы будите получать от системы дополнительные вопросы. Сложность может возникнуть, если Ваш антивирус не настроен, чтобы задавать «разрешающие» вопросы, а просто молча без уведомлений, блокирует действия установщика. В этом случае постарайтесь просто отключить антивирус на время.

    Когда установка пройдет, то в трее (рядом с часами) появиться значек с красным перышком.

    Если под перышком зеленый треугольничек, это значит, чтоhttp сервер запущен и все хорошо. Щелкнув по перышку Вы откроете меню, в котором будут пункты для остановки http сервера, перезапуска и запуска. Ими надо будет пользоваться, если Вы изменяете конфигурационный файл сервера httpd.conf.

    Проверить правильность установки очень просто. Зайдите в браузер и наберите http://localhost/. Не забудьте набрать HTTP://, без него браузер, скорее всего, отправит Вас в посиковую систему искать в интернете сайт «localhost». Если все хорошо, то вы увидете в браузере контрольную страницу со словами «It works!».

    Теперь нам надо проверить, виден ли наш сервер на других компьютерах локальной сети. Для этого на другом компьютере откройте браузер и напишите в строке http://192.168.1.108/ где 192.168.1.108 – ip адрес компьютера, на который установлен Apache Http Server. Вместо IP можно указывать имя компьютера.

    Теперь немного о том, что где лежит:

    1. Конфигурационный файл httpd.conf лежит в каталоге установки программы в подкаталоге «conf». У меня полный путь к нему выглядит так C:\Program Files (x86)\Apache Software Foundation\Apache2.2\conf

    2. Ваш сайт лежит тоже в каталоге программы в подкаталоге htdocs. Соответственно у меня это C:\Program Files (x86)\Apache Software Foundation\Apache2.2\htdocs

    3. По умолчанию Apache настроен, искать в каталоге сайта файл index.html.

    4. Если создать в каталоге htdocs подпапку (например «1с-web»), и в неё поместить свой index.html, то этот документ будет доступен по адресу в браузере http://localhost/1c-web или http://192.168.1.108/1c-web

    На сегодня все, спасибо за внимание

    Apache Web Server Tutorial for Linux

    Apache Web Server Tutorial for Linux Introduction

    The Apache Web Server is one of the most popular open-source HTTP Servers that exists today. It's a powerful, secure, and fully featured web server that can be found hosting anything from personal web sites to corporate domains. If you have a DSL or Cable connection with a static IP then you can use the Apache web server to host your web site (as long as your ISP doesn't have a problem with you running a server on their network). This tutorial will teach you how to set up your own Apache web server on Linux so you can host your own web sites either at home or work. You'll learn how to install the Apache HTP Server with SSL and PHP support, use chkconfig to set Apache to auto-start on boot, edit the Apache httpd.conf configuration file for your server settings, create a directory structure for your web site, create the VirtualHost configuration file for your web site, start the Apache service, verify your site is working, go over the init script options, and finally show you some additional options and settings for Apache such as graceful restarts, htaccess usage, user name and password directory protection, and custom error pages. The two things I won't be covering are setting up DNS for your domain and configuring your firewall to open ports 80 and 443 for HTTP and SSL respectively, however you can read my Bind DNS tutorial and iptables firewall tutorial for information on how to do it. I'll be using CentOS 4.2 and Apache 2.x will be installed using yum instead of source. Let's get started.

    Installing Apache HTTP Web Server

    We'll be using yum to download and install the Apache RPM's from the CentOS repository. Apache shouldn't be loaded on your server unless you selected it during the operating system installation process. If you know you have Apache installed then you can skip this section, but if it's not or you're not sure then you should perform the following tests to see if the Apache web server is on your system. To do this we'll use the which command to look for the httpd binary in the environment variable PATH.

    If you see something similar to the above image then the Apache binary doesn't seem to be found on the server. Our next step is to install Apache by using yum. Issue the next command.

    yum install httpd

    Two RPM packages will be downloaded from the CentOS repository (httpd-2.0.52-22.ent.centos4.i386.rpm and httpd-suexec-2.0.52-22.ent.centos4.i386.rpm ) and installed automatically. If everything goes well you should now have the Apache web server on your system. You might also want to load the Apache documentation so you'll have the man pages available. This is optional but highly recommended. Use yum again and download the Apache manual (yum install httpd-manual ). Next we'll use yum to install mod_ssl for Secure Sockets Layer (SSL) support.

    Installing mod_ssl for Secure Sockets Layer (SSL) Support

    Secure Sockets Layer, also known as SSL for short, provides encrypted commnications between hosts. SSL can be found in e-commerce web sites and any other site that requires sensitive information being transmitted protected from eavesdropping. In a nutshell, the hosts negotiate a protocol they both can understand and then switch to secure communications. The data passed back and forth between the hosts is encrypted with a 128-bit key (hence 128-bit SSL). In a typical SSL setup, the web server has SSL support enabled and a certificate that verifies the company's identity. These certificates are initially generated as Certificate Signing Requests (CSR) by the server's administrator. The CSR is then signed by a third party, a Certificate Authority (CA), that validates the company's identity and makes the CSR into a full certificate. There are many CA's like VeriSign. Thawte. GeoTrust. InstantSSL (aka The Comodo Group), FreeSSL. and many others that sign CSR's. Prices vary from company to company, but as long as they support the mainstream browsers you shouldn't run into any problems. If you'd like to learn more about Secure Sockets Layer then you should check out the Wikipedia Transport Layer Security page.

    You may be wondering where does mod_ssl fits into all of this? On Linux and Unix distributions, there is a software package called OpenSSL that performs all the cryptography and mod_ssl is the Apache interface to OpenSSL. It's mod_ssl that makes it possible for Apache to have SSL capability. We'll now install the mod_ssl RPM (mod_ssl-2.0.52-22.ent.centos4.i386.rpm ) for Apache using yum.

    yum install mod_ssl

    mod_ssl should now be installed. If you didnt have OpenSSL installed then it should have been picked up as a dependency and was installed as well. We have one more package to install and that's the PHP scripting language .

    Installing PHP for Dynamic Web Pages

    PHP is a scripting language for creating dynamic web pages. PHP allows you to include code in your web pages to be processed server-side and the resulting HTML is sent to the user's web browser. With PHP you can add database access, read and write files to the server's filesystem, generate dynamic graphics like graphs and security image codes, and create security control mechanisms for fencing off parts of your web site. PHP has many other uses and that's what makes it a powerful tool for creating dynamic web pages.

    If you're not a programmer or will only he hosting a static HTML web pages, then PHP won't be of any use to you. However, if you want to learn PHP then you should install the PHP modules for Apache. We'll use yum one last time to install PHP on our server. There are many PHP RPM modules, one being the actually binary and modules for Apache and the rest are support features for MySQL, XML, ODBC, and others to tie those subsystems into PHP. It's a good idea to install all the PHP modules since you never know what you'll need now or in the future. Now we'll use yum to install PHP.

    yum install php*

    As you can see above, we used a wildcard to tell yum to install anything starting with the word 'php'. On my server yum downloaded and installed fifteen packages, however yours may be different depending on its configuration. Now that PHP is installed we can move on to setting the Apache service to automatically start on bootup or in the event of a reboot.

    Setting Apache to Start on Bootup with chkconfig

    The Apache web server will need to be set to autostart when the server boots. The Apache RPM didn't set this up for us so we'll have to do it ourselves using chkconfig (Note: you can also use setup to turn on the Apache service). We're going to have Apache start on run levels 2, 3, and 5.

    chkconfig --level 235 httpd on

    chkconfig --list httpd

    The second chkconfig command lists the run levels Apache is configured to start on. If you don't have X Windows installed then you may want to omit run level 5 (Multi-User Mode - boot up in X Windows). To learn more about Linux Run Levels you may want to check out this page on NetworkClue. Now that Apache is installed and set to start up we'll move on to configuring the Apache web server by editing httpd.conf, the Apache server configuration file.

    Configuring Apache Server Settings (httpd.conf)

    Apache's main configuration file is called httpd.conf and is located in /etc/httpd/conf/. The default httpd.conf will work without any changes, however we want to customize Apache a little bit. Our main focus is to setup the use of Virtual Hosts so we can run as many web sites as we want using a single IP address. Also, we want to simplify the management of our Virtual Hosts without cluttering httpd.conf with our entries. Before we get to any of that we will first configure our Apache web server.

    I will make the assumption that you have a single WAN based IP address. For this example I'm using 192.168.1.210 with a hostname of node2.centos (yes, it's a LAN IP but pretend it's WAN). You can use your IP or hostname from /etc/hosts, but I suggest using your hostname because if you ever change IP's all you have to do is update /etc/hosts with the new address. If you do use an IP then you'll have to change all instances of it in httpd.conf. If you don't know what your IP address is or never set up /etc/hosts, you can find your address by using ifconfig (look at the number to the right of 'inet addr:').

    We'll start with opening httpd.conf in the nano text editor, but before that you should make a copy of your existing httpd.conf file. If you encounter any problems you'll still have the original to fall back to.

    cd /etc/httpd/conf

    cp httpd.conf httpd.conf.old

    nano httpd.conf

    Apache's httpd.conf is filled with many helpful comments to tell you what each configuration directive does. Scroll down to line 133 as shown in the picture below. FYI, if you ever want to know what line number you're on in nano, press CTRL-C and nano will show you. We're looking for the line that says 'Listen 80'. We won't be changing this directive since we want Apache listen on all IP addresses set up on the server. I wanted to show you where to change it if you needed to bind Apache to only one address.

    Move on down to line number 235 where it says 'ServerAdmin root@localhost'. The Apache ServerAdmin directive is for the administrator's email address of the server. End users encountering any problems with the server would use this email address to notify the sysadmin. Comment out the existing ServerAdmin line with a pound symbol and enter a new line below with your email address. For this example I used admin@node2.centos.

    #ServerAdmin root@localhost

    ServerAdmin admin@your-domain.com

    Below the ServerAdmin directive is ServerName. The Apache ServerName directive is for Apache to identify itself which is typically the hostname of the server. You'll want to specify your hostname or IP address instead of a valid DNS name especially if you're hosting many web sites. There are some people that may disagree with this method but I think it's better to keep all the generic information in httpd.conf and use specifics in the VirtualHost configuration files. Add a new blank line below the commented ServerName directive and add your hostname or IP. For this server I used my hostname node2.centos.

    #ServerName new.host.name:80

    ServerName yourhostname

    The next directive we'll edit is very close to the end of the file. Scroll all the way down to line number 1005 (tip: use the Page Down key on your keyboard) and look for '#NameVirtualHost *:80'. The NameVirtualHost directive tells Apache that we want to use name-based virtual hosting, or in simpler terms, a bunch of web sites all using the same IP address. Virtual hosting is made possible because when a web browser goes to a site, for example www.xenocafe.com, the web site address is passed as part of the HTTP header (Host: www.xenocafe.com). This allows Apache to distinguish between different hosts sharing the same IP address. Add a couple blank lines underneath '#NameVirtualHost *:80' and on the line right below put NameVirtualHost and your hostname or IP address followed by a :80. The ':80' means we're using name-based virtual hosting for the HTTP protocol. SSL will be configured through VirtualHost configuration files due to its nature. You'll learn why when we create our virtual hosts. For this server I used my hostname node2.centos.

    #NameVirtualHost *:80

    NameVirtualHost yourhostname:80

    We're almost done. The last thing we need to do is create a default virtual host to respond to requests when someone vists our IP address and not our domain name. You may or may not want to add this virtual host and it's totally up to you, but I personally don't want anyone going directly to my IP address. I prefer they visit my web site by name only. A VirtualHost entry can have many directives which I'll explain later, but what you need to know for now is the example I provide responds by IP address visits. At the very end of the file there is a line that instructs Apache to load any configuration files found in the /etc/httpd/conf/vhosts/ directory (which we'll create later). This is my way of keeping the virtual hosts separate from httpd.conf and most importantly, making hosts easier to manage.

    We're done editing httpd.conf. Let's save our changes (CTRL-O ) and exit nano (CTRL-X ). Now we'll move on to creating a web site directory structure and user account for SSH access and S/FTP file uploads.

    Creating the Web Site Directory Structure

    Our web site directory schema should be simple yet structured. The common approach would be to use /home as the root but we won't be doing that. Our web site parent root will be /www and from within it create a directory for each domain we'll be hosting. Within each domain directory there will be a set of common directories (html, html/cgi-bin, databases, and logs). Reading what I wrote doesn't make much sense so here it is visually. For this example and the rest of the tutorial, we'll say we acquired the domain your-domain.com and will be configuring our server for it.

    The databases directory is optional. If you read my mapping mysql databases tutorial then you can migrate your databases outside the default /var/lib/mysql into the databases directory. This will allow you to store your databases on a per site basis in the web site's home directory.

    Creating the Directory Root (one-time only)

    We'll start creating our web site directory structure by making /www. Creating this directory is a one-time process and will be home to all our domains we're hosting (any domains we add will be stored in the /www directory).

    mkdir /www

    chown root.root /www

    After we create the directory we chown it to uid:root gid:root.

    Creating Web Site Domain Directories

    For each web site you're hosting you'll create a directory structure within the parent /www. The directory should be named the same as the domain name with or without the TLD (.com. net, etc). I'll let you decide which way you want your directories to be named, but I tend to prefer them without the TLD. Now we'll create our domain's directories.

    mkdir html

    mkdir html/cgi-bin

    mkdir databases

    mkdir logs

    Now that the directory structure is created we'll need to add a system user that owns the directory base and can log in to upload files.

    Adding a Linux User Account for the Web Site

    The user account will be able to FTP or Secure FTP (SFTP) into the server to upload and download web site content files like HTML, CGI scripts, and PHP pages. This user account will have ownership of the domain's directory base and be locked into it. The user name we'll assign will be the same as the domain name (your-domain) to make it easier to distinguish between it and the other Linux accounts, however you can use any name you want for your account. One thing to keep in mind is when you create this account you'll have to make a choice whether this account will be granted SSH access. If you want to disallow SSH access then you'll need to change the shell to /sbin/nologin. SSH login attempts will fail when you use /sbin/nologin as the account's shell (valid login credentials will be accepted but the connection will be terminated). To create the web site system account, use one of the following commands.

    The first command will set the account's home directory (-d path ) to /www/your-domain and creates a new system account with the user name of domain_user (last parameter of the command). The shell will be set to the default, which is typically bash unless you changed it. The second command is identical to the first except that the shell (-s shell ) is set to /sbin/nologin to prevent SSH logins.

    After the account has been created you'll need to set a password using the passwd command.

    passwd domain_user

    Now that the system account is ready we'll move on to changing the directory base ownership.

    Changing Web Site Directory Ownership & Permissions

    We've created the directories, added the account, the only thing left to do is change the ownership of the directories to the new user account. Right now the directories are owned by root and if you were to try using FTP to upload some files you'd get the dreaded Permission Denied error. To change ownership of the domain directory and all its subdirectories we'll use the chown command with the -R flag for recursive.

    chown -R domain_user:domain_user your-domain

    If you created the databases directory then you'll need to change the owner to the mysql user otherwise MySQL won't be able to write to the database files. All directories, subdirectories, and files starting from databases should be owned by the mysql user (or whatever user account you have the MySQL server running as).

    cd your-domain

    chown -R mysql:mysql databases

    That's it for creating our directory structure. If you have more domains to add then repeat the steps we went through except for the first one of creating the /www directory root. Next we'll create the VirtualHost configuration files to let Apache know the details of our web site.

    Creating VirtualHost Configuration Files

    A VirtualHost configuration file tells Apache the specifics about your web site. It contains information like what IP and port number your site runs on, the server name and any aliases, the local filesystem path (or document root) of your web pages, location of your cgi-bin, file names and paths of your access and error logs, custom error documents for HTTP errors like 404 File Not Found, and can have many other items. For every web site you want Apache to host you must create a virtual host configuration. You've already gotten a taste of a virtual host config when we added the default VirtualHost for handling IP address requests in httpd.conf, so what we're going to be doing now is nothing new. I'm now going to show you an easy way of managing all your virtual hosts.

    The VirtualHost Configuration File Directory (/etc/httpd/conf/vhosts)

    When I first learned Linux from a friend some years ago, he showed me how to configure Apache so I could set up my web server. I looked at his httpd.conf and he had all his virtual hosts in there, so I figured there was nothing unusual about that as I'm sure there are many people that did the same thing. He hosted a lot of domains for friends, his business, and his own stuff, and I noticed that trying to locate a web site in his massive httpd.conf file was nothing short of a headache. Although I didn't doubt his knowledge of Apache I kept thinking there had to be an easier way of managing virtual hosts. Through reading the online Apache Web Server documentation I came across the Include directive.

    The Include directive, much like in C/C++, PHP, and other languages, allows you to insert the contents of another file into the calling file. However, in the case of Apache, the contents of a single file or of several files located in a directory that match the Include statement would be included. If you remember when we were editing httpd.conf, at the very end we added the line 'Include conf/vhosts/*.conf'. That line tells Apache to look in /etc/httpd/conf/vhosts for any *.conf files and include their contents as part of httpd.conf. This allows us to separate out our VirtualHost definitions as their own unique files, on a per domain basis, from the main httpd.conf file. This makes administration easy for several reasons. Finding a virtual host is easy because all you do is look in the vhosts directory for its file, disabling a domain is as simple as renaming the file so it doesn't end in .conf, and adding new domains is accomplished by creating a new virtual host file (copy an exisiting file and edit the changes). Include makes virtual host management a piece of cake.

    We'll now create the /etc/httpd/conf/vhosts directory (this is a one-time process).

    cd /etc/httpd/conf

    mkdir vhosts

    We can start creating VirtualHost configuration files now. I'll show you how to create one for the HTTP protocol as well as one for Secure Sockets Layer (SSL).

    Creating a HTTP Virtual Host

    When creating virtual host config files we should use a good naming convention that's as descriptive as possible. What's worked for me is the format of host.domain.tld.port.conf or in simple terms your-domain.com.80.conf. You may have noticed I excluded host from the file name. When you visit a domain such as redhat.com, or www.redhat.com, they most likely take you to the same web site, so www as a host can be excluded. The only time I use host as part of the file name is when I am adding a subdomain such as forum.example.com or blog.example.com and so forth. Let's create the HTTP virtual host file.

    nano your-domain.com.80.conf

    Type in or copy/paste the configuration data below. Be sure to replace yourhostname with your system's hostname or IP address, ServerAdmin with your email address, ServerName and ServerAlias with your real domain name, and your-domain with the directory name you created earlier for your web site. When you're done, save your changes (CTRL-O ) and exit nano (CTRL-X ).

    I'll clarify what each line does in the virtual host configuration file between the <VirtualHost></VirtualHost> tags.

    • ServerAdmin is used to specify the server administrator's email address. User's will see this address on server generated error pages.
    • ServerName is the name of the server or DNS name. Apache will match this name against the HTTP host header sent by the user's browser. If it's a match then this is the configuration data used to process the request.
    • ServerAlias is identical to ServerName except ServerName is used once and ServerAlias can be used many times. If your web site will respond to more than one DNS name, make sure you use one ServerName directive and all other names are specified using ServerAlias. DNS names can be separated by commas for a single ServerAlias directive (ServerAlias dns_name1,dns_name2,dns_name3) or you can use many ServerAlias directives for each DNS name placed on a line each their own.
    • DocumentRoot defines the file system path to where the web page files are located. This is the same directory where you will place your HTML, PHP, and image files. For our setup, this is the /www/your-domain/html directory.
    • ScriptAlias defines the directory for executing cgi scripts, commonly known as cgi-bin. It takes two parameters with the first being the cgi-bin directory from your web site root path and the second being the full physical directory path on the filesystem. You can have as many cgi-cin directories as you need and they don't need to be called cgi-bin.
    • ErrorLog defines the file to log any errors Apache encounters. Errors can include PHP script failures and files that don't exist.
    • CustomLog defines the file to log any requests to the server. Requests include accessing pages, images, and other files like robots.txt. The second parameter sets the log entry format. We use the combined format since it is used by many Web Server Log Analysis scripts like Awstats .

    You should read the online Apache 2.0 documentation for more information on these directives as well as other Apache web server features.

    Creating a SSL Virtual Host

    When we installed mod_ssl, a file called ssl.conf was written to /etc/httpd/conf.d that contains basic SSL configuration information. We're going to use this as our template for adding a SSL based virtual host. What we'll do is make a copy of it to our vhosts directory and remove the non-website specific information since it should only be loaded once by Apache. This non-website specific information pertains to loading the mod_ssl Apache module among other things while everything else in the file relates to configuring the SSL web site (what we're interested in).

    Let's make a copy of ssl.conf to the vhosts directory which you should still be in (cd /etc/httpd/conf/vhosts ). Following the same format for our virtual host config files (host.domain.tld.port.conf ) as before, we will be naming our SSL virtual host file as your-domain.com.443.conf. The port number for SSL is 443 so we'll use that as opposed to port 80 when we created the HTTP VirtualHost. After that we'l open the config file in nano so we can begin editing it.

    cp /etc/httpd/conf.d/ssl.conf ./your-domain.com.443.conf

    nano your-domain.com.443.conf

    Now comes the fun part. We need to delete a good portion of this file starting from the top and all the way down to the part that says '### SSL Virtual Host Context' (roughly 83 lines total). Instead of using the DEL key, you can use CTRL-K to cut the text line by line in nano. Starting from the top of the file, remove the lines of text until you reach the blank line above '### SSL Virtual Host Context'. Your file should look like the image below when you're done.

    Next we'll edit the default web site specific directives to mold them to our web site. They're actually the same directives we used when creating our HTTP virtual host, so you can see how easy this will be. I should point out that we have been using our hostname for the VirtualHost tag, but in the case of SSL I'd advise against unless you want to set up each host and their binding IP address in /etc/hosts (it's a good idea if you have many IP's). Secure Sockets Layer doesn't work at the Application layer of the OSI model like HTTP does, so the Host part of the HTTP header doesn't apply. So in regards to name-based virtual hosting with SSL, it's non-existent. Replace '_default_' with your IP address when editing your-domain.com.443.conf. The same rules apply as before with ServerName, ServerAlias, and the your-domain directory.

    Here is a stripped down version of our SSL VirtualHost file minus the comments.

    This configuration uses mod_ssl's default SSL certificate and private key for encrypted communications. It's not signed by a trusted authority nor does it have your personal or company credentials. Your web browser will complain about the certificate and throw up a dialog box when you visit your web site (unless you instruct the browser to save the certificate). If you're thinking about doing e-commerce then you'll need to invest in a real SSL certificate because nothing kills a customer's confidence level like a warning screen while making a purchase online. What you would do is generate your Certificate Signing Request (CSR) on your server and then send the data to a Certificate Authority (CA) like Verisign. Once you pay the fees and prove your identity, they'll sign your certificate to make it legitimate and then you can replace the values of SSLCertificateFile and SSLCertificateKeyFile with your files (in the case of Comodo SSL, you'd have to set the SSLCACertificateFile directive with their Bundle Certificate file as well). On the other hand, if you're setting up SSL for your own personal use or for an intranet at work, self-signed SSL certificates work just fine. There is no difference between legitimate and self-signed certs except for the CA taking your money and stamping it with their sign of approval. The encryption protection is the same either way.

    Save your changes (CTRL-O ) to your-domain.com.443.conf and exit nano (CTRL-X ). I don't have a tutorial up for generating SSL certificates using OpenSSL, but I will soon. You can check Google for a site that details those instructions or wait for mine to be posted. Also, you should read up on the Apache SSL/TLS Encryption documention for more information about the directives and virtual host configurations for Apache SSL.

    Starting Apache and Viewing the Web Site

    Apache is set up, our directories have been created, and the VirtualHost config files are done, now is the time to start the Apache web server and see if everything worked. It's taken us a long time to get here and if all goes well then Apache should start without any errors and your HTTP and SSL web sites should be available.

    service httpd start

    If Apache failed to start for you, you should double check httpd.conf, your directories, and your virtual host configs for any typos or syntax mistakes. Apache can be cryptic at times when errors occur. You can verify virtual host files using httpd -S (or for older an older Apache version use httpd -t -D DUMP_VHOSTS ). In the next section I'll show you some tips for tracking down Apache errors.

    With the Apache web server running you should have already opened ports 80 and 443 on your firewall so you can connect to Apache with a web browser to view your web site. Open up your favorite browser and navigate to your site. You should get the default CentOS Apache 2 Test Page unless you have already logged in and uploaded your content via S/FTP.

    Standard HTTP works so how about our SSL version of the web site? Change the http:// to https:// in the address bar of your browser. You should be prompted by the security dialog I mentioned before. This is just a warning about your self-signed SSL certificate not being trusted by your browser.

    Click OK in FireFox or Yes in Internet Explorer to continue to the secure web site.

    As you can see up in the FireFox address bar, there is a little yellow padlock icon that informs us that we are on a secure web site. All communications with this site will be 128-bit encrypted. At this time you may want to log in to your web site via Secure FTP (SFTP) or regular FTP to upload your web site files to the html directory using the system account you created earlier. You're done! You've successfully configured the Apache web server on Linux.

    Other Things to Know for Using Apache

    Here are some common questions that users new to the Apache HTTP Server may ask (well, the questions I could think of at the time).

    How can I restart Apache so that it sees the changes I made to httpd.conf and/or virtual hosts?

    The Apache init script (/etc/init.d/httpd) accepts a number of options, four of the important ones being start, stop, restart, and graceful.

    • start tells the init script to start the Apache process and spawns the child processes.
    • stop tells the init script to terminate the Apache's running process and in turn kills off the child processes. Any existing connections to the server will be terminated.
    • restart tells the init script to stop the Apache process and start it back up. Any changes to httpd.conf or virtual hosts will be read back in. Any existing connections will be terminated, so if users are in the middle of a download the transfers will stop.
    • graceful tells the init script to alert Apache to reload httpd.conf and virtual hosts. Existing connections will not be terminated but changes won't be noticed until a new connection is established (pulling up another page or file from the server). Requests are handled by Apache child workers.

    There are two ways of using these options. You can use the init script or the service command. To use the init script, enter this on the prompt /etc/init.d/httpd option. such as to restart the Apache server use /etc/init.d/httpd restart from the command line. To use the service command, which is what I showed when we started the Apache service, it's service httpd option. such as to do a graceful restart use service httpd graceful from the command line.

    Apache won't start. It keeps saying FAILED when I try and start the service. What can I do to fix it?

    This is probably one of the most difficult tasks to do since sometimes Apache doesn't give an error or it's too cryptic when it does. Errors usually occur when something has changed, either there is a problem with httpd.conf or your virtual hosts. One of my friends enountered an Apache failure and it turned out to be one of its modules got deleted somehow. So the best course of action is to make a copy of your httpd.conf and virtual hosts before you ever change them. If you mess them up you can always replace the old copy to get Apache back up and running.

    • To try and troubleshoot Apache failures, you should take a look in syslog (tail -n 100 /var/log/messages ). See if there are any messages from the httpd process, and if so, does it give you an idea of what may be wrong? I've been able to track down errors by doing this one thing. Get the error and look for it on Google. It's unlikely you're the first person to experience it.
    • If it's a config file error, you can test your httpd.conf and virtual hosts with httpd -S (or on older Apache versions use httpd -t -D DUMP_VHOSTS ). If there is a problem with your files, Apache will tell you when you run the test.
    • Another useful hint is to try starting Apache in debug mode using httpd -e debug and see what it prints to the screen. If there is an error it should be shown to you. Once again, if you see the error, use Google to find an answer.
    • If all else fails, there is trial and error. Move your httpd.conf and virtual host files to another directory and reinstall the Apache RPM's. Once Apache is back up with default settings, start making changes to the new httpd.conf and virtual hosts from the old files. Each time you make a change, save your changes and restart Apache. Like I said, it's trial and error and you may be able to track down the problem.

    Can I use Active Server Pages (ASP) or ColdFusion (CFML) with Apache on Linux?

    Why would you want to? Those are weak and useless languages (my opinion of course). You should use PHP instead, however, if you have the need to use them, there are ports from third party companies that let you use those languages with Apache on Linux. For Active Server Pages, Sun Microsystems has a product called Sun ONE Active Server Pages (a former ChiliSoft product) that let's you use ASP on Linux. They have a free trial version you can download and try out. ColdFusion is no longer a Macromedia product and is now maintained by Adobe Systems. You can download a free trial version after you register for an account.