Я работаю системным администратором Unix. Однажды к нам в отдел эксплуатации сервисов упал тикет от программиста с выдержой из лога application-сервера в заголовке: "pgbouncer cannot connect to server". Посмотрев логи pgbouncer'ов, я увидел, что периодически возникают lookup fail'ы при обращении к нашим DNS. Было установленно, что это связано не с работой наших DNS-серверов, а с ненадёжностью самого протокола UDP: иногда возникают потери пакетов по разным причинам.

В результате, было решено установить на каждом сервере с pgbouncer'ами по кэширующему BIND. И тут возникла интересная проблема: pgbouncer не перечитывал по сигналу HUP файл /etc/resolv.conf и продолжал обращаться к старым DNS-серверам. А перезагружать баунсеры категорически нельзя: есть проблемные проекты, которые очень болезненно относятся к разрывом сессий с базой.

В данной статье я расскажу как можно pgbouncer или любую другую программу, использующую библиотечный вызов getaddrinfo(), заставить перечитать resolv.conf и начать использовать новый DNS-сервер совершенно безболезненно для клиентов (без даунтайма).

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

Вы наверняка знаете или представляете, что управление большой инфраструктурой с помощью Puppet — непростая задача. Если для десяти серверов Паппет не нужен, для пятидесяти в самый раз и код можно писать как угодно, то когда речь идет о 500+ серверов, то в этом случае приходится уже серьезно думать об оптимизации своих усилий. Плохо, что Паппет изначально, видимо, не задумывался, как решение для больших инфраструктур, по крайней мере иерархия в него изначально заложена из рук вон плохо. Стандартные node definitions совершенно неприменимы в больших компаниях. Node inheritance (также как и class inheritance) Puppetlabs не рекомендуют больше использовать вообще, вместо этого лучше загружать данные о иерархии из внешних источников, таких как Hiera и External Node Classifier (ENC).

Компания Google, ранее ревниво охранявшая свои датацентры от посторонних взглядов, опубликовала впечатляющую подборку фотографий, сделанных в святая святых. Более того, по датацентру в городе Ленор (Северная Каролина), теперь можно прогуляться в Google Street View или посмотреть видеотур. Пожалуй, слова тут излишни. Смотрите сами.

В данной стать я хочу поделиться опытом/методологией по реализации Private Cloud. Здесь я приведу вопросы, которыми мы задавались по ходу реализации и как они решались.

.

Мы участвовали в тендере по разработке Private Cloud сервиса для одной крупной европейской организации. Цель данного тендера — предложить инфраструктуру, предоставляющую клиенту сервисы IaaS и PaaS. Ниже приведу ключевые моменты тех. задания:

• основными операционными системами являются Windows и Linux на платформе x86
• «стандартный» список ПО для PaaS сервисов (web, database, application server, etc.), включая базы данных Oracle
• желательно так же предложить Solaris x86
• инфраструктура должна располагаться в двух датацентрах (расстояние < 50 км)
• 6 типов виртуальных машин (от 1 vcpu до 10 vcpu)
• 4 сервиса (SLA): от бронзы (best effort) до платины (RPO: realtime, RTO: 2h)
• твердый заказ на 1000 виртуальных машин, с возможным ростом до нескольких тысяч

Я думаю, что буду прав в 80% случаев, если заявлю, что каждый ребенок родившийся в эпоху становления и развития компьютерных игр, так или иначе играл в них. Кто-то играл достаточно редко, предпочитая футбольные баталии, а кто-то в пух и прах ругался с родителями, вымаливая еще чуть-чуть игрового времени. И наверняка многие слышали, или даже на своем примере видели как компьютер в семье становится предметом нескончаемых скандалов и семейных дрязг.
«Еще пару часиков поиграть в WoW/LineAge/EVE/GW, пусть институт подождет, ведь тут такой интересный рейд/квест/итд» — знакомая ситуация, не правда ли?
А что делать родителям тех чад, которые просто гибнут за мониторами, которые рушат свои жизни, погрузившись в цифровой мир полностью? Как регулировать эти отношения, когда воспитательные методы уже не помогают? Эти вопросы задавала себя одна китайская семья, когда их сын стал проводить в потустороннем мире времени больше, нежели в настоящем. О этой семье и парнишке по имени Дэн Сэньшань и пойдет речь в этой статье.
Суровая драма современности — интернет-зависимость — предстанет в этой статье в полной мере на примере китайского общества, самого многочисленного и самого пораженного этим недугом.

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

Привет.

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

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

Итак, если вы имеете IT-шное образование и вам интересна идея сваливания из печальной пост-совковой реальности, прошу под кат.

1 часть. Заземление
(общая информация, термины и определения)

2 часть. Традиционные способы строительства заземляющих устройств
(описание, расчёт, монтаж)

3 часть. Современные способы строительства заземляющих устройств
(описание, расчёт, монтаж)

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

Д. Основные способы строительства

Д1. Модульное заземление (для обычных грунтов)

Д1.1. Особенности решения

Д1.1.1. Универсальность и простота применения
Д1.1.2. Долгий срок службы
Д1.1.3. Зависимость уменьшения сопротивления заземления от увеличения глубины электрода
Д1.1.4. Суперкомпактность
Д1.1.5. Никакой сварки

Д1.2. Расчёт получаемого сопротивления заземления
Д1.3. Монтаж
Д1.4. Достоинства и недостатки

Д2. Электролитическое заземление (для вечномёрзлых или каменистых грунтов)

Д2.1. Особенности решения

Д2.1.1. Простота применения в вечномёрзлых или каменистых грунтах
Д2.1.2. Компактность
Д2.1.3. Образование талика
Д2.1.4. Никакой сварки

Д2.2. Расчёт получаемого сопротивления заземления
Д2.3. Монтаж
Д2.4. Достоинства и недостатки

Д. Основные способы строительства

Напомню о достоинствах и недостатках традиционных способов строительства заземлителей, описанных в прошлой части:

В первой части обзора CentOS 7 было рассказано о поддержке контейнеров Linux в Cent OS 7. Во второй части мы поговорили об управлении идентификацией. В третья части обзора мы коснулись сетевой файловой системы NFS и ее окружению. В этой статье поговорим о смягчении DDoS атак TCP SYN Flood. В конце поста ссылка на бесплатное тестирование CentOS 7 в облачной VPS от Infobox.



DDoS (Distributed Denial of Service) атаки становятся все более частым явлением, из-за того, что бизнес становится все более зависимым от сети Интернет. Одна из самых распространенных видов DDoS – SYN Flood. Эта основная атака конечных хостов, ставящая ваш сервер на колени. В результате ваш сервер не может правильно обрабатывать входящие запросы.

Важно заметить, что описанные механизмы защиты доступны в CentOS 7, но не включены по умолчанию.

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

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

Эти приемы были описаны во внутреннем проекте компании Google «Testing on the Toilet» (Тестируем в туалете — распространение листовок в туалетах, что бы напоминать разработчикам о тестах).
В данной статье они были пересмотрены и дополнены.

Abstract: Изоляция приложения на уровне сети использованием network namespaces Линукса. Организация SSH-туннелей.

Традиционно, большая часть статьи будет посвящена теории, а скучные скрипты — в конце статьи. В качестве субъекта для экспериментов будет использоваться Steam, хотя написанное применимо к любому приложению, включая веб-браузеры.

Вместо вступления. Я просто покажу эту картинку:

147%… Что-то мне это напоминает. Впрочем, хабр не для политики.

Цена на игры в Стиме зависит от региона. Регион — от IP'шника. Есть желание иметь цены в рублях, а не в евро.

Для этого мы используем VPN через SSH с использованием tun-устройств, плюс network namespaces для изоляции приложения от всех остальных сетевых устройств.

Network namespaces

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

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

Если у нас есть несколько интерфейсов (один из которых относится к VPN), то нет штатных методов сказать стиму, что надо использовать его, а не eth0/wlan0. Точнее, мы можем «завернуть» весь трафик в VPN, но это не всегда желательно. Как минимум — рост latency и снижение скорости (даже если VPN ведёт на супербыстрый сервер, увеличение latency, оверхед от туннеля и фиксированная ширина локального канала ставят TCP в положение, когда приходится резать скорость). Как максимум — одно дело «покупать через русский VPN», другое дело — пускать туда весь трафик. Меня совсем не прельщает использование VPN для получения защиты роскомнадзором от оппозиции и вольнодумства.

В этих условиях возникает большое желание оставить один на один конкретное приложение и заданный сетевой интерфейс. Один. Сконфигурированный для нужд только этого приложения.

Для решения этой задачи в Linux, уже довольно давно (аж с 2007 года) существует технология, называемая network namespaces, то есть пространства имён для сетей. Суть технологии: над сетевыми интерфейсами создаётся подобие «каталогов», в каждом каталоге может быть несколько сетевых интерфейсов и приложений. Приложение, оказавшееся в заданном сетевом пространстве имён, может использовать (и видит) только те сетевые интерфейсы, которые отнесены к этому пространству.

Картинка ниже поясняет происходящее:

Zabbix + Iostat: мониторинг дисковой подсистемы.

Зачем?
Дисковая подсистема одна из важных подсистем сервера и от уровня нагрузки на дисковую подсистему зачастую зависит очень многое, например скорость отдачи контента или то как быстро будет отвечать база данных. Это в большей степени относится к почтовым или файловым серверам, серверам БД. Вобщем, показатели дисковой производительности отслеживать нужно. На основании графиков производительности дисковой подсистемы мы можем принять решение о необходимости наращивания мощностей задолго до того как петух клюнет. Да и вобще полезно поглядывать от релиза к релизу как работа разработчиков сказывается на уровне нагрузки.

Под катом, о мониторинге и о том как настроить.

Мы в компании Centos-admin следим за появлением новых технологий, тестируем их и, конечно же, внедряем. Почти на всех серверах мы используем контейнерную виртуализацию OpenVZ. В целях расширения набора инструментов, применяемых в работе, мы решили изучить и протестировать нативную виртуализацию Linux LXC.
Под катом вы найдете небольшой обзор технологии и краткий мануал по использованию LXC в Debian Wheezy и наши выводы.

Ещё в 2010 году Леонид Каганов (как известно — большой затейник) поделился с читателями своего блога идеей кормушки для птиц с веб-камерой и досыпанием зерна путем отправки платных SMS. Идея мне понравилась. И вот, прошло 4 года, наступили новогодние праздники 2014, я достал из стола завалявшиеся arduino uno, роутер tp-link 3020 и вместе с bitl (ака админом городского сайта) приступил к реализации проекта.


Под катом много фото.

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

Основная задача внедрения любой системы управления конфигурацией, будь то Chef, Puppet или что-то еще, — повторяемо воспроизводить и обновлять окружение всех сред, использующихся при разработке ПО (dev, CI, QA, stage, production). Отсюда следует, что само описание конфигурации необходимо однозначно хранить и обновлять. К сожалению, возможности по версионированию, которые есть в Chef, достаточно ограничены. Поэтому в связке с Chef в последнее время стали активно использовать Librarian. Но перед тем, как рассказать о нем, поговорим немного о кукбуках.

abstract: В статье описаны продвинутые функций OpenSSH, которые позволяют сильно упростить жизнь системным администраторам и программистам, которые не боятся шелла. В отличие от большинства руководств, которые кроме ключей и -L/D/R опций ничего не описывают, я попытался собрать все интересные фичи и удобства, которые с собой несёт ssh.

Предупреждение: пост очень объёмный, но для удобства использования я решил не резать его на части.

Оглавление:

• управление ключами
• копирование файлов через ssh
• Проброс потоков ввода/вывода
• Монтирование удалённой FS через ssh
• Удалённое исполнение кода
• Алиасы и опции для подключений в .ssh/config
• Опции по-умолчанию
• Проброс X-сервера
• ssh в качестве socks-proxy
• Проброс портов — прямой и обратный
• Реверс-сокс-прокси
• туннелирование L2/L3 трафика
• Проброс агента авторизации
• Туннелирование ssh через ssh сквозь недоверенный сервер (с большой вероятностью вы этого не знаете)

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

1. Часть ЧПУ (человекопонятный URL)

По сути, слово с дефисами.

Паттерн: /^[a-z0-9-]+$/

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

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

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

Со всеми сложностями, о которых идет речь выше, мы хорошо знакомы на собственном опыте: у нас имеется 10 точек присутствия с NS-серверами, расположенные в разных точках планеты. На них необходимо регулярно вносить различные изменения: обновлять операционную систему, устанавливать и обновлять различное ПО, изменять конфигурцию и т.п. Мы решили все эти операции автоматизировать и внедрить систему удаленного управления конфигурациями. Изучив имеющиеся решения, мы остановили свой выбор на Ansible.

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