Nginx *

Краткая суть:

Пошаговая инструкция по проксированию Unifi-контроллера через Nginx по http или https.

Конфиги, понятные примеры, комментарии.

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

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

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

В общем, как я уже читал тут в комментах: «целые статьи пишут на то, как добавить 5 символов и пробел в конфиг». Все бы хорошо, если бы не google chrome. Они решили прекратить поддержку SPDY и NPN(кому интересно, вот комментарий chromium по этому поводу).

Игорь Сысоев ( isysoev )

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

Мы продолжаем разработку open source. С момента основания компании темпы разработки существенно увеличились, поскольку над продуктом работает множество людей. В рамках open source мы оказываем платную поддержку.

Я буду говорить о масштабируемой конфигурации nginx, но это не о том, как обслужить с помощью nginx сотни тысяч одновременных соединений, потому что nginx для этого настраивать не надо. Нужно выставить адекватное число рабочих процессов или поставить его в режим «авто», поставить worker_connections в 100 000 соединений, после этого заниматься настройкой ядра — это гораздо более глобальная задача, чем просто настройка nginx. Поэтому я буду рассказывать о другой масштабируемости — о масштабируемости конфигурации nginx, т.е. о том, как обеспечить рост конфигурации от сотни строчек до нескольких тысяч и при этом тратить минимальное (желательно константное) время на сопровождение этой конфигурации.

Давно хотел написать целостный туториал по поднятию Owncloud в условиях домашнего сервера или небольшой компании до 500 пользователей. Owncloud — это прекрасный open-source проект, который позволяет на собственной инфраструктуре поднять свой вариант сервера синхронизации. По возможностям очень похож на Dropbox, а в чем-то его и превосходит. Огромный плюс — отсутствие ограничений по объемам хранения, полный контроль над сервером. Минусы тоже очевидны: вам самим придется следить за всем этим безобразием и беспокоиться о надежности сервера, валяющегося на антресолях или в шкафу.

Совсем недавно мне подвернулась задача по развертыванию Owncloud в домашне-боевых условиях. Я честно отработал свои два литра кошерного русского имперского стаута и решил поделиться своим опытом, собрав все воедино. Итак, сегодня мы рассмотрим:

1. Развертывание актуального LEMP-stack
2. HTTPS. Let's Encrypt для Nginx с автоматическим обновлением сертификата
3. Конфигурирование Nginx для Owncloud
4. Кэширование php-apcu
5. Подключение внешнего основного хранилища по NFS

Устанавливая Helpdesk OTRS я столкнулся с тем, что работа официально поддерживается только с Apache HTTP Server, а мне нужен был Nginx. Как оказалось, подробного руководства по установке OTRS на WEB-сервер под управлением Nginx в интернете нет, попробуем это исправить. В этой статье будет описана только установка OTRS версии 5.0.13, а его настройка это отдельная тема. В качестве ОС, на которой будет развернут сервер, выступит CentOS 7.

Недавно приняли решение переехать с хостинга на VPS, будем использовать: CentOS 7, Nginx, Apache, PHP, MySQL. Несмотря на большое количество статей на эту тему, многие аспекты не упоминаются, поэтому выкладываем эту статью чтобы услышать мнение знающих и опытных людей. Настраивать сервер как Вы уже поняли будем первый раз, поэтому о актуальности статьи можно будет судить из комментариев. Nginx будет отдавать статику, а динамику Apache (скрипты PHP), чтобы снизить нагрузку на сервер.

Подготовка.

Все настройки будем применять на рабочем сервере нашего проекта с конфигурацией сервера: CPU — 2 × 2000 МГц и RAM — 2048 МБ.

Для начала работы находим подходящий VPS с предустановленной CentOS 7, к серверу будем подключаться по SSH через PuTTY.

Вводим название хоста и порт, нажимаем Open:



Далее вводим логин [Enter], потом пароль (обратите внимание, ввод пароля не отображается) [Enter]:

Является ли ошибкой ответ 5хх, если его никто не видит? [1]

Вне зависимости от того, как долго и тщательно программное обеспечение проверяется перед запуском, часть проблем проявляется только в рабочем окружении. Например, race condition от параллельного обслуживания большого количества клиентов или исключения при валидации непредвиденных данных от пользователя. В результате эти проблемы могут привести к 5хх ошибкам.

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

Для облегчения процесса поиска и отладки могут быть использованы некоторые полезные приёмы в случае, когда NGINX используется для проксирования или балансировки приложения. В этой статье будет рассмотрено особое использование директивы error_page в применении к типичной инфраструктуре приложения с проксированием через NGINX.

Привет Хабр! Не так давно, в нашей организации встала задача узаконить wifi доступ, но чтобы в дальнейшем использование системы было бесплатно. (Согласно постановлению Правительства №758 от 31 июля 2014г. и №801 от 12 августа 2014 г. — все публичные WIFI сети обязаны производить идентификацию пользователей). У нас 10 залов для мероприятий (от 30 до 400 человек), а в день в среднем проходит от 4 до 12, плюс постоянная текучка народа и капризные пользователи.

Вопросы SEO-оптимизации и улучшения User eXperience, которые в определенный момент встали перед командой Wrike, потребовали значительного увеличения скорости работы наших веб-проектов. На тот момент их было порядка десяти (основной сайт, блог, справочный центр и т. д.). Решение по ускорению проектов было выполнено на основе связки Nginx + fastcgi cache + LUA + LSYNC.

Всё началось в моего вопроса в Toster. И вот уже полгода как я использую медиа сервер Plex. Для тех, кто о нём не слышал, поясню: это ПО, которое анализирует и структурирует вашу медиатеку, и предоставляет к ней доступ через web и не только, эдакий персональный Netflix без регистрации и SMS. Я использую Plex для просмотра фильмов и сериалов через браузер на ноутбуке или Chromebook.

Раньше мне приходилось настраивать NFS или Samba share, колдовать с automount(8), мириться с отваливанием share после suspend-resume, или просто копировать файлы по sftp/scp, но теперь я использую Тайд Plex. К сожалению, с ним тоже не всё просто.

При попытках организовать https-соединения для различных web-сервисов с использованием ГОСТ-шифрования всегда оставались вопросы с посетителями, браузеры которых не поддерживают ГОСТ-алгоритмы. Логичным казалось решение при установке https-соединения отдавать клиенту сертификат в зависимости от поддерживаемых его системой алгоритмов, но до недавнего времени практические реализации такого подхода мне не встречались.

Если вы используете Nginx для терминации TLS-трафика, то можете улучшить время ответа сервера с помощью патчей от Cloudflare. Подробности под катом.

Эта статья расскажет, как скомпилировать и установить динамические модули в nginx в текущую его установку.

Мы рады представить бету NGINX Amplify, нашего нового инструмента для мониторинга NGINX и NGINX Plus. Используя NGINX Amplify, вы сможете отслеживать и контролировать NGINX и приложения, которые он обслуживает. Новый инструмент позволит быстро решать проблемы с производительностью и доступностью отдельных сервисов и инфраструктуры в целом. На текущий момент он включает в себя гибко настраиваемую панель мониторинга с механизмом оповещений, а также систему автоматических рекомендаций по оптимизации производительности и улучшению безопасности.

Узнать больше и увидеть NGINX Amplify в действии можно записавшись на онлайн вебинар, который пройдет 13 июля в 20:00 по московскому времени.

Также, вы можете начать бесплатно использовать NGINX Amplify прямо сейчас, пройдя регистрацию.

Удостоверяющий центр «Let’s Encrypt» (далее просто letsencrypt) вышел из беты пару месяцев назад, пообтерся в реальных условиях, избавился от детских болезней и оброс различными клиентами. И к этому моменту выдал 5 миллионов сертификатов. Самое время внедрять, т.е. получать сертификаты на свои домены и обновлять их в автоматическом режиме. Но как внедрить так, чтобы приблизиться к любимому админскому «поставил и забыл»? Чтобы было просто получать новые сертификаты, а старые при этом обновлялись автоматом? Ну и как добавить немного безопасности в этот процесс?
Ответ под катом.

Да, на Хабре уже много текстов про сертификаты Let’s Encrypt, но полной пошаговой инструкции я, к сожалению, не нашёл. Хотел восполнить пробел. К тому же, с мая 2016 года в процессе установки произошли незначительные изменения, которые могут сбить с толку новичка. Поэтому я решил написать эту инструкцию. Так сказать себе на память и другим в помощь.

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

Многие я думаю читали о применении Elasticsearch, Logstash и Kibana для сбора и анализа логов, но часто статьи начинаются с длинного мануала как поднять сервисы ELK и заставить работать их совместно.
Здесь я хочу рассказать о быстром старте с помощью Docker.

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

Мы рады представить NGINX 1.10 и 1.11. Эти номера версий обозначают стабильную (stable) и основную (mainline) ветки бесплатных открытых выпусков, над которыми мы сфокусируем наши усилия на протяжении следующих 12 месяцев.

NGINX версии 1.10.0 уже вышел, а будущий выпуск основной ветки будет под номером 1.11.0.

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

Проблема: некоторые пользователи не могли скачать бинарный файл объемом несколько мегабайт. Соединение почему-то обрывалось, хотя файл находился в процессе скачивания. Вскоре мы убедились, что где-то в нашей системе был баг. Воспроизвести проблему можно было достаточно просто единственной командой curl, но исправить ее потребовало невероятных затрат сил и времени.