Установка mod_perl
Все примеры показаны для ОС Linux Debian
Устанавливаем пакет libapache2-mod-perl2

lenny:~# apt-get install libapache2-mod-perl2
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  libapache2-reload-perl libbsd-resource-perl libperl5.10
The following NEW packages will be installed
  libapache2-mod-perl2 libapache2-reload-perl libbsd-resource-perl libperl5.10
0 upgraded, 4 newly installed, 0 to remove and 2 not upgraded.
Need to get 1201kB of archives.
After this operation, 3891kB of additional disk space will be used.
...
Processing triggers for man-db ...
Setting up libperl5.10 (5.10.0-19) ...
Setting up libapache2-mod-perl2 (2.0.4-5) ...
Enabling module perl.
Run '/etc/init.d/apache2 restart' to activate new configuration!
Setting up libapache2-reload-perl (0.10-2) ...
Setting up libbsd-resource-perl (1.28-1+b1) ...

Как можно увидеть, модуль уже активирован.. Но никто не мешает сделать это еще раз (для надежности :) ) Или, например, после изменения конфигурации сервера, да и вообще, чтобы убедиться

lenny:~# a2enmod perl
Module perl already enabled
lenny:~# /etc/init.d/apache2 restart
Restarting web server: apache2 ... waiting .

Модуль установлен, давайте займемся его настройкой. Самое простое – это добавить хендлер perl-status и посмотреть, что же происходит с нашим сервером. Создайте файл /etc/apache2/conf.d/perl-status со следующим содержимым:

 #
 # make status information available at
 #   http://example.com/perl-status/
 #
 <Location /perl-status>
    SetHandler perl-script
    PerlHandler +Apache2::Status
</Location>

 #
 # But only from the local host, and our trusted
 # remote IP.
 #
 <Location /perl-status>
    order deny,allow
    deny from all
    allow from 127.0.0.1
    allow from your.ip.address
</Location>

Перезапустите сервер и зайдите на адрес /perl-status. Узнаете несколько интересных вещей об окружении сервера и о загруженных модулях Perl
Внимание! Эта информация содержит много такого, что не стоило бы показывать всем и каждому. Поэтому не стоит делать ее доступной для всех. Ограничьте доступ!

Ускорение Perl CGI-скриптов
Так как mod_perl уже содержит встроенный интерпретатор Perl, то мы можем использовать его для запуска CGI-скриптов, вместо вызова внешней команды. Это позволит снизить накладные расходы на вызов отдельной копии интерпретатора при поступлении запроса на обработку скрипта. Есть способы добиться более внушительного ускорения, но это потребует внесения изменений в исходный код сценариев. В Debian CGI-скрипты по умолчанию располагаются в /usr/lib/cgi-bin Мы укажем Apache, что хотели бы запускать встроенный интерпретатор вместо внешнего для сценариев из этой директории.

  PerlModule Apache::Registry
  Alias /cgi-bin/ /usr/lib/cgi-bin
  <Location /cgi-bin>
    SetHandler perl-script
    PerlHandler Apache::Registry
    PerlSendHeader On
    Options +ExecCGI
  </Location>

Перезапустите сервер (/etc/init.d/apache2 restart) и посмотрите, насколько быстрее стали работать скрипты :)

Загрузка модулей
Продолжим. Давайте напишем код, который Apache мог бы использовать в процессе обработки страницы и пересылки ее клиенту. Нам необходимо разместить этот код так, чтобы встроенный интерпретатор смог загрузить его. По умолчанию в путь для поиска уже включены большинство системных директорий, но я считаю, что имеет смысл расположить его в очевидном месте :) /etc/apache2/perl Для добавления директории в путь поиска добавьте следующую директиву в /etc/apache2/conf/00-mod-perl

#
# Load the startup script
#
PerlRequire /etc/apache2/perl/startup.pl

Теперь при старте севера будет запускаться указанный скрипт. Давайте создадим его и поместим туда вот такой код

#
# Add /etc/apache2/perl to the mod_perl search path.
#
use lib qw( /etc/apache2/perl );

#
# This script had no errors (?!)
#
1;

После перезапуска сервера путь для поиска будет обновлен и будет включать в себя нужную нам директорию.

Сделаем что-то полезное?
Очень часто я вижу на своих проектах “пауков”, которые методично обшаривают страницу за страницей, качая содержимое. Вообщем я не возражаю против “зеркалирования” своих сайтов, но пока это все происходит незаметно для меня, в один поток и без съедания львиной доли ресурсов. А плохие “пауки” очень часто делают запросы, подобные следующим:

1.2.3.4 – [30/Apr/2009:19:36:29 +0100] “GET /articles/535#comment_2 HTTP/1.0″
1.2.3.4 – [30/Apr/2009:19:36:30 +0100] “GET /articles/535#comment_3 HTTP/1.0″
1.2.3.4 – [30/Apr/2009:19:36:30 +0100] “GET /articles/535#comment_5 HTTP/1.0″
1.2.3.4 – [30/Apr/2009:19:36:31 +0100] “GET /articles/535#comment_4 HTTP/1.0″

Т.е. по якорям методично и многократно вытягивают одну и туже страницу, съедая ресурсы и трафик. Чтоже делать, будем их ловить с помощью вот такого модуля на Perl: DropClients
Это сценарий на Perl, который обрабатывается mod_perl. Он выполняется для каждого входящего запроса и делает следующее:

• Выделяет из запроса IP-адрес и User-Agent
• Если UA и IP – “плохие”, то отклоняет запрос
• В нашем случае запрос отклоняется и тогда, когда в нем содержится “#”

Если все хорошо, то запрос проходит

Чтобы запустить этот сценарий мы должны

1. Загрузить его
2. И заставить его выполняться :)

Сохраним модуль как /etc/apache2/perl/DropClients.pm и создадим файл /etc/apache2/conf/dropclients со следующим содержимым:

#
# Load the module
#
PerlModule DropClients

#
# Ensure it is invoked as an access handler
#
<Location />
PerlAccessHandler DropClients
</Location>

После перезапуска метод DropClients::request() будет выполняться для каждого входящего запроса и нежелательные запросы будут отклоняться.

Нормальный запрос

user@notebook:~$ echo -e “GET / HTTP/1.0\n” | nc lenny 80 |grep ^HTTP
HTTP/1.1 200 OK

“Плохой” запрос

user@notebook:~$ echo -e “GET /#foo HTTP/1.0\n” | nc lenny 80 |grep ^HTTP
HTTP/1.1 403 Forbidden

Поскольку мы только что сделали “плохой” запрос, дальнейший доступ к серверу будет закрыт

user@notebook:~$ echo -e “GET / HTTP/1.0\n” | nc lenny 80 |grep ^HTTP
HTTP/1.1 403 Forbidden

Если заглянете в код модуля, то увидите, что эта блокировка очень просто и снимается командой rm -rf /tmp/blah

Различные типы обработчиков
Для нашего модуля мы использовали обработчик PerlAccessHandler, который запускал скрипт при входящих соединениях. Но это лишь один из многих типов обработчиков. Есть также, например:

• PerlResponseHandler – запускает сценарий после прохождения запроса
• PerlOutputFilterHandler – позволяет выполнить фильтрацию контента, отдаваемого пользователю (заменить слова, добавить футер… Сфера применения ограничена лишь вашей фантазией)

Полный список обработчиков доступен в документации к mod_perl и здесь Там же можно найти и примеры кода

Установка MySQL 5.0

aptitude install mysql-server mysql-client

В процессе установки вас попросят ввести пароль для пользователя root. Этот пользователь не имеет ничего общего с системным пользователем root. Этот пароль будет использован для пользователя, обладающего суперпривелегиями для самой MySQL:

New password for the MySQL "root" user: <-- yourrootsqlpassword
Repeat password for the MySQL "root" user: <-- yourrootsqlpassword

Установка Nginx
Nginx есть в репозитории Debian, что существенно упрощает нашу задачу :)
Установим и запустим его:

aptitude install nginx
/etc/init.d/nginx start

Наберите в браузере IP-адрес или хостнейм сервера (например http://192.168.0.100) и вы увидите стартовую страницу nginx

Установка PHP5
Для “общения” между nginx и PHP мы будем использовать FastCGI. К счастью, в репозиториях Debian есть пакет, обеспечиващий поддержку FCGI в PHP. Установим PHP

aptitude install php5-cgi php5-mysql php5-curl php5-gd php5-idn php-pear php5-imagick php5-imap php5-mcrypt php5-memcache php5-mhash php5-ming php5-pspell php5-recode php5-snmp php5-sqlite php5-tidy php5-xmlrpc php5-xsl

Отредактируйте файл /etc/php5/cgi/php.ini добавив в его конец следующую строку:

cgi.fix_pathinfo = 1

В Debian нет самостоятельного приложения для FastCGI, поэтому мы воспользуемся spawn-fcgi, которая входит в состав lighttpd:

aptitude install lighttpd

И после установки получим сразу же получим ошибку:

Starting web server: lighttpd2009-03-19 15:58:09: (network.c.300) can't bind to port: 80 Address already in use
 failed!

Логично, 80-й порт у нас занят nginx-ом. Поэтому сделаем так, чтобы Лайти не запускался при загрузке системы:

update-rc.d -f lighttpd remove

Мы установили Лайти только для того, чтобы воспользовать крайне полезной для наших целей программой, идущей с ним в комплекте: /usr/bin/spawn-fcgi, именно ее мы будем использовать для запуска процессов FastCGI. Для краткого ознакомления с ее возможностями выполните команду

spawn-fcgi –help

Для запуска PHP FastCGI-демона на 9000 порту на сервере localhost от пользователя www-data выполните

/usr/bin/spawn-fcgi -a 127.0.0.1 -p 9000 -u www-data -g www-data -f /usr/bin/php5-cgi -P /var/run/fastcgi-php.pid

И чтобы каждый раз не приходилось вводить это вручную, команду можно прописать в /etc/rc.local

Настройка Nginx
Конфигурационный файл nginx расположен здесь: /etc/nginx/nginx.conf. Для начала (необязательно) увеличим количество рабочих процессов и поменяем параметр keepalive_timeout:

[...]
worker_processes  5;
[...]
    keepalive_timeout   2;
[...]

Настройки виртуальных хостов расположены в секции server {}, хост по умолчанию описан в /etc/nginx/sites-available/default, модифицируйте его следующим образом:

[...]
server {
        listen   80;
        server_name  _;

        access_log  /var/log/nginx/localhost.access.log;

        location / {
                root   /var/www/nginx-default;
                index  index.php index.html index.htm;
        }

        location /doc {
                root   /usr/share;
                autoindex on;
                allow 127.0.0.1;
                deny all;
        }

        location /images {
                root   /usr/share;
                autoindex on;
        }

        #error_page  404  /404.html;

        # redirect server error pages to the static page /50x.html
        #
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
                root   /var/www/nginx-default;
        }

        # proxy the PHP scripts to Apache listening on 127.0.0.1:80
        #
        #location ~ \.php$ {
                #proxy_pass   http://127.0.0.1;
        #}

        # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
        #
        location ~ \.php$ {
                fastcgi_pass   127.0.0.1:9000;
                fastcgi_index  index.php;
                fastcgi_param  SCRIPT_FILENAME  /var/www/nginx-default$fastcgi_script_name;
                include        fastcgi_params;
        }

        # deny access to .htaccess files, if Apache's document root
        # concurs with nginx's one
        #
        location ~ /\.ht {
                deny  all;
        }
}
[...]

server_name _; – имя хоста “по умолчанию” (конечно же, никто не мешает явно указать имя хоста, например example.com)
В выражении location / мы указываем индексный файл (index.php) и document root (/var/www/nginx-default)
Важная часть для PHP – это location ~ \.php$ {}, раскомментируйте ее. Не забудьте проверить, что вы изменили строку fastcgi_param на fastcgi_param SCRIPT_FILENAME /var/www/nginx-default$fastcgi_script_name (замените /var/www/nginx-default на ваш реальный путь к document root), иначе интерпретатор PHP может не найти запрашиваемый вами через браузер скрипт.
Удостоверьтесь, что между include и fastcgi_params есть пробел, в оригинальном файле они записаны как одно слово – это ошибка.
Перезапустите nginx

/etc/init.d/nginx restart

Создайте тестовый файл PHP со следующим содержанием

<?php
phpinfo();
?>

Сохраните в вашей document root и откройте его в браузере (http://192.168.0.100/info.php)

Обратите внимание на строку ServerAPI

Установим apache

yum install httpd

В пакет httpd в CentOS уже включены модули mod_rewrite, mod_userdir и mod_suexec

Настройка Apache

vim /etc/httpd/conf/httpd.conf

Добавьте загрузку модуля rewrite

LoadModule rewrite_module modules/mod_rewrite.so

В конец файла добавьте следующие строки

## get the server name from the Host: header
UseCanonicalName Off
## splittable logs
LogFormat "%{Host}i %h %l %u %t \"%r\" %s %b" vcommon
CustomLog logs/access_log vcommon
RewriteEngine On
## Create a handle to convert upper or mixed-case to lower-case
RewriteMap lowercase int:tolower
##-----------------------------------
## where hostname has www prefix
##-----------------------------------
## Firstly create custom variable that contains the host without the www prefix
RewriteCond %{HTTP_HOST} ^www\.(.*)$
RewriteRule .? - [E=noWWWHost:%1]
## Map the virtualhost to the documentroot
RewriteCond %{REQUEST_URI} !^/~
RewriteCond %{HTTP_HOST} ^www\.
RewriteRule ^/(.*)$ /home/vhosts/${lowercase:%{ENV:noWWWHost}}/public_html/$1
##-----------------------------------
## where hostname *does not* have www prefix
##-----------------------------------
## Map the virtualhost to the documentroot
RewriteCond %{REQUEST_URI} !^/~
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^/(.*)$ /home/vhosts/${lowercase:%{HTTP_HOST}}/public_html/$1

Рассмотрим подробнее

• Наши сайты располагаются в директории /home/vhosts – каждая поддиректория – это доменное имя сайта (без www), например /home/vhosts/example.com
• Если запрашивается www.example.com, то произойдет перенаправление на example.com
• document_root имеет имя public_html, это необходимо для suEXEC, как мы увидим позже. Если вы не планируете использовать suEXEC, то можете изменить имя на любое другое, но не забудьте поправить правила rewrite

Перезапустите apache

/etc/init.d/httpd restart

Создайте файл index.html в директории виртуального хоста

echo “index.html Hello World” > /home/vhosts/example.com/public_html/index.html

Теперь зайдите браузером на www.example.com, вы должны увидеть строку index.html Hello World. Если ее нет, то посмотрите log-файл apache

tail /var/log/httpd/error_log

Выполняем CGI-скрипты с помощью mod_suexec и mod_userdir
На массовой хостинг-площадке расположено много сайтов и зарегестрировано много пользователей. Естественно, что мы хотим, чтобы пользователи выполняли CGI-скрипты со своими правами, а не правами web-сервера. suEXEC позволяет реализовать нам это либо вручную, при помощи конфигурирования виртуального хоста, либо динамически, с помощью mod_userdir

Во-первых, имя каждого пользователя в системе должно совпадать с именем виртуального хоста. Например, наш example.com

useradd -d /home/vhosts/example.com example.com

Эта команда создаст пользователя example.com с домашней директорией /home/vhosts/example.com. Все файлы, доступные через web должны располагаться в /home/vhosts/example.com/public_html
Вы можете добавлять каждого пользователя в /etc/passwd вручную или настроить LDAP на вашем хосте.
Включим mod_userdir

LoadModule userdir_module modules/mod_userdir.so
<ifmodule>
    UserDir public_html
</ifmodule>

Теперь, при запросе вида http://192.168.1.1/~example.com Apache будет искать директорию public_html в домашней директории пользователя example.com Не очень красиво, что пользователям придется использовать ~ в адресах, поэтому мы “молча” будем выполнять перенаправление. Но не для всех страниц, лишь для CGI-скриптов. Для “обычных” файлов мы используем rewrite-правила, описанные выше
Добавьте следующие строки в конфиг Apache после существующих

## Rewrite script to userdir so we can use suEXEC
RewriteCond %{REQUEST_URI} !^/~
RewriteCond %{SCRIPT_FILENAME} /home/vhosts/(.*)/public_html/(.*\.(pl|cgi))
RewriteRule .* /~%1/%2 [PT,L]
<directory>
	AddHandler cgi-script .pl .cgi
	Options +ExecCGI
</directory>

И перезагрузите web-сервер

/etc/init.d/httpd restart

Создайте тестовый perl-скрипт со следующим содержанием

#!/usr/bin/perl
print "Content-type: text/html\n\n";
print "
<h1&gtltest.pl Hello World</h1>
\n";

Дайте ему права на выполнение и смените владельца

chmod +x test.pl
chown example.com:example.com test.pl

Теперь, зайдя по адресу http://www.example.com/test.pl вы должны увидеть строку test.pl Hello World. Если что-то не так, то, как обычно, смотрите логи

tail /var/log/httpd/error_log
tail /var/log/httpd/suexec.log

Оригинал: http://howtoforge.org/how-to-set-up-mass-virtualhosting-with-apache2-mod_rewrite-mod_userdir-mod_suexec-on-centos-5.3

Устанавливаем LAME
LAME – это mp3-декодер. Он необходим нам для того, чтобы в наших сконвертированных видеофайлах сохранялась аудиодорожка. В репозитриях Etch LAME отсутствует, поэтому мы будем собирать его вручную.
Установим необходимые пакеты:

apt-get install build-essential

Затем скачаем и скомпилируем LAME

cd /tmp
wget http://mesh.dl.sourceforge.net/sourceforge/lame/lame-3.97.tar.gz
tar xvfz lame-3.97.tar.gz
cd lame-3.97
./configure --enable-shared --prefix=/usr
make
make install

Устанавливаем ffmpeg
Для перекодирования видео мы будем использовать ffmpeg. Установим его и плагины к нему

apt-get install ffmpeg libavcodec0d libavformat0d libavifile-0.7c2 libpostproc0d libasound2-plugins avifile-player avifile-utils avifile-mad-plugin avifile-mjpeg-plugin avifile-vorbis-plugin

Проблема LAME в Debian заключается в том, что он не поддерживает кодирование mp3 из-за патентных ограничений, а значит наше видео превратится в “немое кино”. Чтож, немного поправим пакет

cd /usr/src/
apt-get source ffmpeg
cd ffmpeg-0.cvs20060823

Отредактируем файл debain/rules. В начале файла есть две строки confflags с опциями сборки. Добавим в одну из них --enable-mp3lame и сохраним файл

[...]
confflags += --enable-gpl --enable-pp --enable-pthreads --enable-mp3lame
confflags += --enable-vorbis --enable-libogg --enable-a52 --enable-dts --enable-libgsm
[...]

Соберем пакет

dpkg-buildpackage

dpkg-buildpackage, скорее всего, будет “ругаться” на отсутствующие пакеты, которые нужны ему для сборки ffmpeg

server1:/usr/src/ffmpeg-0.cvs20060823# dpkg-buildpackage
dpkg-buildpackage: source package is ffmpeg
dpkg-buildpackage: source version is 0.cvs20060823-8
dpkg-buildpackage: source changed by Sam Hocevar (Debian packages) 
dpkg-buildpackage: host architecture i386
dpkg-buildpackage: source version without epoch 0.cvs20060823-8
dpkg-checkbuilddeps: Unmet build dependencies: debhelper (>= 4.0) quilt libogg-dev libvorbis-dev liba52-dev libdts-dev zlib1g-dev libsdl1.2-dev libfreetype6-dev libimlib2-dev texi2html libraw1394-dev libdc1394-13-dev libtheora-dev (>> 0.0.0.alpha4) libgsm1-dev
dpkg-buildpackage: Build dependencies/conflicts unsatisfied; aborting.
dpkg-buildpackage: (Use -d flag to override.)
server1:/usr/src/ffmpeg-0.cvs20060823#

Если вы видите что-то подобное, то просто доставьте недостающие пакеты

apt-get install debhelper quilt libogg-dev libvorbis-dev liba52-dev libdts-dev zlib1g-dev libsdl1.2-dev libfreetype6-dev libimlib2-dev texi2html libraw1394-dev libdc1394-13-dev libtheora-dev libgsm1-dev

и запустите dpkg-buildpackage снова

dpkg-buildpackage

Процесс создания нового пакета займет некоторое время, а результатом его будут *.deb-файлы в директории /usr/src. Установим их командой

cd ..
dpkg -i *.deb

Устанавливаем flvtool2
При перекодировке видео неплохо было добавить некоторые метаданные в конечные файлы, например информацию о длительности, чтобы наш плеер смог корректно показывать счетчик времени. Для этого воспользуемся утилитой flvtool2. Она написана на Ruby, поэтому сначала установим его

apt-get install ruby

Затем скачаем и установим flvtool2

cd /tmp
wget http://rubyforge.org/frs/download.php/17497/flvtool2-1.0.6.tgz
tar xvfz flvtool2-1.0.6.tgz
cd flvtool2-1.0.6
ruby setup.rb config
ruby setup.rb setup
ruby setup.rb install

Подгототавливаем директории для видео
Корневой директорией для Лайти в нашем случае является /var/www (по умолчанию в Debian так и есть). Конечно же мы не хотим хранить оригинальные и сконвертированные видеофайлы в этой директории, иначе их смогут скачать все, кто захочет (зная прямую ссылку). Поэтому директорию с оригинальными видео (/var/videos/incoming) и сконвертированными (/var/videos/flv) мы расположим вне DocumentRoot

mkdir -p /var/videos/incoming
mkdir -p /var/videos/flv

Вы (или ваши пользователи) смогут загружать файлы в /var/videos/incoming через FTP или WEB-интерфейс, а вы будете их перекодировать (вручную или автоматически) в FLV-формат и хранить в /var/videos/flv

Перекодирование видео
Предположим, что у нас есть файл video.avi в директории /var/videos/incoming (или .mp4 .mov .mpg .3gp .mpeg .wmv). Мы хотим сконвертировать его в fideo.flv и сохранить в /var/videos/flv. Разрешение конечного файла должно быть 320×240, звук 44100 Hz и частота кадров 12 fps

ffmpeg -i /var/videos/incoming/video.avi -s 320×240 -ar 44100 -r 12 /var/videos/flv/video.flv

(для дополнительной информации рекомендую обратиться к man ffmpeg). Это займет некоторое время, а вывод будет похож на

server1:~# ffmpeg -i /var/videos/incoming/video.avi -s 320x240 -ar 44100 -r 12 /var/videos/flv/video.flv
FFmpeg version SVN-rUNKNOWN, Copyright (c) 2000-2004 Fabrice Bellard
  configuration:  --enable-gpl --enable-pp --enable-pthreads --enable-mp3lame --enable-vorbis --enable-libogg
 --enable-a52 --enable-dts --enable-libgsm --enable-dc1394 --disable-debug --enable-shared --prefix=/usr
  libavutil version: 0d.49.0.0
  libavcodec version: 0d.51.11.0
  libavformat version: 0d.50.5.0
  built on Aug 14 2007 15:02:25, gcc: 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
Input #0, avi, from '/var/videos/incoming/video.avi':
  Duration: 00:10:53.8, start: 0.000000, bitrate: 5455 kb/s
  Stream #0.0: Video: mpeg4, yuv420p, 1024x576, 24.00 fps(r)
  Stream #0.1: Audio: ac3, 48000 Hz, 5:1, 448 kb/s
Output #0, flv, to '/var/videos/flv/video.flv':
  Stream #0.0: Video: flv, yuv420p, 320x240, q=2-31, 200 kb/s, 12.00 fps(c)
  Stream #0.1: Audio: mp3, 44100 Hz, stereo, 64 kb/s
Stream mapping:
  Stream #0.0 -> #0.0
  Stream #0.1 -> #0.1
No accelerated IMDCT transform found
Press [q] to stop encoding
frame= 7847 q=2.0 Lsize=   21682kB time=653.8 bitrate= 271.7kbits/s
video:16061kB audio:5108kB global headers:0kB muxing overhead 2.427536%
server1:~#

Обратите особое внимание на секцию Output – там должно быть два потока: видео и аудио. Если вы видите там только видеопоток, то значит какие-то проблемы с аудиокодированием, внимательно проверьте наши инструкции по подключению LAME
После кодирования добавим метаданные

cat /var/videos/flv/video.flv | flvtool2 -U stdin /var/videos/flv/video.flv

Настройка Lighttpd
Теперь приступим к настройке Лайти. Откроем главный конфигурационный файл /etc/lighttpd/lighttpd.conf активируем в нем модули mod_secdownload и mod_flv_streaming. Обратите внимание: крайне важно, чтобы модуль mod_secdownload шел перед модулем mod_flv_streaming в секции server.modules. В обратном случае будут проблемы с отображением видео FlowPlayer’ом

[...]
server.modules              = (
            "mod_access",
            "mod_alias",
            "mod_accesslog",
            "mod_fastcgi",
#           "mod_rewrite",
#           "mod_redirect",
#           "mod_status",
#           "mod_evhost",
#           "mod_compress",
#           "mod_usertrack",
#           "mod_rrdtool",
#           "mod_webdav",
#           "mod_expire",
            "mod_secdownload",
            "mod_flv_streaming",
#           "mod_evasive"
 )
[...]

Также добавьте в конец конфига следующие строки

[...]
flv-streaming.extensions = ( ".flv" )
secdownload.secret          = "somesecret"
secdownload.document-root   = "/var/videos/flv/"
secdownload.uri-prefix      = "/dl/"
secdownload.timeout         = 120

Не забудьте заменить somesecret на реальную парольную фразу
Как работает mod_secdownload:
На web-странице расположена ссылка примерно следующего вида:
<uri-prefix>/<token>/<timestamp-in-hex>/<rel-path> (например: /dl/d8a8cb150f7e5962f6a8443b0b6c6cc2/46c1d9f6/video.flv)
Где <token> – это md5-хэш от

• Секретной строки
• <rel-path> (начинающегося с /)
• <timestamp-in-hex>

mod_secdownload перенаправит эту ссылку на файл, расположенный в secdownload.document-root (который вне основного корня веб-сервера) и обеспечит доступ к нему в течении secdownload.timeout секунд. По истечении времени ссылка перестанет быть валидной и доступ будет закрыт.
После установки FlowPalyer мы будем генерировать валидные сслыки для mod_secdownload при помощи PHP-скрипта. Дополнительную информацию по mod_secdownload можно получить здесь
Не забудьте перезапустить Лайти

/etc/init.d/lighttpd restart

Установка FlowPlayer
Скачайте последнюю версию плеера с http://flowplayer.org/download и приготовьте его к работе

cd /tmp
wget http://belnet.dl.sourceforge.net/sourceforge/flowplayer/flowplayer-1.19.zip
unzip flowplayer-1.19.zip
mv flowplayer /var/www/

Настройка FlowPlayer
Плеер установлен, теперь давайте создадим файл, с помощью которого можно будет посмотреть наше видео. В нашем примере это /var/www/flowplayertest.php, в котором расположены все параметры для запуска плеера и генерируются валидные ссылки для mod_secdownload

<?php
$secret = "somesecret";
$uri_prefix = "/dl/";

# filename
$f = "/video.flv";

# current timestamp
$t = time();

$t_hex = sprintf("%08x", $t);
$m = md5($secret.$f.$t_hex);

?>

<object type="application/x-shockwave-flash" data="/flowplayer/FlowPlayerThermo.swf">
    width="320" height="256" id="FlowPlayer">
<param name="allowScriptAccess" value="sameDomain"></param>
<param name="movie" value="/flowplayer/FlowPlayerThermo.swf"></param>
<param name="quality" value="high"></param>
<param name="scale" value="noScale"></param>
<param name="allowFullScreen" value="true"></param>
<param name="flashvars" value="config={videoFile: '<?php printf('%s%s/%s%s', $uri_prefix, $m, $t_hex, $f, $f); ?>', streamingServer: 'lighttpd', loop: 'false', useNativeFullScreen: true}"></param>
</object>

Не забудьте позаботиться о том, чтобы переменная $secret совпадала со значением, указанным в конфиге Лайти. Также должны совпадать $uri_prefix и secdownload.uri-prefix. Если все верно, то ссылки точно будут рабочими. В переменной $f содержится имя видеофайла, начинающееся со слеша (“/”). В нашем примере имя “жестко” зашито в код, но вы можете получать его из БД, например.
В тэгах <object></object> содержатся конфигурационные параметры для FlowPlayer. Плеер может использовать разные скины (в нашем примере это FlowPlayerThermo), видео имеет размер 320×240 и панель управления имеет высоту 16px. Пожтому мы указали ширину равной 320px и высоту (240+16) 256px. Если вы используете другой скин, поправьте эти параметры. За документацией по FlowPlayer обращайтесь на официальный сайт
В параметре <param name="flashvars"... содержатся настройки окружения плеера. Важным параметром является videoFile – это ссылка на файл, которую генерирует наш скрипт. Другая важная опция – это streamingServer: 'lighttpd', которая указывает, что для потоковой трансляции файла мы используем mod_flv_streaming Остальные опции (loop, useNativeFullScreen) являются необязательными. Например, если вы установите опцию useNativeFullScreen в true (это поддержка нативного полноэкранного режима для Flash Player 9), то вы должны включить в object строку <param name=”allowFullScreen” value=”true” /> и не можете использовать <param name=”wmode” value=”transparent” />
За дополнительными настройками FlowPlayer обратитесь к документации

Проверим?
Зайдем браузером на http://192.168.0.100/flowplayertest.php – видео должно работать (со звуком)

И даже в полноэкранном режиме

Enjoy.

Оригинал: http://howtoforge.org/video_streaming_lighttpd_flowplayer

apt-get install mysql-server mysql-client

Задаем пароль для пользователя root (замените yourrootsqlpassword на ваш пароль)

mysqladmin -u root password yourrootsqlpassword

Проверим, какие адреса слушает MySQL, при помощи команды

netstat -tap | grep mysql

Вывод должен быть примерно таким:

tcp        0      0 localhost.localdo:mysql *:*                     LISTEN     2713/mysqld

Это значит, что MySQL слушает только localhost.localdomain и вы установили пароль. Если же вывод похож на:

tcp        0      0 *:mysql *:*                     LISTEN     2713/mysqld

вам необходимо также установить пароль для вашего хоста (в нашем примере это server1.example.com), иначе кто-угодно сможет подключиться к БД и манипулировать данными

mysqladmin -h server1.example.com -u root password yourrootsqlpassword

Устанавливаем Lighttpd, Python и python-mysqldb
Мы будем использовать скрипт, написанный на Python, для чтения конфигурации из БД. Устанавливаем все необходимое:

apt-get install lighttpd python python-mysqldb

Подготовка базы данных
Подключаемся к MySQL:

mysql -u root -p

создаем базу данных и пользователя. А также даем пользователю привилегии SELECT для запросов к нашей базе

CREATE DATABASE lighttpd;
GRANT SELECT ON lighttpd.* TO lighttpd@localhost IDENTIFIED BY 'secret';
GRANT SELECT ON lighttpd.* TO lighttpd@localhost.localdomain IDENTIFIED BY 'secret';
FLUSH PRIVILEGES;

Не забудьте заменить “secret” на реальный пароль
Осталось создать таблицу для наших виртуальных хостов и подготовка БД на этом закончена

USE lighttpd;
CREATE TABLE IF NOT EXISTS domains (
domain varchar(64) NOT NULL PRIMARY KEY,
docroot varchar(128) NOT NULL,
config text
);
quit;

Сценарий для получения данных из БД
Создаем скрипт на python, который будет читать из БД конфигурацию виртуальных хостов

#!/usr/bin/env python
import sys
import MySQLdb

# load configuration data from the database
db=MySQLdb.connect(host='localhost', db=sys.argv[1], user=sys.argv[2], passwd=sys.argv[3])
cur = db.cursor()
cur.execute("SELECT * FROM domains")
rs=cur.fetchall()
db.close()

for domain in rs:

    print "$HTTP[\"host\"] == \"%s\" {\nserver.document-root = \"%s\"\n%s\n}" % (domain[0], domain[1], domain[2])

и сохраняем его в /usr/share/lighttpd/mysql_vhost.py
Делаем скрипт исполняемым

chmod 755 /usr/share/lighttpd/mysql_vhost.py

Теперь надо настроить Лайти для использования нашего срипта. Для этого открываем конфиг /etc/lighttpd/lighttpd.conf и добавляем в конец следующую строчку

[...]
include_shell "/usr/share/lighttpd/mysql_vhost.py lighttpd lighttpd secret"

(первый параметр – это имя БД, второй – имя пользователя БД, третий – пароль для доступа к БД)
После всех изменений перезапустим lighttpd

/etc/init.d/lighttpd restart

Настройка виртуальных хостов
В примере мы настроим два виртуальных хоста: www.example.com (с корневым разделом в /var/www/www.example.com/web) и www.example.org (с корневым разделом в /var/www/www.example.org/web). Мы будем использовать различные параметры для каждого хоста для демонстрации возможностей :)
Для www.example.com мы разрешим листинг директорий и создадим алиас test, который будет указывать на DocumentRoot. Для
www.example.org листинг директорий будет отключен.

Если корневые разделы еще не существуют, то создадим их:

mkdir -p /var/www/www.example.com/web
mkdir -p /var/www/www.example.org/web

Подключаемся к MySQL и добавим описание наших хостов

INSERT INTO domains VALUES ('www.example.com','/var/www/www.example.com/web/','dir-listing.activate = "enable"\nalias.url = ( "/test" => "/var/www/www.example.com/web" )');
INSERT INTO domains VALUES ('www.example.org','/var/www/www.example.org/web/','dir-listing.activate = "disable"');

Обратите внимание на первый запрос INSERT. Если вы хотите использовать более одной директивы, то поместите между ними управляющий символ “\n”
Все, виртуальные хосты настроены. Для проверки корректности работы нашего скрипта, запустим его из командной строки:

/usr/share/lighttpd/mysql_vhost.py lighttpd lighttpd secret

В выводе должна содержаться корректная информация о наших хостах:

server1:~# /usr/share/lighttpd/mysql_vhost.py lighttpd lighttpd secret
$HTTP["host"] == "www.example.com" {
server.document-root = "/var/www/www.example.com/web/"
dir-listing.activate = "enable"
alias.url = ( "/test" => "/var/www/www.example.com/web" )
}
$HTTP["host"] == "www.example.org" {
server.document-root = "/var/www/www.example.org/web/"
dir-listing.activate = "disable"
}
server1:~#

В отличие от mod_mysql_vhost, наш способ требует перезапуска сервера

/etc/init.d/lighttpd restart

Тестируем
Пришло время проверить, верно ли работают наши виртуальные хосты. В корневых директориях хостов нет индексных файлов
http://www.example.com (листинг директорий включен)

http://www.example.com/test Директории test не существует, но мы прописали алиас для этого пути. Поэтому мы видим содержимое DocumentRoot

http://www.example.org Мы получаем ошибку 404, потому что индексного файла нет, а листинг директорий отключен

http://www.example.org/test Листинг директорий отключен, и мы не делали алиасов для этого хоста. Поэтому все та же ошибка 404

Оригинал: http://howtoforge.org/creating-advanced-mysql-based-vhosts-on-lighttpd-debian-etch

Начнем
Перед установкой APC, мы посмотрим на конфигурацию PHP. Для этого мы создадим файл info.php в домашней директории Лайти (/var/www в нашем примере):

vim /var/www/info.php

Со следующим содержанием:

<?php
phpinfo();
?>

И вызовем его через браузер, у нас он находится по адресу http://192.168.0.100/info.php:

Как мы видим, у нас установлен PHP версии 5.2.0… Но APC нет :(

Установка APC
APC – это расширение для PHP, доступное через PECL. PECL можно установить через php-pear, поэтому сначала давайте установим pear:

apt-get install php-pear

Кроме того, мы должны установить некоторые зависимости APC, чтобы PECL смог его собрать

apt-get install php5-dev build-essential

Ну вот и все, зависимости установлены, ставим APC

pecl install apc

Нюанс: на следующий вопрос ответьте “Нет” (No):

[...]
Use apxs to set compile flags (if using APC with Apache)? [yes] : <– no
[...]

Теперь, когда APC установлен, создадим конфигурационный файл /etc/php5/cgi/conf.d/apc.ini Единственно необходимая опция – это, собственно, активация самого APC: extension=apc.so Остальные опции являются необязательными, подробнее можно прочитать на http://php.net/manual/en/ref.apc.php

vim /etc/php5/cgi/conf.d/apc.ini

extension=apc.so
apc.enabled=1
apc.shm_size=30

Это все :) Давайте снова зайдем на нашу информационную страничку (http://192.168.0.100/info.php) и убедимся, что APC работает

Оригинал: http://howtoforge.org/integrating-apc-into-php5-and-lighttpd-debian-etch

# httpd -X

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

Проверка конфигурационного файла
Для некоторых веб-проектов конфигурационные файлы Apache разрастаются в геометрической прогрессии и локализовать ошибки в них становится все труднее. Сам сервер предлагает два способа решения этой проблемы. Первый – это запуск сервера с ключом -t, который активирует проверку конфигурационного файла:

$ httpd -t -c httpd.conf
Syntax error on line 236 of /etc/httpd/httpd.conf: LogLevel requires level keyword: one of emerg/alert/crit/error/warn/notice/info/debug

Если ошибка найдена, то apache предложит возможные способы ее устранения. В приведенном примере неверно задано значение для директивы LogLevel.
Если проверка говорит, что с конфигами все в порядке, но сервер, тем не менее, не стартует, то можно включить вывод более подробной информации в error_log: для этого установите директиву LogLevel в значение Debug в конфигурационном файле.

Отладка cgi-сценариев
Apache позволяет выполнять сценарии, написанные практически на любом языке, при помощи mod_cgi. Эти сценарии могут формировать динамический контент по запросу клиента. Но вот локализация ошибок в подобных программах может стать не очень тривиальной задачей.
Один из способов отладки таких скриптов – это директива ScriptLog модуля mod_cgi. Когда директива активирована, то сервер записывает в лог-файл вывод любого скрипта, работа которого завершилась неудачно. Вывод включает в себя код ответа сервера, запрос от клиента и ответ клиенту (если он имел место быть). Это великолепный отладочный инструмент для сценариев, которые не пишут ошибки в “традиционный” error_log или для быстрого выяснения проблемы, когда “что-то не работает”
Для активирования логирования CGI-скриптов необходимо добавить директиву ScriptLog и указать расположение лог-файла в конфигурационном файле Apache. Когда логирование включено, mod_cgi пишет примерно вот такие логи:

%% [Tue Dec 26 14:47:21 2006] GET /cgi-bin/print HTTP/1.1
%% 500 /var/tmp/apache/cgi-bin/print
%request
Accept: */*
Accept-Language: en
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/418.9.1 (KHTML, like Gecko) Safari/419.3
Connection: keep-alive
Host: 192.168.1.3:8080
%response
Script /cgi-bin/print
%stdout
Script Location /var/tmp/apache/cgi-bin/print

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

Отладка запросов и ответов
При поддержке веб-приложений необходимо четко локализовать место ошибки: это может сервер приложений, прокси-сервер или же сам веб-сервер. Для облегчения этого процесса хорошо помогает полный дамп диалога сервера с клиентом (то есть все запросы клиента и ответы сервера). Модуль mod_dumpio предназначен как раз для записи заголовков запроса и ответа в error_log. Настройка mod_dumpio выполняется очень быстро и просто: для логирования запросов директива DumpIOInput должна быть установлена в значение On; для логирования ответов установите в On директиву DumpIOOutput. Когда логирование активно, то в error_log появятся примерно вот такие строки:

Sat Oct 28 10:52:31 2006] [debug] mod_dumpio.c(103): mod_dumpio: dumpio_in [getline-blocking] 0 readbytes
[Sat Oct 28 10:52:31 2006] [debug] mod_dumpio.c(51): mod_dumpio: dumpio_in (data-HEAP): 16 bytes
[Sat Oct 28 10:52:31 2006] [debug] mod_dumpio.c(67): mod_dumpio: dumpio_in (data-HEAP): GET / HTTP/1.1rn
< ….. >

Модуль mod_dumpio создает небольшую дополнительную нагрузку при обработке запросов и включение/выключение директив потребует его перезапуска. Вы можете мягкую перезагрузку (graceful restart) чтобы не потерять активных соединений.

Локализация причин “зависания” сервера
Apache прекрасно оттестирован, но, тем не менее, ошибки все равно есть. Они могут выражаться в “подвисаниях” сервера, внезапных остановках или в неверном контенте, переданном пользователю. Когда случаются подобные ситуации, главное – это быстро найти модуль, который вызвал ошибку.
Один из способов локализации ошибок такого рода – это просмотр стека вызовов подвисшего процесса. Стек вызовов содержит список функций, вызванных до той, которая породила ошибка. После зависания вам, вероятно, захочется узнать имя некорректно работающей функции, хотя бы для того, чтобы использовать его в качестве аргумента при поиске ошибки в багтрекерах и в качестве отправной точки при анализе кода сбойного модуля.

Одна из утилит, позволяющих получить такой стек, называется pstack. Она возвращает стек вызовов для процесса, номер которого передается ей в качестве аргумента.

$ pstack 18756

18756: bin/httpd -k start
ff040628 accept (3, 11c560, 11c54c, 1)
0004c3c4 unixd_accept (ffbff904, 7d490, 11c3a0, 0, 2710, 0) + 10
0004a3c0 child_main (7d490, 74400, 4e2e, 74000, 0, 74000) + 2ec
0004a6c8 make_child (4a000, 0, 1, 5, 72c00, 74000) + ec
0004b0e8 ap_mpm_run (72c00, 74000, 74000, 74000, 74000, 74400) + 934
000272d8 main (7ef18, 71c00, 73800, 73800, 0, 0) + 710
00026618 _start (0, 0, 0, 0, 0, 0) + 5c

На платформах, где нет pstack можно воспользоваться утилитами gdb и gcore для получения стека вызовов. Для подключения к процессу напрямую и получению стека вызовов gdb должен быть запущен с ключом -p, идентификатором процесса и вызовом backtrace уже внутри оболочки отладчика

#0 0x0046e7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x0063b681 in accept () from /lib/tls/libpthread.so.0
#2 0x00b14814 in apr_socket_accept (new=0xbff85740, sock=0×9671538,
connection_context=0x97115d8) at network_io/unix/sockets.c:187
#3 0x080819ce in unixd_accept (accepted=0xbff85774, lr=0×9671518, ptrans=0x97115d8) at unixd.c:466
#4 0x0807fd2e in child_main (child_num_arg=Variable “child_num_arg” is not available.) at prefork.c:621
#5 0x0807ffc2 in make_child (s=Variable “s” is not available.) at prefork.c:736
#6 0×08080050 in startup_children (number_to_start=5) at prefork.c:754
#7 0x0808089b in ap_mpm_run (_pconf=0x96730a8, plog=0x96a1160, s=0x9674f48) at prefork.c:975
#8 0x08061b08 in main (argc=3, argv=0xbff85a84) at main.c:717

Каждый дамп стека вызовов содержит несколько фрагментов отладочной информации, однако для полноценного устранения проблемы необходимо бОльшее количество информации и выборочный дамп структур данных сервера. Это может оказаться неприемлемым для проектов, не позволяющих даже кратковременных остановок. В этом слкчае на помощь приходит утилита gcore. Она может сгенерировать core-файл для зависшего процесса, который может быть использован для анализа ситуации системными администраторами и производителями операционных систем. В примере показано использование gcore для получения core-файла и использование gdb для анализа полученной информации:

$ gcore 5649
$ gdb -q /usr/sbin/httpd core.5649 (gdb) backtrace

#0 0x0046e7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x0063b681 in accept () from /lib/tls/libpthread.so.0
#2 0x00b14814 in apr_socket_accept (new=0xbff85740, sock=0×9671538,
connection_context=0x97115d8) at network_io/unix/sockets.c:187
#3 0x080819ce in unixd_accept (accepted=0xbff85774, lr=0×9671518, ptrans=0x97115d8) at unixd.c:466
#4 0x0807fd2e in child_main (child_num_arg=Variable “child_num_arg” is not available.) at prefork.c:621
#5 0x0807ffc2 in make_child (s=Variable “s” is not available.) at prefork.c:736
#6 0×08080050 in startup_children (number_to_start=5) at prefork.c:754
#7 0x0808089b in ap_mpm_run (_pconf=0x96730a8, plog=0x96a1160, s=0x9674f48) at prefork.c:975
#8 0x08061b08 in main (argc=3, argv=0xbff85a84) at main.c:717

В приведенных выше примерах можно увидеть, что выполнялась функция accept(), когда был получен системный сигнал SIGSEGV, которая, в свою очередь, была вызвана из метода apr_socket_accept(). Если эта проблема известна и описана, то выможете использовать эту информацию для поиска по базам данных ошибок. Для более подробной информации обратитесь к официальной документации.

Локализация причин аварийных остановок сервера
Если процесс Apache аварийно завершился, то pstack и gcore будут бесполезны, так как процесс уже завершен. Теоретически, core-файл должен записываться в директорию, определенную в ServerRoot, но у пользователя, под которым запущен сервер, должны быть права на запись в эту директорию, должно быть достаточное количество дискового пространства. Если политики безопасности запрещают запись в ServerRoot, то можно определить местоположение core-файла при помощи директивы CoreDumpDirectory

На некоторых платформах нет возможности автоматически генерировать core-файл. Если вы используете именно такую платформу, то вам поможет модуль mod_backtrace. Этот модуль срабатывает при получении любого сигнала, останавливающего работу приложения (например SIGSEGV, SIGBUS итд.) При получении подобного сигнала mod_backtrace вызывает платформо-зависимую функцию для генерации стека вызовов и пишет его в error_log.

Этот модуль распространяется в исходных кодах и может быть загружен с сайта Apache

$ wget http://people.apache.org/~trawick/mod_backtrace.c

Для установки и подключения модуля утилита Apache apxs c ключом -c для сборки модуля и с ключом -i для его установки.

$ apxs -ci mod_backtrace.c

Для использования mod_backtrace apache должен быть собран с поддержкой ExceptionHook. Для этого можно указать “–enable-exception-hook” при сборке сервера. Когда модуль установлен, загружен и exception hook активен, то активировать модуль можно при помощи директивы LoadModule и установки директивы EnableExceptionHook в значение On:

LoadModule backtrace_module modules/mod_backtrace.so
EnableExceptionHook On

После активации модуля при получении сервером критического сигнала в error_log окажутся похожие строки:

$ kill -SIGSEGV 18745

[Wed Dec 20 16:48:32 2006] pid 18745 mod_backtrace backtrace for sig 11 (thread “pid” 18745)
[Wed Dec 20 16:48:32 2006] pid 18745 mod_backtrace main() is at 26bc8
/var/tmp/apache/modules/mod-backtrace.so:bt_exception_hook+0×108
/var/tmp/apache/bin/httpd:ap_run_fatal_exception+0×34
/var/tmp/apache/bin/httpd:0×32788
/lib/libc.so.1:0xc01dc
/lib/libc.so.1:0xb52d4
/lib/libc.so.1:_so_accept+0×8 [ Signal 11 (SEGV)]
/var/tmp/apache/bin/httpd:unixd_accept+0×10
/var/tmp/apache/bin/httpd:0x3a3c0
/var/tmp/apache/bin/httpd:0x3a6c8
/var/tmp/apache/bin/httpd:0x3a798
/var/tmp/apache/bin/httpd:ap_mpm_run+0x9d4
/var/tmp/apache/bin/httpd:main+0×710
/var/tmp/apache/bin/httpd:_start+0x5c
[Wed Dec 20 16:48:32 2006] pid 18745 mod_backtrace end of backtrace

mod_backtrace использует backtrace() на GNU системах и printstack() на платформах Solaris для получения корректного стека вызовов. В некоторых случаях дамп может содержать некорректные символы. В этом случае вам помогут утилиты nm, readelf и elfdump. Для использования mod_backtrace на хостах с Solaris на него необходимо наложить патч (ссылка на патч приведена в конце статьи)

Отладка в “режиме разработчика” и макросы gdb для apache
Отладка на основе core-файлов – это искусство, требующее недюжинных знаний отлаживаемого кода и технологий его написания и сопровождения. Разработчики Apache это понимают и поэтому они реализовали несколько отличных инструментов для отладки сервера и включили два ключевых приема отладки в сервер. Первый – это так называемый “режим разработчика” (maintainer mode). Для его активации необходимо собрать сервер с ключом –enable-maintainer-mode. Этот режим включает отладочную информацию для всех функций сервера, в нем отсутствует оптимизация и исходный код на С может быть показан при помощи дебаггера.

Второй ключевой момент – это gdb-макросы. С их помощью можно увидеть содержмое сложных структур данных apache (например цепочек фильтров), эти сведения очень полезны при анализе core-файлов, полученных после сбоя сервера. Эти макросы находятся в файле .gdbinit, который расположен в корневой директории с исходными кодами сервера. Если вы хотите больше узнать о этих макросах, то в конце статьи приведены ссылки.

Использование исходного кода Apache для устранения проблем
Когда анализ лог-файлов, core-файлов и использование системных утилит не приносит результатов, можно обратиться напрямую к исходным кодам сервера. Исходный код помещен в четкую иерархическую структуру и каждый каталог содержит код конкретного объекта. В релизе 2.2.3 в дереве содержатся следующие каталоги:

• $SRCROOT/server – ядро сервера
• $SRCROOT/include – заголовочные файлы
• $SRCROOT/srclib/apr – окружение среды выполнения
• $SRCROOT/srclib/apr-util – утилиты среды выполнения
• $SRCROOT/support – утилиты
• $SRCROOT/modules – модули

Если стек вызовов или сессия отладки показывают на проблему со специфичной функцией, то можно найти ее описание в дереве исходных кодов при помощи утилиты find

$ find . -name \*.h | xargs egrep “apr_array_make”

./srclib/apr/include/apr_tables.h:APR_DECLARE(apr_array_header_t *) apr_array_make(apr_pool_t *p, …
< … >

После того, как описание найдено, при помощи find и grep можно найти и ее определение:

$ find . -name \*.c | xargs egrep “apr_array_header_t.*apr_array_make”

/srclib/apr/tables/apr_tables.c:APR_DECLARE(apr_array_header_t *) apr_array_make(apr_pool_t *p, …
< … >

В приведенном пример прототип функции находится в файле apr_tables.h, а описание в apr_tables.c. Но помните, что в зависимости от того, что вы ищете (функцию или макрос) результаты поиска могут потребовать дополнительной обработки.

Полезные ссылки
Официальный сайт Apache
Внутреннее устройство и отладка Apache
Устройство модулей в Apache2
Модуль mod_backtrace
Патч для модуля mod_backtrace для использования на платформе Solaris

Оригинал: http://prefetch.net/articles/debuggingapache.html