Обширный набор шпаргалок от команд терминала и баз данных, до вариантов использования Си. Не очень подробно, но про всё.

​Как в Google (облачные сервисы) формируют метрики доступности, обзорная статья по работе представленной на симпозиуме NSDI'20. Цель работы показать как формировать и использовать такие метрики которые были бы:

- значимыми, отражали реальное поведение пользователя;
- пропорциональными, адекватно выражали изменения опять же с точки зрения пользователя;
- применимыми, позволяли владельцу системы понимать почему доступность в это время снижалась.

Можно сказать что у них получилось создать новую метрику user-uptime. Вот такого графика как на картинке мне точно не хватает. В работе (не в статье) приводится много формул и примеров метрики на реальных данных, чего вполне должно хватить чтобы перенять опыт Google.

Конференция ещё не закончилась и не все докладчики выступили, но всё уже доступно для чтения, должно быть много интересного.

50 MIOPS, 1,6 Тбайт в секунду, до 10Пбайт в одной стойке. Новая хранилка ClusterStor E1000 от Cray - можно заказывать.

*BSD ламповая система, там даже у root есть настоящее имя. А ещё написано про то зачем используется амперсанд в конце поля полного имени.

sudo для Windows, привыкшим к Linux админам должно пригодиться.

Можно скачать бинарники или воспользоваться скриптом установки, только надо в него заглянуть и поправить каталог назначения.

З.Ы. Пока вспомнил. Как правило я ставлю и использую (как минимум пытаюсь) все инструменты которые упоминаю, некоторые приживаются - за полтора года с PopCom могу только похвалить, реально удобно.

Интересно наблюдать за тем как меняется баланс от: "Используем протоколы и формализованное взаимодействие между частями системы на готовых реализациях, изменяя лишь дозволенные настройки" - условно, "админский" подход. В сторону "программного" подхода: "Формализуем только данные и их форматы и делаем с ними что хотим".

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

На другом конце - я знаю о чём знает или хочет мне сказать соседняя система, я знаю какой результат хочу получить и на основе этого программирую своё поведение. Это уровень самостоятельной реализации системы в терминах действия, а не в терминах описания. Вспомним про SDN - сеть без классических протоколов взаимодействия, в которой напрямую программируется поведение устройства для каждого принятого кадра, а ещё язык P4.

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

Производительность CPU современных сетевых устройств давно доросла до возможности использовать универсальные языки и программные подходы для решения специфических сетевых задач, налету. В то же время, универсальные платформы доросли до производительности передачи трафика специализированных сетевых устройств. Итого в современности, мы можем используя Python получить BGP Flowspec от соседа и сформировать нужные ACL самостоятельно, даже если такая возможность не реализована на данном устройстве. Это видео с коротким описанием проблематики и подхода, кусками использованного кода и настроек, так что финальное решение всё равно придётся писать самостоятельно, главное что это можно сделать.

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

В любой непонятной ситуации смотри дамп трафика - девиз настоящего сетевика. Наверное, стоило посмотреть логи LDAP клиента, но если проблема решена всё сделано правильно. Самый короткий путь тот который знаешь.

Есть у Juniper добротный проект Day One+. Это на случай если ты всю жизнь примусы починял, но вдруг тебе неожиданно понадобилось стать сетевиком, а ты езернета в руках не держал.
Ну то есть это просто набор пошаговых инструкций для совсем зелёных новичков, где расписано и как в стойку железку поставить, и как основные вещи настроить и куда бежать за документацией на все случаи жизни.
Молодцы, одним словом.

А у других вендоров есть нечто подобное?

https://www.juniper.net/documentation/dayoneplus/en_US/day-one-plus

​Marek Majkowski из CloudFlare ускоряет выборку уникальных значений из большого (очень большого списка) с 2 мин до 12 секунд, а потом ещё в два раза до 7 секунд. Делает он это путём реализации новой утилиты, код которой можно найти на GitHub. В статье немного математических терминов, про фильтр Блума надо будет почитать где-нибудь в другом месте, и много профилирования кода, а ещё про кеш и современные процессоры.

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

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

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

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

Про базовые подходы проектирования маршрутизации в опорной сети, в данном случае, для интернет провайдера с радиодоступом, что никак не отражается в смысле статьи. В основном про выбор способов управления трафиком и глубину этого способа - от коммутируемой сети и дальше, плюсы и минусы каждого подхода, без особых подробностей всё на понятийном уровне. Про всякие SD* и SR* не упомянули. Где-то за сценой видны ушки Микротика, но статья не про это.
При том что вендор, несомненно, влияет на расстановку акцентов в подаче материала. Читаешь, например, Cisco MPLS где всё начинается с LDP, а дальше всё остальное. А читаешь Juniper MPLS, а там LDP называют не очень полезным протоколом и вообще речь про него заходит только после того как две главы про RSVP-TE подробнейшим образом расписали. Вот и как тут выбор сделать, тем более правильный.

Ещё один клиент для многих утилит сканирования сети - GoScan. Интерактивный интерфейс, готовый набор команд, база данных с результатами работы. Работает в Linux и для Docker всё готово, куда теперь без него.
Может мне кажется, но в последнее время в поле зрения попадает много обёрток над проверенными годами инструментами, а новых оригинальных инструментов которые на слуху, не видно?

С приходом универсальных инструментов на специализированные устройства происходят интересные казусы. Например, SSH пытается разрешить обратное имя по IP и у него обычно это получается, так как DNS обычно настроен на серверах, чего нельзя сказать про коммутаторы. Поэтому либо настраиваем, либо отключаем: UseDNS no в sshd_config. Похожая, но другая классическая проблема у Cisco, решается по другому.

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

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

​Прямо ухх статья, про Unix-way и вообще философию CLI, что мы потеряли или не потеряли за всё прошедшее время. Классический подход, одна утилита - одна функция, отсюда есть отдельно cat и tac. При этом количество аргументов стандартных утилит выросло иногда в разы. Плохо это или хорошо? Чем отличается в сложности построить конвейер из 10 элементов или применить 10 опций у одной утилиты? Автор достаточно критично проходится по "старой школе", что наверное не плохо, нельзя держаться за реалии 50 летней давности.

С другой стороны, очевидный минус который я вижу это наименование опций командной строки для разных утилит, когда "-L" всякий раз значит что-то разное. Не всегда, но полагаться на то что опции одинаковые для разных инструментов не стоит. И тут разница, запомнить 10 утилит с 5 опциями в каждой, или 5 со 100. Может быть вообще можно обойтись и одной утилитой, но чего не отнять - сложность увеличилась. Наличие конвейера всё же заставляло поставлять более менее стандартизированный поток вывода, иначе не заработает.

Но тут опять стоит согласиться с автором, мало кто запоминает ВСЕ опции. Наличие возможности быстро найти то что нужно нивелирует многие спорные моменты. Да и совместимость никуда не делась, можно писать в old school стиле и всё будет работать.

Сделал себе DoH сервер, на всякий случай, а потом подумал, почему только себе и решил поделиться с вами https://host-correct.ru/doh, чем мы хуже Cloudflare :)

Побочным эффектом запилил munin плагин для Knot Resolver (переделал из Unbound плагина). Быстро не нашёл готового, поэтому немного поразмял мозги.

Не уверен что сервер вытащит больше даже 100 запросов в секунду, поэтому надеяться на него не стоит, для надёжности и безопасности лучше свой поднимать. Логи я отключил, оставил только статистику запросов, конфигурация элементарная, места под кеш практически нет, но пользоваться можно.

Мне очень нравится организация файла конфигурации у Juniper: строгая, иерархическая и структурированная. Правда, как оказалось, после того как у нас появился Juniper, самый не очевидный момент для моих коллег это включение интерфейса из состояния disable. Вот такая конструкция delete interfaces xe-0/0/0 disable, вызывает минимум удивление, а максимум эмоций я описывать не стану. При этом Juniper самый логичный из всех - установить настройку всегда set, убрать настройку всегда delete.

В Нuawei используется undo, чтобы убрать настройку, но там в целом подход больше похожий на Cisco CLI - undo shutdown, включит интерфейс.

У Brocade в контексте интерфейса можно написать как no disable, так и просто enable. Где-то не далеко D-Link у которого есть пара enable/disable для сервисов и конструкция conf ... state disable/enable для интерфейсов.

А вот больше всего удивления от delete interfaces xe-0/0/0 disable. Что-то в этом delete не то для нашего брата админа, ассоциации вызывает другие, может слишком знакомое слово, Juniper на заметку.

Junos маршрутизатор собственными руками? Не вопрос!
Теперь вы можете собрать его используя cRPD и LinuxKit
"На момент написания этой статьи бесплатная пробная версия для cRPD отсутствует" - пишет автор статьи. "Но когда это нас останавливало?"- скорее всего подумали вы.
"Тем не менее, многие из Juniper работают над тем, чтобы cRPD стал доступнее."- ответит вам автор.

Что такое сRPD?
cRPD берет некоторые из лучших частей Junos (RPD, MGD), дезагрегирует и упаковывает их в легкий образ контейнера.

Что такое LinuxKit?
Linuxkit - это "набор инструментов для сборки настраиваемых минимальных, постоянных дистрибутивов Linux".
Он позволяет вам собрать свой собственный легковесный дистрибутив Linux, используя контейнеры.

Пойду приготовлю себе маршрутизатор! - 🔥
Меня это не остановит! -💪
Не, не надо! - 😏

Хотите обсудить? Айда в чат - https://t.iss.one/automate_devnet

#juniper #crdp #linuxkit