Создание учетной записи в AD и файла keytab
Для подключения к контроллеру домена нам необходимо подтверждать подлинность. Это выполняется с помощью учетной записи в LDAP и файла keytab.
Создание учетной записи
Открываем консоль управления пользователями и добавляем нового со стандартными правами. От этой учетной записи будут выполняться запросы к AD DS.
В своем примере мы создаем пользователя spnego.
Учетная запись должна быть размещена по пути, в котором присутствуют названия только на латинице. Подразделения и контейнеры не должны быть на русском. В противном случае, при выполнении команды ниже мы получим ошибку «Password set failed! 0x00000020».
Создание keytab-файла
В двух словах, данный файл позволяет пройти идентификацию в Kerberos без запроса пароля. Он содержит пары имен субъектов Kerberos и зашифрованные ключи, полученные из пароля Kerberos.
Мы создадим данный файл на контроллере домена и скопируем на сервер NGINX. Для этого на контроллере домена и от имени администратора запускаем Powershell или обычную командную строку. Вводим:
ktpass /princ HTTP/[email protected] /mapuser [email protected] /crypto ALL /ptype KRB5_NT_PRINCIPAL /out C:\spnego.keytab /pass *
* где:
- nginx.domain.local — полное имя нашего nginx-сервера;
- DOMAIN.LOCAL — наш домен;
- [email protected] — учетная запись в AD для выполнения запросов (создана на шаге выше);
- pass * — пароль, который будет задан пользователю (должен соответствовать требованию AD). Система запросит его ввод дважды.
* регистр важен.
В нашем примере, после выполнения команды на контроллере домена в корне диска С появится файл spnego.keytab. Его копируем на Linux-сервер, например, при помощи WinSCP.
Демонстрационный Upstream-сервер
Для демонстрации будем использовать тривиальный HTTP-сервер, реализованный на Python:
sudo apt update sudo apt install -y python3 python3 -m http.server <PORT> --bind 127.0.0.1
Эта команда создает тривиальный HTTP-сервер, который просто выводит структуру каталога, в котором запущен. Вы можете запустить его на локальной машине, например, на 8000 порту и проверить его работу через браузер или curl:
curl http://localhost:8000/
Для целей урока на сервере, где будет настраиваться Nginx, мы так же запустим два сервера — один на порту 8081, второй на порту 8082.
Будем использовать различные каталоги, чтобы нагляднее видеть как меняется поведение. Эти серверы не будут доступны извне, но будут использоваться в качестве Upstream-серверов, между которых будет распределять трафик Nginx:
cd /tmp; python3 -m http.server 8081 --bind 127.0.0.1 & cd /usr; python3 -m http.server 8082 --bind 127.0.0.1 &
Обратите внимание на символ ‘&‘ в конце строки — это означает, что процесс будет запущен в фоновом режиме. Вы не должны закрывать терминал, в котором запустили эти процессы до окончания урока
Проверьте работоспособность обоих серверов с помощью curl, соединившись с ними:
curl http://localhost:8081/ curl http://localhost:8082/
Сценарии настройки
В реальной жизни настройки могут быть несколько сложнее, чем приведенные здесь или в официальной документации. Рассмотрим несколько примеров, что может понадобиться настроить при балансировке.
1. Backend на https
Предположим, что наши внутренние серверы отвечают по SSL-каналу. Таким образом, нам нужно отправлять запрос по порту 443. Также схема проксирования должна быть https.
Настройка сайта:
server {
…
location / {
proxy_pass https://dmosk_backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
…
}
* обратите внимание на 2 момента:
- Мы в схеме подключения proxy_pass указали https. В противном случае при подключении NGINX будет возвращать ошибку 400.
- Мы задали дополнительные опции proxy_set_header, которых не было в примерах выше.
Настройка upstream:
upstream dmosk_backend {
server 192.168.10.10:443;
server 192.168.10.11:443;
server 192.168.10.12:443;
}
* в данном примере мы указали конкретный порт, по которому должно выполняться соединение с бэкендом. Для упрощения конфига дополнительные опции упущены.
2. Разные бэкенды для разных страниц
Нам может понадобиться разные страницы сайта переводить на разные группы внутренних серверов.
Настройка сайта:
server {
…
location /page1 {
proxy_pass http://backend1;
}
location /page2 {
proxy_pass http://backend2;
}
…
}
* при такой настройке мы будем передавать запросы к странице page1 на группу backend1, а к page2 — backend2.
Настройка upstream:
upstream backend1 {
server 192.168.10.10;
server 192.168.10.11;
}
upstream backend2 {
server 192.168.10.12;
server 192.168.10.13;
}
* в данном примере у нас есть 2 апстрима, каждый со своим набором серверов.
3. На другой хост
Может быть необходимым делать обращение к внутреннему ресурсу по другому hostname, нежели чем будет обращение к внешнему. Для этого в заголовках проксирования мы должны указать опцию Host.
Настройка сайта:
server {
…
location / {
proxy_pass https://dmosk_backend;
proxy_set_header Host internal.domain.com;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
…
}
* в данном примере мы будем проксировать запросы на бэкенды, передавая им имя хоста internal.domain.com.
4. TCP-запрос
Рассмотрим, в качестве исключения, TCP-запрос на порт 5432 — подключение к базе PostgreSQL.
Настройка сайта:
server {
listen 5432;
proxy_pass tcp_postgresql;
}
* в данном примере мы слушаем TCP-порт 5432 и проксируем все запросы на апстрим tcp_postgresql.
Настройка upstream:
upstream tcp_postgresql {
server 192.168.10.14:5432;
server 192.168.10.15:5432;
}
* запросы будут случайным образом передаваться на серверы 192.168.10.14 и 192.168.10.15.
5. UDP-запрос
Рассмотрим также и возможность балансировки UDP-запросов — подключение к DNS по порту 53.
Настройка сайта:
server {
listen 53 udp;
proxy_pass udp_dns;
proxy_responses 1;
}
* в данном примере мы слушаем UDP-порт 53 и проксируем все запросы на апстрим udp_dns. Опция proxy_responses говорит о том, что на один запрос нужно давать один ответ.
Настройка upstream:
upstream udp_dns {
server 192.168.10.16:53;
server 192.168.10.17:53;
}
* запросы будут случайным образом передаваться на серверы 192.168.10.16 и 192.168.10.17.
Обновление сертификата
Если планируется использовать сертификат SSL от Let’S Encrypt более 90 дней, его придется систематически обновлять. И делать это рекомендуется заранее, минимум за 30 дней до истечения срока действия. Иначе возникают риски временной неработоспособности протокола SSL, когда сайт перестает открываться по прежним ссылкам (браузеры предупреждают об ошибке).
Выполняется процедура обновления командой:
$ certbot renew
После ее ввода будут проверены все ранее выпущенные и установленные в системе сертификаты и заново созданы те, по которым сроки подходят к концу. Если хочется настроить автоматический перевыпуск SSL, нужно ввести команду cron:
$crontab -e 30 2 * * 1 /usr/bin/certbot renew >> /var/log/renew-ssl.log
В таком виде она каждый понедельник в 2:30 будет выполнять проверку актуальности всех SSL и записывать результат в файл с указанным названием.
2: Создание страниц для сайтов
Создав необходимую структуру каталогов, можно переходить к созданию стандартных страниц сайтов, чтобы иметь возможность просмотреть добавленный контент.
Создайте страницу index.html для первого сайта.
В этот файл вставьте следующий код; эта простая базовая страница сообщит, какой из двух сайтов открыт.
Сохраните и закройте файл.
Файл для второго сайта будет почти таким же, потому можно просто скопировать только что созданный файл, а затем отредактировать его.
Откройте этот файл в текстовом редакторе:
Откорректируйте данные, указав информацию о втором сайте:
Сохраните и закройте файл.
Теперь стандартные страницы сайтов готовы.
Тюнинг веб-сервера
PHP
Открываем на редактирование следующий файл:
vi /etc/php/7.4/apache2/php.ini
И правим следующее:
post_max_size = 1G
…
upload_max_filesize = 512M
…
short_open_tag = On
…
date.timezone = «Europe/Moscow»
* где post_max_size — максимальный объем отправляемых на сервер данных; upload_max_filesize — максимально допустимый размер одного загружаемого файла; short_open_tag — разрешение использования короткого способа открытия php (<?); date.timezone — временная зона, которая будет использоваться веб-сервером, если ее не переопределить настройками в коде php или в файле .htaccess.
Теже настройки применяем для php-fpm:
vi /etc/php/7.4/fpm/php.ini
post_max_size = 1G
…
upload_max_filesize = 512M
…
short_open_tag = On
…
date.timezone = «Europe/Moscow»
Перезапускаем php-fpm и apache:
systemctl restart php7.4-fpm
systemctl restart apache2
NGINX
Открываем на редактирование следующий файл:
vi /etc/nginx/nginx.conf
И внутри секции http добавляем:
client_max_body_size 512M;
После перезапускаем nginx:
systemctl restart nginx
Шаг 3: проверка работы веб-сервера
После завершения процесса установки Debian 10 запустит nginx. То есть веб-сервер будет уже работать.
Это можно проверить следующей командой:
$ systemctl status nginx
Вы увидите вывод:
nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2019-07-12 12:52:54 UTC; 4min 23s ago Docs: man:nginx(8) Main PID: 3942 (nginx) Tasks: 3 (limit: 4719) Memory: 6.1M CGroup: /system.slice/nginx.service ├─3942 nginx: master process /usr/sbin/nginx -g daemon on; master_process on; ├─3943 nginx: worker process └─3944 nginx: worker process
Это значит, что сервис успешно запущен. И лучший способ убедиться в этом — это загрузить начальную страницу nginx, перейдя по IP-адресу вашего сервера. Если вы его не знаете, то введите команду:
$ ip addr show eth0 | grep inet | awk '{ print $2; }' | sed 's/\/.*$//'
В выводе вы увидите несколько строк — попробуйте в строке браузера каждую из них.
После ввода IP-адреса сервера вы должны увидеть:
Если страница отобразилась, значит, сервер работает корректно.
Структура файла конфигурации Nginx и рекомендации
- Все файлы конфигурации Nginx находятся в каталоге .
- Главный файл конфигурации Nginx — это .
- Чтобы упростить поддержку конфигурации Nginx, рекомендуется создать отдельный файл конфигурации для каждого домена. У вас может быть столько файлов блоков сервера, сколько вам нужно.
- Файлы блоков сервера Nginx хранятся в каталоге . Файлы конфигурации, найденные в этом каталоге, не используются Nginx, если они не связаны с каталогом .
- Чтобы активировать серверный блок, вам необходимо создать символическую ссылку (указатель) из файла конфигурации sites в каталоге с каталог с поддержкой .
- Рекомендуется следовать стандартному соглашению об именах, например, если ваше доменное имя — тогда ваш файл конфигурации должен называться
- Каталог содержит фрагменты конфигурации, которые можно включить в файлы блоков сервера. Если вы используете повторяющиеся сегменты конфигурации, вы можете преобразовать эти сегменты в фрагменты и включить файл фрагмента в блоки сервера.
- Файлы журнала Nginx ( и ) находятся в каталоге . Рекомендуется иметь разные файлы и журналов для каждого блока сервера.
- Вы можете установить корневой каталог документов домена в любое место. Наиболее распространенные места для webroot:
Метод балансировки
Рассмотрим способы балансировки, которые можно использовать в NGINX:
- Round Robin.
- Hash.
- IP Hash.
- Least Connections.
- Random.
- Least Time (только в платной версии NGINX).
Настройка метода балансировки выполняется в директиве upstream. Синтаксис:
upstream <название апстрима> {
<метод балансировки>
…
}
Round Robin
Веб-сервер будет передавать запросы бэкендам по очереди с учетом их весов. Данный метод является методом по умолчанию и его указывать в конфигурационном файле не нужно.
Hash
Данный метод определяет контрольную сумму на основе переменных веб-сервера и ассоциирует каждый полученный результат с конкретным бэкендом. Пример настройки:
upstream dmosk_backend {
hash $scheme$request_uri;
server 192.168.10.10;
server 192.168.10.11;
server 192.168.10.12;
}
* это самый распространенный пример настройки hash — с использованием переменных $scheme (http или https) и $request_uri. При данной настройке каждый конкретный URL будет ассоциирован с конкретным сервером.
IP Hash
Ассоциация выполняется исходя из IP-адреса клиента и только для HTTP-запросов. Таким образом, для каждого посетителя устанавливается связь с одним и тем же сервером. Это, так называемый, Sticky Session метод.
Для адресов IPv4 учитываются только первые 3 октета — это позволяет поддерживать одинаковые соединения с клиентами, чьи адреса меняются (получение динамических адресов от DHCP провайдера). Для адресов IPv6 учитывается адрес целиком.
Пример настройки:
upstream dmosk_backend {
ip_hash;
server 192.168.10.10;
server 192.168.10.11;
server 192.168.10.12;
}
Least Connections
NGINX определяет, с каким бэкендом меньше всего соединений в данный момент и перенаправляет запрос на него (с учетом весов).
Настройка выполняется с помощью опции least_conn:
upstream dmosk_backend {
least_conn;
server 192.168.10.10;
server 192.168.10.11;
server 192.168.10.12;
}
Random
Запросы передаются случайным образом (но с учетом весов). Дополнительно можно указать опцию two — если она задана, то NGINX сначала выберет 2 сервера случайным образом, затем на основе дополнительных параметров отдаст предпочтение одному из них. Это следующие параметры:
- least_conn — исходя из числа активных подключений.
- least_time=header (только в платной версии) — на основе времени ответа (расчет по заголовку).
- least_time=last_byte (только в платной версии) — на основе времени ответа (расчет по полной отдаче страницы).
Пример настройки:
upstream dmosk_backend {
random two least_conn;
server 192.168.10.10;
server 192.168.10.11;
server 192.168.10.12;
}
Least Time
Данная опция будет работать только в NGINX Plus. Балансировка выполняется исходя из времени ответа сервера. Предпочтение отдается тому, кто отвечает быстрее.
Опция для указания данного метода — least_time. Также необходимо указать, что мы считаем ответом — получение заголовка (header) или когда страница возвращается целиком (last_byte).
Пример 1:
upstream dmosk_backend {
least_time header;
server 192.168.10.10;
server 192.168.10.11;
server 192.168.10.12;
}
* в данном примере мы будем делать расчет исходя из того, как быстро мы получаем в ответ заголовки.
Пример 2:
upstream dmosk_backend {
least_time last_byte;
server 192.168.10.10;
server 192.168.10.11;
server 192.168.10.12;
}
* в данном примере мы будем делать расчет исходя из того, как быстро мы получаем в ответ целую страницу.
Управление дистрибутивами WSL
Управлять дистрибутивами мне проще через ConEmu, который интерпретирует команды *nix под Win стандарт.
Мы можем установить несколько дистрибутивов. Список всех дистрибутивов получаем командой .
Если вы не выбрали дистрибутив по умолчанию, то им будет тот, который вы установили первым. Назначить дистрибутив по умолчанию легко:
,
Войти в конкретный дистрибутив WSL так же просто:
,
Интересный момент, что WSL позволяет использовать команды LInux за пределами дистрибутива. Да, мы можем взаимодействовать с файловой системой маздая через терминал, используя привычные команды. Но разработчики пошли еще дальше. Команды можно смешивать.
Подробнее о том как миксовать команды WSL (Linux) и команды PowerShel можно почитать в официальной документации.
Проверьте состояние службы NGINX
Давайте сделаем быструю проверку, чтобы подтвердить статус сервиса NGINX. Для этого выполните следующую команду:
Проверьте состояние службы NGINX
Вывод приведенной выше команды подтверждает, что NGINX активен и работает.
Если вы получаете сообщение о том, что NGINX неактивен, не запущен или не работает. Тогда вы можете вручную запустить службу NGINX. Для этого выполните следующую команду:
Чтобы проверить установленную версию Nginx, запустите:
Провера версии Nginx на Ubuntu
Проверьте версию Nginx на Ubuntu
Эти данные показывают, что установлен nginx версии 1.18.0. На момент написания статьи это последняя версия для Ubuntu 20.04.
Подготовка к сборке своего rpm пакета
Для начала поставим все, что нам понадобится для самостоятельной сборки своего rpm пакета.
# yum groupinstall "Development Tools" && yum install rpmdevtools yum-utils wget git
Подключим репозитории nginx mainline ветки для СentOS 7
Обращаю внимание, что используется не стабильная версия stable, а основная — mainline. Она достаточно надежная, в ней все свежие обновления
# mcedit /etc/yum.repos.d/nginx.repo
name=nginx repo baseurl=http://nginx.org/packages/mainline/centos/7/$basearch/ gpgcheck=0 enabled=1 name=nginx source repo baseurl=http://nginx.org/packages/mainline/centos/7/SRPMS/ gpgcheck=1 enabled=0 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
Обновите репозитории:
# yum update
Перейдем в домашний каталог и создадим там структуру каталогов.
# cd ~ # rpmdev-setuptree
У nginx в репозитории уже есть все в готовом виде для сборки из исходников. Загрузим пакет с исходниками и установим его.
# yumdownloader --source nginx # rpm -Uvh nginx*.src.rpm
Если работаете от root, то получите пачку предупреждений.
Для сборки пакетов рекомендуется использовать отдельного пользователя. Но это не критично.
Устанавливаем зависимости, необходимые для сборки.
# yum-builddep nginx
Установка Nginx на Ubuntu 20.04
Установить Nginx можно двумя способами. Первый способ заключается в установки пакета из официального репозитория Ubuntu. На момент написания статьи (1 августа 2021 года) актуальной версией Nginx присутствующей в репозитории Ubuntu была версия 1.18.0. Данная версия считается устаревшей. Актуальной же версией считается 1.20.1 (по состоянию на 1 августа 2021 года).
1. Официальные репозитории Ubuntu
Если вы хотите установить версию Nginx из репозиториев Ubuntu необходимо выполнить следующие действия. Для начала обновляем списки пакетов при помощи команды:
Для того, чтобы установить Nginx, достаточно выполнить команду:
После этого программу можно использовать. Проверка и настройка программы будет описана в разделах ниже.
2. Официальные репозитории Nginx
Второй способ заключается в установке последней версии Nginx из официальных репозиториев, которые предоставляют разработчики Nginx. Если вы хотите использовать данный метод установки, для начала необходимо обновить списки пакетов при помощи команды:
Установите необходимые пакеты:
Далее у вас на выбор есть два пути – подключить репозиторий со стабильной версией nginx или подключить репозиторий с основной версией. Стабильная версия является более проверенной и работоспособной. Эту версию можно использовать, как и в тестовых средах так и на производственных. Основная версия не такая стабильная и может содержать ошибки. Данную версию не рекомендуется использовать в производственных средах.
Для подключения репозитория со стабильной версией nginx, выполните следующую команду:
Для подключения репозитория с основной версией nginx, выполните следующую команду:
Следующие шаги необходимо выполнять вне зависимости от выбранного репозитория. Импортируйте официальный ключ, используемый пакетным менеджером для проверки подлинности пакетов:
Проверьте, верный ли ключ был загружен:
Вывод команды должен содержать полный отпечаток ключа 573BFD6B3D8FBC641079A6ABABF5BD827BD9BF62:
Переместите ключ в каталог доверенных ключей apt:
Чтобы установить nginx, выполните следующие команды:
Версия Nginx от разработчиков немного отличается от версии из официальных репозиториев. Все дополнительные конфигурационные файлы здесь находятся в папке /etc/nginx/conf.d. Если вы хотите использовать папки sites-available и sites-enabled, то необходимо их создать:
Затем добавьте следующую строчку в конец секции http файла /etc/nginx.conf для того чтобы из папки /etc/nginx/sites-enabled загружалась конфигурация сайтов:
Затем перезапустите Nginx:
3. Запуск Nginx
После установки пакета, проверяем что Nginx успешно запустился при помощи команды:
Если в статусе вместо active будет inactive (dead), то сервис необходимо запустить вручную при помощи команды:
Так же обратите внимание, что вы не можете запускать Apache и Nginx на одном порту. В таком случае вы получите ошибку nginx address already in use 80. Для корректной работы Nginx, необходимо будет отключить веб-сервер Apache (если он у вас используется) или изменить его порт с 80 (который используется по умолчанию) на другой свободный порт
4. Настройка брандмауэра
По умолчанию брандмауэр закрывает все неразрешённые входящие подключения. Поэтому, чтобы к вашему веб-серверу можно было получить доступ извне, необходимо добавить его порт в исключения:
5. Проверка работы Nginx
После того, как Nginx будет запущен, он будет доступен по адресу сервера, на который он устанавливался. Вы можете проверить, всё ли работает, просто перейдя по адресу сервера, введя его в браузере. Для примера Nginx был установлен на localhost:
Если вы увидите приветственное сообщение как на скриншоте выше это означает что Nginx успешно установлен и запущен.
uWSGI + NGINX
По сути, наш сервер готов к работе, но очень часто, uWSGI настраивается в связке с NGINX, который берет на себя задачи по проксированию запросов http и отдачи статики. Рассмотрим пример настройки данной связки.
Изменение настроек uWSGI
Откроем на редактирование ранее созданный конфигурационный файл:
vi /etc/uwsgi/apps-enabled/python_app.ini
Закомментируем строку:
#http = 0.0.0.0:8080
* мы будем обращаться к uWSGI через сокетный файл, таким образом, держать сервис на отдельном порту избыточно.
Добавим к нашей настройке:
…
socket = wsgi.sock
chmod-socket = 660
vacuum = true
uid = www-data
gui = www-data
* где:
- socket — путь до сокетного файла, через который будут взаимодействовать наши uWSGI и NGINX.
- chmod-socket — выставляем права на сокетный файл.
- vacuum — удалять или нет при старте сервиса ранее созданные сокетные файлы.
- uid — назначает владельца сокетного файла.
- gui — назначает группу владельца сокетного файла.
Меняем владельца каталога нашего проекта на пользователя, под которым работает NGINX (в Ubuntu это, как правило, www-data):
chown -R www-data:www-data /var/www/python_app
Перезапускаем uwsgi:
systemctl restart uwsgi
Установка и настройка NGINX
Переходим к настройке NGINX. Для начала, установим его:
apt-get install nginx
Разрешим автозапуск:
systemctl enable nginx
Откроем на редактирование конфигурационный файл default:
vi /etc/nginx/sites-enabled/default
* это самый простой путь для тестирования нашей настройки. Для продуктивной среды хорошим тоном будет настройка виртуальных доменов.
Приведем location / к следующему виду:
location / {
#try_files $uri $uri/ =404;
include uwsgi_params;
uwsgi_pass unix:/var/www/python_app/wsgi.sock;
try_files $uri $uri/ /wsgi.py?$query_string;
}
* в данном примере мы все запросы переводим на файл wsgi.py с передачей в качестве аргументов строки запроса. Все запросы передадутся на uWSGI через сокетный файл wsgi.sock, находящийся в каталоге нашего проекта.
Проверим корректность настройки nginx:
nginx -t
Перезапустим его:
systemctl restart nginx
Готово, открываем браузер и переходим по адресу http://<IP-адрес нашего сервера>/ (уже без указания на порт) — должна открываться все та же страница Hello World.
2.1Установка Keepalived
(в зависимостях подтянет ipvsadm-утилиту для администрирования ipvs (ip virtul server))
apt-get install keepalived
Включаем маршрутизацию пакетов на обоих балансерах
# nano /etc/sysctl.conf
net.ipv4.ip_forward = 1 net.ipv4.ip_nonlocal_bind = 1
Проверяем sysctl -p
Далее редактируем server1;
nano /etc/keepalived/keepalived.conf
vrrp_instance VI_1 {
interface eth0 # interface to monitor
state MASTER
virtual_router_id 51 # Assign one ID for this route
priority 100 # 100 on master, 50 on backup
virtual_ipaddress {
10.1.9.176 # the virtual IP
}
}
Запускаем keepaliver
sudo /etc/init.d/keepalived start
Проверяем его
ip addr show | grep 176
Видим это
inet 10.1.9.176/32 scope global eth0
Далее на втором серваке (server 2);
nano /etc/keepalived/keepalived.conf
vrrp_instance VI_1 {
interface eth0 # interface to monitor
state MASTER
virtual_router_id 51 # Assign one ID for this route
priority 50 # 100 on master, 50 on backup
virtual_ipaddress {
10.1.9.176 # the virtual IP
}
}
Запускаем keepaliver
sudo /etc/init.d/keepalived start
Проверяем его
ip addr show | grep 176
Видим это(если первый сервак выключить или остановить keepalived на 1 серваке)
inet 10.1.9.176/32 scope global eth0
2.2 Установка PHP серверов
В качестве php сервера выберем PHP-FPM
sudo apt-get install nginx nginx-extras - y
sudo apt-get install php5-cli php5-common php5-mysql php5-gd php5-fpm php5-cgi php5-fpm php-pear php5-mcrypt mysql-server -y
Далее перейдем к настройке.
Настройка состоит из двух этапов — настройки «Nginx» и «PHP-FPM». Для начала необходимо остановить процессы (демоны) «Nginx» и «PHP-FPM», например, командами
sudo service nginx stop sudo service php5-fpm stop
ывыв
Настройка PHP-FPM
На обоих серверах( не балансировщиках) web-server 1 и web-server 2 производим почти аналогичную настройку
Прежде всего, следует открыть файл «/etc/php5/fpm/php.ini» для редактирования, например, командой
sudo nano /etc/php5/fpm/php.ini
после чего, найти строчку содержащую «cgi.fix_pathinfo», которая по-умолчанию выглядит так (закомментирована)
;cgi.fix_pathinfo = 1
и привести её к виду
cgi.fix_pathinfo = 0
Это призвано устранить опасность неправильно трактования (и возникающей уязвимости) запросов вида «/image.gif/foo.php» (см. Don’t trust the tutorials: check your configuration!, Nginx 0day exploit for nginx + fastcgi PHP)
Если планируется загрузка больших файлов (важно для ownCloud версий
post_max_size = 200M
и ниже
upload_max_filesize = 200M
Затем сохранить изменения в файле.
listen.owner = www-data listen.group = www-data listen.mode = 0660
Следует сохранить изменения в файле и перезапустить «PHP-FPM», например, командой
sudo service php5-fpm start
Можно убедится в том, что права доступа к сокету установлены верно:
ls -la /var/run/php5-fpm.sock
