Тут в последнем посте было про тему Windows95 для BS, если уж на то пошло то вот есть более качественная.
https://github.com/AlexBSoft/win95.css

А если от Windows устали и хочется соскочить, то вам сюда. Правда курс на английском.

Не совсем DevNet, но всё-таки если хотите начать изучать Linux, то бесплатный курс от Cisco Netacad, то что вам нужно. Мое мнение, что без базовых знаний линукса в понимании DevNet все же не обойтись.

Что вы узнаете пройдя этот курс:

1. Поймете основы командной строки Linux (CLI)
2. Выполните практические упражнения с использованием виртуальной машины Linux (предоставляется бесплатно)
3. Определите, подходит ли вам Linux или нет.
4. Научитесь базовой установке и настройке программного обеспечения Linux

Искал что-то подобное!- 🤩
Пройденный этап- 👌
Windows forever!-✌️

Хотите поделиться своим мнением? Добро пожаловать в чат - https://t.iss.one/automate_devnet

#linux #free_course

Инженеры всегда были инженерами, людьми для которых нет проблем.

"Hello, world" на Python и Netmiko. Простой пример, настолько простой, что возможно даже плохой если захотеть использовать его в боевом режиме. В нём нет никакой такой задачи, кроме подключения и использования Netmiko, которую бы нельзя было решить используя менее избыточные инструменты. Как минимум расширения include и exclude в командной строке Cisco и не только это уже регулярное выражение. Во многих современных устройствах можно и полноценные конвейеры строить.

А если хочется что-то посложнее, то SSH отлично позволяет выполнять команды тут же при подключении и выходить после выполнения. Например, вывести все интерфейсы Vlan оставив заголовок (вторая строка в выводе):

$ssh [email protected] "show ip int br" | sed -ne "2p;/vlan/Ip;"

Interface IP-Address Status Protocol
Vlan1 unassigned down down
Vlan15 192.0.2.15 up up

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

Кто-то скажет: "Ага! Вот уже начинаются сложности и даже такой пример с Python может поспорить с нагромождением команд". Конечно, всегда стоит помнить когда остановиться и прекратить писать однострочники в нескольких сотен символов, но тратить всю мощь Netmiko на вывод списка интерфейсов, так себе применение инструмента. Как простейший пример, в рамках первый раз попробовать - всё отлично, именно так и надо начинать, повторять свои ежедневные действия в консоли. В продакшн тянуть такое не стоит.

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

​Махнул не глядя.

На скриншоте не всё поместилось, выше ещё показаны начатые треки, у меня там CCNP SP. Но по сути нововведения ничего не меняют, даже упрощают: раньше было 4 экзамена на этот трек без учёта обязательного CCNA SP, сейчас только два если идти самым коротким путём, которым я скорее всего и пойду. Мой сданный в прошлом году SPROUTE зачёлся, но особой роли уже не играет.

А внизу ещё просроченные сертификаты, там у меня ветка Voice, которую отменили очень давно, точнее заменили на Collaboration что превратило мой CCNA Voice в два сертификата специалиста которые дожили аж до 26 января этого года, до истечения срока давности.

Ещё в новом интерфейсе можно запросто скачать свой сертификат в PDF, раньше надо было заказывать да ещё и оплачивать.

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

​Как в 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 недоступен вследствие той самой аварии, то теряются драгоценные секунды если разрешение имён не выключено, хотя в остальное время он очень даже полезен.