Смена мп loc update что это
Перейти к содержимому

Смена мп loc update что это

  • автор:

Конфигурация web сервера

Адрес, на котором будет поднят backend (web сервер, на который будет передавать запросы frontend сервер). При одновременной установке nginx и apache backend — apache.

Список используемых web серверов

Имя пользователя, с правами которого работает web сервер (необходимо указывать именно имя, а не uid)

Группа, с правами которой работат web сервер (необходимо указывать именно имя, а не gid)

WebRestartDelay

Минимальное время, которое должно проходить между перезапусками web сервера

SSLSecureProtocols

Список протоколов, указываемых web-серверу для использования в случае, если используется повышенная безопасность SSL (например, SSLSecureProtocols TLSv1 TLSv1.1 TLSv1.2)

SSLSecureChiphers

Список шифров в формате openssl, указываемых web-серверу для использования в случае, если используется повышенная безопасность SSL (например, SSLSecureChiphers HIGH:!RC4:!aNULL:!eNULL:!MD5:!EXPORT:!EXP:!LOW:!SEED:!CAMELLIA:!IDEA:!PSK:!SRP:!SSLv2)

ApsExtRepository

Путь до xml-файла внешнего репозитория APS

Option ApsRepositoryUpdated

Наличие этой опции указывает, что при старте панели управления не нужно выполнять обновления списка APS-скриптов

Option DisableSecurePhpBin

Наличие этой опции отключает создание защищенной директории php-bin (DefaultHomeDir/php-bin/username) для пользователя и создание хардлинок для php и php.ini из домашней директории пользователя в защищенную директорию (применяется в режимах работы php как CGI или FastCGI (Apache)). Вместо этого php и php.ini будут создаваться в директории php-bin пользователя

Список доступных кодировок web домена берется из файла etc/charset. По умолчанию в нем указана только utf-8.

Настройка Apache

Во время запуска панели происходит опрос загруженных модулей apache. Так мы определяем список возможных настроек

возможность работы с CGI скриптами

fastcgi_module или fcgid_module

возможность работы с php в режиме fastcgi

php5_module

возможность работы c php через модуль apache

Если есть поддержка CGI и найден файл, указанный в path php-cgi, появляется возможность работы с php в режиме CGI

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

Option ApacheITK

Добавляется, если используется apache ITK. При этом в конфиг вместо директивы SuexecUserGroup пишется AssignUserID

path apachectl

Путь до программы/скрипта, используемого для перезапуска apache. Должен уметь обрабатывать следующие параметры: -M (получить список модулей), graceful (мягкая перезагрузка), restart (жесткая перезагрузка, используется при добавлении/удалении IP адресов)

path apache-vhosts

Имя каталога, в котором будут создаваться файлы с настройками web доменов

path apache.conf

Путь до основного файла конфигурации apache. В него будут записываться директивы Listen и NameVirtualHost

ApacheWidePorts

Для указанных портов в apache будет добавляется Listen для всех IP адресов сервера. По умолчанию: 80 443. Это позволяет уменьшить количество жестких перезапусков apache.

Настройка Nginx

Во время запуска панели проверяется наличие сервиса php-fpm. Если он найден, будет доступно использовать в настройках web доменов php в режиме fastcgi.

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

path nginx-vhosts

Имя каталога, в котором будут создаваться файлы с настройками web доменов

path nginx-vhosts-includes

Пути до файлов с дополнительными настройками, которые будут добавлены в секцию server каждого web домена (используется директива Include)

path fpm-pool.d

Имя каталога, в котором будут создаваться файлы с настройками php-fpm

path fpm-service

Имя сервиса php-fpm. Используется для его перезапуска при добавлении новых пользователей.

path nginx-static

Используется для определения файлов, которые nginx должен отдавать самостоятельно.

path nginxctl

Используется для перезапуска nginx при добавлении новых web доменов. Должна обрабатывать параметры: reload (перечитать настройки web доменов), restart (перезапустить nginx, используется при добавлении/удалении IP адресов), stop/start (запустить nginx, используется при конвертации настроек в случае добавления/удаления web сервера)

path nginx-configtest

Используется для проверки корректности содержимого конфигурационных файлов Nginx. По умолчанию равна [path nginxctl] configtest

Используется при запуске панели для проверки работоспособности nginx. Должна корректно обрабатывать параметр -V

ForwardedSecret

Используется для защиты от подделки IP адреса.

Пример
path nginx-static ~* ^youscript\.ext$ 

То создастся location

location ~* ^youscript\.ext$ < try_files $uri $uri/ @fallback; >
вместо
location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$ < try_files $uri $uri/ @fallback; >
ForwardedSecret

В случае, если вы переправляете запросы из nginx в панель, мы определяем обратный адрес по HTTP заголовку X-Forwarded-For. Злоумышленник получает возможность подменить обратный адрес, используя этот заголовок, что, в свою очередь, позволяет ему воспользоваться чужими COOKIE для выполнения запросов от имени другого пользователя. Панель игнорирует заголовок X-Forwarded-For, если запрос не содержит заголовка X-Forwarded-Secret с таким же значением, как то, что записано в конфиге.

Перезапуск web сервера

Попытка перезапуска web сервера происходит через 2 секунды после последнего изменения настроек. Если в течение этого времени происходят другие изменения, то перезапуск будет отложен еще на 2 секунды. Дополнительно вы можете задать параметр WebRestartDelay — минимальную задержку между последовательными перезапусками web сервера.

В случае, если изменения не затрагивали списка прослушиваемых IP адресов/портов, делается мягкая перезагрузка web сервера, в противном случае сервер перезапускается полностью.

Шаблоны конфигурационных файлов web-сервера

Начиная с версии 5.64 конфигурация web-сервера осуществляется с помощью нового механизма, описанного в статье Шаблонизатор конфигурационных файлов .

Данный раздел относится только к панелям управления, установленных ранее выхода версии 5.64 или не имеющих параметра Option EnableWebTemplate в конфигурационном файле

Для того, чтобы администратор сервера мог влиять на формирование конфигурационных файлов web-сервера для конкретного web-домена, реализованы шаблоны конфигурационных файлов, создаваемых ISPmanager 5.

Шаблоны не переопределяют тех настоек, что производит ISPmanager, а лишь позволяют добавлять дополнительные строки.

Файлы шаблонов находятся:

  • etc/templates/apache-vhost.template — шаблон файла конфигурации web-домена для web-сервера Apache
  • etc/templates/nginx-vhost.template — шаблон файла конфигурации web-домена для web-сервера Nginx

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

Макросы имеют вид: ____, имена параметров всегда полностью в верхнем регистре

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

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

  • _NAME_ — имя web-домена
  • _OWNER_ — имя пользователя-владельца web-домена
  • _ALIASES_ — список псевдонимов web-домена
  • _EMAIL_ — email администратора web-домена
  • _DIRINDEX_ — список индексных страниц web-домена
  • _CHARSET_ — кодировка страниц web-домена по умолчанию
  • _HOSTNAME_ — доменное имя сервера, на котором установлена панель управления
  • _LISTEN_ON_ — список пар типа IP-адрес:порт, используемых web-доменом
Пример

Чтобы добавить в location / сервера строки, составим следующий шаблон

server < server_name __NAME__ __ALIASES__; location / < try_files $uri $uri/ /index.php?$args; rewrite /wp-admin$ $scheme://$host$uri/ permanent; >> 

Обратите внимание, строка server_name _NAME_ _ALIASES_; должна обязательно присутствовать в шаблоне, иначе ISPmanager не определит в какой server добавить данные и добавить еще один server в конец файла.

Ротация журналов

Все журналы web сервера записываются в каталог httpd-logs, недоступный пользователям. В домашнем каталоге пользователя создается каталог logs куда создаются жесткие ссылки на журналы посещений и ошибок web доменов пользователя. Кроме того, в каталог logs сохраняются старые копии журналов после ротации.

ISPmanager 5 использует logrotate для ротации журналов web сервера.

path logrotate.d

Указывает каталог, куда будут сохраняться настройки logrotate (отдельные файлы для каждого web домена)

LogrotateInfiniteValue

Указывает количество хранимых архивов, если в панели указано бесконечное значение

Анализаторы журналов

Теоретически, ISPmanager может работать с любыми анализаторами журналов. На данный момент через интерфейс могут быть установлены:

path analyzer.d

Указывает каталог, куда будут сохраняться скрипты для анализа журналов (отдельные файлы для каждого web домена)

При установке анализатора журналов в конфиг панели записывается следующая секция:

Analyzer awstats < ConfPath /etc/awstats/awstats.__NAME__.conf BinPath /usr/lib/cgi-bin/awstats.pl Lang en Lang ru >

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

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

указывает поддерживаемые языки. Секция Analyzer может содержать любое количество таких строк

При включении анализатора журналов из каталога etc/template берется соответствующий шаблон скрипта (имя файла совпадает с именем анализатора). В нем происходит подстановка всех макросов (список макросов можно узнать, включив дебаг для модуля web) и копируется в каталог analyzer.d. Дополнительно формируется конфиг. Из etc/template берется соответствующий файл с расширением .conf, в нем так же заменяются все макросы и он сохраняется в файл, имя которого указано в ConfPath (вместо _NAME_ подставляется имя web домена).

Полученный скрипт вызывается всякий раз при ротации журнала через logrotate. Если вы задали периодический анализ, вызов этого скрипта будет добавлен в планировщик.

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

  • AwstatsEncoding — кодировка генерируемых awstats html-страниц отчетов
  • WebalizerEncoding — кодировка генерируемых webalizer html-страниц отчетов

По умолчанию данные параметры имеют значение «utf-8»

Переконфигурирование web-сервера

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

Внимание! Данное действие не сохранит изменения в конфигурационных файлах, внесенные вручную! 

Для выполнения операции последовательно нужно выполнить следующие функции:

webreconfigure.initialize с параметром shutdown=on webreconfigure.restore 

Пример выполнения с помощью mgrctl для ISPmanager Lite:

/usr/local/mgr5/sbin/mgrctl -m ispmgr webreconfigure.initialize shutdown=on /usr/local/mgr5/sbin/mgrctl -m ispmgr webreconfigure.restore 

В этой статье

  • Настройка web-сервера
  • Настройка Apache
  • Настройка Nginx
  • Пример
  • ForwardedSecret
  • Перезапуск web сервера
  • Шаблоны конфигурационных файлов web-сервера
  • Пример
  • Ротация журналов
  • Анализаторы журналов
  • Переконфигурирование web-сервера

PTS UPDATE

ВНИМАНИЕ! Все изменения устанавливаемые на тестовый сервер не являются окончательными, возможно некоторые из них никогда не будут установлены на основные сервера. Будьте осторожны при планировании действий на основных серверах, основываясь на обновлениях тестового сервера.

1699946116920.png

1700122680440.png

Общие изменения:
— Исправлена ошибка, из-за которой критические умения (Книжный крит) не учитывали параметры ближней атаки при использовании
— Снижена атака по монстрам в дальнем бою
— Улучшена атака по монстрам в ближнем бою
— Скорректирована сила атаки магии по древним монстрам
— Скорректирована атака по некоторым видам боссов

1700122680440.png

Изменения в умениях:

1701017365307.png

Взрыв элементаля — снижен дополнительный урон с 50/100/150% до 10/10/10%, а так же были изменены некоторые эффекты стихий:

1701017550111.png

Огненная стрела — снижает эффективность восстановления НР противника на 5/10/15%

1701017590962.png

Шаровая молния — замедляет скорость атаки противника на 30/60/90

1701017598664.png

Ледяная стрела — выжигает MP противнику 10/20/30% от текущего запаса МР

1701017606024.png

Кислотная стрела — снижает все виды защиты противника на 5/10/15
Эффект защиты от элементаля теперь действует 1 минуту, вместо 3
Эффект разрушения элементаля больше нельзя развеять

— У следующих умений изменена задержка применения, теперь скорость применения составляет 0,3 сек. (Ранее было 1 сек.), и так же добавлена перезарядка умения 0,7 сек.

1701017550111.png

Огненная стрела

1701017590962.png

Шаровая молния

1701017598664.png

Ледяная стрела

1701017606024.png

Кислотная стрела

1701566850142.png

1701472814778.png

1701472861280.png

1701649657185.png

Исцеление/Проклятие/Смертельная хватка — ускорена задержка применения

1701472911148.png

1701472939380.png

Медитация — больше не влияет на перезарядку других умений

1701211202790.png

Умение священный доспех (Древо умений) — изменено расположение в древе, перезарядка умения снижена до 60 секунд, поглощаемый урон снижен до 10%. Ускорено время применения.

1701830933064.png

Теперь требует 5 очков предыдущей строки для изучения

1701566850142.png

Сила стихий — увеличен базовый урон умения

1701616100786.png

Левитация — Повешенное уклонение — теперь эффект уклонение даёт все виды уклонения

1701566391265.png

Усиление развеивания магии, изменено расположение в древе умений:

1701650103520.png

Теперь требует 5 очков предыдущей строки для изучения

1701651062196.png

Усиление духовного удара ур.1-5 (Древо умений) — больше не увеличивает точность умения, теперь усиливает урон при использовании умения Духовный удар

1701651062196.png

, урон умения +5/10/15/20/25

1701839813667.png

Умение ледяная бездна (Древо умений), заменено на активное умение Магический кокон

1701839819357.png

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

1701840245539.png

Время эффекта поглощения 3 секунды, время перезарядки умения 1 минута

1700122680440.png

Изменения в предметах:
— Скорректирован магический урон сфер разрушения
— Изменён расчет магического урона для оружия, теперь оружие наносит урон в диапазоне от минимального до максимального
Например: урон +9 священного скипетра Метеоса был 280, теперь урон 280 и дополнительно 1 до 100 рандомного урона.
— Шлем героя арены теперь добавляет соответствующий магический урон
— Снижен магический урон бижутерии высокого интеллекта
— Посох веры Демоджара, снижен физический урон, повышена магическая точность, исправлена работа эффекта двойной выстрел

1699946116920.png

Класс рыцарь:

1700122680440.png

1703167173111.png

Усиление мощного удара (Древо умений) — больше не увеличивает урон умения Мощный удар, теперь наделяет пассивным эффектом шанса критических атак

1700122680440.png

1702257171914.png

Умение тройной удар (Древо умений) — заменено на умение Проклятие копья

1702258046471.png

1702258046471.png

Активное умение проклятие копья — при использовании ваш персонаж получает бонус к общей атаки, количество бонусной атаки зависит от общего показателя урона вашего персонажа
Время действия эффекта 3 минуты, время перезарядки 3 минуты

1700122680440.png

1702636991357.png

Умение улучшение мощного удара (II) (Древо умений) — Больше не даёт пассивный бонус силы и шанса критических атак, теперь умение увеличивает наносимый урон при использовании умения Мощный удар

1702637098474.png

, дополнительный урон 5/10/15

1700122680440.png

1702637554161.png

Умение яростный удар — теперь дополнительно восстанавливает запас НР при успешном использование умения Мощный удар

1702637098474.png

Эффект замедления атаки противника остался

1700122680440.png

1705488805347.png

Умение волна гнева — больше не увеличивает силу и точность атак, теперь даёт скорость атаки и передвижения.
Эффект развеивания отрицательных эффектов остался

1699946116920.png

Другие изменения

1700122680440.png

Была улучшена защита экипировки защиты, с +9 до +13
Дополнительные параметры начислены в скрытую защиту, визуально вы не сможете этого увидеть

Последнее редактирование: 29.01.2024

Комментарии

vov2oscar

За что рдд магу урон снижают по мобам? Онж бомж в сравнении с остальными классами

TopRein

За что рдд магу урон снижают по мобам? Онж бомж в сравнении с остальными классами
Сказочники вылезли) маг дальник с фул шмотом на заточку ниже фармит больше рейна если что

Skay4

Ну если начали — Скорректирована сила атаки магии по древним монстрам, то скорректируйте количество магического порошка который нужен для урона.

После исследования древа черной магии «покупки самых дешевых книг на этот класс» понимаешь что фарм мобов из за количества порошка и кристаллов которые нужны для убийства, приносит минус, даже не ноль. По крайней мере в таких локах как ИЛЮМА и ей подобных по уровню. Ну или же нужно как минимум +8+9 проточки пушка, то есть фарм таких лок изначально магу не подходит или не имеет смысла после покупки пушки на+8+9. Если задонил на пушку и книги то фармить ИЛЮМУ точно не будешь. А тут еще и урон по древним «Скорректирован» Это только верх Айсберга.

Снижен магический урон бижутерии высокого интеллекта, если купил себе пушку +8+9 то бегать с Бижей высокой инты точно не буду, а если только начинаю играть и бегаю с пушкой +6+7 то сниженный магический урон бижи еще больше загоняет этот класс в минус.
Клас маг с древом черной магии предназначен для игроков которые могут сразу задонить на пушку высокой проточки,»дешевые книги» количество которых ОГОГО, теперь еще и на бижу , не говоря о шмоте.

Забыть о фарме этим классом (зачем фарм если и так на все задонил)))

Вывод: Черный Маг будет внесен в красную книгу, если не в музей R2!)

vov2oscar

Сказочники вылезли) маг дальник с фул шмотом на заточку ниже фармит больше рейна если что

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

SinDrug

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

vov2oscar

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

Skrepy

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

Поделиться:

  • Форум
  • Reign of Revolution
  • News & Announcements
  • Updates

RevolGC.pro FIRSTPAYMENT LTD (Unit 42016, 2nd floor 6 Market Place, Fitzrovia, London, Registered Number: 12246448)

Установка и настройка nginx: пошаговая инструкция

url image

Как установить и настроить nginx

Nginx — высокопроизводительный веб-сервер и почтовый прокси-сервер с открытым исходным кодом, обслуживающий огромное количество высоконагруженных сайтов по всему миру. Nginx завоевал широкую популярность благодаря своей лёгкости, надёжности, масштабируемости и простоте настройки. Если вы хотите облегчить трудовые будни вашего сервера, nginx поможет снять с него часть нагрузки, а также повысить безопасность и отказоустойчивость ваших сайтов. В этой статье мы расскажем, как установить и настроить nginx, и рассмотрим его основные возможности на примере связки с php-fpm (PHP FastCGI Process Manager).

Установка nginx в Linux

Если nginx ещё не установлен в вашей системе, сделать это очень просто:

sudo apt update && sudo apt install nginx

для deb-based дистрибутивов (Debian и другие) и

sudo dnf update && sudo dnf install nginx

для rpm-based (CentOS и прочие). В дальнейшем мы будем говорить о Debian и CentOS, при необходимости останавливаясь на некоторых технических различиях этих платформ. Какой бы дистрибутив вы не выбрали, любой из них с успехом справится с обслуживанием вашего сайта.

Запуск nginx

После стандартной установки nginx запуск службы (service) можно выполнить командой:

sudo systemctl start nginx

Автозапуск nginx после перезагрузки системы включается так:

sudo systemctl enable nginx

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

sudo systemctl status nginx

Если все прошло успешно, вы должны увидеть строки:

. Loaded: loaded Active: active (running) . 

Тестовая страница приветствия

Теперь, если в браузере ввести адрес вашего сервера, например http://localhost в случае локальной установки, то вы увидите тестовую страницу приветствия. Если вы настраиваете сервер удалённо, здесь и далее замените localhost на IP-адрес или доменное имя вашего сайта. Если что-то пошло не так, возможно, придётся добавить необходимое правило для вашего брандмауэра (firewall). В любом случае вы всегда можете посмотреть подробный отчёт о работе nginx в журналах (логах) службы (об этом чуть позже), в терминале или с помощью команды

sudo journalctl -u nginx

Nginx в Docker

Если ваш сайт будет работать в контейнере и Docker уже установлен, то запустить nginx в новом контейнере можно командой

docker run -p 80:80 nginx

Если nginx ещё не установлен, эта команда также автоматически скачает и установит его из официального образа. Ключ -p здесь отвечает за сопоставление, или «проброс», портов: первым указывается порт на локальном компьютере, вторым — внутри контейнера. Поскольку мы пока не меняем настройки nginx, для тестирования используем стандартный порт 80 для http соединений. Теперь можно посмотреть список запущенных контейнеров:

docker ps

Обратите внимание на столбцы IMAGE и PORTS. В нашем примере в выводе этой команды должна присутствовать строка

. nginx . 0.0.0.0:80->80/tcp . 

Cтраница приветствия

Это значит, что nginx готов принимать входящие HTTP соединения по IP-адресу вашего сервера. Например, если docker установлен локально, то по адресу http://localhost в браузере вы увидите страницу приветствия с надписью. Отлично, мы запустили nginx, конфигурация по умолчанию сделала за нас всю основную работу. Запуск внутри контейнера особенно удобен для разработки, потому что позволяет отлаживать неограниченное число копий сайта с разными настройками и версиями программ.

Структура каталогов nginx

Во время установки nginx может создавать несколько папок в зависимости от вашего дистрибутива Linux. Нас интересует, в первую очередь, главный файл конфигурации nginx.conf , который по умолчанию обычно расположен в каталоге /etc/nginx/ . На тот случай, если на вашем сервере будет работать несколько сайтов, их настройки удобно вынести в отдельные файлы. Debian предлагает использовать для этого папку /etc/nginx/sites-available/ или /etc/nginx/conf.d/ на выбор, а CentOS — только /etc/nginx/conf.d/ . В этом руководстве мы поместим настройки всех наших сайтов в каталог /etc/nginx/conf.d/ , что обеспечит переносимость конфигурации на любой дистрибутив. Тестовая страница приветствия находится в каталоге /usr/share/nginx/html , а журналы службы записываются в /var/log/nginx/ .

Первичная настройка nginx

Теперь можно приступать к самому интересному — настройке. Давайте взглянем на основной файл конфигурации /etc/nginx/nginx.conf . Он содержит строки, содержащие директивы nginx и их параметры, и комментарии, начинающиеся со знака «#». Общая структура конфигурации nginx выглядит так:

. http < . server < . location . < . >> >
  • Во-первых, у вас может быть несколько сайтов. Тогда вам понадобится несколько блоков server, и файл станет настолько большим, что его будет трудно читать.
  • Во-вторых, некоторые настройки могут повторяться в разных блоках, поэтому обычно их выносят в отдельные файлы и в нужных местах подключают директивой include.
  • В-третьих, если вынести настройки каждого блока server в отдельную конфигурацию, очень удобно включать и отключать сайты простым переносом или переименованием всего одного файла.
  • В-четвёртых, вы всегда будете видеть, какой именно сайт был изменён последним по времени модификации файла.
  • И в пятых, хранение настроек сайта в отдельном файле сводит к минимуму риск случайного повреждения общей конфигурации при редактировании.

Надеемся, мы убедили вас придерживаться правила «один сайт — один файл конфигурации».

А пока давайте рассмотрим nginx.conf , настройка которого была выполнена автоматически при установке пакета, повнимательней. Полная версия этого файла в Debian выглядит так:

user www-data; worker_processes auto; pid /run/nginx.pid; error_log /var/log/nginx/error.log; include /etc/nginx/modules-enabled/*.conf; events < worker_connections 768; >http < sendfile on; tcp_nopush on; types_hash_max_size 2048; include /etc/nginx/mime.types; default_type application/octet-stream; ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; ssl_prefer_server_ciphers on; access_log /var/log/nginx/access.log; gzip on; include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*; >
user nginx; worker_processes auto; error_log /var/log/nginx/error.log notice; pid /run/nginx.pid; include /usr/share/nginx/modules/*.conf; events < worker_connections 1024; >http < log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; sendfile on; tcp_nopush on; keepalive_timeout 65; types_hash_max_size 4096; include /etc/nginx/mime.types; default_type application/octet-stream; include /etc/nginx/conf.d/*.conf; server < listen 80; listen [::]:80; server_name _; root /usr/share/nginx/html; include /etc/nginx/default.d/*.conf; error_page 404 /404.html; location = /404.html < >error_page 500 502 503 504 /50x.html; location = /50x.html < >> >

Как мы видим, эти файлы очень похожи. Разница в том, что основная конфигурация CentOS содержит блок server для сайта по умолчанию, который в Debian вынесен в отдельный файл в каталоге /etc/nginx/sites-enabled/ и включается директивой include . После установки мы найдем тут файл default (на самом деле, являющийся ссылкой на файл /etc/nginx/sites-available/default ) следующего содержания:

server < listen 80 default_server; listen [::]:80 default_server; server_name _; root /var/www/html; index index.html index.htm index.nginx-debian.html; location / < try_files $uri $uri/ =404; >>

Как мы убедились ранее, этот блок указывает службе nginx принимать, или, как говорят администраторы, «слушать» входящие соединения на порту 80. Это порт по умолчанию для протокола HTTP.

Теперь давайте в каталоге /etc/nginx/conf.d/ создадим файл example.conf с настройками нашего первого сайта, или, в терминах nginx, «виртуального сервера»:

sudo nano /etc/nginx/conf.d/example.conf

Конечно, вместо nano вы можете использовать свой любимый редактор.

Поместите в этот файл такие строки:

server < listen 8080; root /var/www/html; index index.html index.htm; location / < try_files $uri $uri/ =404; >>

Обратите внимание, что наш новый виртуальный сервер слушает порт 8080. Это сделано потому, что порт 80 уже занят сервером по умолчанию, описанным выше.

После перезапуска nginx конфигурация вступит в силу:

sudo systemctl restart nginx

Давайте проверим результат, набрав в адресной строке браузера http://localhost:8080/ . Вы должны увидеть уже знакомую нам страницу приветствия.

А теперь давайте отредактируем example.conf таким образом, чтобы nginx перенаправлял, или «проксировал», входящие соединения службе php-fpm . Для этого в блоке server добавьте ещё один блок location :

location ~ \.php$ < include snippets/fastcgi-php.conf; fastcgi_pass 127.0.0.1:9000; >

Этот блок обработает все запросы к динамическим файлам с расширением .php , а директива fastcgi_pass здесь делает основную работу — проксирует запросы на порт 9000 (номер порта можно изменить). Адрес 127.0.0.1 используется, если оба сервера запущены на одном компьютере. Теперь можно настроить ваш основной сервер php-fpm на прослушивание локального адреса http://127.0.0.1:9000.

Обратите внимание на использование специальной директивы fastcgi_pass. Если вам нужно перенаправить запрос другой службе или другому серверу в сети, можно использовать более общий вариант — proxy_pass :

proxy_pass 127.0.0.1:9000;

Если ваши службы работают на разных физических серверах, здесь и в дальнейших примерах замените 127.0.0.1 на их IP-адреса в сети.

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

server < listen 8080; root /var/www/html; index index.html index.htm; location / < try_files $uri $uri/ =404; >location ~ \.php$ < include snippets/fastcgi-php.conf; fastcgi_pass 127.0.0.1:9000; >>

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

sudo systemctl restart nginx

Установка и настройка php-fpm

Установить пакет php-fpm можно командой

sudo apt install php-fpm
sudo dnf install php-fpm

Конфигурация для CentOS будет находится в файле /etc/php-fpm.d/www.conf ,

а для Debian в /etc/php/8.2/fpm/pool.d/www.conf .

Номер установленной версии PHP (в нашем примере 8.2) можно узнать так:

sudo ls /etc/php/
php --version

Затем в файле конфигурации www.conf добавьте строку:

listen = 127.0.0.1:9000

а существующую директиву listen закомментируйте:

; listen = /run/. 

Для проверки работы связки nginx — php-fpm давайте создадим тестовый файл:

sudo echo "" > /var/www/html/info.php

и перезапустим службу php-fpm:

sudo systemctl restart php8.2-fpm
sudo systemctl restart php-fpm

Если вы всё сделали правильно, то по адресу http://localhost:8080/info.php в браузере откроется стандартный вывод phpinfo.

Стандартный вывод phpinfo

А если нет, лучше заглянуть в журнал /var/log/nginx/error.log . Кроме того, вы всегда можете проверить прослушиваемые порты командой:

netstat -lntp

Как видите, настройка веб-сервера nginx в связке с php-fpm также не вызывает особых сложностей.

Настройка безопасного соединения

Если ваш сервер принимает или передаёт чувствительные данные пользователя, например данные авторизации или платёжную информацию, рекомендуется использовать протокол безопасной передачи данных HTTPS. Этот протокол по умолчанию использует порт 443. Для прослушивания этого порта в блок server в файле конфигурации сайта нужно добавить строку

listen 443 ssl;

Кроме того, для работы по протоколу HTTPS вам понадобится сертификат SSL. Его можно как купить, так и получить бесплатно, например в центре сертификации Let’s Encrypt. Для того, чтобы nginx самостоятельно проверял сертификаты, нужно добавить строки

ssl_certificate example.ru.crt ssl_certificate_key example.ru.key;

где www.example.ru.crt — абсолютный путь к файлу публичного сертификата, а www.example.ru.key — секретный ключ. Например, для сертификатов Let’s Encrypt эти строки могут выглядеть так:

ssl_certificate /etc/letsencrypt/live/example.ru/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.ru/privkey.pem;

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

Таким образом, минимальная рабочая конфигурации сайта теперь может выглядеть примерно так:

server < listen 8080; root /var/www/html; index index.html index.htm; location / < try_files $uri $uri/ =404; >location ~ \.php$ < include snippets/fastcgi-php.conf; fastcgi_pass 127.0.0.1:9000; >> server < listen 443 ssl; server_name example.ru www.example.ru; root /var/www/html; index index.html index.htm; charset UTF-8; ssl_certificate /etc/letsencrypt/live/example.ru/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.ru/privkey.pem; location / < try_files $uri $uri/ =404; >location ~ \.php$ < include snippets/fastcgi-php.conf; fastcgi_pass 127.0.0.1:9000; >>

Для автоматического обновления SSL-сертификатов Let’s Encrypt вы можете использовать клиент certbot. Документацию по его настройке можно найти на официальном сайте (на английском языке) или в статье «Как установить бесплатный сертификат Let’s Encrypt и настроить автоматический перевыпуск».

Обратите внимание, что этот виртуальный сервер принимает только запросы к сайту example.ru (и его «алиасу» www.example.ru ), а все остальные соединения продолжает обрабатывать блок server по умолчанию.

Если вы ещё не настроили DNS для домена example.ru или отлаживаете сервер локально, пользуясь самозаверенным сертификатом, вы можете временно указать соответствие этого домена IP-адресу сервера в файле hosts на вашем персональном компьютере, добавив в него строку

127.0.0.1 example.ru www.example.ru

Расположение файла hosts зависит от операционной системы. Для Windows это будет c:\windows\system32\drivers\etc\hosts , для MacOS — /private/etc/hosts , а для Linux — /etc/hosts . Для редактирования этого файла потребуются права администратора.

После включения протокола HTTPS рекомендуется проверить соответствие ваших настроек современным требованиям безопасности. Для этого удобно использовать онлайн сервисы, например: https://audit.statdom.ru/, https://observatory.mozilla.org/, https://www.wormly.com/test_ssl и другие.

Редирект с http на https

Для того, чтобы пользователи вашего сайта случайно не зашли на страницу авторизации по протоколу http, лучше перенаправить их на безопасный протокол https автоматически. Nginx легко справится и с этой задачей. Просто добавьте в файл конфигурации вашего сайта в блок server, прослушивающий порт 80, такую директиву:

return 301 https://$host$request_uri;

и перезапустите nginx.

В итоге полная версия файла будет такой:

server < listen 80; server_name example.ru www.example.ru; return 301 https://$host$request_uri; >server < listen 443 ssl; server_name example.ru www.example.ru; root /var/www/html; index index.html index.htm; charset UTF-8; ssl_certificate /etc/letsencrypt/live/example.ru/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.ru/privkey.pem; location / < try_files $uri $uri/ =404; >location ~ \.php$ < include snippets/fastcgi-php.conf; fastcgi_pass 127.0.0.1:9000; >>

Обратите внимание, что в этой конфигурации мы снова прослушиваем порт 80, но на этот раз на домене example.ru. Если из блока server , отвечающего за редирект, убрать директиву server_name , перенаправление работать не будет, так как nginx применит настройку по умолчанию. Другими словами, при добавлении виртуальных доменов вам нужно следить, чтобы один и тот же порт не использовался на одинаковых доменах.

Если виртуальный сервер по умолчанию, созданный автоматически при установке nginx, вам больше не нужен, можно просто удалить блок server , описанный в начале этого руководства. В Debian вместо этого достаточно удалить только символическую ссылку на файл default :

sudo rm /etc/nginx/sites-enabled/default

После этого, если это необходимо, вы можете удалить директивы server_name из конфигурации вашего сайта, чтобы nginx использовал его по умолчанию.

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

sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/default.orig

Директивы nginx

Мы уже рассмотрели блочные директивы http, server и location. Теперь можно привести краткий справочник прочих директив, используемых в этом руководстве (в алфавитном порядке):

  • access_log — задаёт путь, формат и настройки буферизованной записи в лог;
  • allow — позволяет ограничить доступ для определённых адресов клиентов;
  • auth_basic — включает проверку имени и пароля пользователя по протоколу «HTTP Basic Authentication»;
  • auth_basic_user_file — задаёт файл, в котором хранятся имена и пароли пользователей;
  • charset — добавляет указанную кодировку в поле «Content-Type» заголовка ответа;
  • client_max_body_size — задаёт максимально допустимый размер тела запроса клиента;
  • default_type — задаёт MIME-тип ответов по умолчанию;
  • deny — запрещает доступ для указанной сети или адреса;
  • error_log — конфигурирует запись в лог;
  • error_page — задаёт URI, который будет показываться для указанных ошибок;
  • events — предоставляет контекст файла конфигурации, в котором указываются директивы, влияющие на обработку соединений;
  • fastcgi_pass — задаёт адрес FastCGI-сервера. Адрес может быть указан в виде доменного имени или IP-адреса и порта;
  • include — включает в конфигурацию другой файл или файлы, подходящие под заданную маску;
  • index — определяет файлы, которые будут использоваться в качестве индекса;
  • keepalive_timeout — задаёт таймаут, в течение которого keep-alive соединение с клиентом не будет закрыто со стороны сервера;
  • limit_conn — задаёт зону разделяемой памяти и максимально допустимое число соединений для одного значения ключа;
  • limit_conn_zone — задаёт параметры зоны разделяемой памяти, которая хранит состояние для разных значений ключа;
  • limit_req — задаёт зону разделяемой памяти (zone) и максимальный размер всплеска запросов (burst);
  • limit_req_zone — задаёт параметры зоны разделяемой памяти, которая хранит состояние для разных значений ключа;
  • log_format — задаёт формат лога;
  • pid — задаёт файл, в котором будет храниться номер (PID) главного процесса;
  • proxy_cache — задаёт зону разделяемой памяти, используемой для кэширования;
  • proxy_cache_path — задаёт протокол и адрес проксируемого сервера;
  • proxy_pass — задаёт протокол и адрес проксируемого сервера;
  • proxy_set_header — позволяет переопределять или добавлять поля заголовка запроса, передаваемые проксируемому серверу;
  • return — завершает обработку и возвращает клиенту указанный код;
  • root — задаёт корневой каталог для запросов;
  • satisfy — разрешает доступ, если все (all) или хотя бы один (any) из модулей разрешают доступ;
  • server_name — задаёт имена виртуального сервера;
  • ssl_certificate — указывает файл с сертификатом в формате PEM для виртуального сервера;
  • ssl_certificate_key — указывает файл с секретным ключом в формате PEM для виртуального сервера;
  • stub_status — информация о состоянии будет доступна из данного location;
  • tcp_nopush — разрешает или запрещает использование параметра сокета TCP_CORK при использовании sendfile;
  • types_hash_max_size — задаёт максимальный размер хэш-таблиц типов;
  • upstream — описывает группу серверов;
  • user — задаёт пользователя и группу, с правами которого будут работать рабочие процессы;
  • worker_processes — задаёт число рабочих процессов.

С полным перечнем директив можно ознакомиться на официальном сайте.

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

Переменные в nginx

В файлах конфигурации можно использовать встроенные переменные. Например, выше мы использовали переменные $host и $request_uri . $host содержит название вашего домена (в примере это example.ru или www.example.ru), а $request_uri — всю остальную часть запроса (путь) или пустую строку.

Другим полезным примером может быть передача доменного имени и IP-адреса в заголовках запроса. Для этого достаточно в блок location добавить строки

proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr;

Здесь мы использовали переменные $http_host и $remote_addr . С полным списком переменных можно ознакомиться в официальной документации.

Команды nginx

Мы уже упоминали, что после изменения настроек службы её нужно перезапустить командой restart . Но для этого в nginx есть и более удобная команда — reload :

sudo systemctl reload nginx
sudo nginx -s reload

Эта команда выполнит «горячую» перезагрузку без остановки nginx. При наличии ошибки в одном из файлов конфигурации перезагрузка выполнена не будет, а сервис продолжит работу. Настоятельно рекомендуется на рабочем сервере использовать именно reload .

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

sudo nginx -t

Для немедленной остановки используется команда

sudo systemctl stop nginx

Статические файлы

Теперь, когда вы научились свободно обращаться с вашим сервером и выполнили основные настройки, пришло время сделать что-то полезное. Одна из самых востребованных функций nginx — возможность отдавать клиентам «статические» файлы, такие как css, js, изображения и любые другие. Для примера, давайте поместим эти файлы в отдельную папку и добавим в блок server такую запись:

location /static < root /путь/к/папке/со/статическими/файлами; >

Этот блок обработает все запросы, поступившие на адрес https://example.ru/static . Теперь ваш основной сервер не будет тратить ресурсы на передачу статического содержимого. Просто и эффективно, не правда ли?

При необходимости в блоке location вы можете использовать регулярные выражения так же, как мы делали это для файлов .php:

location ~ \.(jpg|jpeg|png|ico|gif|css|js)$ < root /путь/к/папке/со/статическими/файлами; >

Кэширование в nginx

Что, если после того, как ваш сайт наберёт обороты, вы поймёте, что php-fpm начал плохо справляться с возросшей нагрузкой? В таком случае разумно будет на непродолжительное время запомнить наиболее частые ответы сервера во временных файлах (кэше) и отдавать эти файлы клиенту напрямую.

В nginx за этот режим отвечает директива proxy_cache_path . Вот пример:

proxy_cache_path /var/lib/nginx/proxy_cache keys_zone=nginx_proxy_cache:10m;

Здесь /var/lib/nginx/proxy_cache — путь хранения кэша. Этот каталог можно предварительно создать командой

sudo mkdir /var/lib/nginx/proxy_cache

где параметр keys_zone определяет имя зоны для хранения активных ключей и размер выделяемой для этого памяти.

Чтобы включить режим кэширования, нужно поместить директиву proxy_cache_path в блок http (контекст верхнего уровня), а в блок server добавить заданное этой директивой имя зоны. Например:

http < . proxy_cache_path /var/lib/nginx/proxy_cache keys_zone=nginx_proxy_cache:10m; server < proxy_cache nginx_proxy_cache; location ~ \.php$ < . fastcgi_pass 127.0.0.1:9000; >> >

Мониторинг nginx

Кроме чтения журналов, nginx предоставляет возможность отслеживать его статус на «странице состояния» с помощью модуля ngx_http_stub_status_module . Проверить наличие этого модуля в вашей системе можно командой

nginx -V 2>&1 | grep -o http_stub_status_module

Если модуль установлен, вы можете добавить в блок server ещё один блок location :

location /nginx-status

После перезагрузки nginx вы сможете открыть в браузере страницу https://example.ru/nginx-status, содержащую базовую информацию о состоянии службы, например:

Active connections: 21 server accepts handled requests 907 907 453 Reading: 12 Writing: 74 Waiting: 18

Полная версия файла конфигурации виртуального сервера теперь должна быть такой:

server < listen 80; server_name example.ru www.example.ru; return 301 https://$host$request_uri; >server < listen 443 ssl; server_name example.ru www.example.ru; charset UTF-8; ssl_certificate /etc/letsencrypt/live/example.ru/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.ru/privkey.pem; location / < try_files $uri $uri/ =404; >location ~ \.php$ < include snippets/fastcgi-php.conf; fastcgi_pass 127.0.0.1:9000; >location /nginx-status < stub_status on; >>

Доступные состояния расшифровываются так:

  • active connections — текущее число активных клиентских соединений, включая Waiting соединения;
  • accepts — суммарное число принятых клиентских соединений;
  • handled — суммарное число обработанных соединений;
  • requests — суммарное число клиентских запросов;
  • reading — текущее число соединений, в которых nginx в настоящий момент читает заголовок запроса;
  • writing — текущее число соединений, в которых nginx в настоящий момент отвечает клиенту;
  • waiting — текущее число бездействующих клиентских соединений в ожидании запроса.

Балансировка нагрузки

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

http < upstream load_balancer < server 127.0.0.1:9000; server 127.0.0.1:9001; >server < listen 80; server_name example.ru; location / < proxy_pass http://load_balancer; include proxy_params; >> >

Здесь load_balancer — произвольное имя вышестоящего потока (upstream), используемое в директиве proxy_pass . В этом примере nginx распределяет запросы между двумя независимыми службами, слушающими порты 9000 и 9001.

Безопасность сайтов в nginx

Мы уже рассматривали работу nginx по безопасному протоколу HTTPS. Теперь давайте включим авторизацию пользователей, например при просмотре настроенной выше страницы мониторинга. Для этого измените location таким образом:

location /nginx-status < stub_status on; auth_basic "Restricted area"; auth_basic_user_file /etc/nginx/conf.d/htpasswd; >

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

Создать файл /etc/nginx/conf.d/htpasswd можно так:

sudo htpasswd -c /etc/nginx/conf.d/htpasswd admin

Эта команда предложит вам ввести пароль пользователя admin и подтвердить его, а затем поместит зашифрованные данные в указанный файл. Утилита htpasswd входит в состав пакета apache2-utils в Debian и httpd-tools — в CentOS. Если этот пакет ещё не установлен в вашей системе, выполните стандартную команду install .

Кроме запроса авторизации, мы можем также ограничить доступ к странице по IP-адресу пользователя:

location /nginx-status < stub_status on; satisfy any; allow 192.168.0.0/24; deny all; >

Директива allow разрешает доступ к странице только из локальной сети. Таких директив при необходимости может быть несколько — например, вы можете перечислить здесь конкретные IP-адреса администраторов.

Ещё мы можем закрыть доступ к некоторым каталогам в структуре сайта, например блок

location ~ /.git

закроет доступ к директории .git.

Вот что у нас должно получиться:

server < listen 80; server_name example.ru www.example.ru; return 301 https://$host$request_uri; >server < listen 443 ssl; server_name example.ru www.example.ru; root /var/www/html; index index.html index.htm; charset UTF-8; ssl_certificate /etc/letsencrypt/live/example.ru/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.ru/privkey.pem; location / < try_files $uri $uri/ =404; >location ~ \.php$ < include snippets/fastcgi-php.conf; fastcgi_pass 127.0.0.1:9000; >location /nginx-status < stub_status on; stub_status on; satisfy any; allow 192.168.0.0/24; deny all; auth_basic "Restricted area"; auth_basic_user_file /etc/nginx/conf.d/htpasswd; >location ~ /.git < return 404; >>

Как видите, nginx позволяет нам свободно комбинировать различные ограничения.

Предотвращение DDoS атак

DoS, или Denial of Service (отказ в обслуживании), и его разновидность DDoS, или Distributed Denial of Service (распределённый отказ в обслуживании), — это тип хакерской атаки, вызывающий перегрузку сервера и, в результате, замедление или полную недоступность сайта. Конечно, nginx, конфигурация которого позволяет выполнять очень широкий спектр задач, придёт нам на помощь и в этот раз.

Предотвращать последствия DDoS атак можно несколькими методами. Выше мы уже рассматривали балансировку нагрузки и кэширование, которые также снижают возможный ущерб от DDoS. Ещё одним способом добиться стабильной работы сайта может стать ограничение скорости обработки запросов. Давайте добавим к конфигурации нашего сайта директивы limit_req_zone и limit_req :

limit_req_zone $binary_remote_addr zone=limitbyreq:10m rate=10r/s; server < . location ~ \.php$ < limit_req zone=limitbyreq; . >>

В этом примере limit_req_zone определяет ограничение скорости обработки для каждого IP-адреса клиента до 10 запросов в секунду, а limit_req включает это ограничение для нужного вида запросов (здесь мы снимаем нагрузку с php-fpm).

Ещё один метод борьбы с нежелательным трафиком — ограничение количества одновременных подключений с помощью директивы limit_conn :

limit_conn_zone $binary_remote_addr zone=limitbyaddr:20m; server < . location ~ \.php$ < limit_conn limitbyaddr 50; . >>

В этом примере мы позволяем подключиться к php-fpm не более 50-ти клиентам одновременно.

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

Ошибки nginx

Мы уже узнали, как настроить nginx и познакомились с общими методами решения возможных проблем, почти неизбежно возникающих при настройке сервера. Напомним, что лучшая практика при отладке служб — это анализ журналов (логов). Также, разумеется, первым делом нужно проверить статус служб и убедиться, что они находятся в активном состоянии. Кроме того, стоит обратить внимание на коды ошибок, которые предоставляет нам nginx. Вот некоторые из них:

502 Bad Gateway

Эта ошибка означает, что nginx не может получить ответ от службы, на которую перенаправлен запрос, в нашем случае php-fpm. Как правило, возникает из-за отключённого или неверно настроенного сервиса, а так же в случае ошибки 500 в самом сервисе. Рекомендации по устранению приведены в разделе «Установка и настройка php-fpm». Ошибка 502 может также возникать, если php-fpm не справляется с нагрузкой. В этом случае лучше ещё раз взглянуть на раздел «балансировка нагрузки».

503 Service Unavailable

Сервер временно не готов обработать запрос, например из-за перегрузки или при проведении технических работ.

504 Gateway Time-out

Означает, что служба не отвечает в течение установленного времени. В случае php-fpm можно попробовать увеличить это ограничение:

location ~ \.php$

403 Forbidden

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

413 Request Entity Too Large

Возможно, клиент пытается загрузить слишком большой файл. Ограничение размера файла можно изменить директивой client_max_body_size в блоке server:

server

404 Not Found

Означает, что запрашиваемого файла просто нет в структуре сайта. Эта ошибка не имеет прямого отношения к nginx, но тем не менее её, как и другие ошибки, можно обработать.

Давайте будем показывать пользователям вместо сухой технической информации красивые страницы в фирменном стиле вашего сайта. Для этого добавьте в блок server ещё несколько директив, например:

error_page 404 /404.html; location = /404.html

При необходимости в блоке location вы также можете использовать директиву root для указания каталога, содержащего файл страницы ошибки.

Теперь вы можете отредактировать HTML страницу /var/www/html/404.html в стиле вашего сайта. Таким же образом можно обработать и другие ошибки. Вот полный пример:

limit_conn_zone $binary_remote_addr zone=limitbyaddr:20m; limit_req_zone $binary_remote_addr zone=limitbyreq:10m rate=10r/s; server < listen 80; server_name example.ru www.example.ru; return 301 https://$host$request_uri; >server < listen 443 ssl; server_name example.ru www.example.ru; root /var/www/html; index index.html index.htm; charset UTF-8; ssl_certificate /etc/letsencrypt/live/example.ru/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.ru/privkey.pem; location / < try_files $uri $uri/ =404; >location ~ \.php$ < limit_req zone=limitbyreq; limit_conn limitbyaddr 50; include snippets/fastcgi-php.conf; fastcgi_pass 127.0.0.1:9000; >location /static < root /var/www/html; >location /nginx-status < stub_status on; stub_status on; satisfy any; allow 192.168.0.0/24; deny all; auth_basic "Restricted area"; auth_basic_user_file /etc/nginx/conf.d/htpasswd; >location ~ /.git < return 404; >error_page 404 /404.html; location = /404.html < internal; >error_page 403 413 500 502 503 504 /500.html; location = /500.html < internal; >> 

Заключение

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

В качестве домашнего задания рекомендуем перенести структуру вашего сайта из каталога по умолчанию /var/www/html , например, в домашнюю папку пользователя, используя директиву root в блоке server , и определить нужный индексный файл с помощью директивы index .

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

Удачи в настройке и работе!

Глава 21. Обновление системы и смена версии FreeBSD

Этот перевод может быть устаревшим. Для того, чтобы помочь с переводом, пожалуйста, обратитесь к Сервер переводов FreeBSD.

21.1. Краткий обзор

Между релизами над FreeBSD ведется постоянная работа. Некоторые отдают предпочтение официально выпущенным версиям, в то время как остальные предпочитают использовать последние разработки. Тем не менее, даже для официальных версий часто выходят обновления, связанные с безопасностью и другими критическими исправлениями. Независимо от используемой версии FreeBSD предоставляет все необходимые инструменты для поддержания системы в актуальном состоянии, а также позволяет легко перейти на другую версию. Эта глава описывает, как отслеживать систему в процессе её разработки, а также основные инструменты для поддержания системы FreeBSD в актуальном состоянии.

После чтения этой главы вы будете знать:

  • Как поддерживать систему FreeBSD в актуальном состоянии при помощи freebsd-update, Subversion или CTM.
  • Как узнать состояние установленной системы по отношению к известной нетронутой копии.
  • Как поддерживать установленную документацию в актуальном состоянии при помощи Subversion или портов документации.
  • Разницу между двумя ветвями разработки: FreeBSD-STABLE и FreeBSD-CURRENT.
  • Как перестраивать и переустанавливать всю базовую систему.

Перед чтением этой главы вы должны:

  • Правильно настроить сетевое подключение (Сложные вопросы работы в сети).
  • Знать, как устанавливать дополнительное стороннее программное обеспечение (Установка приложений. порты и пакеты).

В этой главе для получения и обновления исходных текстов FreeBSD используется команда svn . Для этого нужно сперва установить порт или пакет devel/subversion.

21.2. Обновление FreeBSD

Своевременное применение обновлений безопасности и переход на более новую версию операционной системы — важные аспекты системного администрирования. FreeBSD включает в себя программу freebsd-update , которую можно использовать для решения обеих задач.

Эта программа используется для установки распространяемых в двоичном виде обновлений безопасности и исправлений для FreeBSD без необходимости ручной компиляции и установки патчей или нового ядра. Двоичные обновления доступны для всех архитектур и версий, поддерживаемых группой безопасности. Перечень поддерживаемых версий и их ожидаемые даты окончания поддержки указаны на странице http://www.FreeBSD.org/security/.

Эта программа также используется для незначительных обновлений версии операционной системы, а также для перехода на другую ветвь выпуска релизов. Перед обновлением следует ознакомиться с объявлением о выпуске новой версии, так как там может содержаться важная информация, применимая к версии, на которую намечен переход. С соответствующими объявлениями можно ознакомиться по ссылке http://www.FreeBSD.org/releases/.

Если имеется задание crontab , запускающее freebsd-update(8), то перед сменой версии операционной системы его обязательно нужно выключить.

В этом разделе описывается конфигурационный файл freebsd-update , демонстрируется применение исправлений безопасности и обновление операционной системы со сменой младшей или старшей версии, а также обсуждаются некоторые соображения касаемо смены версии операционной системы.

21.2.1. Конфигурационный файл

Конфигурационный файл freebsd-update самодостаточен и работает по умолчанию. Некоторые пользователи могут пожелать отредактировать конфигурационный файл /etc/freebsd-update.conf для лучшего контроля над процессом обновления. В комментариях описываются доступные в этом файле параметры, но для следующих из них может потребоваться дополнительное разъяснение:

# Components of the base system which should be kept updated. Components world kernel

Данный параметр определяет, какие части FreeBSD будут обновлены. По умолчанию обновляется вся базовая система (world) и ядро (kernel). Вместо этого можно указать отдельные компоненты, такие как src/base или src/sys . Тем не менее, лучшим вариантом будет оставить всё как есть, поскольку изменение этого перечня с целью добавления особых пунктов потребует от пользователя указания подряд всех пунктов. Со временем это может привести к негативным последствиям из-за возможной рассинхронизации между исходными текстами и двоичными файлами.

# Paths which start with anything matching an entry in an IgnorePaths # statement will be ignored. IgnorePaths /boot/kernel/linker.hints

Добавьте сюда пути к каталогам (например, /bin или /sbin ), которые вы бы хотели оставить нетронутыми в процессе обновления. Этот параметр можно использовать для предотвращения перезаписывания локальных изменений программой freebsd-update .

# Paths which start with anything matching an entry in an UpdateIfUnmodified # statement will only be updated if the contents of the file have not been # modified by the user (unless changes are merged; see below). UpdateIfUnmodified /etc/ /var/ /root/ /.cshrc /.profile

Этот параметр позволяет обновлять конфигурационные файлы в указанных каталогах, только если они не содержат изменений. При наличии каких-либо изменений со стороны пользователя автоматическое обновление таких файлов отменяется. Есть другой параметр KeepModifiedMetadata , который предписывает команде freebsd-update сохранять изменения в процессе слияния.

# When upgrading to a new FreeBSD release, files which match MergeChanges # will have any local changes merged into the version from the new release. MergeChanges /etc/ /var/named/etc/ /boot/device.hints

Список каталогов с конфигурационными файлами, для которых freebsd-update попытается выполнить слияние. Процесс слияния файла представляет собой последовательность изменений в формате diff(1), похожую на mergemaster(8), но с меньшим количеством параметров. Результат слияния принимается, открывается редактор или freebsd-update прекращает работу. В случае сомнений сделайте резервную копию /etc и просто согласитесь со всеми изменениями. Для получения подробной информации по команде mergemaster смотрите Объединение файлов конфигурации.

# Directory in which to store downloaded updates and temporary # files used by FreeBSD Update. # WorkDir /var/db/freebsd-update

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

# When upgrading between releases, should the list of Components be # read strictly (StrictComponents yes) or merely as a list of components # which *might* be installed of which FreeBSD Update should figure out # which actually are installed and upgrade those (StrictComponents no)? # StrictComponents no

Если выставлено значение yes , то freebsd-update будет исходить из того, что список Components является полным, и не будет пытаться выполнить изменения за пределами этого списка. В действительности freebsd-update попытается обновить все файлы, которые принадлежат списку Components .

21.2.2. Обновления безопасности

Процесс применения обновлений безопасности FreeBSD был упрощён, что позволяет поддерживать систему в актуальном состоянии, используя freebsd-update . Для получения дополнительной информации по бюллетеням безопасности FreeBSD смотрите Сообщения безопасности FreeBSD.

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

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

Можно настроить ежедневную автоматическую проверку наличия обновлений, добавив следующую запись в /etc/crontab :

@daily root freebsd-update cron

При наличии обновлений они будут автоматически загружены. Пользователю root будет отправлено письмо, так что эти обновления можно будет просмотреть и установить самостоятельно командой freebsd-update install .

На случай, если что-то пошло не так, в freebsd-update предусмотрен механизм возврата последнего набора изменений с использованием следующей команды:

 Uninstalling updates. Если после завершения всех действий было изменено ядро или какой-либо из его модулей, система должна быть перезагружена, а все затронутые исполняемые файлы нужно перезапустить.

Команда freebsd-update позволяет автоматически обновлять только ядро GENERIC . Если используется ядро с собственной конфигурацией, его понадобится пересобрать и переустановить после того, как freebsd-update завершит установку обновлений. Тем не менее, freebsd-update обнаружит и обновит ядро GENERIC при наличии /boot/GENERIC , даже если оно не является текущим используемым ядром в системе.

Всегда храните копию ядра GENERIC в /boot/GENERIC . Оно пригодится при решении различных проблем, а также при выполнении обновления со сменой версии. Смотрите Собственная конфигурация ядра в FreeBSD 9.X и более поздних версиях для описания получения копии ядра GENERIC .

Если конфигурация в /etc/freebsd-update.conf не изменялась, freebsd-update вместе с остальными обновлениями установит обновлённые исходные тексты ядра. После этого можно обычным способом выполнить перестроение и переустановку нового ядра с собственной конфигурацией.

Обновления, получаемые с помощью freebsd-update , не всегда затрагивают ядро. Перестроение собственного ядра не является обязательным, если исходные тексты ядра не были изменены при выполнении freebsd-update install . Тем не менее, freebsd-update всегда обновляет /usr/src/sys/conf/newvers.sh . Текущий набор изменений, как указано в номере -p в выводе uname -r , получается из этого файла. Перестроение собственного ядра, даже если ничего больше не менялось, позволяет uname правильно сообщать текущий набор изменений в системе. Это в частности может помочь при сопровождении множества систем, поскольку позволяет быстро оценить наличие установленных обновлений в каждой из них.

21.2.3. Обновления со сменой старшей и младшей версий

Обновление с FreeBSD 9.0 на FreeBSD 9.1, называется обновлением со сменой младшего номера версии. Смена старшего номера версии происходит, когда FreeBSD переходит с одной значительной версии на другую, как, например, при обновлении с FreeBSD 9.X на FreeBSD 10.X. Оба типа обновлений можно произвести, указав freebsd-update версию, на которую нужно перейти.

Если в системе используется ядро с собственной конфигурацией, убедитесь перед началом обновления в наличии копии ядра GENERIC в /boot/GENERIC . Смотрите Собственная конфигурация ядра в FreeBSD 9.X и более поздних версиях для описания получения копии ядра GENERIC .

Следующая команда, будучи запущенной на FreeBSD 9.0, выполнит обновление до версии FreeBSD 9.1:

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

Looking up update.FreeBSD.org mirrors. 1 mirrors found. Fetching metadata signature  9.0-RELEASE from update1.FreeBSD.org. 

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

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

WARNING: This system is running a 

На этом этапе предупреждение можно проигнорировать. На промежуточном этапе процесса обновления будет использовано обновлённое ядро GENERIC .

После того, как все изменения были загружены, они будут применены. Этот процесс может занять определённое время, в зависимости от производительности и текущей загруженности компьютера. Затем будет выполнено слияние конфигурационных файлов. Процесс слияния требует от пользователя определённого вмешательства, так как для файла можно выполнить слияние автоматически, а можно открыть текстовый редактор для слияния вручную. Результат успешного слияния будет показан на экране. Неудачное или пропущенное слияние вызовет преждевременное завершение программы. Можно подготовить резервную копию каталога /etc для таких важных файлов как master.passwd и group и выполнить их слияние вручную позднее.

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

В первую очередь изменения будут применены к ядру и его модулям. При использовании ядра с собственной конфигурацией укажите для следующей загрузки обновлённое ядро /boot/GENERIC с помощью nextboot(8):

Перед перезагрузкой с ядром GENERIC убедитесь, что оно содержит все необходимые драйвера для системы для корректной загрузки и подключения к сети, если машина обновляется удалённо. В частности, если в ядре содержится встроенная функциональность, которая обычно обеспечивается модулями ядра, загрузите эти драйвера с ядром GENERIC , временно указав их как модули в /boot/loader.conf . Рекомендуется отключить несущественные службы, а также любые локальные и сетевые диски до завершения процесса обновления.

Теперь компьютер должен быть перезагружен с новым ядром:

После перезагрузки нужно повторно запустить команду freebsd-update . Команда прочитает, на каком этапе она находится, и перейдёт к удалению старых объектных файлов и совместно используемых библиотек.

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

На этом процесс завершён. Если было выполнено обновление со сменой старшего номера версии, переустановите все порты и пакеты в соответствии с описанием, которое предоставляет Обновление пакетов после смены старшей версии системы.

21.2.3.1. Собственная конфигурация ядра в FreeBSD 9.X и более поздних версиях

Перед использованием freebsd-update убедитесь в наличии копии ядра GENERIC в /boot/GENERIC . Если ядро с собственной конфигурацией было собрано единожды, то в /boot/kernel.old будет находиться ядро GENERIC . Просто переименуйте этот каталог в /boot/kernel .

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

Иначе, ядро GENERIC можно собрать и установить из исходных текстов:

Чтобы такое ядро было определено как ядро GENERIC программой freebsd-update , в файле конфигурации GENERIC должны отсутствовать изменения. Также предлагается, что ядро было собрано без использования каких-либо специальных параметров.

Загрузка с GENERIC не требуется, поскольку для freebsd-update достаточно существования /boot/GENERIC .

21.2.3.2. Обновление пакетов после смены старшей версии системы

После обновления системы со сменой младшей версии установленные приложения, в целом, продолжают работать без каких-либо проблем. Различные старшие версии используют различающиеся двоичные интерфейсы приложений (Application Binary Interface, ABI), из-за чего перестаёт работать большинство сторонних приложений. После обновления системы со сменой старшей версии все установленные пакеты и порты также нуждаются в обновлении. Пакеты можно обновить с использованием pkg upgrade . Для обновления установленных портов используется ports-mgmt/portmaster.

Принудительное обновление все установленных пакетов приведёт к их замене на последние версии из репозитория, даже если номер версии при этом не увеличивался. Это требуется из-за смены версии ABI при обновлении на другую старшую версию FreeBSD. Принудительное обновление можно выполнить так:

Перестроение всех установленных приложений можно выполнить этой командой:

Эта команда будет отображать экран выбора конфигурации для каждого приложения, в котором доступны параметры конфигурации, с ожиданием пользовательского ввода. Чтобы не использовать такое поведение и всегда выбирать параметры по умолчанию, добавьте ключ -G в вышеприведённую команду.

После завершения процесса обновления программного обеспечения закончите процесс обновления последним запуском freebsd-update , для того чтобы убедиться, что ничто не было пропущено в процессе обновления:

Если в качестве временной меры использовалось ядро GENERIC , то это подходящее время для построения и установки нового ядра с собственной конфигурацией в соответствии с инструкциями в Настройка ядра FreeBSD.

Перезагрузите машину с новой версией FreeBSD. На этом процесс обновления завершён.

21.2.4. Сравнение состояния системы

С помощью команды freebsd-update IDS можно получить состояние установленной версии FreeBSD относительно известной доверенной копии. Эта команда проверяет текущую версию системных утилит, библиотек и конфигурационных файлов, и её можно использовать в качестве встроенной системы обнаружения вторжений (Intrusion Detection System, IDS).

Эта команда не является заменой IDS, такой как security/snort. Поскольку freebsd-update сохраняет свои данные на диске, возможность подмены становится очевидной. И хотя эта возможность может быть уменьшена при использовании настройки kern.securelevel , а также используя для записи данных freebsd-update файловую систему, которая в остальное время смонтирована только на чтение, лучшим решением будет сравнить систему относительно эталона на физически защищенном носителе, таком как DVD или внешний USB диск с включённой защитой от записи.

Для того, чтобы начать сравнение, укажите файл для сохранения результатов:

> outfile.ids

Запустится проверка системы, результат которой будет записан в указанный файл в виде списка файлов вместе с их контрольными суммами в формате SHA256 - для известных файлов из релиза и текущих в системе.

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

' | more /etc/master.passwd /etc/motd /etc/passwd /etc/pf.conf

Вывод специально обрезан, на самом деле файлов намного больше. Некоторые из них изменены в ходе нормальной работы: так, файл /etc/passwd был изменён после заведения пользователей в системе. Модули ядра могли измениться вследствие обновления через freebsd-update . Для исключения из проверки конкретных файлов и каталогов укажите их в качестве значения параметра IDSIgnorePaths в /etc/freebsd-update.conf .

21.3. Обновление документации

Документация является неотъемлемой частью операционной системы FreeBSD. И хотя актуальная версия документации FreeBSD всегда доступна на сайте FreeBSD (http://www.freebsd.org/doc/), может быть удобно иметь под рукой актуальную локальную копию сайта FreeBSD, руководств, FAQ и статей.

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

За информацией о редактировании и отправке изменений для документации обращайтесь к FreeBSD Documentation Project Primer for New Contributors (FreeBSD Documentation Project Primer).

21.3.1. Обновление документации из исходного кода

Для перестроения документации FreeBSD из исходного текста требуется набор инструментов, который не является частью основной системы FreeBSD. Требуемые инструменты, включая svn, можно установить из пакета или порта textproc/docproj, разработанного в рамках проекта документации FreeBSD.

После установки используйте svn для получения копии исходных текстов документации:

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

Последующие обновления можно получить, выполнив:

После того как в /usr/doc была загружена актуальная копия исходных текстов, всё готово для обновления установленной документации.

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

Для обновления только указанной языковой версии команду make можно запустить в соответствующем подкаталоге /usr/doc :

Альтернативный способ обновления документации заключается в запуске следующей команды из из /usr/doc или подкаталога с желаемой языковой версией:

Используемый при установке формат можно указать через FORMATS :

Для упрощения процесса частичного обновления документации и построения только нужных переводов имеется несколько параметров. Их можно задать как на общесистемном уровне, указав в /etc/make.conf , так и непосредственно в команде make .

Данные параметры включают:

Перечень языков и кодировок для построения и установки, например, en_US.ISO8859-1 для англоязычной документации.

Единый формат или набор форматов для построения. На данный момент поддерживаются html , html-split , txt , ps и pdf .

Путь для установки документации. По умолчанию /usr/shared/doc .

Для получения других переменных make , также работающих во FreeBSD в качестве общесистемных, обратитесь к make.conf(5).

21.3.2. Обновление документации из портов

В предыдущем разделе был представлен метод обновления документации FreeBSD из исходных текстов. В этом разделе описывается альтернативный метод с использованием Коллекции Портов, который позволяет:

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

Данный метод обновления документации FreeBSD предоставляется портами и пакетами документации, которые ежемесячно обновляет Группа Менеджеров Дерева Документации . Они перечислены в Коллекции Портов FreeBSD в категории docs (http://www.freshports.org/docs/).

Порты документации организованы следующим образом:

  • Пакет или порт misc/freebsd-doc-en устанавливает всю англоязычную документацию.
  • Метапакет или порт misc/freebsd-doc-all устанавливает всю документацию на всех доступных языках.
  • Имеются пакеты и порты для каждого перевода, например, misc/freebsd-doc-hu для венгерской документации.

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

Для пакетов используется другая схема наименования, которая отличается от названия соответствующего порта: lang-freebsd-doc , где lang соответствует сокращённому языковому коду, такому как hu для венгерского или zh_cn для упрощённого китайского.

Чтобы указать используемый формат документации, для этого вместо установки готового пакета нужно собрать порт самостоятельно. Ниже приводится пример построения и установки английской документации:

В порте имеется меню конфигурации, в котором можно указать нужный формат. По умолчанию выбирается HTML с разделителями, такой как на http://www.FreeBSD.org, а также PDF.

Иначе, при построении порта документации можно указать параметры make , которые включают в себя:

Документ в формате HTML на одной странице. Сформированная документация сохраняется в файле article.html или book.html .

Сформированная документация сохраняется в файле article.pdf или book.pdf .

Указывает место размещения документации. По умолчанию /usr/local/shared/doc/freebsd .

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

Пакеты или порты документации обновляются согласно инструкциям в Установка приложений. порты и пакеты. Например, следующая команда выполняет обновление установленной документации на венгерском языке с помощью ports-mgmt/portmaster в режиме использования только готовых пакетов:

21.4. Использование ветви разработки

Во FreeBSD имеется две ветки разработки: FreeBSD-CURRENT и FreeBSD-STABLE.

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

21.4.1. Использование FreeBSD-CURRENT

FreeBSD-CURRENT является "передним краем" разработки FreeBSD и предназначена для пользователей с высокой технической грамотностью. Менее продвинутым пользователям, также желающим отслеживать ветку разработки, следует использовать FreeBSD-STABLE.

FreeBSD-CURRENT обозначает последнюю версию исходных текстов FreeBSD и включает в себя незавершённые работы, экспериментальные изменения и переходные механизмы, которые могут отсутствовать в следующем официальном релизе. Хотя многие разработчики FreeBSD выполняют компиляцию исходных текстов FreeBSD-CURRENT ежедневно, бывают периоды, когда исходные тексты могут не компилироваться. Обычно такие проблемы решаются сразу по мере возможности, но всё же выбор точки синхронизации исходных текстов является определяющим фактором, содержит ли FreeBSD-CURRENT новую функциональность или же мину замедленного действия.

FreeBSD-CURRENT предназначена для трёх основных групп:

  1. Члены сообщества FreeBSD, активно работающие над некоторой частью дерева исходных текстов.
  2. Члены сообщества FreeBSD, которые являются активными тестерами. Они тратят свое время на исправление проблем, вносят важные предложения по изменениям и общему развитию FreeBSD, присылают патчи.
  3. Пользователи, которые хотят быть в курсе изменений, используют текущие исходные тексты для ознакомительных целей либо же иногда высказывают замечания или предоставляют собственный код.

FreeBSD-CURRENT не должна использоваться в качестве быстрого способа получить новые возможности, не дожидаясь выпуска следующей версии, поскольку предварительная версия не является полностью проверенной и скорее всего содержит ошибки. FreeBSD-CURRENT не является быстрым способом получения исправлений, поскольку любое изменение является в равной мере источником исправления существующих ошибок и появления новых. FreeBSD-CURRENT не является "официально поддерживаемой" каким бы то ни было способом.

Чтобы отслеживать изменения во FreeBSD-CURRENT:

  1. Подпишитесь на списки рассылки Список рассылки, посвящённый обсуждению FreeBSD-CURRENT и Список рассылки сообщений об изменениях в репозитории SVN для ветки head/-current дерева исходных текстов. Это необходимо для того, чтобы получать сообщения и важные бюллетени относительно текущего состояния FreeBSD-CURRENT.

Список рассылки Список рассылки сообщений об изменениях в репозитории SVN для ветки head/-current дерева исходных текстов содержит записи из журнала коммитов по каждому изменению, а также сопутствующую информацию о возможных побочных эффектах.

Чтобы подписаться на эти списки рассылки, перейдите по ссылке https://lists.freebsd.org, щёлкните на нужном списке и следуйте дальнейшим инструкциям. Для того чтобы отслеживать изменения всего дерева исходных текстов, а не только FreeBSD-CURRENT, подпишитесь на Список рассылки сообщений об изменениях в репозитории SVN для всего дерева исходных текстов (за исключением user и projects).

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

Перед началом компиляции FreeBSD-CURRENT внимательно прочтите файл /usr/src/Makefile и следуйте инструкциям в Пересборка мира. Список рассылки, посвящённый обсуждению FreeBSD-CURRENT и /usr/src/UPDATING позволят быть в курсе прочих процедур, которые иногда бывают необходимы в процессе перехода к следующему релизу.

21.4.2. Использование FreeBSD-STABLE

FreeBSD-STABLE является веткой разработки, из которой выпускаются основные релизы. Изменения в этой ветке происходят с меньшей скоростью и в предположении, что они сперва были проверены во FreeBSD-CURRENT. При этом она остаётся веткой разработки, и в любой момент времени исходные тексты FreeBSD-STABLE могут оказаться не готовы для обычного использования. Это просто другая ветка разработки, не предназначенная для конечных пользователей. Пользователям, у которых нет возможности заниматься тестированием, следует использовать самый последний выпуск FreeBSD.

Тем, кто заинтересован процессом разработки FreeBSD или желает поучаствовать, особенно поскольку от этого зависит следующий релиз FreeBSD, стоит отслеживать FreeBSD-STABLE.

Хотя ветка FreeBSD-STABLE должна всегда компилироваться и работать, это невозможно гарантировать. Поскольку гораздо больше людей работает с FreeBSD-STABLE, неудивительно, что в FreeBSD-STABLE иногда обнаруживаются ошибки и всплывают непредвиденные ситуации, которые не проявляли себя в FreeBSD-CURRENT. По этим причинам не рекомендуется слепо использовать FreeBSD-STABLE. Особенно важно не обновлять какие-либо сервера, находящиеся в эксплуатации, до FreeBSD-STABLE без тщательного тестирования кода в среде разработки.

Чтобы отслеживать изменения во FreeBSD-STABLE:

  1. Подпишитесь на список рассылки Список рассылки, посвящённый обсуждению FreeBSD-STABLE;, чтобы быть в курсе о зависимостях процесса компиляции, которые могут появиться во FreeBSD-STABLE или любых других проблемах, требующих особого внимания. Также в этом списке рассылки разработчики делают объявления о спорных исправлениях или добавлениях, давая пользователям возможность высказать свое мнение о возможных тонких моментах.

Подпишитесь на список рассылки svn, соответствующий используемой ветви. Например, при использовании 9-STABLE следует подписаться на Список рассылки сообщений об изменениях в репозитории SVN для ветки 9-stable дерева исходных текстов. Этот список рассылки содержит записи из журнала коммитов по каждому изменению, а также сопутствующую информацию о возможных побочных эффектах.

Чтобы подписаться на эти списки рассылки, перейдите по ссылке https://lists.freebsd.org, щёлкните на нужном списке, и следуйте дальнейшим инструкциям. Для того чтобы отслеживать изменения всего дерева исходных текстов, подпишитесь на Список рассылки сообщений об изменениях в репозитории SVN для всего дерева исходных текстов (за исключением user и projects).

Чтобы скомпилировать новую или обновить существующую систему FreeBSD до FreeBSD-STABLE, используйте svn для загрузки исходных текстов нужной ветки. Имена веток вида stable/9 перечислены на странице www.freebsd.org/releng. При отсутствии надёжного Интернет-соединения можно воспользоваться CTM (Использование CTM).

21.5. Синхронизация исходных текстов

Имеются различные способы синхронизации с исходными текстами FreeBSD. В этом разделе сравниваются основные из них, Subversion и CTM.

Хотя возможно частичное обновление дерева исходных текстов, единственной поддерживаемой процедурой обновления является обновление всего дерева и перекомпиляция всех программ, работающих в контексте пользователя, например тех, что находятся в каталогах /bin и /sbin , а также исходных текстов ядра. Обновление только части дерева исходных текстов, только ядра или только программ часто приводит к возникновению проблем от ошибок компиляции до аварийных остановов системы или потери данных.

Subversion для обновления исходных текстов использует модель pull. Пользователь или сценарий cron запускают программу svn , которая обновляет локальную версию исходных текстов. Subversion является предпочтительным способом обновления локального дерева исходных текстов, поскольку обновления являются актуальными с точностью до минуты и пользователь управляет временем их загрузки. Загрузку определённых файлов и каталогов легко ограничить, а запрашиваемые обновления формируются на лету на стороне сервера. О том, как актуализировать исходные тексты с использованием Subversion, описано в svn.

CTM не выполняет интерактивное сравнение имеющихся исходных текстов с находящимися в главном архиве, и не выполняет их загрузку. Вместо этого несколько раз в день на главной машине CTM запускается скрипт, находящий изменения в файлах с момента своего предыдущего запуска. Все обнаруженные изменения сжимаются, помечаются последовательным номером и кодируются для передачи по электронной почте в печатном формате ASCII. После получения эти "дельта-файлы CTM" могут быть переданы утилите ctm.rmail , которая осуществляет автоматическое декодирование, проверку и применение изменений к пользовательской копии исходных текстов. Этот процесс более эффективен по сравнению с используемым в Subversion и требует меньше ресурсов сервера, так как он выполнен по модели push, а не pull. Инструкции по использованию CTM для синхронизации исходных текстов даны в Использование CTM.

Если пользователь случайно уничтожил часть своего архива, Subversion обнаружит и перестроит повреждённую часть. CTM этого не делает, поэтому если пользователь удалил часть дерева исходных текстов и не имеет архивной копии, то нужно будет начать с самого начала (с последнего "базового дельта-файла"), перестроив всё с помощью CTM.

21.6. Пересборка мира

После того, как локальное дерево исходных текстов было синхронизировано с некоторой версией FreeBSD (FreeBSD-STABLE или FreeBSD-CURRENT), его можно использовать для перестроения системы. Этот процесс известен как перестроение мира.

Перед перестроением мира убедитесь в выполнении следующих действий:

Procedure: Перед тем как приступать к построению мира

  1. Сохраните резервную копию всех важных данных на другую систему или съёмный носитель, проверьте её целостность и держите под рукой загрузочный носитель. Невозможно переоценить важность создания резервной копии системы до начала перестроения системы. Хотя перестроение системы является простой задачей, неизбежно возникают ситуации, при которых ошибки в исходных текстах приводят к тому, что система перестаёт загружаться. Возможно, вам никогда не придётся этим воспользоваться, но, постучав по дереву, всегда лучше подстраховаться.
  2. Проверьте последние сообщения в списке рассылки Список рассылки, посвящённый обсуждению FreeBSD-STABLE; или Список рассылки, посвящённый обсуждению FreeBSD-CURRENT (в зависимости от отслеживаемой ветки). Будьте в курсе любых известных проблем, и тех систем, которые они затрагивают. В случае возникновения подобной проблемы, дождитесь сообщения о том, что эта проблема решена. После этого повторите синхронизацию исходных текстов для получения необходимого исправления.
  3. Прочтите /usr/src/UPDATING для получения информации о дополнительных шагах, необходимых для данной версии исходных текстов. В этом файле содержится важная информация о возможных проблемах и может быть указан порядок выполнения соответствующих команд. При большинстве обновлений требуются дополнительные шаги, например, переименование или удаление определённых файлов перед установкой нового мира. Эти шаги будут перечислены в конце файла, где в явном виде описывается текущая рекомендуемая последовательность действий при обновлении. Если содержимое UPDATING противоречит каким-либо шагам в этой главе, руководствуйтесь инструкциями в файле UPDATING , которые имеют больший приоритет.

Не используйте make world

В некоторой устаревшей документации рекомендуется использование make world . Эта команда пропускает некоторые важные шаги, поэтому использовать её следует лишь в том случае, если вы точно знаете, что делаете. Почти во всех случаях make world - это неправильный способ, вместо этого следует использовать описанную здесь процедуру.

21.6.1. Обзор процесса

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

Во FreeBSD термин "world" обозначает ядро, исполняемые файлы основой системы, библиотеки, файлы для программирования и встроенный компилятор. Имеет значение порядок, при котором эти компоненты собираются и устанавливаются.

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

Новый мир может зависеть от особенностей нового ядра, поэтому новое ядро должно быть установлено до установки нового мира. Старый мир может работать неправильно на новом ядре, поэтому новый мир должен быть установлен сразу после установки нового ядра.

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

Исходя из этих соображений в следующей процедуре описана рекомендуемая последовательность обновления.

Хорошей практикой является запись в файл вывода команды make . Если что-то пошло не так, копию сообщения об ошибке можно отправить в один из списков рассылки FreeBSD.

Проще всего использовать для этого script с параметром, задающим имя файла для сохранения всего вывода. Не сохраняйте вывод в /tmp , так как этот каталог может быть очищен при следующей перезагрузке. Более подходящим местом является /var/tmp . Запустите команду непосредственно перед перестроением мира, а после завершения процесса наберите exit :

 Script started, output file is /var/tmp/mw.out

Procedure: Обзор процесса построения мира

Команды для построения мира должны запускаться в указанном здесь порядке. В этом разделе даётся краткое описание назначения каждой из команд.

  1. Если процесс построения мира уже запускался ранее на этой системе, то в /usr/obj могла остаться копия предыдущей сборки. Удалите этот каталог для ускорения процесса построения нового мира и возможного сокращений работы по разрешению зависимостей.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *