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

      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), даже если используется маленькая сеть
                    Читать дальше →