• Автомонтирование файловых систем с 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», то ваш сервер будет перезагружаться час с хвостиком. А если там цифра поболе, или просто программа, которая не хочет завершаться, то и ребут никогда не закончится.
        Читать дальше →
      • Взаимоотношения 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
                • 14,7k
                • 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 узлы. Однако, среди остального мы можем посмотреть на примерное распределение ресурсов по популярности.

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


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

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

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