Архив метки: Software

Обновление PostgreSQL с 11 до 12 версии

PostgreSQL 12 вышел 03.10.2019. Обновится со старой версии можно через pg_dumpall и pg_upgrade. Ниже описан вариант обновления через pg_upgrade.




Установите PostgreSQL 12:




sudo apt-get update
sudo apt-get install postgresql-12 postgresql-server-dev-12




Перенесите ваши кастомные настройки из старых конфигов в новые. Различия конфигов разных версий удобно посмотреть командами:




diff /etc/postgresql/11/main/postgresql.conf /etc/postgresql/12/main/postgresql.conf
diff /etc/postgresql/11/main/pg_hba.conf /etc/postgresql/12/main/pg_hba.conf




Остановите запущенный PostgreSQL:




sudo systemctl stop postgresql.service




Перейдите в каталог с временными файлами. Туда будут записаны логи и добавлены некоторые скрипты:




cd /tmp




Запускаем работу в командной строке от пользователя postgres:




sudo su postgres




Безопасно проверяем кластеры, без изменения каких-либо данных:





/usr/lib/postgresql/12/bin/pg_upgrade 
 — old-datadir=/var/lib/postgresql/11/main 
 — new-datadir=/var/lib/postgresql/12/main 
 — old-bindir=/usr/lib/postgresql/11/bin 
 — new-bindir=/usr/lib/postgresql/12/bin 
 — old-options ‘-c config_file=/etc/postgresql/11/main/postgresql.conf’ 
 — new-options ‘-c config_file=/etc/postgresql/12/main/postgresql.conf’ 
 — check




Если ошибок нет, проводим миграцию данных (если у Вас нет необходимости в копировании файлов в новый кластер, то используйте параметр — link. Будут использованы жесткие ссылки на старый кластер, без копирования):




/usr/lib/postgresql/12/bin/pg_upgrade 
 — old-datadir=/var/lib/postgresql/11/main 
 — new-datadir=/var/lib/postgresql/12/main 
 — old-bindir=/usr/lib/postgresql/11/bin 
 — new-bindir=/usr/lib/postgresql/12/bin 
 — old-options ‘-c config_file=/etc/postgresql/11/main/postgresql.conf’ 
 — new-options ‘-c config_file=/etc/postgresql/12/main/postgresql.conf’




Возвращаемся к обычному пользователю




exit




Ваш старый PostgreSQL, скорее всего, использовал порт 5432, а для нового, по-умолчанию, используется 5433. Меняем друг на друга.




sudo vim /etc/postgresql/12/main/postgresql.conf
# меняем "port = 5433" на "port = 5432"

sudo vim /etc/postgresql/11/main/postgresql.conf
# меняем "port = 5432" на "port = 5433"




Запускаем PostgreSQL




sudo systemctl start postgresql.service




Работаем от пользователя postgres




sudo su postgres




Проверяем версию запущенного PostgreSQL




psql -c "SELECT version();"




На новом кластере нет никакой статистики. Нужно запустить ANALYZE по кластеру. Для этого pg_upgrade создал скрипт analyze_new_cluster.sh. Запускаем.




./analyze_new_cluster.sh




Возвращаемся к обычному пользователю




exit




Смотрим, какие старые версии PostgreSQL остались в системе.




apt list --installed | grep postgresql




Удаляем старые версии PostgreSQL, например:




sudo apt-get remove postgresql-11




Удаляем старую конфигурацию:




sudo rm -rf /etc/postgresql/11/




В последний раз заходим под пользователем postgres




sudo su postgres




Удаляем данные старого кластера




./delete_old_cluster.sh




Обновление завершено!




Источник: https://dmitry-naumenko.medium.com/%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5-postgresql-%D1%81-11-%D0%B4%D0%BE-12-%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D0%B8-b35fa87a0c35



2022-04-15T16:48:23
Software

 Резервное копирование и восстановление баз данных PostgreSQL

Создание резервной копии базы PostgreSQL




Идея, стоящая за методом дампа, заключается в генерации текстового файла с командами SQL, которые при выполнении на сервере, пересоздадут базу данных в том же самом состоянии, в котором она была на момент создания дампа. PostgreSQL предоставляет для этой цели программную утилиту pg_dump. Базовый форма команды выглядит так:




pg_dump имя_БД > файл_дампа




то-есть, pg_dump записывает результаты своей работы на стандартный вывод. Далее будет рассмотрено как из этого можно извлечь пользу.




pg_dump является для PostgreSQL обычным клиентским приложением. Процедура резервного копирования может выполняться с любого удалённого компьютера, который имеет доступ к нужной базе данных. Эта утилита должна иметь доступ на чтение всех таблиц базы данных, резервную копию которых вы хотите сделать, так что на практике её почти всегда нужно запускать с правами суперпользователя СУБД.




Чтобы указать, к какому серверу должен подключаться pg_dump, необходимо использовать опцию командной строки -h сервер и -p порт. По умолчанию, в качестве сервера выбирается localhost или тот сервер, что указан в переменной окружения PGHOST. Похожим образом, по умолчанию используется порт, указанный в переменной окружения PGPORT или, если переменная не заданна, то порт, указанный по умолчанию при компиляции.




Как и любое другое клиентское приложение PostgreSQL, pg_dump по умолчанию будет подключаться к базе данных, под пользователем, имя которого совпадает с именем текущего пользователя в операционной системе. Чтобы изменить пользователя необходимо использовать опцию -U, либо установить нужное значение переменной окружения PGUSER.




Важное преимущество pg_dump над другими методами резервного копирования состоит в том, что базы данных, сохраненные при помощи pg_dump, могут быть залиты в более новые версии PostgreSQL, в то время как резервная копия на уровне файловой системы (простое копирование файлов баз данных) являются жёстко зависимыми от версии сервера.




Также, только pg_dump является методом, который будет работать при переносе базы данных на другую машинную архитектуру, например, при переносе с 32-битной на 64-битную версию сервера.




Дампы, создаваемые pg_dump являются внутренне целостными, что означает, что дамп представляет собой снимок базы данных на момент начала запуска pg_dump. pg_dump не блокирует другие операции с базой данных во время своей работы.




Если  схема базы данных полагается на OID (например, как внешние ключи), вы должны сказать pg_dump, чтобы в дамп были также включены OID. Чтобы сделать это, используйте опцию командной строки -o.




Команда pg_dump может сохранять резервную копию базы в двух форматах: в формате текстовых файлов, содержащих набор команд SQL и специальный формат дампа. Если PostgreSQL была скомпилирована в системе с установленной библиотекой zlib, то специальный формат дампа будет сжимать данные, которые выдаются в файл вывода. Это приведёт к созданию файла дампа, который по размеру будет похож на дамп, сжатый gzip, но такой формат будет иметь преимущество, потому что позволяет выборочное восстановление таблиц. Следующая команда делает дамп базы данных, используя специальный формат дампа:




pg_dump -Fc имя_БД > имя_файла




В принципе можно сжать и текстовый формат резервной копии используя стандартные инструменты Linux — ипользовать программу сжатия, например gzip:




pg_dump имя_БД | gzip > имя_файла.gz




распаковывая впоследствии сжатый дамп командой:




gunzip -c имя_файла.gz | psql имя_БД




или:




cat имя_файла.gz | gunzip | psql имя_БД




При больших базах данных и нежелании использовать сжатие можно использовать команду split. Команда split позволяет разбивать текстовые файлы на файлы меньшего размера, которые не попадают под ограничения на максимальный размер файла в файловой системе. Например, чтобы нарезать дамп на кусочки по 1 мегабайту:




pg_dump имя_БД | split -b 1m - имя_файла




Загружая впоследствии полученные файлы командой:




cat имя_файла* | psql имя_БД




Восстановление резервных копий баз PostgreSQL




Текстовые файлы резервных копий баз данных PostgreSQL, содержащие команды sql, предназначаются для последующего чтения программой psql, то-есть выполнения сгенерированной последовательности скриптов. Общий вид команды для восстановления дампа:




psql имя_БД < файл_дампа




где файл_дампа — это файл, содержащий вывод команды pg_dump. База данных, заданная параметром имя_БД не будет создана данной командой, так что ее необходимо предварительно создать из шаблона базы template0 перед запуском psql, например, с помощью команды:




createdb -T template0 имя_БД




psql поддерживает опции для указания сервера, к которому осуществляется подключение и имени пользователя, похожие на pg_dump.




Перед восстановлением SQL дампа, все пользователи, которые владеют объектами или имеют права на объекты в базе данных, выгруженной в дамп, должны уже существовать. Если их нет, при восстановлении будут ошибки пересоздания объектов с оригинальными владельцами и/или правами.




По умолчанию, если произойдёт ошибка SQL, программа psql продолжит своё выполнение. Можно запустить psql с установленной переменной ON_ERROR_STOP, чтобы  заставить psql в случае возникновения ошибки SQL завершить работу с кодом 3:




psql --set ON_ERROR_STOP=on имя_БД < файл_дампа




В любом случае база данных будет только частично восстановлена. В качестве альтернативы можно задать, что-бы весь дамп должен быть восстановлен в одной транзации, так что восстановление или будет полностью выполненно или полностью не выполнено. Данный режим может быть задан, с помощью опций командной строки -1 или —single-transaction для psql.




Возможность pg_dump и psql писать и читать из конвееров, делают возможным создание дампа базы данных напрямую с одного сервера на другой, например:




pg_dump -h сервер1 имя_БД | psql -h сервер2 имя_БД




Дампы, которые делает pg_dump являются относительными template0. Это означает, что любые языки, процедуры и т.д. добавленные через template1, также попадут в дамп при выполнении pg_dump. В итоге, при восстановлении, если вы использовали специально изменённый template1, вы должны создать пустую базу данных из template0, как показано в примере выше.




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




Специальный формат дампа не является скриптом для psql и должен восстанавливаться с помощью команды pg_restore, например:




pg_restore -d имя_БД имя_файла




Для очень больших баз данных, вам может понадобиться сочетать split с одним из двух других методов.




Резервное копирование всего кластера баз данных PostgreSQL




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




pg_dumpall > файл_дампа




Результирующий дамп может быть восстановлен с помощью psql:




psql -f файл_дампа postgres




При восстановлении дампа, сделанного pg_dumpall, всегда необходимо, выполнять восстановление с правами суперпользователя баз данных, потому что они требуются для восстановления ролей и информации о табличных пространствах.




Источник: https://www.oslogic.ru/knowledge/718/rezervnoe-kopirovanie-i-vosstanovlenie-baz-dannyh-postgresql/



2022-04-15T16:44:17
Software

Балансировка нагрузки с помощью HAProxy

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




Рассмотрим решение по балансировке нескольких веб-серверов при помощи сервиса HAProxy.







Технические требования




  • Сервер под балансировщик с двумя сетевыми интерфейсами (Рекомендация. Внешний адрес для связи с внешним миром и локальный для общения между узлами кластера);
  • Два и более серверов под распределение запросов/трафика;




В примере будет использоваться дистрибутив Linux CentOS 7.




Установка и настройка backend-серверов




В качестве backend-серверов я буду использовать несколько веб-серверов с NGINX и настроенным SSL.




Прежде всего установим NGINX




yum install nginx




Выполним настройку веб-сервера




server {
    listen 80;
    server_name devservers.network;
    rewrite ^(.*)$ https://devservers.network$1 permanent;
}
 
server {
    server_name devservers.network;
    access_log /srv/www/devservers.network/logs/access.log;
    error_log /srv/www/devservers.network/logs/error.log;
    root /srv/www/devservers.network/public_html;
 
    ssl on;
    ssl_session_timeout 24h;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;
    listen 443 ssl http2 proxy_protocol;
 
    set_real_ip_from 10.0.1.10/32;
    real_ip_header proxy_protocol;
 
    ssl_certificate /etc/nginx/ssl/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/privkey.pem;
 
    location / {
   try_files $uri $uri/ /index.html;
    }
 
    location ~ .(js|css|png|jpg|gif|swf|ico|pdf|mov|fla|zip|rar)$ {
        try_files $uri =404;
    }
 
}




Конфигурацию SSL можно выполнить и на самом балансировщике, а бэкенд сервера оставить работать на 80 порту, но в моем случае я буду использовать режим SSL Pass-Through. Не забываем поместить SSL-сертификаты в директорию /etc/nginx/ssl.




Для того, чтобы принимать реальные IP-адреса клиентов на веб-сервере от HAProxy необходимо добавить proxy_protocol в параметр listen, а также указать реальный адрес откуда разрешить принимать запросы:




set_real_ip_from 10.0.1.10/32;
real_ip_header proxy_protocol;




Создадим приветственную страницу на обоих веб-серверах touch /srv/www/devservers.network/public_html со следующим содержимым, изменив только номер сервера для его дальнейшего определения:




<!DOCTYPE html>
<html>
<head>
<title>Server #1</title>
</head>
<body>
<h1>This is server #1</h1>
</body>
</html>




Добавляем NGINX в автозагрузку и запускаем сервис.




systemctl enable nginx
systemctl start nginx




И не забываем выполнить настройку Firewalld




firewall-cmd --permanent --add-service=https
firewall-cmd --reload




Установка и настройка балансировщика




В качестве сервера балансировки я буду использовать VDS сервер с ресурсами 1 vCPU и 1Gb RAM. При правильной настройке, данных мощностей хватит для обслуживания 10-15к одновременных сессий, чего вполне достаточно для среднестатистического интернет-ресурса.




Установим HAProxy




Пакет HAProxy доступен в базовой репозитории CentOS.




yum install haproxy




Настройка HAProxy




HAProxy обладает очень гибкими настройками и конфигурация может содержать большое количество директив и условий. Конфигурационный файл состоит из нескольких секций. Директивы frontend, backend, listen должны иметь своё имя, к примеру defaults — может, но не обязательно, а такие как global — не должны.




Выполняем конфигурацию HAProxy в файле /etc/haproxy/haproxy.cfg. Рекомендую использовать свой конфигурационный файл, а представленный по умолчанию оставить как резерв.




Секция global




global
    log   /dev/log  local0
    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    stats    timeout 30s
    maxconn     4000
    user        haproxy
    group       haproxy
    daemon




Рассмотрим настройки в директиве global:




  • log — вести лог в /dev/log сохраняя в local0;
  • chroot — настройки безопасности, позволяющие работать HAProxy только в указанной директории;
  • maxconn — максимальное количество соединений на один процесс;
  • daemon — запуск процесса как демона.




Секция defaults




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




В нашем примере указаны следующие параметры:




defaults
    log global
    mode http
    retries 3
    option httplog
    option redispatch
    maxconn 2000
    contimeout 2000
    timeout http-request    10s
    timeout queue   1m
    timeout connect         10s
    timeout client          1m
    timeout server          1m
    timeout http-keep-alive 10s
    timeout check           10s




  • log — указывает в какой лог вести запись (global в данном случае означает, что используются параметры, заданные в секции global);
  • mode — устанавливает протокол взаимодействия, принимает одно из значений: tcp, http, health;
  • retries — количество попыток соединения с сервером в случае отказа;
  • option httplog — формат лога, в случае использования HAProxy для проксирования HTTP-запросов (рекомендуется включить данную настройку);
  • option redispatch — разрешает программе разорвать и переназначить сессию в случае отказа сервера;
  • contimeout — максимальное время ожидания успешного соединения с сервером.




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




Секция frontend




Укажем HAProxy какие запросы он должен обрабатывать, для этого задаем секцию frontend с именем https-in:




frontend https-in
    log /dev/log local0
    mode tcp
    option tcplog
    bind *:443
    default_backend backend-https-servers




Параметр bind со значением *:443 говорит о том, что HAProxy должен принимать все запросы на 443-й порт. Ещё раз напомню, что в данном примере я использую режим SSL Pass-Through, поэтому настройка SSL на самом HAProxy не выполняется.




Параметр default_backend указывает, какие сервера будут обрабатывать эти запросы. В данном случае — backend-https-servers, именно так необходимо назвать секцию backend.




Секция backend




В этой секции мы задаем алгоритм балансировки (параметр balance) и список серверов-обработчиков (server). В качестве алгоритма балансировки указываем roundrobin.




HAProxy имеет несколько алгоритмов балансировки:




  • roundrobin — каждый сервер получает запросы пропорционально своему весу, при этом веса серверов могут меняться на лету;
  • static-rr — то же, что и roundrobin, только изменение весов на лету не даст никакого эффекта;
  • leastconn — выбирает сервер с наименьшим количеством активных соединений;
  • first — выбирает первый сервер с доступными слотами для соединения source — на основе хэша IP-адреса отправителя запроса и весов серверов назначается сервер для соединения;
  • uri — сервер выбирается на основе адреса (без параметров) страницы;
  • url_param — сервер выбирается на основе GET-параметров запроса;
  • hdr — сервер выбирается на основе заголовков запроса;
  • rdp-cookie — сервер выбирается на основе cookie (если они не установлены, то применяется обычный roundrobin);




При перечислении серверов используется следующий формат: ключевое слово server, имя сервера, IP-адрес, дополнительные параметры (в данном случае — проверка статуса хоста и Proxy Protocol, которые позволяет перенаправлять реальные IP-адреса клиента с HAProxy на веб-сервер).




backend backend-https-servers
    mode tcp
    balance roundrobin
    option ssl-hello-chk
    server nginx01 10.0.1.3:443 check send-proxy
    server nginx02 10.0.1.4:443 check send-proxy




Просмотр статистики HAProxy




Для включения расширенной статистики HAProxy необходимо в конфигурационный файл добавить секцию:




listen stats
    bind :10001
    stats enable
    stats uri /haproxy_stats
    stats auth admin:password




  • bind :10001 — HAProxy будет ожидать запросы к порту 10001;
  • stats enable — включить отчёты со статистикой;
  • stats uri — установка адреса страницы с отчётом;
  • stats auth — логин и пароль для авторизации на странице со статистикой;




В секции listen указываем HAProxy, что он должен показывать статистику на странице /haproxy_stats на порту 10001 после ввода логина admin и пароля password.




Проверяем.




Переходим по адресу HAProxy (IP-адрес или хостнйем) и просто обновляем страницу. В зависимости от выбранного балансировщиком сервера будем получать ответ This is server #1 либо This is server #2.




Проверяем статистику. Переходим по адресу SITE_NAME:10001/haproxy_stats







На этом всё. Выше рассмотрен самый простой метод балансировки. Более сложная настройка требует грамотно составленного ТЗ и технических данных проекта. HAProxy очень удобный и гибкий в настройке инструмент с помощью которого можно выполнить балансировку и других сервисов, к примеру почтовый сервер, Memcached, Redis и пр.



2022-04-14T17:49:53
Software

Блокировка доступа к NGINX

Способы ограничения доступа к ресурсу в NGINX




Блокировка по User Agent`у




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




if ($http_user_agent ~ "Windows 95|Windows 98|xpymep|TurnitinBot|sindice|Purebot|libwww-perl")  {
  return 403;
  break;
}




Я выбрал для блокирования libwww-Perl, потому что в последние несколько лет, я не видел ни GET или POST по libwww-Perl, вероятно пробовали использовать какую-то уязвимость ПО.




Блокировка по IP-адресу




deny 85.17.26.68;     # spam
deny 85.17.230.23;    # spam
deny 173.234.11.105;  # junk referrers
deny 173.234.31.9;    # junk referrers
deny 173.234.38.25;   # spam
deny 173.234.153.30;  # junk referrers
deny 173.234.153.106; # spam
deny 173.234.175.68;  # spam
deny 190.152.223.27;  # junk referrers
deny 195.191.54.90;   # odd behaviour, Mozilla, doesnt fetch js/css. Ended up doing a POST, prob a spambot
deny 195.229.241.174; # spammy comments
deny 210.212.194.60;  # junk referrers + spam




Блокировка по запросу




Кроме того, можно заблокировать доступ на основе информации которая отправляется в заголовках HTTP.




if ($http_referer ~* (viagra|sex|porn|) ) {
  return 403;
}




Я использую ключ ~* для того чтобы предотвратить запрос GET по указанным словам во всей строке.




Блокировка по подсети




deny 69.28.58.0/24;   # spam
deny 79.142.64.0/20;  # spam
deny 80.67.0.0/20;    # spam




Блокировка по геолокации




Мы можем заблокировать целые страны, основанные на данных GeoIP предоставляемых MaxMind. Необходимо, чтобы NGINX имел модуль GeoIP. Во-первых, вы должны обозначить NGINX где база данных GeoIP находится в файловой системе. Вы можете сделать это внутри HTTP {}; Конфигурация блока:




geoip_country /etc/nginx/GeoIP.dat;




Теперь сообщаем NGINX страны которые необходимо заблокировать:




if ($geoip_country_code ~ (BR|CN|KR|RU) ) {
  return 403;
}




Блокировка по паролю




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




location ^~ /codes/ {
   root   /path/to/server;
          autoindex    on;
          autoindex_exact_size  off;
          auth_basic "Hello, please login";
          auth_basic_user_file /usr/nginx/passwords;
          access_log   /usr/nginx/logs/codes.log   download;
      }




либо админки с ограничением по IP-адресу:




location ^~ /admin/ {
   fastcgi_pass unix:/home/project/server.sock;
            include  conf/fastcgi.conf;
            allow 11.11.0.0/16;
            allow 22.22.22.22;
            deny all;
            auth_basic "Hello, Admin, please login";
            auth_basic_user_file /usr/nginx/adminpassword;
            access_log   /usr/nginx/logs/admin.log  main;
}




Добавить пользователя можно с помощью стандартной утилиты от apache:




htpasswd -b passwords NewUser NewPassword




В файле запись с зашифрованным паролем имеет вид NewUser:P47ghZ4kloG78: #Your Can Comment Here




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




  • Блокирование IP на время, если количество запросов в секунду превышает какое-либо разумное количество
  • Вести лог неудачных попыток подбора пароля и скриптом раз в минуту проверять лог и заносить IP адреса в iptables




Для первого варианта достаточно создать правила:




iptables -A INPUT -p tcp --syn --dport 80 -i eth0 -m state --state NEW
   -m recent --name bhttp --set
iptables -A INPUT -p tcp --syn --dport 80 -i eth0 -m state --state NEW
            -m recent --name bhttp --update --seconds 120
            --hitcount 360 -j DROP
iptables -A INPUT -p tcp --syn --dport 80 -i eth0 -j ACCEPT




Можно вместо DROP использовать TARPIT, чтобы усложнить жизнь ломателям.




Для второго варианта надо добавить в конфиг:




location /401.html {
   root   /usr/nginx;
            access_log   /usr/nginx/logs/denied.log  error401;
        }




Формат error401, у меня например такой:




log_format error401  '$remote_addr - $remote_user [$time_local] '
   '$status "$request"';



2022-04-14T17:32:32
Software

Деректива Nginx — location с примерами

Директива location служит для установки конфигурации в зависимости от URI-запроса.

Синтаксис location в общем виде следующий:

Syntax:   location [=|~|~*|^~] uri { ... }
   location @name { ... }
Context:  server, location

Перед тем, как перейти к более детальному изучению, нужно заметить, что location определяется в контексте server (или в location в случае вложенной директивы), и в одном настраиваемом виртуальном хосте могут использоваться разные конфигурации в зависимости от обрабатываемого сервером URI. Читать →

Ошибка NGINX — Число имен серверов или их длине — could not build the server_names_hash

Исправление ошибки в числе имен серверов или их длине




Если задано большое число имён серверов, либо заданы необычно длинные имена, возможно потребуется скорректировать значения директив
server_names_hash_max_size и server_names_hash_bucket_size на уровне http.
Значение по умолчанию директивы server_names_hash_bucket_size может быть равно 32, 64, либо другой величине, в зависимости от размера строки кэша процессора.
Если значение по умолчанию равно 32 и имя сервера задано как “too.long.server.name.example.org”, то nginx откажется запускаться и выдаст сообщение об ошибке:




could not build the server_names_hash,
you should increase server_names_hash_bucket_size: 32




В этом случае следует увеличить значение директивы до следующей степени двойки:




http {
    server_names_hash_bucket_size  64;
    ...




Если задано большое число имён серверов, то будет выдано другое сообщение об ошибке:




could not build the server_names_hash,
you should increase either server_names_hash_max_size: 512
or server_names_hash_bucket_size: 32




В таком случае сначала следует попробовать установить server_names_hash_max_size в величину, близкую к числу имён серверов, и только если это не поможет или время запуска nginx станет неприемлемо большим, следует попытаться увеличить server_names_hash_bucket_size.




Если сервер является единственным сервером для слушающего порта, то nginx не будет проверять имена сервера вообще (а также не будет строить хэш-таблицы для слушающего порта).




За одним исключением: если имя сервера задано регулярным выражением с выделениями, то nginx’у придётся выполнить это выражение, чтобы получить значения выделений.



2022-04-14T17:28:47
Software