Приветствую тебя, дорогой читатель. Скорее всего, если ты это читаешь, то уже очень устал получать кучу алертов о том, что твоя площадка загибается от регулярных набегов печенегов ботов или других нежелательных посетителей контента. Я надеюсь, что эта статья поможет тебе спать спокойно и оградит тебя от недугов, а также внесет больше ясности в твое понимание теории и практики защиты от dos и ddos. Приятного чтения!
Помогая пользователям NGINX с разрешением проблемных ситуаций, мы поняли, что большинство из них часто совершает одни и те же ошибки конфигурации. Более того, подобные ситуации вполне могут возникнуть даже у самих инженеров NGINX! В этой статье рассмотрим 10 наиболее распространенных ошибок и объясним как их исправить.
Я поставил задачу сделать Кэш как можно проще, чтоб не увеличивать сложность сервиса и уровень вхождения программистов. На ум сразу приходит Varnish, и подобные инструменты выглядели заманчиво, но они кажутся оверхедом для такой задачи. Пилить микросервисы или масштабировать сервера тоже
Основная проблема - связать кэш с логикой, чтоб кэш сбрасывать только при изменениях. Если внутри Laravel или другого фреймворка мы имеем доступ к бизнес логике зависимых сущностей, то на стороне nginx у нас только параметры запроса.
Я являюсь full stack разработчиком на культурно-историческом IT портале Königsland, который успешно начал свою работу примерно месяц назад. Этот ресурс посвящается культуре и истории Восточной Пруссии и является своеобразной летописью времен, которая больше всего напоминает вирутальный музей, где можно получить довольно полную информацию об истории этого великого края, а эта информация пополняется по мере возникновения у меня свободного времени.
Страницы этой летописи приоткрывают завесу тайны и позволяют получить пользу от современных технологий тем, кто увлекается стариной.
Для приготовления локализации страниц об ошибках нам понадобится сам nginx и его плагины error_page_inherit и include_server. Конечно, такую локализацию можно сделать и без этих плагинов, но у неё будет несколько недостатков. Во-первых, если в каком-то локейшене задаётся своя страница об ошибке, то все страницы об ошибках из предыдущих уровней не наследуются для этого уровня. Эту проблему решает первый плагин, позволяя наследовать страницы сообщений об ошибках. А, во-вторых, для каждого сервера придётся вручную включать локейшен обработки страницы об ошибке. И эту проблему как раз решает второй плагин, позволяя наследовать подключение файлов из главной конфигурации во все сервера.
Жизненный цикл разработки корпоративного приложения в нашей компании привел меня к, по сути, банальной задаче - “прикручиванию” пользовательской авторизации к фронту приложения. Пользователями приложения должны быть сотрудники компании, а идентификационным провайдером должен стать корпоративный Active Directory (далее AD).
Было принято решение не работать с AD напрямую при авторизации сотрудников в корпоративных приложениях, а использовать для этого довольно удобный брокер авторизации – KeyCloak.
NGINX — это HTTP-сервер и обратный прокси-сервер, почтовый прокси-сервер, а также TCP/UDP прокси-сервер общего назначения, изначально написанный Игорем Сысоевым. Уже длительное время он обслуживает серверы многих высоконагруженных сайтов.
Однако кросс-компиляция NGINX практически невозможна, поскольку разработанные Игорем Сысоевым скрипты конфигурирования исходного кода в большинстве случаев используют так называемую процедуру «Try Run».
Те кто знаком с утилитами Autoconf, Automake знают, что проверки необходимых параметров системы и кросс-компилятора осуществляются различными процедурами, которые, в свою очередь, могут применять попытки сборки исходного кода (Try compile), линковки объектных файлов (Try link) и, наконец, попытки запуска тестовых программ (Try Run).
Естественно, если речь идет о кросс-сборке, операции «Try Run» недопустимы, ведь мы не можем запустить программу, собранную под целевую архитектуру отличающуюся от архитектуры машины сборки на самой машине сборки.
В Autotools проблемы, связанные с невозможностью запуска целевых программ на сборочной машине в некоторых случаях решаютcя кешированием переменных, которые могу быть переопределены пользователем в файле --cache-file или заданы в командной строке вызова скрипта ./configure.
Скрипты Игоря Сысоева не предусматривают такого переопределения машинно-зависимых величин. Однако величин, которые необходимо задать во время конфигурирования исходных кодов NGINX достаточно много. К ним, в первую очередь, относятся размеры типов данных. Именно с них мы и начнем.
Если вы сталкивались с CORS, то знаете всю ту боль, которую испытывает разработчик, когда нужно сходить к API на другом домене. Если конфигурация сервера не доступна для настройки, то использовали какое-нибудь решение на основе не менее популярного решения cors-anywhere.
Для приготовления авторизации через auth0 нам понадобится сам nginx и его плагины encrypted-session, headers-more, auth_request, set-misc, echo, json, evaluate и jwt. Можно также воспользоваться готовым образом.
Совсем недавно, 25 января 2022 года вышел новый релиз Nginx - 1.21.6, в котором исправлена проблема неравномерного распределения входящих соединений между несколькими worker процессами в дефолтной конфигурации на Linux системах. Если конкретнее - use epoll, accept_mutex off, reuseport выключен.
В данной конфигурации при определенном характере нагрузки большинство входящих в Nginx соединений обрабатывается лишь одним worker процессом.
Насколько я понимаю, эта проблема существует уже более пяти лет и берет начало в версии 1.11.3 (Jul 2016), когда в Nginx по умолчанию отключили accept_mutex, а вместо него стали полагаться на флаг EPOLLEXCLUSIVE, появившийся в ядре Linux 4.5.
Стоит заметить, что проблема балансировки входящих соединений при использовании механизма epoll и флага EPOLLEXCLUSIVE более глобальна и касается не только Nginx, а любых сетевых приложений, работающих по аналогичной схеме.
В этой статье мы посмотрим на историю и причины появления данной проблемы, а также рассмотрим код ее решения в новом релизе Nginx.
О чем статья
В этой статье речь пойдет о БАЗОВЫХ подходах и принципах к такому quality attribute (QA) как Availability. Никаких сложных случаев, ничего слишком сложного, только теория с двумя примерами, скипайте, если искали что-то эдакое.
Вся информация основана на парах книг, статей, и моем опыте. В конце статьи я покажу, какие именно. Также, эта статья - по суть перевод моей же статьи, только написанной на английском.
Что такое Availability?
Перед тем, как рассматривать паттерны и техники для обеспечения availability мы должны определить сам термин.
Добрый день. Данная статья будет очень полезна для тех, кто впервые поднимает свое приложение, которое будет доступно всему этому большому и замечательному Миру и хочет сделать его как можно более безопасным, устойчивым к разным атакам.
Цель статьи - поделиться практиками, которые я применил для защиты данных при поднятии собственного VPS в публичной сети. Всегда, когда твой IP открыт всему Миру напоказ и доступен извне внутренних контуров сети - это означает, что любой прохожий может устроить тебе неприятности: похитить твои данные, завладеть твоим сервером и сломать твое замечательное приложение. Я буду приводить пример атаки, показывать, как ее можно заметить и после этого будем разбирать возможные способы защиты.
Приветствую читателей! В рамках текущей серии статей я рассказываю о том, как настроить сервер для простых проектов. Имеется ввиду сервер для работы нескольих сайтов, с небольшой нагрузкой под наиболее популярной CMS такой например как Bitrix. Основная цель статьи указать на ошибки допускаемых младшими специалистами при выполнении подобной настройки. Также указать на какие то вещи, которые сделают troubleshooting простым и удобным.
Это не совсем стэк LEMP, так как здесь используется Apache2, но вы можете использовать PHP-FPM вместо этого, если разработчик не против внедрения такого решения.
В комментариях к статьям я часто вижу сообщения, о том, что Apache2 уже не актуален и вместо него можно поднять другое ПО. От себя могу сказать, что до сих пор большое количество небольших и средних организаций, встающих на обслуживание используют Apache2 и файлы .htaccess, поэтому я не согласен с данным утверждением. Но опять же если вы опытный администратор, понимающий как работает эта связка, вы можете пропустить эту статью и поднять то, что вашей дуже угодно.
Статья написана не с целью взять и бездумно скопировать все команды и получить готовый сервер для размещения площадки. Также если в вашей конкретной компании используется другой стэк, я очень за вас рад, но это не отменяет того факта, что то ПО которое описано в этой статье все еще популярно, используется и администрируется без каких-либо проблем.
Предыдущие части статей доступны по следующим ссылкам:
Данная статья является продолжением предыдущей статьи https://habr.com/ru/company/nixys/blog/645451/. Статья является обучающим материалом для начинающих администраторов, а также для разработчиков, которые хотели бы познакомиться с миром администрирования проектов. Если вы являетесь опытным администратором, можете смело пропускать данный материал.
Целью серии статей является описание подготовки работы сервера со стеком LEMP (Linux, Nginx, MySQL, PHP), отмечу, что в качестве PHP интерпретатора здесь используется Apache2, а не PHP-FPM, так как показывает практика многим разработчикам по прежнему необходим файл.htaccess, работу с которыми PHP-FPM из коробки не поддерживает.
Со своей стороны мы переносим правила из файла .htaccess в Nginx при необходимости установки PHP-FPM, однако это также занимает определенное время, зачастую разработчикам проще и быстрее внести нужные правила для текущих площадок именно в .htaccess файл. Также статьи описывают развертывание стэка и поднятие на нем работающих площадок. Инструкция подойдет для небольших Bitrix проектов, а тажке для проектов развернутых под любой популярной CMS.
Не смотря на то, что тема уже достаточно подробно отражена в сети, мы решили подробно описать общие стандарты администрирования с нуля, поскольку регулярно получаем большое количество базовых вопросов от людей, так или иначе, связанных с нашей сферой.
Целью статей не является показать как развернуть идеальное окружение, а лишь указать на нюансы в работе и защитить начинающих специалистов от базовых ошибок при настройке.
Здравствуйте!
Хочу представить вам пошаговую инструкцию по деплою django проекта.
Сразу скажу, что используя мою краткую инструкцию вы не поймете механику развертывания. По сути, это просто список команд для деплоя. Тут не будет никаких подробностей касательно работы UWSGI, NGINX и самого Django. Я просто помогу быстро добраться до цели, а цель у нас одна - задеплоить уже наконец этот **** проект!
Ведение
Приветствую читателей. В практике нашей компании часто появляется потребность в настройке серверов для простых односерверных проектов или небольших кластеров. В этой статье я бы хотел рассказать вам о нашем опыте подобной настройки, выделить особенности, которые могут вам пригодиться при дальнейшем администрировании. Статья предназначена для людей, которые только вникают в администрирование, а также для тех, кто самостоятельно администрирует свой небольшой проект и хочет набраться опыта в этом деле. Если вы являетесь опытным администратором, то можете смело пропускать данный материал.
Целью серии статей является описание подготовки работы сервера со стоком LEMP (Linux, Nginx, MySQL, PHP, Apache), развертывание стэка и поднятие на нем работающих площадок. Инструкция подойдет для небольших Bitrix проектов, а тажке для проектов развернутых под любой популярной CMS.
Не смотря на то, что тема уже достаточно подробно отражена в сети, мы решили подробно описать общие стандарты администрирования с нуля, по-скольку регулярно получаем большое количество базовых вопросов от людей, так или иначе, связанных с нашей сферой.
Большая часть проектов базируется на ОС Ubuntu, Debian в статьях будут отражены настройки для этих систем.
В данной статье будут описаны такие вещи как:
Всем привет! Данное руководство поможет вам установить централизованное логирование событий на основе Graylog версии 4.2.1 (на момент написания статьи). Использовать мы будем операционную систему AlmaLinux 8.5 (альтернатива CentOS 8 от Red Hat). В процессе установки Graylog, мы рассмотрим первоначальную настройку сервера, настройку правил файрвола, а также использование NGINX в качестве обратного прокси серверу Graylog’а.
Вводные данные:
1. Свежеустановленный сервер на базе AlmaLinux release 8.5 (Arctic Sphynx);
2. 8 CPUs, 15 GB RAM и раздел подкачки размером 4 GB;
3. Graylog будет доступен по адресу https://logs.example.com
После установки операционной системы AlmaLinux, нам необходимо её настроить для дальнейшего использования. То есть усилить безопасность настроек демона sshd, выбрать часовой пояс, настроить синхронизацию времени и установить дополнительные пакеты программ и т. п.
Напишем небольшой скрипт для этого:
Репозиторий: https://github.com/denisxab/django-start-pack
Какая существует проблемы: Слишком много времени уходит на первоначальную настройку Django проекта. Существует много технологий которые уже стали неотъемлемыми зависимостями для Django проектов. Например:
Когда речь заходит про права доступа в приложении, то из этой ситуации появляется два результата:
Либо в коде приложения появляются привязки к неким ролям/scope’ам;
Либо разработчик обрастает бородой и начинает сыпать фразами вроде abaс, xacml и матрица доступа;
Если вам интересно как можно из подручных средств собрать RBAC на любой сервис соблюдающий REST, то добро пожаловать.
