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

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

Каждый процесс расходует память и каждое переключение между ними требует дополнительных циклов процессора, а также приводит к вымыванию L-кэшей

У медали есть и обратная сторона. Главной проблемой асинхронного подхода, а лучше даже сказать «врагом» — являются блокирующие операции. И, к сожалению, многие авторы сторонних модулей, не понимая принципов функционирования NGINX, пытаются выполнять блокирующие операции в своих модулях. Такие операции способны полностью убить производительность NGINX и их следует избегать любой ценой.

Но даже в текущей реализации NGINX не всегда возможно избежать блокировок. И для решения данной проблемы в NGINX версии 1.7.11 был представлен новый механизм «пулов потоков». Что это такое и как его применять разберем далее, а для начала познакомимся с нашим врагом в лицо.

Всем доброго времени суток!

Позвольте представиться.
Я CEO/CTO/CIO/итд VPN сервиса SmartVPN.biz.
Можно называть меня Виктор Иванов, так как таков был мой псевдоним в службе поддержки клиентов SmartVPN.biz.

Пару лет назад я решил создать свой первый стартап — VPN сервис.
Идея нагрянула после того как около 5 друзей попросили у меня VPN на моем личном сервачке.
Естественно, никакого анализа рынка, конкурентов и написания бизнес плана не было. Я просто сел и начал кодить.
Спустя какое-то время проектом стало можно пользоваться — и он увидел свет.

Есть сервисы, защищающие нас от DDoS атак. Они работают по принципу прокси: в DNS прописывается их IP, они фильтруют трафик и проксируют на ваш сервер. Все они настоятельно рекомендуют прятать свой IP и в публичном доступе давать только IP прокси-защитника. Вполне здравый подход, достаточный для успешной защиты. А я расскажу на чем можно проколоться и как от этого защитится.

Шифруем всё подряд

Эра незашифрованного веба проходит, и это хорошо. В этой инструкции мы предполагаем, что на вашем сервере работает веб-сервер Nginx. И теперь мы сделаем так, чтобы все посетители сайта пользовались исключительно протоколом HTTPS. Кроме этого мы включим HSTS – это «HTTP Strict Transport Security», когда сайт не только поддерживает HTTPS, но и настаивает на его использовании.

Для этого есть множество способов, но я опишу метод под названием «HTTPS termination». Иначе говоря, мы поставим перед веб-сервером обратный прокси, который и будет обеспечивать HTTPS. Это получается проще и гибче, чем настраивать HTTPS только при помощи возможностей веб-сервера. Возможно, вам покажется контринтуитивным, что добавление ещё одного приложения в стек упростит вашу жизнь – но это действительно так.

Уточним, что данный рецепт подходит для серверов на базе Linux, на которых установлен Nginx.

То, что будет работать прежде всех остальных приложений в стопке – это HAProxy. Это в первую очередь приложение для балансировки – он умеет распределять приходящие запросы между разными физическими серверами. Много высоконагруженных сайтов используют его в этом качестве (тот же reddit), но в последней версии у него появилась возможность выполнять SSL termination. Он умеет устанавливать HTTPS-соединения от имени сервера.

Поэтому мы поставим HAProxy, скормим ему наши сертификаты SSL/TLS, поручим перенапрявлять все HTTP запросы на HTTPS, и покажем ему уже сам веб-сервер в качестве бэкенда.

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

Частичная открытость Android немного улучшает ситуацию, но полноценного решения проблемы утечки приватных данных пока не существует. Основная проблема в том, что пока на устройстве используются блобы нет никаких гарантий, что в них нет закладок (вроде обнаруженных в прошивках Samsung Galaxy). Аналогичная проблема с проприетарными приложениями без открытых исходников (вроде всего пакета GApps, начиная с самого Google Play Маркет). По сути всё как раз наоборот — крайне высока вероятность, что закладки там есть. Нередко их даже не пытаются скрывать, выдавая за удобные «фичи» для синхронизации и/или бэкапа ваших данных, обеспечивания вас полезной рекламой, и «защиту» от вредоносного софта или на случай утери устройства. Один из самых надёжных способов защиты своих данных описан в статье Mission Impossible: Hardening Android for Security and Privacy, но там речь не о телефоне, а о планшете, причём с поддержкой только WiFi (мобильных чипов без блобов по-моему вообще пока ещё нет, для мобильного инета вместе с этим планшетом предлагается использовать отдельный 3G-модем, блобы в котором никому не навредят т.к. на этом модеме личных данных просто нет), и, на всякий случай, физически отрезанным микрофоном. Но, несмотря на невозможность полноценно защитить личные данные на телефоне, я считаю что стоит сделать максимум возможного: прикрыть столько каналов утечек, сколько получится — ведь мало кто может позволить себе не использовать мобильный телефон или не держать на нём личные данные (хотя бы контакты и историю звонков).

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

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

Какие с ней есть проблемы!? Да по началу никаких. Выглядит она примерно вот так и вполне решает свои задачи. Но это не совсем так.

На прошедшем в начале марте этого года мероприятии Vault, организованным Linux Foundation в Бостоне, было много разговоров о файловых системах и хранилищах. Если думаете, что там не было сказано ничего нового, то вы ошибаетесь.

Думали ли вы когда-нибудь о том, что однажды слишком быстро втянулись в веб-программирование на PHP? И вот уже прошло много лет, у вас хороший опыт, и вы не думаете ни о каких других способах „делать“ веб, кроме как на PHP. Может быть, у вас возникают сомнения в правильности выбора, однако непонятно, как найти способ быстро его проверить. А хочется примеров, хочется знать, как изменятся конкретные аспекты деятельности.

Сегодня я попробую ответить на вопрос: «А что если вместо PHP писать на Python?».

Сам я долгое время задавался этим вопросом. Я писал на PHP 11 лет и даже являюсь сертифицированным специалистом. Я научился его «готовить» так, чтобы он работал в точности, как мне надо. И когда я в очередной раз читал на Хабре перевод статьи о том, как всё в PHP плохо, я просто недоумевал. Однако подвернулся случай пересесть на Ruby, а потом и на Python. На последнем я и остановился, и теперь попробую рассказать вам PHP-шникам, как нам питонистам живётся.

В статье данные сведения по заголовкам кэширования (ЗК) для HTTP и соответствующее поведение сетей доставки контента (CDN). Если вам хочется разобраться, каким образом заголовки кэширования вписываются в современный веб, или вам просто интересно, о чём говорят ваши коллеги – эта статья для вас.

Если вы уже понимаете преимущества ЗК, и хотите расширить свои знания, я рекомендую вам обратиться к документации от W3.

Что могут ЗК сделать для вас?

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

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

Не претендуя на полноту, все же считаю, что это может пригодиться системным администраторам.

Увеличение размера диска в виртуальной машине происходило при следующих вводных: формат файла виртуалки qcow2, виртуальная машина использует lvm и ext4, root partition находится в extended partition. Действо обычно происходит ночью, когда нагрузка минимальна и даунтайм не сильно давит на нервы. Хотя при работе с highload-проектами адреналина всё равно выделяется достаточно, чтобы 10 раз подумать, перед тем, как что-либо делать. Поэтому перед началом процесса, лучше отключить систему оповещения по СМС, чтобы не пугать коллег сообщениями типа «Server down» среди ночи.

Для управления серверами профессиональные администраторы давно используют такие SCM системы, как Chef, Ansible, SaltStack и т.п. Данные инструменты помогают централизованно администрировать большой парк серверов. Для управления же одним сервером трудозатраты на установку и настройку такого инструмента часто превышают выигрыш от его использования. В данном случае нередко применяется подход «да ну его, я быстрее скрипт на баше напишу». Подход достаточно популярный, а потому я хотел бы познакомить вас с легковесным SCM инструментом, который не требует ничего, кроме старого доброго баша, и может вполне успешно применяться для настройки одного сервера.

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

Преамбула

В связи с наметившимися тенденциями решил я обфусцировать свой скромный OpenVPN-туннель, просто чтобы набить руку — мало ли пригодится…

Дано: дешевая VPS с белым IP, работающая под Ubuntu Trusty Server Edition и служащая OpenVPN сервером.
Требуется: по-возможности скрыть OpenVPN туннель, желательно без изобретения велосипедов.

достаточно сильный лебедь

Если вы когда-либо искали VPN, который будет работать на десктопах, мобильных устройствах и роутерах без установки дополнительного ПО и перепрошивки роутера, вы, вероятно, выбирали между PPTP и L2TP+IPsec. У протокола PPTP имеются проблемы с безопасностью и прохождением через брандмауеры и NAT, так что в 2015 году его уже использовать не стоит, а использование L2TP излишне, т.к. L2 VPN, по моему мнению, для обычного удаленного доступа не нужен практически никогда.

Удивительно, что в интернете не так-то просто можно найти информацию о настройке чего-то помимо L2TP+IPsec в транспортном режиме, учитывая, что это обширный стек протоколов, который можно конфигурировать буквально как душе угодно, поэтому я попытаюсь устранить такое несовершенство мира.

Небольшое введение в мир IPsec

Вообще говоря, не совсем правильно называть IPsec VPN. IPsec не предназначен для построения «виртуальных частных сетей», а создан для шифрования или защиты от подмены передаваемых по IP данных. Это специальный слой поверх IP, который, в зависимости от режима и настроек, работает по-разному. В отличие от привычного VPN, который создает новый интерфейс в системе, на который вы, как это чаще всего бывает, назначаете IP-подсеть из диапазона частных адресов (т.е. создаете новый сетевой сегмент), и через который маршрутизируется трафик в зашифрованном виде, IPsec просто шифрует трафик магическим образом между «внешними» интерфейсами сервера и клиента.

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

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

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

Однажды мне окончательно надоели странички вроде «данный ресурс заблокирован по требованию», которые стали попадаться все чаще и чаще. А еще все больше стало упоминаний про «глубинный интернет», i2p, tor, onion, анонимные p2p сети и вообще повеяло хакерской романтикой детства, когда интернет был чем-то загадочным и был доступен только с двух часов ночи со скоростью 31200…

В общем, была поставлена цель: сделать прокси сервер, через который можно заходить на любые сайты (включая сайты в доменах .i2p и .onion) в обход любых блокировок. Цель обеспечения анонимности не ставилась.

Ужа с ежом удалось скрестить, и вот теперь я, как и 17 лет назад, исследую глубинные слои интернета. Кстати, если говорить про i2p, то скорость по ощущениям не намного больше, чем у интернета 17 лет назад. История циклична.

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

Как это работает:

Основным прокси сервером явлется squid.
Через cache_peer (вышестоящий прокси) squid подключается к i2p и tor. tor является Socks прокси, а squid — http прокси, поэтому между squid и tor встраивается прослойка privoxy.
Также мы имеем обновляемый ACL список всех заблокированных ресурсов в русском интернете.
Squid обрабатывает запросы от браузеров следующим образом:
Если запрашивается URL в домене .i2p, то запрос передается по цепочке в i2p.
Если запрашивается URL в домене .onion, то запрос передается по цепочке в tor.
Если запрашивается запрещенный URL, то запрос передается по цепочке в tor.
Все остальные запросы отправляются напрямую самим squid.

Инструкция как сделать интернет без ограничений своими руками:

Привет, Гиктаймс! Скажите честно, знакомы ли вы с «пасхальными яйцами» в IT, и, если да, то находили ли что-нибудь сами, случайно или намеренно, зацепившись взглядом за подозрительную штуку?



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

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

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

Сначала мы рассмотрим принцип работы xargs и разберем примеры попроще, а затем перейдем к разбору сложных и интересных кейсов.

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

Итак, у нас имеется:

• Ubuntu Server 14.04 (думаю не принципиально, должно работать на других дистрибутивах)
• Fail2Ban
• MySQL
• Asterisk (или любой другой сервис, который нужно защитить от брут форс атак)
• Роутер MikroTik
• Руки
• Желание изобрести велосипед

После прочтения пары статей (один, два) родился следующий концепт:

1. баним злоумышленника на определённое время при помощи Fail2Ban и добавляем запись с его IP адресом в БД MySQL
2. после определённого количества выданных банов добавляем IP адрес в список запрещённых на роутере