• 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
                        • 15,9k
                        • 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 узлы. Однако, среди остального мы можем посмотреть на примерное распределение ресурсов по популярности.

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


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

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

                            Читать дальше →
                          • Обработка логов с учётом предыдущих сообщений в logstash/elasticsearch

                              Про отлов ядерных MCE (machine check error) и прочей гадости с помощью netconsole я писал недавно. Крайне полезная вещь. Одна проблема: throttling на CPU из-за локального перегрева (длительной нагрузки) фиксируется как MCE. Случается бэкап — и админам приходит страшное сообщение об MCE, которое на практике означает «чуть-чуть перегрелось» и точно не требует внимания к себе в 3 часа ночи.

                              Смехотворность проблемы ещё тем, что Linux фиксирует MCE после того, как throttling закончился. То есть режим 'normal', но вместо этого оно превращается MCE. Выглядит это так:
                              CPU0: Core temperature above threshold, cpu clock throttled (total events = 40997)
                              CPU4: Core temperature above threshold, cpu clock throttled (total events = 40997)
                              CPU4: Core temperature/speed normal
                              CPU0: Core temperature/speed normal
                              mce: [Hardware Error]: Machine check events logged
                              

                              При этом мы точно хотим реагировать на нормальные MCE. Что делать?

                              В рамках logstash обработка сообщений предполагается stateless. Видишь сообщение — реагируешь. Внедрять же ради одного типа сообщений более сложную систему — оверкилл.

                              Казалось бы, есть фильтр (не путать с output) elasticsearch, который позволяет делать запросы. К сожалению, он не умеет делать 'if'ы, то есть remove_tag и add_tag будут отрабатывать вне зависимости от того, удался поиск или нет.

                              Грустно.
                              Читать дальше →
                              • +10
                              • 6,8k
                              • 7
                            • Обработка сообщений ядра

                                Предисловие


                                Страшная сказочка:
                                EDAC MC0: 1 CE read ECC error on CPU#0Channel#1_DIMM#0 (channel:1 slot:0)
                                EXT4-fs error: ext4_wait_block_bitmap:445: Cannot read block bitmap
                                Out of memory: Kill process 95 (sshd) score 31 or sacrifice child
                                CMCI storm detected: switching to poll mode
                                page allocation failure: order:1, mode:0x4020
                                invalid opcode: 0000 [#1] SMP

                                Неприятно выглядит, правда? Список может быть очень длинным очень длинный. В этой статье я расскажу как с этим жить и что мы с ним сделали.

                                Часть из этих сообщений в примерах выше заставит вас погрузиться в бездны современной архитектуры процессоров («CMCI storm», удачи в поиске дороги назад, из дебрей интернетов)… Cтранные вещи в ядре могут нарушать ожидания о том, как работают компьютеры, делая последующую отладку очень затруднённой. Отсутствие знания о том, что случилось может даже оставить с грустным ответом «какая-то неведомая фигня, ребутнули, вроде, прошло».
                                Читать дальше →
                              • Не используйте "!!" в баше

                                  Каждый раз, когда неофит открывает для себя возможности баша и решает про это написать, он обязательно всем рассказывает про удобный метод «повторить команду» с использованием "!!".

                                  Типа так:
                                  $ touch /test
                                  touch: cannot touch ‘/test’: Permission denied
                                  $ sudo !!
                                  sudo touch /test
                                  

                                  Типа, хэппи-энд.

                                  Я никогда такого не использовал, но не задумывался, «почему». Просто мне не нравилась эта идея.

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

                                  echo NO ROOT PLEASE
                                   echo do it with sudo
                                  sudo !!
                                  

                                  (просто скопипастите это пример в шелл)
                                  объяснение
                                • network manager + автоматизация http-логина в wifi

                                    Пост будет коротким, но очень полезным.

                                    abstract: Есть масса wifi-хот-спотов, которые просят сделать какую-нибудь глупость при подключении. Ввести пароль в http-форме, поставить чекбокс «согласен с продажей почки в обмен на интернет» и т. д.

                                    Это задалбывает, особенно, если из wifi периодически выкидывает. В посте предлагается простое решение для автоматизации логина с помощью хуков Network Manager.

                                    Подготовка


                                    Нам надо понять куда кого как посылать, чтобы оно заработало. Ставим firebug или любой другой похожий плагин. Включаем, идём в вкладку 'net', включаем persistent (это важно), логинимся.

                                    Получаем вот такое:



                                    Находим POST (если их несколько — методом перебора и комбинирования), выбираем copy as curl, сохраняем куда-нибудь на будущее.

                                    Дальше находим uuid нашего коннекта — в файле /etc/NetworkManager/system-connections/our_wifi.

                                    Пишем скрипт (всё ниже — от рута) в каталоге /etc/NetworkManager/dispatcher.d/, например, /etc/NetworkManager/dispatcher.d/02-our_wifi-auto
                                    Читать дальше →
                                  • SSD + raid0 — не всё так просто

                                      Вступление


                                      Коллеги с соседнего отдела (UCDN) обратились с довольно интересной и неожиданной проблемой: при тестировании raid0 на большом числе SSD, производительность менялась вот таким вот печальным образом:

                                      По оси X — число дисков в массиве, по оси Y — мегабайтов в секунду.

                                      Я начал изучать проблему. Первичный диагноз был простой — аппаратный рейд не справился с большим числом SSD и упёрся в свой собственный потолок по производительности.

                                      После того, как аппаратный рейд выкинули и на его место поставили HBA, а диски собрали в raid0 с помощью linux-raid (его часто называют 'mdadm' по названию утилиты командной строки), ситуация улучшилась. Но не прошла полностью -цифры возросли, но всё ещё были ниже рассчётных. При этом ключевым параметром были не IOPS'ы, а многопоточная линейная запись (то есть большие куски данных, записываемых в случайные места).

                                      Ситуация для меня была необычной — я никогда не гонялся за чистым bandwidth рейдов. IOPS'ы — наше всё. А тут — надо многомногомного в секунду и побольше.

                                      Адские графики


                                      Я начал с определения baseline, то есть производительности единичного диска. Делал я это, скорее, для очистки совести.

                                      Вот график линейного чтения с одной SSD.



                                      Увидев результат я реально взвился. Потому что это очень сильно напоминало ухищрения, на которые идут производители дешёвых USB-флешек. Они помещают быструю память в районы размещения FAT (таблицы) в FAT32 (файловой системе) и более медленную — в район хранения данных. Это позволяет чуть-чуть выиграть по производительности при работе с мелкими операциями с метаданными, при этом предполагая, что пользователи, копирующие большие файлы во-первых готовы подождать, а во вторых сами операции будут происходить крупными блоками. Подробнее про это душераздирающее явление: lwn.net/Articles/428584
                                      Читать дальше →
                                    • По поводу появления 8 и 10Тб жёстких дисков

                                        Новость: начались поставки 8Тб жёстких дисков, анонсированы 10Тб жёсткие диски с «черепичной» системой записи (shingled magnetic recording), которая обещает увеличение объёмов путём снижения скорости случайного доступа (подробности).

                                        Комментарий


                                        SSD почти полностью сожрали всё в диапазоне десятков/сотен гигабайт. HDD используется только как сверхдешёвая заглушка, и я не понимаю, почему ни один ушлый китаец не догадался сделать SD-кардридер с mSATA-интерфейсом. Для low-end'а (лишь бы загрузиться) этого хватит за глаза и за уши, а стоить будет дешевле. Если же человеку это «медленно», то очевидно, что SSD его спасёт. По мере продвижения за 300-400Гб картинка становится экономически непривлекательной для многих сегментов (1Tb стоит €50 за HDD против €350 за самую дешёвую SSD). Но все понимают, что выход на бюджетный терабайт для SSD — вопрос времени. Хотя потребности в месте растут (игры/кино всё больших разрешений), в то же самое время область потребностей сокращается (зачем качать, когда можно смотреть в онлайне), то есть десктопный рынок можно считать потерянным.

                                        Но, кроме него есть и другие рынки.

                                        HDD, кроме low-end'а, продолжают жить:
                                        1. Из-за совершенно сумашедшего парка серверов, которые живут много больше, чем диски. Диски надо менять.
                                        2. Из-за гигантских объёмов за разумные деньги
                                        3. Из-за лучшей производительности на устоявшуюся линейную запись.

                                        Вот последний фактор определяет уникальную нишу для HDD — они лучше подходят для линейной записи. У SSD с этим много хуже — если на SSD постоянно писать большими блоками, то housekeeep'инг перестаёт справляться (особенно, если запись циклическая внутри файла, типа серверов видеонаблюдения), кеш забивается, и SSD деградирует до уровня WD Green'ов или даже хуже. При этом стоят они дороже, износ на запись у них множится на write amplification (когда диск забит данными, SSD приходится перемещать несколько блоков, чтобы записать один), чем дешевле SSD, тем у неё обычно хуже ресурс (а в отличие от бытового «ой, моя SSD'ка изнашивается» потенциальный износ SSD на сервере видеонаблюдения — вполне объективный вопрос).
                                        Читать дальше →