• Основы Ansible, без которых ваши плейбуки — комок слипшихся макарон, часть 3

    • Tutorial

    В этой части мы перестаём говорить о простом и приятном и начинаем говорить о трудном. Переменные в Ansible: scope, precedence, рекурсивная интерполяция. Для тех, кто дочитает до конца, маленький бонус: упрощённая таблица приоритетов, с которой можно жить. Предыдущие части: 1, 2.


    Обычно рассказ про переменные в Ансибл начинают с чего-то очень простенького, что создаёт у читателя иллюзию, что переменные в Ансибл — это как в любом другом языке программирования. Мутабельные или немутабельные, локальные и глобальные. Это не так.


    Это не так.


    У Ансибла возникла уникальная модель переменных (модель памяти?), которую надо учить с нуля. И рассматривать мы её начнём с того места, где значения используются (обычно переменные Ансибла рассматривают с того места, откуда они появляются). Почему? Потому что при рассказе в этом направлении у нас образуется направленный граф, который куда легче уложить в голову.


    Обратите внимание — я сказал "значения", потому что "переменные" — это всего лишь имена к значениям. У перменных свой глубокий внутренний мир, и про него во второй части.

    Читать дальше →
  • Основы Ansible, без которых ваши плейбуки — комок слипшихся макарон, часть 2

    • Tutorial

    Я продолжаю выразительно пересказывать документацию Ансибла и разбирать последствия её незнания (ссылка на предыдущую часть).


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


    Мы будем разбирать каждый элемент инвентори (кроме host_group_vars plugin) и обсуждать зачем он, как его использовать правильно, и как неправильно.


    Оглавление:


    • Что такое хост? (и немного про транспорты)
    • Доступ IP vs FQDN; inventory_hostname vs ansible_host
    • ansible_user — писать или не писать?
    • Группы
    • Переменные: в инвентори или в плейбуку?
    • Классификация инвентори по происхождению.
    Читать дальше →
  • Основы Ansible, без которых ваши плейбуки — комок слипшихся макарон

    • Tutorial

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


    Для исправления этой вселенской несправедливости я решил написать введение в Ансибл для тех, кто его уже знает. Предупреждаю, это не пересказ манов, это лонгрид в котором много букв и нет картинок.


    Ожидаемый уровень читателя — уже написано несколько тысяч строк ямла, уже что-то в продакшене, но "как-то всё криво".

    Читать дальше →
  • Откуда этот конфиг? [Debian/Ubuntu]

      Цель этого поста: показать технику отладки в debian/ubuntu, связанную с "поиском первоисточника" в системном конфигурационном файле.


      Тестовый пример: после долгих издевательств над tar.gz копией установленной ОС и после её восстановления и установки апдейтов мы получаем сообщение:


      update-initramfs: Generating /boot/initrd.img-4.15.0-54-generic
      W: initramfs-tools configuration sets RESUME=/dev/mapper/U1563304817I0-swap
      W: but no matching swap device is available.
      I: The initramfs will attempt to resume from /dev/dm-1
      I: (/dev/mapper/foobar-swap)
      I: Set the RESUME variable to override this.

      Цель: понять, откуда это значение (U1563304817I0) пришло и как его правильно поменять. Это первый попавшийся пример, не особо интересный сам по себе, но удобный, чтобы показать практические методы работы с Linux.


      Шаг номер 1: Откуда пришёл RESUME?

      Читать дальше →
    • How to vendor a git into another git

        Discovering git vendor extension.


        Cross-post from my medium blog: https://medium.com/opsops/git-vendor-295db4bcec3a


        I would like to introduce the proper way to handle vendoring of git repositories.


        What is is ‘vendoring’?


        Vendoring is a way to integrate other’s work into your own. It’s the opposite of ‘linking’ against third-party library. Instead of having that library as a dependency, application uses this library as a part of own source code and keep that code ‘inside’ itself.


        Normally, vendoring is done by language tooling: bundler, cargo, pip, etc. But sometimes you need to vendor something not covered by any existing toolset, or something multi-language, that it’s impossible to find the ‘core’ language tool for that.


        The solution for this situation is vendoring on a git level. You have your own git repository (I call it ‘destination repo’), and you want to incorporate some other repository (I call it ‘source repo’) as a directory into your (destination repo).


        The things you expect from a well-designed vendoring system (regardless of Git it is or not):


        • Visibility. You want to know that some code is vendored, means it wasn’t written by committer.
        Read more →
      • snap & flatpack — трагедия общин

          Лонгрид варнинг: вас предупредили, много букв.


          Уже давно ведётся разработка формата дистрибуции приложений, которые были "свободны" от общесистемных зависимостей. Ubuntu очень, очень активно продвигает свой snap, gnome — flatpack. Оба обещают рай и свободу от rpm/deb. Давайте же подумаем про проблему, которую они хотят решить, и цену, которую они просят за решение этой проблемы.

          Читать дальше →
        • FreeCAD — новый метод рисования

            Disclamer: Я никогда в своей жизни не работал с CAD/CAM приложениями раньше, и, вдруг, пришлось. Принципы работы FreeCAD меня так восхитили, что это требует срочного поста на Хабр, чтобы рассказать другим.


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


            Вступление


            У меня возникла простая задача — сделать 3D модель своей квартиры. Не просто "стенки в размер", а все балки, выступы и загибы. Я попробовал одну, вторую, третью программу… Я отчаялся (началось с SweetHome3D, а закончилось blender и inkscape). Они все были чертовски неудобными. Среди программ, которые я попробовал, был и FreeCAD, который я пропустил по причине "нифига не сделать" и "не работает толком". После того, как я отчаялся, я пошёл по второму кругу. На этот раз, чуть больше читая документацию… И FreeCAD не только "взлетел", но и ещё и открыл для меня восхитительный новый мир точного векторного рисования, основывающегося на Constrains.

            Читать дальше →
          • Принудительное введение в системы управления конфигурациями

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


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


              Введение для отшельников, которые не слышали что такое configuration management systems


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


              Главная боль любой системы управления конфигурациями


              Главная боль состоит в том, что система управления конфигурациями ломает привычную автоматику пальцев. Раньше вы могли поднять веб-сервер за 2 минуты почти не глядя на экран. Теперь вам предлагают потратить на абсолютно те же самые действия минут 15-20 (если вы хорошо знаете систему управления конфигурациями) или даже несколько дней (!!!!!), если вы её изучаете.


              Это преступление против личной эффективности. Уменьшить её в десять (0xA) раз — и это они называют прогрессом?

              Читать дальше →
            • Не было печали, апдейтов накачали

                У меня дома используется Debian Sid. Большей частью он весьма и весьма хорош, но местами он слишком Bleeding слишком Edge. Например, когда отгружает пакеты, ломающие работоспособность системы. Вчера приехал wpasupplicant, который сломал мне wifi. Я его откатил, но в процессе я подумал, что многие пользователи не умеют этого делать. Рассказ "как откатить плохой apt-get install/upgrade" — в этом посте.


                Ситуация


                Мы сделали apt-get install что-то, или apt-get upgrade, или даже apt-get dist-upgrade, и после перезагрузки (или даже сразу же) обнаружили, что так нельзя. Сервис не стартует, убрана важная нам фича, кто-то падает и т.д. Мы хотим откатиться. Но вот, незадача — куда именно мы не знаем, потому что какая была версия до обновления мы не знаем.

                Читать дальше →
              • Автомонтирование файловых систем с systemd

                • Tutorial
                Среди множества функций, которые предоставляет systemd, есть одна, которую несправедливо забыли. Это функция автомонтирования. При настройке автомонтирования указанный каталог будет подмонтирован только после первого обращения к нему (точнее, прямо во время).

                NFS over VPN


                Конкретный пример: у меня есть удалённый сервер, на котором есть интересующий меня каталог. Я хочу иметь этот каталог локально на своей машине. Протокол доступа — nfs. Т.к. он не имеет шифрования, то разумным решением выглядит использование vpn-канала до сервера.

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

                Как оно устроено


                Systemd имеет специальный вид automount-юнитов, которые позволяют автоматически монтировать указанный каталог.
                Читать дальше →
              • История одного бага (#1653967)

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

                  Вступление


                  Рядовой апгрейд в лаборатории с Openstack Mitaka до Openstack Newton (более новая версия). Несколько deprecated options в файлах конфигурации, keystone переехал с eventlet на WSGI и поломал существующую конфигурацию с haproxy; из-за типового «ipv6 listen» apache не стал конфликтовать с haproxy за одинаковые используемые порты на звезде (один слушал ipv6, другой ipv4 only), так что запросы уходили в haproxy вместо апача, где умирали с 503, т.к. апстрима не было… Впрочем, история не об этом.

                  После того, как основные проблемы были пофишкены, Nova (одна из компонент Openstack) при запуске начала падать с ошибкой: ConfigFileValueError: Value for option url is not valid: invalid URI: 'http://neutron-server.example.com:21345'.. Это было очень странно. С учётом, что в конфиге поменялось 100500 опций, возникло подозрение, что мы используем устаревшую опцию, которую больше не надо использовать. Однако, документация говорила, что пример опции — url = http://controller:9696.

                  Отладка


                  Очевидные шаги отладки:
                  • Закомментировать опцию — не падает
                  • Повторить опцию из примера — не падает
                  • Заменить в опции порт на «наш» — возможно, нельзя использовать слишком большой номер порта — не падает
                  • Заменить в опции url на наш — падает
                  • Вернуть «controller» на место — не падает
                  • Подозрение: не умеет fqdn: заменить controller на controller.dns — не падает
                  • Подозрение: слишком много точек (у нас в реальном коде было 8 точек в url) — controller.dns1.dns2.dns3.dns4 — не падает
                  • Оставить из нашего имени только первую часть: http://neutron-server:9696 — падает! гипотеза уже понятна.
                  • Проверка1: http://neutronserver:9696 — не падает
                  • Проверка2: http://with-dashes:9696 — падает!
                  Читать дальше →
                • Запуск worker'ов сервиса с помощью systemd

                  • Tutorial
                  После выхода Ubuntu 16.04 (новый LTS релиз), systemd стал реальностью всех основных дистрибутивов Linux, использующихся на серверах. Это означает, что можно закладываться на расширенные возможности systemd, не рискуя оставить часть пользователей приложения «за бортом».

                  Этот пост о том, как реализовать многоворкерное приложение средствами systemd.

                  Abstract: Использование шаблонов сервисов и target'ов для запуска нескольких инстансов сервиса (реализация «воркеров»). Зависимость PartOf. Немного про [install] секцию у unit'ов.

                  Вступление


                  Многие языки программирования с плохой или никакой многопоточностью (Python, Ruby, PHP, довольно часто C/C++) используют концепцию «воркера». Вместо того, чтобы городить сложные отношения между тредами внутри приложения, они запускают несколько однопоточных копий приложения, каждое из которых берёт на себя кусок нагрузки. Благодаря опции SO_REUSEPORT есть даже возможность «вместе» слушать на одном и том же порту, что покрывает большинство задач, в которых возникает потребность в воркерах (собственно, обычные серверные приложения, реализующие API или обслуживающие веб-сайт).

                  Но такой подход требует наличия «супервизора», который отвечает за запуск копий, следит за их состоянием, обрабатывает ошибки, завершает при всякого рода stop/reload и т.д. При кажущейся тривиальности — это совершенно не тривиальная задача, полная нюансов (например, если один из воркеров попал в TASK_UNINTERRUPTIBLE или получил SIGSTOP, то могут возникнуть проблемы при restart у не очень хорошо написанного родителя).

                  Есть вариант запуска без супервизора, но в этом случае задача reload/restart перекладывается на администратора. При модели «один процесс на ядро» перезапуск сервиса на 24-ядерном сервере становится кандидатом в автоматизацию, которая в свою очередь требует обработки всех тех же самых SIGSTOP и прочих сложных нюансов.

                  Одним из вариантов решения проблемы является использование шаблонов сервисов systemd вместе с зависимостью от общего target'а.
                  Читать дальше →
                • Как перезагрузить сервер?

                    Abstract: описание видов ребута, рассказ про sysrq, ipt_SYSRQ, ipmi, psu.

                    Как перезагрузить сервер? — Это вопрос, который обычно задают ну очень начинающим пользователям, которые путаются между halt, shutdown -r, reboot, init 6 и т.д.

                    Опытный администратор уточнит вопрос: «а что с сервером не так?» Разные виды отказов серверов требуют разных видов ребута — и неверно выбранный вариант приведёт к тяжелейшим последствиям, из которых визит в веб-морду IPMI/DRAC/iLO с целью «доперезагрузить» будет самым лёгким. Самым тяжёлым в моей личной практике была командировка эникейщика в соседний город. С целью «нажать ребут» на одиноко стоящем сервере.

                    В этой статье: что мешает серверу перезагрузиться и как ему помочь.

                    Начнём с теории ребута.

                    При выключении или перезагрузке сервера менеджер инициализации (в большинстве современных дистрибутивов — systemd, в эксцентричной Ubuntu 14.04 до сих пор upstart, в архаичном хламе — sysv-init) в определённом порядке посылает всем демонам команду «выключись». И большинство демонов (например, СУБД, вроде mysql) знают, как выключаться правильно. Например, закончить все транзакции, сохранить все несохранённые данные на диск и т.д. Для in-memory СУБД, наподобие redis, это и вовсе может быть критичным: не сохранил — потерял.

                    Старые системы иницализации ждали неограниченно долго каждый из инит-скриптов. Например, если «шутник» добавил вам в «stop» веточку «sleep 3600», то ваш сервер будет перезагружаться час с хвостиком. А если там цифра поболе, или просто программа, которая не хочет завершаться, то и ребут никогда не закончится.
                    Читать дальше →
                  • Google выключает навсегда контроллеры Revolv у пользователей

                      Корпорация зла держит марку.

                      Google (превратившаяся потом в Alphabet) купила некоторое время назад Revolv — производителя контроллеров для домашней умной электроники. Теперь она уничтожает контроллеры этой марки у купивших пользователей. Не прекращает поддержку и производство, а просто «окирпичивает».

                      Дальше можно только цитировать с сайта revolv.com:

                      What happens to my Revolv service?
                      As of May 15, 2016, Revolv service will no longer be available. The Revolv app won’t open and the hub won’t work.
                      Is my product still under warranty?
                      No. Our one-year warranty against defects in materials or workmanship has expired for all Revolv products.
                      What will happen to Revolv data?
                      Revolv data will be deleted.


                      В добавок этому, пожалуйт, можно только процитировать customer testimony:
                      Google is intentionally bricking hardware that I own.

                      That’s a pretty blatant “fuck you” to every person who trusted in them and bought their hardware.
                      Читать дальше →
                    • Взаимоотношения dhcpclient и resolv.conf'а в Linux

                        Abstract: описание того, как обновляется файл /etc/resolv.conf в условиях работающего dhcp-клиента, специфика различных ОС и варианты реализации.

                        Охват: Debian, Ubuntu, Centos/Fedora/RHEL; dhclient с resolvconf и без. NetworkManager не учитывается.

                        Лирика: Я только что потратил несколько дней (подробности на английском [1], [2]) разбираясь как правильно сохранять 'options rotate' в /etc/resolv.conf в разных дистрибутивах при работающим DHCP. Оказалось, внятной документации по этому вопросу нет, и информацию пришлось собирать из разных источников, исходных текстов и экспериментальных данных. Дальше будет сухо и по делу.

                        О чём речь?

                        У компьютера сетевой интерфейс принципиально может быть сконфигурирован тремя видами: вручную/специализированным софтом, статически заданными настройками и через DHCP-клиент. (Есть ещё сколько-то экзотики, но эти три — основные методы). Первый метод нам не интересен, со статической конфигурацией всё просто — как написано, так и будет. DHCP интересен тем, что компьютер запрашивает настройки по сети «у кого-то». Протокол DCHP имеет множество опций (настроек), которые могут изменять совершенно неожиданные настройки компьютера — часовой пояс, адрес сервера с точным временем, таблицу маршрутизации, имя или домен сервера, и т.д. Из всего этого нас интересует возможность задавать настройки DNS.

                        Традиционно, настройки DNS-ресолвера хранятся в файле /etc/resolv.conf, и после обновления dhcp-аренды этот файл обновляется. В этой статье объясняется, как именно "-ся" этот файл.

                        Устройство DHCP client


                        Существует несколько реализаций dhcp-клиента, нас интересует ISC DHCP, как наиболее распространённая.
                        Сам клиент называется /sbin/dhclient, однако, стандартно, для обновления настроек, вызывается не он, а /sbin/dhclient-script. dhclient-script вызывает dhclient и использует его ответ для изменения разных частей системы. В самом dhclient-script есть функция make_resolv_conf, которая, собственно, и создаёт файл resolv.conf.
                        Читать дальше →
                      • Multihome IPv4 в Linux

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

                          Ключевые слова: policy routing, source based routing

                          Лирика: Есть достаточно статей про policy routing в Linux. Но они чаще всего разбирают общие, более тонкие и сложные случаи. Я же разберу тривиальный сценарий следующего вида:



                          Нашему компьютеру (серверу) доступно три интерфейса. На каждом интерфейсе шлюз ему выдал IP (статикой или по dhcp, не важно) и сказал «весь трафик шли мне».

                          Если мы оставим эту конфигурацию как есть, то будет использоваться принцип «кто последний встал, того и дефолтный шлюз». На картинке выше, если последним поднимется нижний интерфейс (241), то в него будет отправляться весь трафик. Если к нашему серверу придёт запрос на первый интерфейс (188), то ответ на него всё равно пойдёт по нижнему. Если у маршрутизатора/провайдера есть хотя бы минимальная защита от подделки адресов, то ответ просто дропнут, как невалидный (с точки зрения 241.241.241.1 ему прислали из сети 241.241.241.0/24 пакет с src 188.188.188.188, чего, очевидно, быть не должно).

                          Другими словами, в обычном варианте будет работать только один интерфейс. Чтобы сделать ситуацию хуже, если адреса получены по dhcp, то обновление аренды на других интерфейсах может перезаписать шлюз по умолчанию, что означает, что тот интерфейс, который работал, работать перестанет, а начнёт работать другой интерфейс. Удачной стабильной работы вашему серверу, так сказать.

                          Решение

                          Читать дальше →
                        • Самые элитные IP-адреса

                            N.B. Просьба не воспринимать написанное серьёзно.

                            Есть в России любовь к «блатным номерам». Про госномера для автомобилей все знают. Золотые телефонные номера — торгуются во всю, и даже официально. Вот, некоторое время назад всплыла новость даже про «красивый номер» паспорта с пятью нулями.

                            А как же IP-адреса?


                            На иллюстрации кипрский Пиццехат хвастается блатным (увы, телефоном) 77.77.77.77. Хотя урл 77.77.77.77 выглядел бы куда как интереснее.

                            Ну, допустим, нолик себе в конце IP кое-кто с небольшими усилиями может получить. Всего-то надо сетку больше /24 использовать.

                            А два нолика? /15 звучит уже серьёзно.

                            Но настоящие мажоры — это владельцы адресов с тремя нулями. И нет, я не говорю про гордых обладателей 10.0.0.0 и root-администраторов localhost, я про настоящие элитные белые IP. В первом приближении может показаться, что их всего 256, но с учётом всяких мультикастов, серых и экспериментальных сегментов, локалхостов и т.д., их совсем мало. Если верить IANA (тут), то у нас всего-навсего 221 /8 сетей. То есть всего может быть 221 блатных IPv4-адресов.

                            Вооружившись nmap'ом, nping'ом, whois'ом и прочими инструментами, изучаем, кто же эти счастливые люди, способные отвечать на адреса вида X.0.0.0?

                            Технологическая врезка


                            На самом деле в современном интернете вполне можно получить себе .0 (и прочие .0.0, .0.0.0), даже если используется маленькая сеть
                            Читать дальше →
                          • Forensic system administration

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

                              Я сейчас исключаю из рассмотрения инциденты с осмысленным злым умыслом, это отдельный топик. Речь про стихийные проблемы (сервер упал/завис, виртуальная машина начала тормозить а потом перестала, приложение потеряло 100500 транзакций и считает, что всё хорошо).

                              Суть происшествия


                              Иногда она тривиальная («самопроизвольно перезагрузился сервер», или «упал самолёт»). Иногда она крайне трудная для объяснения («клиенты жалуются что у не получается поменять регион», при этом все сотрудники с клиентскими аккаунтами регион поменять могут). Чаще всего, чем дальше от системного администратора источник жалобы, тем более размытой становится жалоба: «клиент говорит, что после заказа в интернет-магазине плюшевого медведя он не может поменять регион на IE7 при использовании LTE-коннекта через USB-модем, а ещё он получает 500ую ошибку при попытке отменить операцию и нажатии „назад“).

                              Ещё более сложным является случай, когда несколько проблем сливаются вместе: „сервер внезапно перезагрузился, а на другом сервере был таймаут работы с базой данных, а клиенты в это время писали, что у них не грузятся картинки“. Сколько тут проблем? Одна, две, три, а может и больше? Какие из проблем надо молча объединить (база данных и отсутствие картинок), а какие надо учитывать раздельно? А если в этот момент ещё придёт жалоба, что пользователь не может залогиниться в систему — это обычное „забыл пароль“ или тоже симптом? А если таких пользователей два? Или кто-то мимоходом говорит, „что-то у меня почта не проходит“?

                              Подсознательно в момент начала проблем, каждая новая жалоба тут же объединяется с существующими (и может завести не туда), плюс резко увеличивает стресс из-за того, что приходится думать не о трёх симптомах, а о восьми, например. А в голове хорошо только семь удерживаются. Но в то же время в моей практике бывало так, что пришедший „новый“ симптом с лёгкостью приводил к сути проблемы и её устранению…… за вычетом того, что серьёзная проблема (с которой всё началось) не имеет никакого отношения к радостно и быстро починенной ерунде. А время потрачено.

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

                              То есть журнал (в sticky notes) выглядит так:
                              • Мониторинг сработал на srv1 (22:05)
                              • (имя) сказал про проблемы с почтой (22:07)
                              • Не могу залогиниться на srv12 (22:08)/refused — Зашёл 22:16, dmesg чисто, аптайм большой
                              • Не могу залогиниться на srv13 (22:10) (timeout) — отвалился офисный wifi (22:11)
                              • Не открывается панель (22:12)
                              • Саппорт пишет, что клиент жалуется, что ничего не работает, 22:15

                              Не стоит увлекаться (не время печатать), но симптомы стоит выписывать. Один это случай или несколько, важные это симптомы или нет, станет понятно потом. Я обычно начинаю выписывать примерно после третьего отвлекающего обращения.

                              Вторым аспектом проблемы является доказательство существования проблемы. Самая ненавистная фраза, которой не удаётся избежать:

                              У меня всё работает


                              После того, как Энийские Авиалинии пожаловались производителю на то, что самолёты иногда падают, разработчик проверил, что самолёты взлетают/садятся и закрыл тикет с 'Unable to reproduce'. Сотрудники поддержки Энийских Авиалиний продолжают собирать статистику по падению самолётов и пытаются научиться воспроизводить падение в лабораторных условиях.

                              Читать дальше →
                              • +23
                              • 16.6k
                              • 6
                            • Админские байки: в погоне за фрагментацией туннелей в оверлейной сети

                                Лирическое вступление


                                Когда администраторы сталкиваются с неожиданной проблемой (раньше работало, и, вдруг, после обновления, перестало), у них существует два возможных алгоритма поведения: fight or flight. То есть либо разбиратся в проблеме до победного конца, либо убежать от проблемы не вникая в её суть. В контексте обновления ПО — откатиться назад.

                                Откатиться после неудачного апгрейда — это, можно сказать, печальная best practice. Существуют целые руководства как готовиться к откату, как их проводить, и что делать, если откатиться не удалось. Целая индустрия трусливого поведения.

                                Альтернативный путь — разбираться до последнего. Это очень тяжёлый путь, в котором никто не обещает успеха, объём затраченных усилий будет несравним с результатом, а на выходе будет лишь чуть большее понимание произошедшего.

                                Завязка драмы


                                Облако «Instant Servers» Webzillа. Рутинное обновление хоста nova-compute. Новый live image (у нас используется PXE-загрузка), отработавший шеф. Всё хорошо. Внезапно, жалоба от клиента: «одна из виртуалок странно работает, вроде работает, но как начинается реальная нагрузка, так всё замирает». Инстансы клиента переносим на другую ноду, проблема клиента решена. Начинается наша проблема. Запускаем инстанс на этой ноде. Картинка: логин по ssh на Cirros успешен, на Ubuntu — зависает. ssh -v показывает, что всё останавливается на этапе «debug1: SSH2_MSG_KEXINIT sent».

                                Все возможные внешние методы отладки работают — метаданные получаются, DHCP-аренда инстансом обновляется. Возникает подозрение, что инстанс не получает опцию DHCP с MTU. Tcpdump показывает, что опция отправляется, но не известно, принимает ли её инстанс.

                                Нам очень хочется попасть на инстанс, но на Cirros, куда мы можем попасть, MTU правильный, а на Ubuntu, в отношении которой есть подозрение о проблеме MTU, мы как раз попасть не можем. Но очень хотим.

                                Если это проблема с MTU, то у нас есть внезапный помощник. Это IPv6. При том, что «белые» IPv6 мы не выделяем (извините, оно пока что не production-ready в openstack), link-local IPv6 работают.
                                Читать дальше →
                              • Для чего используют TOR?

                                  Вступление


                                  Я не буду разводить параноидальные сказки о том, что NSA и ФСБ за всеми следит. Просто примем за базовый тезис, что tor и i2p — «наше всё». К сожалению, в контексте TORа часто можно слышать только про silkroad и детскую порнографию. Мол, рассадник, раскачивающий и покушающийся.

                                  Я управляю несколькими tor-exit node'ами и i2p маршрутизаторами. Чтобы избежать вопросов, мой работодатель к ним не имеет никакого отношения: все эти ноды — исключительно за мой счёт, в свободное от работы время. Самой старой из них уже почти год, самой молодой — примерно 4 месяца. За это время я не получил ни одного abuse report'а (я сам работаю в хостинговом бизнесе, так что хорошо представляю себе процесс реакции на «абузу» — она в первую очередь пересылается клиенту).

                                  Не смотря на отсутствие abuse'ов, вопрос оставался: для чего люди используют TOR?

                                  Контроль над exit node'ой позволяет посмотреть на проходящий трафик. Понятно, что мы исключаем весь шифрованный трафик (TLS, SSH), а так же весь трафик на .onion узлы. Однако, среди остального мы можем посмотреть на примерное распределение ресурсов по популярности.

                                  Забегая вперёд, слегка упрощённый ответ на вопрос статьи:


                                  (более подробная табличка — в конце статьи)

                                  Методология измерения

                                  Читать дальше →