Рубрики
Web-сервер

Как настроить Redis в качестве кэширующего сервера

Кэширование данных в оперативной памяти посредством Redis является одним из методов ускорения работы сайта. Данное хранилище высокопроизводительно и может использоваться для кэширования не только сайтов, но и сессий, а также в качестве нереляционной базы данных.

Как настроить Redis в качестве кэширующего сервера

Установка Redis производится в два шага:

  1. Подключение репозитория backports. Версия в стандартном репозитории слишком стара.
  2. Установка командой aptitude install -t jessie-backports redis-server redis-tools

Содержание статьи:

  • 1 Настраиваем оптимальную конфигурацию
  • 2 Кэширование php сессий

Настраиваем оптимальную конфигурацию

В Debian конфигурационный файл расположен в каталоге /etc/redis/ и называется redis.conf.

В первую очередь необходимо исправить ошибку с некорректно указанным максимальным количеством tcp соединений. Это актуально в случае использования tcp-сокетов.

Печатаем в консоли команду cat /proc/sys/net/core/somaxconn и выставляем соответствующее количество:

tcp-backlog 128

Для более быстрой работы подключаем возможность работы с unix-сокетом.

unixsocket /var/run/redis/redis.sock unixsocketperm 777

Ограничиваем максимальное количество подключаемых клиентов. Если необходимо больше 1024-х подключений, также потребуется изменить ограничение на количество одновременно открытых файлов (ulimit).

maxclients 1024

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

maxmemory 64mb

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

maxmemory-policy allkeys-lru

Так же, во избежание проблем с работой Redis (пункт 3 руководства, англ), следует отключить функцию ядра Transparent HugePages.

# echo never > /sys/kernel/mm/transparent_hugepage/enabled

Перезапускаем для вступления изменений в силу.

# service redis restart

И добавляем в файл /etc/rc.local следующие строки, чтобы после перезагрузки сервера данная функция была отключена.

if test -f /sys/kernel/mm/transparent_hugepage/enabled; then    echo never > /sys/kernel/mm/transparent_hugepage/enabled fi if test -f /sys/kernel/mm/transparent_hugepage/defrag; then    echo never > /sys/kernel/mm/transparent_hugepage/defrag fi

Кэширование php сессий

Настроить php на хранение сессий можно несколькими путями, в зависимости от используемой связки.

Напрямую в php.ini

[Session] session.save_handler = redis session.save_path = "unix:///run/redis/redis.sock"

Apache2 и mod_php (в файле виртуального хоста или apache2.conf)

 php_admin_value session.save_handler "redis" php_admin_value session.save_path "unix:///run/redis/redis.sock"

PHP-FPM (в файле пула)

php_admin_value[session.save_handler] = "redis" php_admin_value[session.save_path] = "unix:///run/redis/redis.sock"
Рубрики
Web-сервер

Как в nginx исключить IP из логов?

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

Как в nginx исключить IP из логов?

При помощи условной записи, которая доступна в nginx, начиная с версии 1.7.0, мы можем проверять ip посетителя и не записывать его в лог-файлы. Действительно, зачем это делать, если в логгировании своего айпи нет необходимости?

Чтобы добавить такое исключение, нужно создать условную запись на основе map_module. Результат вычисления условной записи не будет записываться в лог, если будет равен 0. Правило будет выглядеть так:

map $remote_addr $loggable {  "127.0.0.1" 0;  "::1" 0;  default 1; }

То есть, по-умолчанию результат равен 1, а для указанных ip — 0, и они не будут записаны в лог. Поддерживаются версии протокола 4 и 6. Обратите внимание, здесь первая переменная — это адрес подключившегося клиента. А вторую переменную нужно записать в параметрах access лога.

access_log /var/log/nginx/access.log combined if=$loggable;

Блок map можно прописать как на уровне http конфига nginx, так и на уровне server.

Исключение других данных из логов

Отключение логгирования конкретных ip — это только один пример из множества. Можно использовать различные переменные из стандартных.

Давайте отключим, в качестве примера, запись в лог страницы error.html. Для этого создадим такой блок:

map $request_uri $loggable {  ~*error.html 0;  default 1; }

И пропишем, как выше, параметр if в качестве аргумента для параметра access_log. После перезапуска nginx все запросы error.html не будут записаны. Включая вариации типа error.html?q=search. Для точного совпадения нужно прописать другое регулярное выражение.

Рубрики
Web-сервер

Создаём пользователей для веб-сервера

Казалось бы, что может быть проще, чем добавить пользователя на сервере? Напечатал в консоли команду adduser, ответил на пару вопросов о пароле и другой информации, и вот, можно заходить с полученным логином и паролем, размещать файлы и т.д.

Создаём пользователей для веб-сервера

Затем, вручную, приходится создавать папки. Например, одну для сайта. Другую — для временных файлов, чтобы не бросать их в общий /tmp в целях защиты. Ещё одну — для сессий, если не настроено кэширование в Redis. А ещё же нужно скопировать нужные файлы настроек, типа публичного ssh ключа для аутентификации.

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

Первичные настройки, определяемые при использовании команды adduser, берутся из файла /etc/adduser.conf.

Изменяем домашнюю папку

Изначально домашние папки всех пользователей размещаются в разделе /home. Но мы можем заранее переопределить местоположение, используя любую другую папку, например /var/www. Для этого отредактируем параметр DHOME.

DHOME=/var/www

Следует обратить внимание на параметр SKEL=/etc/skel. Он определяет, откуда будут скопированы файлы настроек и папки для каждого конкретного пользователя. Наверняка вы видели в папках пользователей своего сервера файлы .profile.bashrc. Они как раз скопированы из этого источника. :)

Добавление пользователей в единую группу

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

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

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

Общей группой станет группа пользователя www-data. Он специально создан для запуска веб-серверов, имеет максимально ограниченные права и не может пользоваться шелл-ом.

В файле adduser.conf нам нужно сначала отключить создание одноимённой группы при создании пользователя.

USERGROUPS=no

А, затем, указать ID группы www-data.

USERS_GID=33

Как правило, идентификатор равен 33. Но следует перепроверить командой, запускаемой от root: id www-data.

И последний параметр, изменяемый в этом конфигурационном файле:

DIR_MODE=0710

Он определяет права на домашнюю папку пользователя /var/www/username. Тут мы разрешаем все действия владельцу файлов, только исполнение для группы и не даём никаких прав всем остальным.

Права для конкретного пользователя и дополнительные файлы

Теперь нам нужно продолжить выдачу корректных прав, но уже в рамках одного пользователя. Чтобы при создании файлов и папок им сразу присваивались нужные права, отредактируем соответствующим образом параметр umask в файлах .bashrc и .profile.

umask 027

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

А для файлов 0640: чтение/изменение для владельца и только чтение для группы. Рекомендую самостоятельно изучить статью о правах доступа в Linux.

Также не забываем в каталоге /etc/skel обновить права на существующие файлы и папки командой chmod.

В завершение создаём дополнительные папки: для сайтов, временных файлов, сессий и т.д. Файл authorized_keys с вашим публичным ключом к ssh нужно расположить в папке .ssh пользователя. В итоге структура будет выглядеть примерно так:

/etc/skel   -.ssh/   --authorized_keys   -sessions/   -tmp/   -www/   -.bashrc   -.profile

Всё это будет скопировано в домашний каталог пользователя при его создании.