заметки на полях » debian

Ограничение канала для отдельных приложений

Дерябин Сергей — Sun, 09 Jan 2011 22:09:29 +0000

В один прекрасный момент может сложиться ситуация когда приложение непростительно отжирает весь канал, когда хотелось бы ограничить его небольшими ресурсами. У меня возникла такая проблема когда скрипт резервного копирования начинал перекладывать архивы с бэкапами на FTP. Т. к. FTP для бэкапов является локальным ресурсом и скорость подключения к нему большая, то и получалось что скрипт отжирал весь канал, в результате чего в логах на время копирования вываливались ошибки от nginx

8557#0: *8936853 upstream timed out (110: Connection timed out) while reading response header from upstream

а HostTracker начинал слать уведомления об ошибке доступа к ресурсу.

Решением явилось использование утилиты trickle

$ sudo apt-get install trickle

Можно использовать как демон (trickled), а можно независимо для приложений. Самые нужные в данный момент ключи, это trickle -d 512 -u 512 ... устанавливающие в данном случае скорость в 512 килобайт в секунду для входящего и исходящего трафика соответственно.

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

ftp -n $FTPHOST <<EOF

на

trickle -d 512 -u 512 ftp -n $FTPHOST <<EOF

Вот собственно первое что нагуглил по теме когда искал решение: Ограничение сетевого трафика для приложений и от этого уже пошел +

$ man trickle

Перевод сайта c cp1251 на UTF-8

Дерябин Сергей — Wed, 13 Jan 2010 18:57:03 +0000

Для начала перевести БД из cp1251 в utf8.
Сделать дамп mysqldump -u svd -n --skip-opt --skip-set-charset --triggers --disable-keys svdev > dump.sql – получится чистый дамп без упаминания кодировок, можно получить отдельно данные: mysqldump -u svd -nt --skip-opt --skip-set-charset --disable-keys svdev > data.sql, поменять кодировку полей в схеме, вместо:

name VARCHAR(64) CHARACTER SET cp1251 NOT NULL

сделать

name VARCHAR(64) CHARACTER SET utf8 NOT NULL

или же убрать упоминание кодировки из полей вовсе:

name VARCHAR(64) NOT NULL

так как при установке правильной кодировки для БД кодировки для текстовых полей создаваемых таблиц будут устанавливаться верно сами, затем изменить кодировку самой БД:

ALTER DATABASE svdev DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci

и залить назад в обратном порядке – сначала структуру, затем данные.
Следующим шагом необходимо изменить кодировку файлов, для этого я набросал простенький скрипт (подключаемые библиотеки которые трогать не надо – типа tiny просто вынес сначала из проекта, а затем вернул обратно:

#!/bin/sh
for FILE in `find /var/www/svdev/ | egrep -i "\.(php|html)$"`
do
iconv -f cp1251 -t utf8 $FILE > $FILE".utf"
mv -f $FILE".utf" $FILE
echo $FILE" - work complete"
done

Он в заданной директории файлы по маске .php и .html перекодирует в UTF используя утилиту iconv во временный файл, а затем перезаписывает исходный файл временным.
Следующим шагом убедимся в правильной настройке mb_ функций PHP. Для этого создадим файлик vim strtest.php и положим в него следующее содержимое:

echo strlen("мама мыла раму") . "\n";
echo mb_strlen("мама мыла раму") . "\n";
echo mb_strlen("мама мыла раму", "UTF-8");
?>

Правильная длина строки – 14 символов. Выполним его из консоли: php5-cgi strtest.php В начале у меня получилось следующее:

X-Powered-By: PHP/5.2.10-2ubuntu6.3
Content-type: text/html

26
26
14

Для исправления – установим верные значения в /etc/php5/cgi/php.ini и /etc/php5/cli/php.ini, для этого по файлу надо поискать encoding и charset
Нашлись следующие параметры:

default_charset = "UTF-8"
...
mbstring.language = Russian
mbstring.internal_encoding = UTF-8

Теперь при повторном выполнении теста php5-cgi strtest.php второе значение без указания кодировки должно совпасть с первым и появиться кодировка по умолчанию:

X-Powered-By: PHP/5.2.10-2ubuntu6.3
Content-type: text/html; charset=UTF-8

26
14
14

Так же не лишним будет в конфиге проекта указать верно локаль, к примеру setlocale(LC_ALL, "ru_RU.utf8"); список доступных локалей в системе можно посмотреть locale -a (ну и на всякий случай проверить что с новой локалью не будет багов, подробнее здесь: Как float зависит от локали?! )
Указать кодировку в настройках nginx для нужного сайта /etc/nginx/sites-available/svdev:

server {
...
charset UTF-8;
source_charset UTF-8;
...
}

Ну и самая нудная часть – пройтись по проекту и заменить функции работы со строками на их mb_ аналоги, в используемые регулярные выражения добавить модификатор u и если отправляются где-то письма – изменить кодировку писем.
Ну вот вроде и все! Перед всеми манипуляциями неплохо бы сделать резервную копию файлов и БД, на всякий случай.

Дополнительное чтиво

PHP библиотека GD в debian сборке или выкидываем GD на помойку

Дерябин Сергей — Thu, 24 Dec 2009 00:34:00 +0000

В ходе работы выяснилась неприятная вещь – в библиотеке GD под debian отсутствуют некоторые функции, я столкнулся именно с imagerotate. Некоторые предлагают пересобрать PHP c использованием библиотеки разработчиков, вместо системной, но нашлось более элегантное решение – ImageMagick и PHP обертка для нее Imagick.
Собственно давно уже пора переходить на её использование:

быстрее
возможность выбора различных фильтров при ресайзе
ОО интерфейс
нет необходимости заморачиваться с типами файлов – все уже сделано за нас
эксепшены вместо ошибок

Ну и наверняка есть еще достоинства, которые просто не пришли вот так сразу в голову.

Поставим её.

sudo apt-get install imagemagick
sudo apt-get install php-pear
sudo pecl install imagick

Если второй шаг завершится ошибкой, вроде этой: ERROR: `phpize' failed то необходимо установить:

sudo apt-get install php5-dev

и повторить установку Imagick, при возникновении ошибки ERROR: `/tmp/pear/temp/imagick/configure --with-imagick' failed необходимо дополнительно установить:

# для debian:
sudo apt-get install libmagick9-dev
# для убунты:
sudo apt-get install libmagickwand-dev

Теперь Imagick должен точно встать, если нет – то дальше в Google.
Осталось только прописать новую либу в php.ini:

extension=imagick.so

http://www.php.net/manual/en/book.imagick.php – дока по Imagick
http://valokuva.org/?cat=1 – блог с полезными и познавательными примерами использования Imagick

Backup проекта, часть 2

Дерябин Сергей — Tue, 22 Dec 2009 17:54:40 +0000

Немного ранее, был представлен SHELL скрипт резервного сохранения данных проекта. При наличии нескольких проектов хочется каким-то образом систематизировать этот процесс, для облегчения подключения новых проектов к резервному копированию, кроме как плодить файлы с дублированием кода, учитывая тот факт, что со временем может измениться логика выполняемых действий или настройки подключения к БД/FTP серверу.

Вынесем общую логику в отдельный скрипт, а индивидуальные данные проекта, такие как имя БД и загружаемые файлы в конфигурационный файл для каждого проекта.

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

CREATE USER backup@localhost IDENTIFIED BY 'dbpassword';
GRANT SELECT, LOCK TABLES ON svdev.* TO backup@localhost;

Далее немного модифицируем скрипт из предыдущей части для подключения настроек. Так же проект может не использовать БД или использовать совместно с другим проектом, в этом случае достаточно сохранить её один раз – такая возможность так же реализована. Вот что получилось в итоге:

#!/bin/sh

#Данные для подключения к БД

DBUSER="backup"
DBPASS="dbpassword"

# FTP для сохранения данных
FTPUSER='ftpuser'
FTPHOST='ftphost'
FTPPASS='ftppassword'

# Путь на FTP где хранятся бэкапы, общая директория,
# в которой для каждого проекта есть поддиректория,
# путь от домашней директории пользователя FTP
FTPPATH="./"

# Дата, для именования файла бэкапа в формате YYYY.MM.DD
DT=`date '+%Y.%m.%d'`
# Временная директория для хранения файлов
TEMPDIR="/tmp/backup-"$DT"/"
SQLFILE="dump.sql"
# Файл архива
DESTFILE=$DT".tar"

mkdir $TEMPDIR
cd $TEMPDIR

echo "Начало резервного копирования: "`date '+%F %T'`

# Если все проекты находятся в директории /var/www то для каждого, который
# необходимо сохранить должен быть файл backup.conf
for CONFIG in `find /var/www -mindepth 2 -maxdepth 2 -name backup.conf`
do
. $CONFIG
# Если в конфиге установлено имя БД, до делаем её дамп
# и добавляем в архив
if [ ! -z $DBNAME ]; then
mysqldump --user=$DBUSER --password=$DBPASS $DBNAME > $SQLFILE
TARFILES=$TARFILES" -C "$TEMPDIR" "$SQLFILE
fi

tar -cf $DESTFILE $TARFILES
gzip -9 $DESTFILE

# Отправляем полученный архив на FTP; не забываем
# включить бинарный режим передачи, иначе архивы побъются
ftp -n $FTPHOST <<EOF
quote USER $FTPUSER
quote PASS $FTPPASS
binary
cd $FTPPATH$PROJECTNAME
put $DESTFILE".gz"
quit
EOF

echo " - "`date '+%F %T'`" проект "$PROJECTNAME" сохранен, размер архива "`stat -c %s $DESTFILE'.gz'`" байт;"

# Удаляем за собой все файлы
for TFILE in $TEMPDIR"/*"
do
rm -rf $TFILE
done
done

# Удаляем за собой временную директорию
rm -rf $TEMPDIR

Полученный файл назовем sites-backup и положим его в /etc/cron.daily/ таким образом он будет запускаться один раз в сутки, вместе с остальными служебными скриптами, такими как ротация логов и другие. Для пущей надежности права на файл лучше дать 700 и сделать владельцем рута:

sudo chown root:root /etc/cron.daily/sites-backup
sudo chmod 0700 /etc/cron.daily/sites-backup

Осталось только для каждого проекта создать файл конфига. К примеру для проекта svdev, получаем следующий конфиг /var/www/svdev.ru/backup.conf:

#!/bin/sh
DBNAME="svdev"
PROJECTNAME="svdev.ru"
TARFILES=" -C /var/www/svdev.ru/htdocs wp-config.php -C /var/www/svdev.ru/htdocs/wp-content uploads"

Если БД не используется, то необходимо указать пустую строку в качестве имени БД:

#!/bin/sh
DBNAME=""
PROJECTNAME="svdev.ru"
TARFILES=" -C /var/www/svdev.ru/htdocs wp-config.php -C /var/www/svdev.ru/htdocs/wp-content uploads"

Теперь для создания бэкапов нового проекта необходимо дать права пользователю скрипта на БД, создать на удаленном FTP директорию куда будут складываться архивы и добавить конфиг из 3х строчек.

Главное не забывать вовремя чистить FTP.

Ротация логов nginx

Дерябин Сергей — Sat, 19 Dec 2009 14:45:07 +0000

Простенький скрипт, который проверяет доступность пакета logrotate и запускает ротацию. Кладется в /etc/cron.daily и запускается как правило в 4 часа утра, за это отвечает запись в /etc/crontab (у меня в 6 часов 25 минут):

25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )

Сам скрипт, запускающий суточные задания:

#!/bin/sh

test -x /usr/sbin/logrotate || exit 0
/usr/sbin/logrotate /etc/logrotate.conf

Среди которых ротация логов nginx:

/var/log/nginx/*.log /var/www/*/logs/error.log {
daily
missingok
rotate 1
compress
delaycompress
notifempty
create 640 root adm
sharedscripts
postrotate
[ ! -f /var/run/nginx.pid ] || kill -USR1 `cat /var/run/nginx.pid`
cat /var/log/nginx/error.log.1 | mail -s "Nginx error log" root
cat /var/www/*/logs/error.log.1 | mail -s "Sitests nginx error log" root
endscript
}

Что здесь происходит? Ротируются логи nginx из /var/log/nginx а за позапрошлый день сжимаются и так же с логами для всех проектов, если учесть что проекты находятся в /var/www а логи соответственно в директории logs проекта. А логи за предыдущий день отправляются на почту рута двумя письмами – одно со всех проектов, а второе самого nginx.

Backup проекта

Дерябин Сергей — Wed, 25 Nov 2009 20:20:07 +0000

Люди делятся на тех кто еще не делает
и тех, кто уже делает бэкапы

Обязательным свойством любого проекта являются резервное сохранение данных. И так, приступим. Допустим все данные у нас хранятся в БД (в моем случае mysql, но если это postgres – отличие будет в одной строчке) и существуют различные файлы загружаемые пользователями. Файлы проекта хранятся в репозитории, поэтому за их сохранность можно не беспокоиться (можно на всякий случай еще сохранять конфиг). Так же понадобится другая машина для сохранения бэкапов, более чем достаточно иметь FTP на другой машине.

UPD: Немного подчищен код и приведен к соответствию соглашениям.

Начнем с сохранения БД:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

#!/bin/sh

# Данные для подключения к БД
DBUSER="dbuser"
DBNAME="dbname"
DBPASS="password"

# Дата, для именования файла бэкапа в формате YYYY.MM.DD
DT=`date '+%Y.%m.%d'`
# Временная директория для хранения файлов
TEMPDIR="/tmp/backup-"$DT"/"
SQLFILE="backup.sql"

mkdir $TEMPDIR
cd $TEMPDIR

mysqldump --user=$DBUSER --password=$DBPASS $DBNAME > $SQLFILE

Итак у нас теперь есть дамп БД и мы знаем какие пользовательские файлы необходимо сохранять. Собираем их в один архив, сжимаем его и кладем через FTP на другую машину. В итоге получается следующий скрипт:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

#!/bin/sh

# Данные для подключения к БД
DBUSER="dbuser"
DBNAME="dbname"
DBPASS="password"

# Данные для подключения по FTP
FTPUSER='ftpuser'
FTPHOST='ftp.svdev.ru'
FTPPASS='password'

# Дата, для именования файла бэкапа в формате YYYY.MM.DD
DT=`date '+%Y.%m.%d'`
# Временная директория для хранения файлов
TEMPDIR="/tmp/backup-"$DT"/"
SQLFILE="backup.sql"
# Путь на FTP куда положим файл
# !!! Путь от корня домашней директории FTP
REMOTEDIR="backups/svdev"
# Файл архива
DESTFILE=$DT".tar"

TARFILES=" -C /var/www/svdev/htdocs wp-config.php -C /var/www/svdev/htdocs/wp-content uploads -C "$TEMPDIR" backup.sql"

mkdir $TEMPDIR
cd $TEMPDIR
mysqldump --user=$DBUSER --password=$DBPASS $DBNAME > $SQLFILE
tar cf $DESTFILE $TARFILES
gzip -9 $DESTFILE
ftp -n $FTPHOST < quote USER $FTPUSER
quote PASS $FTPPASS
binary
cd $REMOTEDIR
put $DESTFILE".gz"
quit
EOF

# Удаляем за собой все временные файлы
rm -rf $TEMPDIR

exit 0

Вот в принципе и все, осталось прописать его в крон и можно наслаждаться результатом.

Данный пример является самым простым, что хотелось бы добавить:

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

Можно скачать приведенный пример: backup.tar.gz и поэксперементировать с ним в свое удовольствие.

Использованный полезный материал:

Advanced Bash-Scripting Guide
Shell-кодинг (азы так сказать)

Вывод ошибок PHP в логи nginx

Дерябин Сергей — Mon, 10 Aug 2009 19:06:34 +0000

После того как не осталось Apache, то и негде посмотреть ошибки PHP привычным способом (в логах Апача); сделаем что бы nginx вел лог ошибок PHP. nginx перехватывает то, что ему пришло от php-fastcgi на stderr и пишет это в лог, предваряя примерно следующим:

2009/08/10 22:54:38 [error] 11004#0: *7 FastCGI sent in stderr:

Теперь же осталось только отдавать эти самые ошибки и предупреждения из PHP на stderr, для этого надо немного подправить конфиг /etc/php5/cgi/php.ini:

; лишним здесь ничего не будет :) пусть пишет все!
error_reporting = E_ALL

; первый параметр отвечает как раз за отдаду ошибок на фронтэед
display_errors = "stderr"
;
; stdout (On) - Display errors to STDOUT
; здесь же ошибки будут выводиться на экран, для сервера разработки -
; это оптимальный вариант, а вот на боевом их все таки лучше отключить
display_errors = On
; Ну и последняя опция, что бы PHP все таки
; писал ошибки в лог (в нашем случае отдавал на stderr)
log_errors = On

Готово! Осталось только перезапустить php-cgi:

sudo /etc/init.d/init-fastcgi restart

php + memcached

Дерябин Сергей — Tue, 04 Aug 2009 18:36:48 +0000

Установим все что может понадобиться для использования связки php + memcached.

1	sudo apt-get install memcached php5-memcache

Единственный файл конфига /etc/memcached.conf:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

# запустить как "демон"
-d

# лог файл
logfile /var/log/memcached.log

# я так понимаю расширенный формат лога :)
# -v

# ограничение памяти в мегабайтах
-m 512

# слушать порт
-p 11211

# от имени какого пользователя запускать,
# если параметр не указан, то будет запущен от root
-u nobody

# какой интерфейс слушать
-l 127.0.0.1

И ротация единственного файла логов sudo vim /etc/logrotate.d/memcached:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

/var/log/memcached.log {
daily
missingok
size 2M
rotate 2
compress
delaycompress
notifempty
create 640 root adm
sharedscripts
postrotate
/etc/init.d/memcached restart > /dev/null
endscript
}

Команда скорее всего не понадобится, т. к. в автозагрузку пакет добавится при установке, но на всякий случай:

1	sudo update-rc.d memcached defaults

Nginx + PHP-FastCGI или избавляемся от apache

Дерябин Сергей — Sat, 01 Aug 2009 13:41:16 +0000

В предыдущем шаге мы уже убрали apache слушать только локальные запросы (те которые приходят от nginx) теперь же пришло время убрать его совсем и заставить nginx обрабатывать все самому!

Для этого понадобится php5-cgi, если он еще не установлен, необходимо поставить:

1	sudo apt-get install php5-cgi

Для запуска php потребуется утилита spawn-fcgi от lighttpd. Сейчас она идёт как отдельный проект и расположена по адресу http://redmine.lighttpd.net/projects/spawn-fcgi. Можно получить последнюю версию оттуда, а можно воспользоваться советом отсюда и взять её из lighttpd:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

mkdir ~/sources
cd ~/sources
# возможно будет уже и более свежая версия
wget http://www.lighttpd.net/download/lighttpd-1.4.19.tar.bz2
tar jxvf lighttpd-1.4.19.tar.bz2
# необходимые пакеты для установочного скрипта
sudo apt-get install libpcre3-dev libbz2-dev
cd lighttpd-1.4.19
# здесь может возникнуть ошибка, но и тут же предлагается решение -
# конфигурировать с параметром --without-zlib
./configure --without-zlib
make
sudo cp src/spawn-fcgi /usr/bin/spawn-fcgi
# И удалим за собой ненужныеболее файлы
cd ~/
rm -Rf sources/

Таким образом, или взяв отдельный пакет, но spawn-fcgi у нас получился установлен. Теперь необходимо все это дело запускать. Сделаем скрипт, который будет устанавливать дополнительные управляющие переменные и запускать php5-cgi:

1	sudo vim /usr/bin/php-fastcgi

и вставляем:

1
2
3
4
5
6

#!/bin/sh
# сколько процессов запускать
PHP_FCGI_CHILDREN=3
# через сколько обработанных запросов перезапускать экземпляр
PHP_FCGI_MAX_REQUESTS=1000
exec /usr/bin/php5-cgi

Скрипт для запуска php5-cgi готов, теперь нам нужен скрипт, для запуска spawn-fcgi, который будет дергать уже наш скрипт для установки переменных и запуска php5-cgi:

1	sudo vim /etc/init.d/init-fastcgi

и вставляем сюда:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

#!/bin/bash
PHP_SCRIPT="/usr/bin/spawn-fcgi -a 127.0.0.1 -p 9000 -u www-data -g www-data -f /usr/bin/php-fastcgi"
RETVAL=0
case "$1" in
start)
$PHP_SCRIPT
RETVAL=$?
;;
stop)
killall -9 php5-cgi
RETVAL=$?
;;
restart)
killall -9 php5-cgi
$PHP_SCRIPT
RETVAL=$?
;;
*)
echo "Usage: sudo /etc/init.d/init-fastcgi {start|stop|restart}"
exit 1
;;
esac
exit $RETVAL

Осталось только сделать оба новых скрипта доступных для запуска:

1 2	sudo chmod 755 /usr/bin/php-fastcgi sudo chmod 755 /etc/init.d/init-fastcgi

Теперь можно попробовать запустить наш FastCGI:

1
2
3

sudo /etc/init.d/init-fastcgi start
# В ответ должно получится примерно следующее:
spawn-fcgi.c.197: child spawned successfully: PID: 16428

Осталось только добавит наш скрипт в автозагрузку:

1	sudo update-rc.d init-fastcgi defaults

Теперь надо подправить все конфиги, что бы nginx обрабатывал PHP сам, а не передавал их на apache. У меня в конфиге

1	sudo vim /etc/nginx/sites-available/svdev.ru

получилось примерно следующее:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

server {
listen 80;
server_name www.svdev.ru;
# здесь при заходе на www.svdev.ru происходит редирект на svdev.ru
rewrite ^(.*) http://svdev.ru$1 permanent;
}

server {
listen 80;
server_name svdev.ru;
error_log /var/www/svdev.ru/logs/error.log warn;
access_log /dev/null;

root /var/www/svdev.ru/htdocs;
charset utf-8;
# страницы с ошибками, вместо стандартных, путь указывается от root (выше)
error_page 404 /error/404.html;
error_page 403 /error/403.html;
error_page 500 /error/500.html;

location ~ .*(gif|jpg|jpeg|png|ico|css|swf|js|html|htm)$ { }
# Для wordpess - это директория с upload и по умолчанию получится
# что залив php скрипт можно будет выполнить его по прямой ссылке
location ~ wp-content/uploads/.*\.php { }

location ~ \.php$
{
include /etc/nginx/fastcgi_params;
fastcgi_param SCRIPT_FILENAME /var/www/svdev.ru/htdocs$fastcgi_script_name;
fastcgi_param QUERY_STRING $query_string;
fastcgi_pass 127.0.0.1:9000;
# Директива определяет что ответы FastCGI-сервера с кодом больше или равные 400
# перенаправлять на обработку nginx'у с помощью директивы error_page
fastcgi_intercept_errors on;
break;
}

location / {
fastcgi_index index.php;
fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILENAME /var/www/svdev.ru/htdocs$fastcgi_script_name;
fastcgi_param QUERY_STRING $query_string;
include /etc/nginx/fastcgi_params;
fastcgi_intercept_errors on;
}
}

и на этом можно пока остановиться. Теперь apache можно окончательно удалить с сервера.

1	sudo apt-get remove apache2

Настройка nginx + apache на debian

Дерябин Сергей — Sun, 26 Jul 2009 20:24:44 +0000

Основная задача – что бы apache слушал запросы на
127.0.0.1:81 #порт можно взять и другой, к примеру 8080
а nginx слушал запросы с внешних адресов на 80 порту, разбирал статику или еще какие действия выполнял, а остальные запросы прокидывал на apache на локальный адрес 127.0.0.1 и 81 порт

Установка nginx:

1	apt-get install nginx

Сначала настроим nginx для работы, дефолтный конфиг и создадим конфиги для все используемых сайтов.
В самом конфиге (/etc/nginx/nginx.conf) получилось следующее:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

user www-data;
worker_processes 1;

error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;

events {
worker_connections 1024;
}

http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
server_names_hash_bucket_size 64;
access_log /var/log/nginx/access.log;

sendfile on;

keepalive_timeout 65;
tcp_nodelay on;

gzip on;

include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}

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

1
2
3

sudo nginx -t
[info] 31015#0: the configuration file /etc/nginx/nginx.conf syntax is ok
[info] 31015#0: the configuration file /etc/nginx/nginx.conf was tested successfully

Далее правим дефолтный конфиг /etc/nginx/sites-available/default, для всех запросов. Так как запросы, кроме определенных сайтов нам не нужны, повесим их переадресацию на заглушку /var/www/nginx-default/index.html, больше нам здесь ничего не надо – 404 можно перекидывать сюда же:

1
2
3
4
5
6
7
8
9
10
11
12

server {
listen 80;
server_name localhost;

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

location / {
root /var/www/nginx-default;
index index.html;
}
error_page 404 /index.html;
}

В итоге все неразобранные запросы попадут на нашу заглушку: http://77.220.185.16/.

Далее создаем настройки для всех поддерживаемых ресурсов, по аналогии с apache конфиги хранятся в /etc/nginx/sites-available/, а подключенные в /etc/nginx/sites-enabled/. Создаем /etc/nginx/sites-available/svdev.ru:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

server {
listen 80;
server_name svdev.ru www.svdev.ru;

access_log /var/www/svdev.ru/logs/nginx-access.log;

location / {
proxy_pass http://127.0.0.1:81/; # делаем переадресацию запросов на apache
proxy_redirect off;

proxy_set_header Host $host;
# Эти настройки необходимы, что бы из скриптов было видно реальные IP пользователя, а не фронт-части
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

client_max_body_size 10m;
client_body_buffer_size 128k;

proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;

proxy_buffer_size 4k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
}
}

Перовоначальные настройки позволяют просто перенаправлять запросы с nginx на apache. Настройкой правил для отдачи статики без участия apache и прочим займемся позже. После создания настроек их необходимо подключить, по аналогии apache утилит a2ensite и a2dissite нет и надо создать симлинк самому:

1	sudo ln -s /etc/nginx/sites-available/svdev.ru /etc/nginx/sites-enabled/svdev.ru

Далее заставляем apache слушать 81 порт с внутреннего интерфейса, поправив /etc/apache2/ports.conf:

1 2	NameVirtualHost *:81 Listen 127.0.0.1:81

И необходимо подправить настройки хостов apache /etc/apache2/sites-available/svdev.ru:

1 2	# заменить 80 порт на выбранный, у меня 81 <VirtualHost *:81>

Таким образом попасть на apache теперь можно только через nginx, т. е. снаружи он недоступен!

Для удобства необходимо еще установить пакет

libapache2-mod-rpaf - module for Apache2 which takes the last IP from the 'X-Forwarded-For' header

1	sudo apt-get install libapache2-mod-rpaf

Мне дополнительно настраивать ничего не пришлось, после установки в $_SERVER["REMOTE_ADDR"] начал подставляться реальный IP посетителя, вместо 127.0.0.1 Дополнительную информацию по модулю можно найти погуглив, в документации или по ссылкам ниже.

Далее настроим ротацию логов. Сначала для nginx, приятно был удивлен, увидев /etc/logrotate.d/nginx, добавим туда еще один файл:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

/var/log/nginx/*.log {
daily
missingok
rotate 2
compress
delaycompress
notifempty
create 640 root adm
sharedscripts
postrotate
[ ! -f /var/run/nginx.pid ] || kill -USR1 `cat /var/run/nginx.pid`
cat /var/log/nginx/error.log.1 | mail root
endscript
}

cat /var/log/nginx/error.log.1 | mail root – таким образом данные из последнего обработанного файла будут отправлену на почту рута, а уж куда она придет можно настраивать в /etc/aliases

Полезные ссылки

Официальная документация по nginx
OperNET: Настройка совместной работы Apache и nginx (web nginx http)
Установка и настройка Nginx.