InfoCity
InfoCity - виртуальный город компьютерной документации
Реклама на сайте







Размещение сквозной ссылки

 

Приручаем дикого индейца: Apache


Данила Данилов, Сетевые решения


В данной статье я хотел бы рассмотреть несколько вопросов по миниатюрной настройке Apache HTTP Server: будут рассмотрены вопросы по использованию наиболее популярных freeware продуктов: Apache, SSL и http-акселерации.

Итак, приступим-с. Нередко можно встретить среднестатистический офисный сервер поставленный под Linux, на дохленькой 486 машине, которая выполняет все функции internet сервера и плюс ко всему сглаживает взаимодействие локальных пользователей с глобальной сетью и всеми предоставляемыми ею сервисами. А зачастую бывает так, что этот работяга выполняет функции веб-сервера. Все бы хорошо и отлично работает, скажете вы. Конечно же, но ведь у некоторых web-сервер обрабатывает не два запроса в день, а несколько десятков тысяч, как и было в моем случае. Мечтать о том, что начальство соизволит поменять машину, было делом совершенно бесполезным, тогда я решил поработать напильником в самом софте, что в принципе принесло свои плоды.
Первое за что я взялся это за беднягу apache, которому приходилось "шуршать" по диску постоянно, то затем чтобы пропарсить shtml, то затем чтобы выполнить прихоти server-side приложений. Причем делать это при любом и каждом запросе пользователя. Раскрыв толстые умные книжки "Linux Encyclapedia" и "Linux Internet Server", открыв мануалы, я принялся за работу.

http-акселерация


Изначально Apache, как вы понимаете работает, как web-сервер, но с помощью нехитрых манипуляций его можно переключить в режим http-акселерации. Сама суть механизма сводиться к следующему: есть frontend-сервер, который отвечает на запросы пользователя и кэширует информацию и есть backend сервер, который занимается генерацией страниц.
Прежде чем чего-то ровнять в вашем работающем софте надо проверить с какими модулями скомпилирован ваш apache, это делается просто:

[root bin]#./httpd -l
Compiled-in modules:
	http_core.c
	mod_charset.c
........
	mod_proxy.c
........

и так далее. Он обязательно должен быть собран с модулем mod_proxy. Итак, есть какой-то хост lnx.open.by, веб-сервер установленный на котором будет подвергаться всяческим измывательствам и турбо-ускорениям;). Выбираем любой свободный порт для организации backend сервера и переводим существующий сервер на работу через этот порт. А делается это только для того, чтобы отключить генерацию логов, дабы не вводить в заблуждение анализаторы оных.
Вот примерное описание вашего существующего сервера (я надеюсь он у вас простроен через vhost?). (IP адреса и имена хостов естественно вымышленные):

<VirtualHost 192.168.0.1:80>
ServerName lnx.open.by
DocumentRoot /home/httpd/html/lnx-server
ServerAdmin admin@lnx.open.by
ErrorLog /var/log/httpd/lnx-server-errorlog
CustomLog /var/log/httpd/lnx-server-accesslog combined
</VirtualHost>

Для построение backend, меняем на следующее:

<VirtualHost 192.168.0.1:8081>
ServerName lnx.open.by
DocumentRoot /home/httpd/html/lnx-server
ServerAdmin admin@lnx.open.by
</VirtualHost>

Теперь идем в httpd.conf для внесения и там некоторых правок:
Listen 8081
# тем самым мы разрешаем соединяться с 8081 портом и обрабатывать запросы приходящие на него.

ProxyRequests On
# включаем прокси

ProxyVia On
# разрешаем передавать сведения о том, от кого пришел запрос

CacheRoot "/usr/local/apache/cache/"
# тут у нас будет храниться сам кэш

CacheSize 50000
# размер кэша указываем в килобайтах

CacheGcInterval 2
#интервал в часах, по истечении которого будет проверяться лимит объема кэша и необходимость удаления старых страниц

CacheMaxExpire 2
# максимальное время, которое станицы могут лежать в кэше.

NoConcurrentCacheUpdates On
# разрешает обновление кэша различными программами.
Этого должно хватить по идее. Если вас интерисует более подробная информация о модуле mod_proxy, то обращайтесь за ней по адресу:
http://www.apache.org/docs/mod/mod_proxy.html 

Теперь займемся "рисованием" frontend сервера.

<VirtualHost 192.168.0.1:80>
ServerName lnx.open.by
ProxyPass / http://192.168.0.1:8081/
ProxyPassReverse / http://192.168.0.1:8081/
CacheRoot "/usr/local/apache/cache/"
ErrorLog /var/log/httpd/lnx-server-errorlog
CustomLog /var/log/httpd/lnx-server-accesslog combined
NoCache chat
</VirtualHost>

Теперь создаем каталок /usr/local/ apache/cache/ с полными правами для пользователя от имени которого запускается Apache сервер, обычно это nobody.

[root bin]# mkdir /usr/local/apache/cache
[root bin]# chown nobody.nobody /usr/local.apache/cache

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

ProxyPass / http://192.168.0.1:8081/

Написать что-нибудь такое:

ProxyPass /info http://info.lnx.open.by:8081/

И при обращении пользователя к http://lnx.open.by/info он получит данные с http://info.lnx.open.by. Это иногда бывает полезным при объеденении нескольких серверов в один.
Команда NoCache указывает на те слова в URL, при встрече которых, информация не будет кэшироваться на диске. Такое может понадобиться для быстрообновляющихся страниц, которые не оказывают большой нагрузки на сервер.
Вот собственно и все, при условии, что настроено все у вас правильно. И после перезапуска сервера, все запросы будут прокэшированы. Проверить это очень легко.

[root@lnx home]# cd /usr/local/apache/cache
[root@lnx cache]# ls
2 8 E H J M O R U W _ c i v
3 B G I L N P T V Z b h j z
[root@lnx cache]#

А теперь типизированно расмотрим, как же все таки работает эта связка. На 80-й порт по адресу 192.168.0.1 приходит запрос. Apache разбирает его и смотрит, для какого виртуального сервера он предназначен. Если для lnx.open.by, прокси разбирает запрос и смотрит в кэше, не делал ли кто такой запрос раньше. Если делали и время "протухания" страницы еще не подошло, то просто отдаем закэшированную страницу и вес. Если не делали или страница протухла", до делает запрос к backend-серверу на 8081-й порт и кэширует заново выданную страницу. Все очень просто и надежно.

SSL для Apache HTTP Server


Итак, теперь ваш "индеец" немерянно быстр и неплохо бы ему быть нактолько же защищеным и уметь защищать других. (Это так — алигория;) Попробуем прикрутить к нему SSL.
Сначала нам необходим сам Apache. Если у вас уже есть собранное и работающее дерево apache, то скопируйте его в безопасное место. Если нет, то вытяните самую последнюю версию Apache и разверните его.
Будем рассматривать настройку на базе следующих пакетов:
ftp://ftp.modssl.org/source/mod_ssl-2.6.4-1.3.12.tar.gz
ftp://ftp.openssl.org/source/openssl-0.9.5a.tar.gz
и непосредственно самого Apache 1.3.12.
Делаем со всем этим следующее, тем самым распаковываем архивы:

[root@lnx tmp]# gzip -d -c mod_ssl-2.6.4-1.3.12.tar.gz | tar xvf -
[root@lnx tmp]# gzip -d -c openssl-0.9.5a.tar.gz | tar xvf -

Идем дальше:

[root@lnx tmp]# cd openssl-0.9.5a
[root@lnx openssl-0.9.5a]#./config
[root@lnx openssl-0.9.5a]# make

Отконфигурировали и собрали openssl, пакет, который и будет обеспечивать шифрование. Я рекомендую дать еще команду make install, после которой в /usr/local/ssl будет лежать это пакет.
Далее...

[root@lnx openssl-0.9.5a]# cd..
[root@lnx tmp]# cd mod_ssl-2.6.4-1.3.12
[root@lnx mod_ssl-2.6.4-1.3.12]#./configure -with-apache=../apache_1.3.12 
       -with-ssl=../openssl-0.9.5a -prefix=/usr/local/apache)

Этими командами вы включили модуль mod_ssl в число собираемых модулей для Apache. (в нашем случае Apache находиться в директории: tmp/apache_1.3.12)
Теперь просто перейдите в каталог с Apache и скажите make — все необходимые модули будут собраны. Так же, если у вас раньше были собраны нестандартные модули, как у меня, они никуда не исчезнут и будут тоже вкомпилированы.
Далее....
make certificate
На всяческие вопросы можно особо усердно могз не напрягать, а вводить любые пароли или просто давить Enter, тем самым вы сгенерируете свои сертефикаты.
make install
Этой командой вы инсталлируете Apache в предназначенное для него место (/usr/local/apache).
Все, можете попробовать запустить apache командой
/usr/local/apache/bin/apachectl startssl
Если все запустилось, а проверить можно так:
ps ax|grep ht
в ответ должно появиться появляются httpd -DSSL, то можете себя поздравить — оно собралось.
Теперь надо чуть-чуть подпилисть наш apache.
Итак, начнем конфигурировать, открываем в редакторе файл httpd.conf.
Listen 443
NameVirtualHost 192.168.0.1:443
Эти команды указывают Apache слушать 443 порт (стандартный порт для secure http (https)) и обслуживать на нем виртуальные серверы.
Теперь добавляем описание виртуального сервера.

<VirtualHost 192.168.0.1:443>
SSLEngine on
SSLCertificateFile /usr/local/apache/conf/ssl.crt/server.crt
SSLCertificateKeyFile /usr/local/apache/conf/ssl.key/server.key
SSLLog /usr/local/apache/logs/ssl_engine_log
SSLLogLevel warn
SSLOptions +StdEnvVars

Тут добовляем стандартные для этого места директивы;)
</VirtualHost>

Теперь надо перезапустить сервер, в первый раз после перезапуска он у вас должен спросить парольную фразу. Но следует обратить внимание, что это происходит лишь однажды и такое не приемлимо для уже рабочего https-сервера. Теперь делаем следуещее:
Входим в каталог с ssl.key
cp server.key server.key.org
openssl rsa -in server.key.org -out server.key
Вводим пароль для дешифровки
chmod 400 server.key
И закрываем файл с отрытым ключом от посторонних глаз, все сервер больше не будет спрашивать пароль. На данном этапе уже должен работать SSL на полную катушку. То есть, набирая https://ваш.хост.ltd вы должны получать запрос браузера на использование этого сертификата.
Для того, чтобы немножко автоматизировать процесс запуска Apache вместе с SSL подредактируем bin/apachectl. Исправим в нем условие start на startold, а startssl на просто start. Затем скопируем его в /etc/rc.d/ init.d/httpd. Теперь по умолчанию при загрузке сервера, будет запускаться Apache с поддержкой SSL.
Чтобы не мучаться с PATH, сделаем, чтобы openssl запускался нормально.
cd /usr/local/bin
ln -s /usr/local/ssl/bin/openssl openssl
Итак, теперь будем генерировать нормальные сертификаты.
Генерируем ключ.
openssl genrsa -des3 -out server.key 1024
На данном этапе мы создали server.key, теперь генерируем запрос в службу верификации.
openssl req -new -key server.key -out server.csr
Будьте аккуратны в ответах, ведь это потом увидят все. Если ошиблись, все можн повторить заново. CommonName — это адрес хоста без http://.
Все, если вы получили следующую надпись, то запрос сгенерирован правильно:
You now have to send this Certificate Signing Request (CSR)
to a Certifying Authority (CA) for signing
Но мы не буржуи, подписывать у нас некому, поэтому мы будет сами подписывать себя. Хотя если у вас есть деньги и вам необходимо подписать свой сертификат именно у глобальных авторизационных центров, то на modssl.org Вы найдете все необходимые адреса и ссылки.
openssl genrsa -des3 -out ca.key 1024
openssl req -new -x509 -days 365 -key ca.key -out ca.crt
Генерируем подпись авторизационного центра на год (можно и на больше), процедура полность схожа с генерацией ключа.
Копируем sign.sh из pkg.contrib из пакета mod_ssl в каталог с ключами
И подписываем свой же запрос
./sign.sh server.csr
Получив надпись, содержащую
Now you have two files: server.key and server.crt. These now can be used as following
Начинаем радоваться, все собрано так, как надо. Копируем server.key и server.crt на место старых, но в каталоге c crt файлом Makefile не трогаем. Скопировав новый.crt файл, наберите make в этом же каталоге — он создаст некий хеш файл.
Все, теперь перезапустите Apache и можете наслаждаться тем, что вы сделали собственный WWW сервер, защищенный с помощью SSL.
Проверить защищенность вы можете посмотрев информацию о сертификатах или соединении в info-окнах браузеров. Если вы им не доверяете, то дайте команду
openssl s_client -connect localhost:443 -state -debug
Она выведет полностью всю информацию, которую она сможет выжать из вашего SSL сервера.


Реклама на InfoCity

Яндекс цитирования



Финансы: форекс для тебя








1999-2009 © InfoCity.kiev.ua