ServerAdmin.ru
28.2K subscribers
248 photos
32 videos
10 files
2.58K links
Авторская информация о системном администрировании.

Информация о рекламе: @srv_admin_reklama_bot
Автор: @zeroxzed

Второй канал: @srv_admin_live
Сайт: serveradmin.ru
Download Telegram
🎓 Немного необычная тема для моего канала, хотя косвенно я иногда её затрагиваю. Предлагаю вашему вниманию бесплатный курс на stepik.org на тему написания IT статей:

Статьи для IT: как объяснять и распространять значимые идеи
https://stepik.org/course/101672/

Я люблю писать большие статьи, мне близка эта тема. Хотя давно уже не занимался ею. В прошлом я много писал статей для сайта, а также по заказу на тот же хабр, или просто коммерческие обзоры. Сейчас не занимаюсь этой деятельностью, потому что получить желаемых доход написанием статей у меня не получилось. Рассматривал варианты стать техническим писателем, но все предложения, что получал, по деньгам очень грустные. Они не сопоставимы с практический деятельность по настройке.

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

К чему я всё это. Если хотите научиться хорошо писать материалы по IT, рекомендую этот курс. Там помимо теории, даётся очень много полезных ссылок на различные ресурсы, блоги, площадки, авторов, книги и т.д. Прямо таки кладезь хороших технических текстов.

#обучение #бесплатно
​​Последнее время стала актуальна тема VPN. Расскажу вам по этому поводу про интересный open source проект — Nebula. Авторы называют его scalable overlay networking tool, что для меня затруднительно однозначно перевести. В общем случае это программа для построения связной виртуальной сети поверх физической, в том числе и через интернет.

Термин overlay обычно применяют для больших виртуальных сетей, построенный как бы над обычными. Есть физические сети underlay и виртуальные overlay. В Nebula используется агент, который устанавливается на каждый хост и в зависимости от своих настроек, подключается к тем или иным хостам. Соединения образуются между хостами напрямую (p2p), то есть получается mesh сеть. В этом основное отличие от традиционных VPN сетей, где используются туннели между шлюзами, а все остальные хосты общаются друг с другом посредством шлюзов.

Nebula разработали в Slack и потом выложили в открытый доступ. Авторы инструмента открыли свою компанию, saas сервис, занимаются внедрением и поддержкой. У них, кстати, есть бесплатный тарифный план.

Развернуть Nebula у себя не представляет большой сложности. Простейшая инструкция для запуска есть в самом репозитории. Аутентификация хостов происходит посредством сертификатов, как в openvpn. Так что придётся поднять свой CA и выпускать для клиентов сертификаты. У Nebula всё это есть в комплекте, так что не придётся прибегать к сторонним инструментам.

Пример выпуска CA:
# ./nebula-cert ca -name "Myorganization, Inc"
Сертификата для клиента:
# ./nebula-cert sign -name "laptop" -ip "192.168.100.2/24" \
-groups "laptop,home,ssh"

Тут сразу идёт функциональная привязка к выпущенному сертификату, так что продумать структуру сети нужно до выпуска сертификатов. Потом клиенту передаётся конфиг с сертификатом, где указан IP адрес одного или группы хостов, которые выступают в роли управляющего сервера. Точкой обмена трафиком они не будут. В зависимости от своих настроек, хосты обмениваются трафиком между собой напрямую. Даже если оба клиента находятся за NAT, управляющая нода соединит их напрямую посредством технологии UDP hole punching.

Если я правильно понял принцип работы Nebula, VPN туннели поднимаются динамически между хостами в случае необходимости. При этом используется своя технология на базе обмена ключами Диффи-Хеллмана (ECDH) и шифре AES-256-GCM. То есть это не надстройка над каким-нибудь wireguard или чем-то аналогичным. И всё это создано для построения очень больших сетей из сотен и тысяч хостов.

Nebula немного похожа на Tailscale, только у неё изначально всё готово для установки на своём железе. Нет привязки к облачному сервису. Для Tailscale тоже есть подобный сервер — Headscale. Но его развивают и поддерживают другие люди, не разработчики.

⇨ Сайт / Исходники / Документация / Обзор

#vpn
​​Решил немного развить тему с развлечением в терминале. Сегодня как раз подходящий день для этого. Ниже будет подборка приколов и просто забавных приложений для терминала. А вечером подборка игр.

Cmatrix. Визитная карточка фильма Матрица — набор символов, падающих как водопад, сверху вниз. Эта утилита воспроизводит его у вас в терминале. Живёт в стандартных репах:
# apt install cmatrix
Почитайте man, там много ключей для видоизменения эффектов. Выглядит прикольно, хоть и не так, как в кино. Посмотреть.

MapSCII. Карта мира в терминале. Написана на JS, поэтому живёт в репах nodejs.
# npm install -g mapscii
В убунте через snap можно поставить:
# snap install mapscii
Выглядит необычно и подробно для такого рода программы. Вплоть до отдельных улиц городов можно увидеть. Посмотреть.

Aafire. Разжигает терминальный ASCII огонь. Живёт в репах:
# apt install libaa-bin
Поджигаем:
# aafire
После этого огня у меня все символы в терминале становятся серыми. Не понял, это так задумано или какой-то глюк. Релогин сбрасывает эффект.

Toilet. Преобразует введённые слова в большие символы ASCII. Совершенно не понятно, почему у утилиты такое странное название. Живёт в репах:
# apt install toilet
# toilet туалет
Посмотреть.

Cowsay. С помощью этой утилиты вы можете попросить ASCII корову сказать любую фразу:
# apt install cowsay
# /usr/games/cowsay Hi
Посмотреть. Похожие программы: cowthink, ponysay.

Cal. Терминальный календарь. Рассказывал о нём отдельно. Полноценный календарь. В rpm дистрибутивах пакет называется cal, в deb — ncal:
# apt install ncal
Утилита без всяких шуток может быть полезной. В Centos вроде бы в базовой установке была. Даже устанавливать не надо было. Посмотреть месяц назад, текущий и будущий:
# cal -A 1 -B 1

Rev. Отображает введённый текст в обратном порядке. В Debian присутствует по умолчанию в минимальной установке.
# rev
serveradmin
nimdarevres

Sl. Паровозик в терминале. Писал о нём не так давно.
# apt install sl
По полям, по полям, ASCII-паровозик едет к нам... (поймут только отцы)

Рождественская ёлочка от хостера scaleway в виде bash скрипта. Посмотреть.

Пасхалка в apt-get и apt:
# apt moo

Пасхалка в who:
# who is GOD?

#linux #terminal
​​Подборка консольных игр в Linux. Начнём с классики. Интересно, с этими играми знакомы те, кому сейчас до 25 лет? Я в эти игры играл ещё на приставках, типа денди, и на отдельных карманных устройствах на батарейках с монохромным дисплеем.

Тетрис. Его придумал Алексей Леонидович Пажитнов в 1984 году, работавший в Вычислительном центре Академии наук СССР.
# apt install bastet
Не удержался, и сыграл раунд после написания этих строк 😎

Pacman. Классический pacman. В обычной консоли выглядит немного узко, но играбельно.
# apt install pacman4console
Напомню, кто не знает. Задача скушать все звёздочки и не встретиться с другими движущимися символами.

Snake. Классическая змейка.
# apt install nsnake
Стартовая скорость очень низкая. Захотелось на кнопку Turbo нажать. Когда я программировал что-то подобное в школе на turbo basic, это ускоряло исполнение кода примерно в два раза. Очень любил эту игру на телефоне Nokia 3310.

📌 Переходим к менее массовым играм.

2048. Математическая игра, где сдвигая плитки нужно добиться их объединения с увеличением номинала.
# apt install 2048
Немного непривычно и непонятно. Пришлось пару раз возвращаться к правилам, пока не понял, как тут играть.

Moon Buggy. Очень простая и залипательная игрушка, где особо не надо думать. Вы управляете машинкой, которая едет по луне. Нужно перепрыгивать ямы разной длины.
# apt install moon-buggy

Ascii-patrol. Очень навороченная и красивая консольная игра. Автор упаковал её в snap, предлагает устанавливать оттуда:
# snap install ascii-patrol
Либо можете в html версию поиграть.

Space Invader. Вам надо управлять корабликом, стрелять по вражеским кораблям и уворачиваться от их выстрелов.
# apt install ninvaders

ZAngband. Терминальная rpg. Очень навороченная, где куча классов, специальностей. Надо качать персонажа, улучшать навыки. Лазить по подземелью, собирать предметы, улучшать оружие и т.д.
# apt install zangband (нужен non-free репозиторй)
В универе сокурсник постоянно играл в эту игру на парах по Linux и программированию. Я не мог понять, как эта консольная штука может быть игрой, да ещё интересной.

BSD games. Куча старых консольных игр, портированных из BSD систем.
# apt install bsdgames
Там есть аналог змейки - worm, аналог тетриса - tetris-bsd, монополия - monop, пасьянс - canfield, нарды - backgammon и другие.

Sudoku. Классическая Судоку, которую часто печатают во всяких сборниках и журналах.
# apt install sudoku

#игра #подборка
​​В операционной системе на базе Linux существуют два разных способа назначения прав доступа к файлам. Не все начинающие администраторы об этом знают. Недавно один читатель попросил помочь настроить права доступа к файловой шаре samba. Он описал задачу на основе того, как привык раздавать права на директории в Windows. В Linux у него не получалось настроить так же в рамках стандартных прав доступа через локальных пользователей, групп и утилит chown, chmod.

В Linux, помимо основных прав доступа, которые вы видите при просмотре директории с помощью ls -l, существуют дополнительные списки доступа ACL (access control list). Они позволяют очень гибко управлять доступом. По умолчанию инструменты для управления этими списками в минимальной установке Debian отсутствуют. Устанавливаются так:
# apt install acl

После установки данного пакета у вас появятся две основные утилиты, которые будут нужны для управления доступом: getfacl - посмотреть права доступа, setfacl - установить права доступа.

Я не буду сейчас подробно расписывать как всем этим пользоваться. В интернете масса руководств. Просто знайте, что в Linux правами на файлы и директории можно управлять практически точно так же, как в домене Windows. Есть нюансы и различия, но в базовых случаях несущественные. Если добавить Linux сервер с Samba и ACL в домен, то через систему Windows можно будет управлять доступом к файлами через её свойства папки с галочками и списками групп.

Пример того, как всё это может выглядеть, есть в моей статье:
https://serveradmin.ru/nastroyka-samba-s-integratsiey-v-ad/
Она очень старая и скорее всего уже неактуальна в технической части. Я сам давно файловые сервера в Linux в домене не настраивал и не эксплуатировал. Но общее понимание картины можно получить. Соответственно, вместо Microsoft AD может выступать любой другой LDAP каталог пользователей и групп.

Подскажите, кто скрещивает Linux с Windows. На текущий момент нет проблем с добавлением Linux в AD под управлением свежих Windows Server? Интеграция упростилась или усложнилась? Давно уже не слежу за этой темой. Я где-то видел новость, что Ubuntu для платных подписчиков выпустила какой-то свой инструмент для упрощения работы в AD.

#linux #fileserver
​​В комментариях как-то раз увидел упоминание утилиты f*ck. Заинтересовался. Думаю, что это может быть, ни разу не слышал. Прям так и загуглил со звёздочкой. Оказалось, что речь идёт об open source проекте The Fuck.

Было очень любопытно, что же скрывается под таким неговорящим названием. Причём явно что-то популярное и полезное, потому что 77.7k звёзд на гитхабе. Оказалось, что это утилита для исправления опечаток или неполностью набранных команд.

Показываю сразу на примерах. Допустим, вы устанавливаете софт через пакетный менеджер и забыли написать sudo:
# apt install mc
Появляется ошибка:
E: Could not open lock file /var/lib/dpkg/lock -
open (13: Permission denied)
Вы расстраиваетесь и материтесь, потому что нервы у айтишников никудышные. Сидячая работа, стрессы, кофе и т.д. Пишите в консоль с досады:
# fuck
TheFuck понимает ошибку и предлагает выполнить команду с учётом исправления.
# sudo apt-get install mc

TheFuck распознаёт популярные ошибки, опечатки, не только в командах, но и в их ключах, параметрах. Например:
# git push
fatal: The current branch master has no upstream branch.
# fuck
# git push --set-upstream origin master
То есть запустили гит пуш, забыли обязательные параметры, fuck добавил дефолтные параметры для этой команды.

Ещё больше примеров можно в репе посмотреть. Все исправления описаны правилами, которые лежат в соответствующей директории. Правила написаны на python, можете изменить готовые или написать свои. Например, есть правило для chmod. Если в консоли запускается скрипт через ./ и в выводе появляется сообщение permission denied, что типично, если у файла нет прав на исполнение, fuck исправляет это, добавяля права через chmod +x.

Больше всего правил написано для git. Судя по всему этот инструмент писался для разработчиков и немного девопсов, поэтому так много звёзд на гитхаб.

Если будете пробовать в Debian, утилита живёт в стандартных репах:
# apt install thefuck
Автор пакет заботливо отключил все правила для sudo. На всякий случай. По умолчанию бинарники ставятся в $HOME/.local/bin, поэтому надо добавить этот путь в PATH:
# export PATH="$PATH:$HOME/.local/bin"

Если что, матершину не одобряю. Сам не матерюсь.

#linux #консоль
​​Сегодня расскажу вам про современный функциональный инструмент для управления парком рабочих станций и серверов с разными ОС. Речь пойдёт про Fleetdm. В рунете вообще не нашёл не то что информации по настройке, но даже упоминаний. Во всём разбирался сам на основе документации. Установил себе сервер и два управляемых хоста: Windows и Linux.

Fleetdm — это open source клиент-серверное приложение. Устанавливаете сервер, на управляемые хосты агенты. Поддерживаются системы: Windows, Linux, Macos. Раскатка агентов максимально простая — заранее готовится преднастроенный установщик. Далее он устанавливается на хост и тот появляется в панели управления.

С помощью Fleetdm можно управлять настройками хостов и проверять всё установленное ПО на наличие уязвимостей. Для выборки используется известный open source язык запросов osquery, который разработан специально для этих целей. С его помощью можно делать всевозможные выборки и к ним применять какие-то действия или политики. Вот простой пример, как это работает. Допустим, вы хотите найти все хосты и учётные записи, где установлена оболочка bash. Запрос выглядит так:
SELECT * FROM users WHERE shell='/bin/bash';

Для Windows запросы схожи. К примеру, найдём всех, у кого разрешён SMB1 на клиенте:
SELECT 1 FROM windows_optional_features \
WHERE name = 'SMB1Protocol-Client' AND state != 1;
Описание запросов хорошо документировано. Писать их с помощью подсказок не сложно.

Бесплатная версия Fleetdm не предполагает встроенных средств для автоматизации выставления настроек или обновления уязвимого ПО. Вы можете создавать политики, которые будут в режиме реального времени проверять хосты. И если находят расхождения в политиках или уязвимое ПО, уведомляют об этом. С помощью API и вебхуков вы можете сами решать проблемы, например с помощью Ansible. Либо автоматически создавать задачи в Jira и Zendesk. В бесплатной версии настроены эти интеграции.

Теперь постараюсь кратко рассказать, как это всё быстро развернуть в тестовой среде, чтобы получилось быстро. В продуктив лучше поставить руками, есть подробная инструкция. Для работы сервера обязательно нужен TLS сертификат. Желательно валидный. С этим я провозился дольше всего, так как настраивал всё в локалке с использованием самоподписанного сертификата. Подготовим его:
# mkdir fleet
# openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes \
-keyout fleet/server.key -out fleet/server.cert -subj "/CN=fleet.example.com" \
-addext "subjectAltName=DNS:fleet.example.com"
# chown -R 100:101 fleet/

Теперь берём минимально необходимый набор софта (Mysql+Redis) и запускаем Fleetdm через docker-compose (возьмите свежую 2-ю версию):
# docker-compose up

Дожидаемся запуска, идём на fleet.example.com:8080, создаём учётку. На всех управляемых хостах имя fleet.example.com должно резолвиться в IP адрес. Это важно.

Теперь качаем fleetctl последней версии под Linux. Это утилита, которая генерирует установщик для хостов. Распаковываем и создаём установщики под deb и windows. Используем тот же сертификат сервера, secret смотрим в веб интерфейсе, в разделе hosts.

# wget https://github.com/fleetdm/fleet/releases/download/fleet-v4.32.0/fleetctl_v4.32.0_linux.tar.gz
# tar xzvf fleetctl_v4.32.0_linux.tar.gz
# cd fleetctl_v4.32.0_linux
# ./fleetctl package --type=msi --fleet-url=https://fleet.example.com:8080 \
--enroll-secret=jlBXb1LUMo4/0Pn1cHXnVKqziMo87CgN --fleet-certificate=server.cert
# ./fleetctl package --type=deb --fleet-url=https://fleet.example.com:8080 \
--enroll-secret=jlBXb1LUMo4/0Pn1cHXnVKqziMo87CgN --fleet-certificate=server.cert

Передаём установщики на целевые хосты. Я запустил http сервер и скачал пакеты:
# python3 -m http.server 8181

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

Программа мне понравилась, достойна полноценной статьи. Может напишу. Бесплатную, мультисистемную, с похожей функциональностью не припоминаю.

Сайт / Исходники

#управление #security #devops
Буквально на днях узнал, что в bash квадратная скобка [ и утилита test это одно и то же. Точнее, я вообще не знал, что существует эта встроенная утилита. Всегда и везде в скриптах видел и сам использовал именно скобку.

# type test
test is a shell builtin

# type [
[ is a shell builtin

Синтаксис с квадратными скобками в bash терпеть не могу. Всё время, когда пишу, думаю, кто же это всё придумал. Вообще неинтуитивно и нечитаемо. Простой пример. Создадим файл:
# touch file.txt
Сделаем проверку, что он существует, как я обычно это делаю:

#!/bin/bash

if [ -e file.txt]
then
 echo "File exist"
else
 echo "There is no testfile"

А теперь то же самое, только через test:

#!/bin/bash

if test -e file.txt
then
 echo "File exist"
else
 echo "There is no testfile"

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

Bash максимально непонятный язык программирования. Если неподготовленному человеку показать какой-то более ли менее сложный скрипт на bash, он ничего не поймёт. Но если посмотреть код python или go, то он вполне читаемый. Помню как-то писал про программу, которая делает обфускацию bash скриптов. Понравился к ней комментарий, где человек написал, что разве bash коду нужна какая-то обфускация? Его и так невозможно понять. Пример:

ps axo rss,comm,pid | awk '{ proc_list[$2] += $1; } END { for (proc in proc_list) { printf("%d\t%s\n", proc_list[proc],proc); }}' | sort -n | tail -n 10 | sort -rn | awk '{$1/=1024;printf "%.0fMB\t",$1}{print $2}'

Что тут происходит? 😲 Всего-то посмотрели топ 10 пожирателей оперативной памяти на сервере. Кстати, скрипт сохраните, пригодится.

Не знаю, в чём феномен bash и почему он стал таким популярным в повседневном использовании. На нём трудно и муторно писать и отлаживать. Я лично не могу сходу написать что-то на bash. Мне нужно сесть, подумать, посмотреть, как я что-то похожее делал раньше, вспомнить синтаксис условий, вспомнить, чем одинарные скобки отличаются от двойных, посмотреть логические операторы. И только после этого я готов с копипастом что-то писать.

А у вас какие с bash отношения?

#bash #script
​​Разбираю ещё один документ от CIS с рекомендациями по настройке Docker. Напомню, что ранее я уже делал выжимки по настройке Nginx, MySQL, Apache, Debian 11. Используя эти руководства нелишним будет освежить свои инструкции и принять некоторую информацию к сведению.

📌 Директорию для информации /var/lib/docker рекомендуется вынести на отдельный раздел. Docker постоянно потребляет свободное место, так что переполнение раздела нередкое явление.

📌 У Docker высокие полномочия для доступа к хостовой системе. Следите за тем, чтобы в системной группе docker не было лишних пользователей.

📌 Для повышения безопасности рекомендуется настроить аудит службы docker, например с помощью auditd. Ставим службу:
# apt install auditd
Добавляем правило в /etc/audit/rules.d/audit.rules:
-w /usr/bin/dockerd -k docker
Перезапускаем службу:
# systemctl restart auditd
Для повышенной безопасности можно настроить аудит и за файлами и директориями Docker, за конфигурационными файлами, за юнитом systemd, за сокетом. Это общая рекомендация для служб, которые работают с правами root.

📌 Разделяйте контейнеры по отдельным сетям для межконтейнерного взаимодействия. Если этого не делать, они будут взаимодействовать через общий системный бридж, который docker создаёт по умолчанию.

📌 Включите уровень логирования службы "info", добавив в файл конфигурации /etc/docker/daemon.json параметр:
"log-level": "info"
Для повышения безопасности логи имеет смысл хранить где-то во вне. Их можно направить по syslog. Пример:
{
 "log-driver": "syslog",
 "log-opts": {
  "syslog-address": "tcp://192.xxx.xxx.xxx"
 }
}

📌 Если используете подключение к службе Docker по TCP, не забудьте настроить аутентификацию по TLS и ограничьте сетевой доступ.

📌 Используйте параметр no-new-privileges при создании контейнеров, либо добавьте этот параметр в настройку службы по умолчанию.
"no-new-privileges": true
Это предотвратит повышение привилегий в контейнере от пользователя до root. Подробнее тут.

📌 Включите параметр live-restore:
"live-restore": true
Это позволит не останавливать контейнеры в случае остановки самой службы docker, что позволит обновлять её без остановки сервисов. По умолчанию он отключен.

📌 Отключите использование userland-proxy.
"userland-proxy": false
В подавляющем большинстве случаев для проброса портов в контейнеры используется NAT. Отключение прокси уменьшает вектор атак.

📌 Чаще всего файл с настройками /etc/docker/daemon.json по умолчанию отсутствует и вы его создаёте сами, когда нужно задать те или иные параметры. Проследите, чтобы доступ на запись к нему имел только root (root:root 644).

📌 Не используйте без крайней необходимости в контейнерах пользователя root. Хорошая практика запускать всё от обычного пользователя.

📌 Ограничивайте использование памяти контейнерами так, чтобы они не могли использовать всю доступную память хоста. Для этого запускайте их с параметром --memory и задайте объём, к примеру, 1024m.

📌 Ограничивайте количество попыток перезапуска контейнера в случае ошибок. То есть не запускайте их с параметром --restart=always. Используйте вместо этого --restart=on-failure:5. Будет сделано 5 попыток запуска в случае ошибки.

Было много советов по написанию DockerFile. Не стал их разбирать, так как мне кажется, это отдельная тема, которая к самой службе не имеет отношения. Также было много советов по запуску контейнеров. Например, не запускать там службу sshd, не монтировать системные директории и т.д. Это тоже отдельная тема, пропускал такие рекомендации.

К данной заметке будет актуальна ссылка на автоматическую проверку контейнеров с помощью Trivy и исправление с помощью Copacetic. Я написал небольшую статью:
Проверка безопасности Docker образов с помощью Trivy

Данный список составил на основе переработки вот этого документа: CIS Docker Benchmark v1.5.0 - 12-28-2022. Там подробное описание с обоснованием всех рекомендаций.

#cis #docker
​​Вы когда-нибудь задумывались, чем в Unix отличаются директории /bin, /sbin, /usr/bin, /usr/sbin, /usr/local/{bin,sbin}? Я давно задавался этим вопросом. Точно помню, что несколько лет назад разбирался с этой темой, но уже забыл, к чему пришёл. Решил ещё раз поднять её и поделиться с вами, чтобы и самому запомнить.

Отдельно ещё стоит директория /usr/loca/etc. Я начинал изучение Unix с Freebsd. Все конфиги установленных программ по умолчанию были в /usr/loca/etc. Это было удобно. Так как всё системное в /etc, а всё, что поставил ты, в /usr/loca/etc. Потом непривычно было на Linux переходить, где директория /usr/loca/etc вообще не используется.

Вообще, на эту тему есть много различных мнений. В том же Debian можно запустить:
# man hier
И прочитать про иерархию файловой системы. Там сказано:
/bin - каталог, содержащий исполняемые программы, необходимые для работы в однопользовательском режиме и для запуска или ремонта системы.
/sbin - как и /bin, содержит команды, необходимые для запуска системы, но, как правило, не запускаемые обычными пользователями.
/usr/bin - основной каталог для исполняемых программ. Большая часть программ, не требующихся для загрузки или для ремонта системы, не устанавливаемых локально и запускаемых обычными пользователями, должна быть помещена в этот каталог.
/usr/sbin - каталог, содержащий исполняемые программы для системного администрирования, не относящиеся к процессу загрузки, запуску /usr или ремонту системы.
/usr/local/bin - локальные исполняемые файлы.
/usr/local/sbin - локальные программы для системного администрирования.

Вроде объяснили, но всё равно не понятно, а почему именно такая иерархия. Есть такое мнение на этот счёт. Разработчики Unix в далёком 71-м году в какой-то момент проапгрейдили комп и получили 2 диска вместо одного. Когда ОС разрослась и перестала помещаться на первый диск, часть данных решили перенести на второй диск, где хранились данные пользователей, поэтому раздел назвали /usr (от слова user). Они продублировали на этом разделе все необходимые для ОС директории, в том числе bin и sbin. И всё новое складывали на новый диск, так как на старом не осталось места. Но при этом, чтобы во время загрузки иметь возможность смонтировать диск с /usr, программы типа mount обязательно жили в /bin на первом диске.

Такая есть история появления раздела /usr. С директорией /usr/local уже более ли менее понятно по смыслу. Туда кладётся всё то, что относится к конкретной локальной системе, а не дистрибутиву. В Freebsd именно так и было и это удобно. В Linux почему-то это не поддержали. Там обычно каталог /usr/local пустой.

В Debian 11 /bin и /sbin это символьные ссылки на /usr/bin и /usr/sbin. В rpm дистрибутивах то же самое уже давно. Так что в целом вся эта историческая иерархия фактически не поддерживается. Па факту всё живет в /usr. Было бы неплохо, если бы это всё привели к какому-то единому виду и распрощались с анахронизмами. А то неудобно с кучей каталогов, в которых уже не осталось смысла. Единственное, я бы идею с local поддержал и распространил.

#linux
Утилиту lsof в дистрибутивах Linux чаще всего используют для просмотра открытых файлов. Я и сам так делаю, и много материалов на эту тему видел. Да и название у неё говорящее. Оно как раз образовано от фразы list open files.
Тем не менее, её можно использовать не только для этого.

 Но сначала про основную функциональность. Лично я чаще всего запускаю lsof для просмотра открытых файлов, которые удалили, но забыли закрыть файловый дескриптор. Например, наживую удалили лог nginx или docker и не перезапустили сервис. В итоге файла нет, а место он занимает. Такие файлы будет видно вот так:
# lsof | grep '(deleted)'
или так:
# lsof +L1

 Смотрим кем и что конкретно открыто из файлов в указанной директории:
# lsof +D /var/log

 Смотрим открытые файлы конкретного пользователя:
# lsof -u user
Часто бывает нужно быстро узнать, сколько файлов у него открыто, чтобы понять, если с ним проблема или нет:
# lsof -u user | wc -l
А теперь то же самое, только наоборот исключим открытые файлы пользователя:
# lsof -u^user | wc -l
Рассмотрим ситуацию, когда под пользователем плодятся процессы, которые открывают кучу файлов и нам всё это надо быстро прибить. Добавляем ключ -t к lsof, который позволяет выводить только PID процессов. И отправляем вывод в kill:
# kill -9 `lsof -t -u user`

 Файлы, открытые конкретным процессом, для которого указан его PID. Очень востребованная функциональность.
# lsof -p 94169

 А теперь немного того, что от lsof не ожидаешь. Список TCP соединений, причём очень наглядный и удобный для восприятия.
# lsof -ni

 Смотрим подробную информацию о том, кто открыл 80-й порт:
# lsof -ni TCP:80

 Список TCP соединений к конкретному IP адресу:
# lsof -ni TCP@172.29.139.228

 Список TCP соединений конкретного пользователя:
# lsof -ai -u nginx

 Помимо TCP, можно и UDP соединения смотреть:
# lsof -iUDP

Публикацию имеет смысл сохранить в закладки.

#linux #terminal #perfomance
​​Вчера немного успел застать вебинара Ребрейн про OpenVPN. Попал на самый конец, но всё равно успел получить очень полезную для себя информацию, которой поделюсь с вами.

1️⃣ Первое прям открытие для меня — параметр ccd-exclusive. Если установлен этот параметр, то пользователь даже при наличие актуального сертификата сможет пройти аутентификацию только в том случае, если для него существует файл конфигурации пользователя в директории, заданной параметром client-config-dir.

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

С помощью ccd-exclusive можно отключать пользователей, просто удаляя их файл конфигурации. Я лично их почти всегда использую. Даже если там нет отдельных параметров, привык создавать эти файлы пустыми, чтобы для каждого пользователя был его файл конфигурации. На основе этих файлов делаю мониторинг подключений openvpn.

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

Лет 10 активно использую openvpn, а этот параметр никогда не попадался на глаза. Не знал, что так можно было сделать.

2️⃣ Работы по переводу OpenVPN из контекста пользователя в ядро Linux ведутся. Более того, модуль ядра уже написан и он реально работает. Пока ещё его не добавили в популярные дистрибутивы. Скорее всего это рано или поздно состоится. Уже сейчас можно скачать исходники модуля, скомпилировать их и всё заработает с некоторыми ограничениями по параметрам. К примеру, при обработке ядром не работает сжатие.

Поясню, в чём тут проблема. OpenVPN работает в пространстве пользователя, в отличите от WireGuard, которая обрабатывается напрямую в ядре Linux. Этим объясняется её быстродействие. Разработчики OpenVPN озадачились и решили тоже перенести обработку в ядро и написали свой модуль для этого. Так что в скором времени большой разницы в скоростях между OpenVPN и Wireguard не должно быть.

#openvpn
С памятью в Linux всё сложно. Многие не понимают, как в принципе её смотреть и на какое конкретно значение обращать внимание. Особенно тяжело разбираться в этом после такого родного и понятного диспетчера задач в Windows, который чётко показывает, сколько у тебя памяти использовано и сколько свободно. В Linux использование памяти процессами — сложный вопрос. Вы не сможете просто запустить какую-то программу и сразу понять, что у нас с памятью процесса.

В заметке речь пойдёт о том, как посмотреть, что конкретно занимает память в каком то процессе. Возьмём для примера Nginx или Php-fpm. У них много модулей, поэтому бывает интересно заглянуть, а сколько каждый из них может потреблять памяти.

Для этого сначала посмотрим PID материнского процесса:
# ps ax | grep nginx

А теперь смотрим потребление памяти с помощью pmap. Эта утилита обычно есть в стандартном системном наборе.
# pmap 1947 -p

Если я правильно понимаю, то данная команда в самом низу показывает всю виртуальную память процесса (VSZ или VIRT), которая включает в себя в том числе и библиотеки, которые могут быть разделены между разными процессами, а также то, что в swap. То есть эта такая условная метрика, с которой не понятно, что делать. Мастер процесс Nginx и все его рабочие процессы будут занимать одну и ту же виртуальную память.

Если использовать ключ -x, то увидим ещё и резидентную память (RES или RSS).
# pmap 1947 -x

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

Ключ -d добавляет ещё одну метрику writeable/private:
# pmap 1947 -d

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

Информацию pmap берёт из /proc/PID/smaps и превращает её в удобочитаемый формат.

Если я в чём то заблуждаюсь или вам есть чем дополнить данную заметку, поделитесь информацией. Тема с памятью в Linux замороченная, так что иногда мне кажется, что не понимаю, как там всё устроено и просто забиваю на это, добавив память виртуалке, или явно ограничив какой-то сервис.

#linux #terminal
Увидел на неделе вот этот мем с девопсом. Не знаю почему, но в голове сразу же возникла идея, что тут не хватает продолжения со словом девопёс. Решил реализовать.

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

Я всегда думаю, кто те люди, которые сами придумывают мемы. Никого не знаю, кто бы это делал. Вижу только, как все репостят одно и то же друг у друга. Но кто генерирует всё это в товарных количествах, не понимаю. Может уже давно ИИ это делает, а не люди? Откуда все эти мемы берутся в пабликах и группах?

#мем
🎓 Рекомендую вам очередной бесплатный курс по Stepik. Я его увидел в резюме одного системного администратора. За курс дают именной сертификат и он его решил добавить к себе. Я уже как-то говорил, что это не такая плохая идея, если у тебя есть какие-то другие, более значимые сертификаты с экзаменами. Разбавить его другими для подтверждения знания предметной области, думаю, лишним не будет.

Введение в базы данных

Курс ориентирован на начинающих программистов, но системным администраторам очень полезно, а зачастую жизненно необходимо, разбираться в SQL и в работе СУБД. С ними приходится сталкиваться повсеместно. Ну и написание простых SQL запросов тоже лишним не будет. Не так уж и редко приходится это делать. В простых случаях можно спастись поиском готовых выражений, но даже в этом случае лучше понимать, что ты делаешь.

Особенное внимание рекомендую уделить индексам. Я как-то писал о них заметку. Иногда проблему с производительностью СУБД можно решить добавлением индексов, про которые просто все забыли, либо разработчиков давно уже нет и за базой никто не следит. В общем случае индексы делают разработчики сами. Это если понимают, что это такое.

В курсе также немного захватывают NoSQL базы: Redis и MongoDB, что сейчас администраторам и девопсам очень актуально, так как эти базы популярны не менее SQL.

#обучение #бесплатно
На днях вышел релиз Debian 12 Bookworm. Для меня это не стало сюрпризом, так как недавно я уже смотрел эту версию и проверял, как проходит обновление с прошлого релиза. У меня уже довольно много серверов под управлением Debian, так что вопрос меня касается напрямую.

Решил не откладывать задачу на потом и сразу рассмотреть изменения новой версии. Я написал подробную статью с обновлением с 11-й версии на 12-ю. Постарался рассмотреть наиболее значимые моменты обновления в соответствии с рекомендациями самих разработчиков из заметки Upgrades from Debian 11 (bullseye).

https://serveradmin.ru/kak-obnovit-debian-11-do-debian-12-bookworm/

Из основных нововведений, помимо обновления пакетов, я отметил следующие:

В установочные образы включили некоторые прошивки из репозитория non-free. Это сделано для лучшей поддержки железа во время установки. Debian всегда очень внимательно относился к проприетарному софту, выделяя его в отдельный репозиторий non-free. В этом релизе решили сделать некоторые исключения. Поэтому добавлен ещё один репозиторий для проприетарных прошивок non-free-firmware.

В Debian 12 добавлен пакет ksmbd-tools, который реализует функциональность файлового сервера на базе протокола SMB3. Сервер работает на базе модуля ядра Linux. Подобная реализация более эффективна с точки зрения производительности, потребления памяти и интеграции с расширенными возможностями ядра. При этом ksmbd не претендует на полноценную замену Samba. Скорее как расширение для неё.

По умолчанию не используется rsyslog для записи системных логов. Вместо этого предлагают использовать journalctl для просмотра логов systemd. Если хотите (а мы хотим) по старинке системные логи в текстовом виде в /var/log, установите пакет system-log-daemon.

Из дистрибутива выпилили утилиту which, которая объявлена устаревшей. Вместо неё предлагают использовать type. Это приведёт к поломке многих скриптов, где часто используют which для определения полного пути к бинарнику. Не забудьте установить вручную whitch, если она у вас используется.

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

С полным списком можете ознакомиться в официальной новости или переводе на opennet. За что лично мне нравится Debian, так это за его стабильность. В нём мало каких-то революционных изменений ради изменений. К примеру, сколько я знаю Debian, ещё со времён 6-й версии, у него не менялся интерфейс установщика. В этом просто нет смысла. Всё, что нужно в плане функциональности, там есть. Нет смысла менять то, что хорошо работает.

Я один свой сервер уже обновил, всё прошло штатно. Остальной прод торопиться обновлять не буду. Подожду месячишко, другой.

Скоро наверное Proxmox свою новую версию выкатит. Он обычно подгоняет свои релизы под релизы Debian. Я уже видел инфу про появление 8-й беты.

#debian
​​Хочу дать пару простых советов, которые не все знают и используют, но они могут сильно упростить жизнь при работе со стандартными утилитами Unix в консоли.

1️⃣ Первое это символ ^, который означает начало строки. Например, можно в каком-то конфиге исключить все строки с комментариями, которые начинаются на #:
# grep -E -v '^#' nginx.conf
Тут важно именно в начале строки найти #, потому что он может быть и в рабочей строке конфига, когда комментарий стоит после какого-то параметра, и его убирать не надо.

Когда проверял этот пример, заметил, что в стандартном пакете Nginx в Debian, конфиг по умолчанию включает в себя комментарии, где в начале строки идёт табуляция, потом #. Соответственно, пример выше не помог избавиться от комментариев. При этом в консоли bash вы просто так не введёте табуляцию в строку. Чтобы это получилось, необходимо ввести команду выше, навести указатель на символ сразу после ^, нажать Ctrl-V и потом уже на tab. Таким образом вы сможете найти все строки, которые начинаются с табуляции и символа #. Это очень удобно чистит конфигурационные файлы от комментариев.
# grep -E -v '^ #' nginx.conf
Получится что-то типа такого, но если вы скопируете эту команду, то она у вас не сработает. Нужно именно в своей консоли нажать Ctrl-V и tab.

Также символ начала строки удобно использовать в поиске, когда надо найти что-то по началу имени файла.
# ls | grep ^error
error-windows-10-share-110x75.png
error-windows-10-share-110x75.png.webp
error-windows-10-share-150x150.png
В этой директории были файлы со словом error не только в начале имени.

2️⃣ Второй символ $, который означает конец строки. Можно сразу же продолжить последний пример. Там есть файлы с двойным расширением. Это пример с реального веб севера, где модуль конвертации файлов в webp породил такого рода имена файлов. Выведем файлы только с расширением png. Если действовать в лоб, то получится вот так:
# ls | grep .png
error-windows-10-share-110x75.png
error-windows-10-share-110x75.png.webp
error-windows-10-share-150x150.png

А если c $, получим то, что надо:
# ls | grep .png$
error-windows-10-share-110x75.png
error-windows-10-share-150x150.png

Можно совместить:
# ls | grep ^error | grep png$

А вместе символы ^$ означают пустую строку, что тоже удобно для чистки конфигурационных файлов. Удалим строки, начинающиеся на # и пустые:
# grep -E -v '^#|^$' nginx.conf

#bash #script
​​В выходные просматривал тематические ролики из youtube, которых накопилось некоторое количество. В одном из них увидел упоминание веб интерфейса для Ansible. Речь идёт про ролик: This web UI for Ansible is so damn useful!. Я сразу обратил на него внимание и запомнил, чтобы посмотреть, когда будет время.

В видео речь идёт про Ansible Semaphore. Я видел недавно его упоминание в некоторых TG каналах. Подумал, что выкатили какой-то новый продукт, поэтому на него обратили внимание. Но на самом деле нет. Это старый open source проект из 2015 года. Ранее о нём не слышал, поэтому решил посмотреть, что это такое. Специально никогда не искал веб интерфейс для Ansible, как-то не было необходимости. Вообще не знаю ни одного бесплатного решения для этой задачи.

Как я уже сказал, Ansible Semaphore — open source проект, написанный на чистом Go, а веб интерфейс с примесью Vue. С его помощью можно создавать и запускать плейбуки, превращая всё это в подобие CI/CD системы на минималках. То есть это для тех, кому не надо GitLab или Jenkins, но хочется автоматизации на базе ansible.

Для понимания возможностей Ansible Semaphore, покажу, какие там реализованы сущности. Тогда станет понятно, что он умеет. Там реализованы:
Задачи, для запуска плейбуков.
Шаблоны для этих задач.
Репозитории для подключения кода плейбуков и приложений.
Инвентарь, то есть список серверов, для которых можно выполнять задачи.
Хранилище ssh ключей и переменных.

Посмотреть всё это можно в публичном demo:
⇨ https://demo.ansible-semaphore.com

Работает всё это как обычная CI/CD система. Подключаем репозиторий с приложением, репозиторий с плейбуками. Создаём задачу, которая следит за репозиторием приложения и в случае коммита выполняет какие-то плейбуки из репозитория с ними.

Настроить всё это дело в Ansible Semaphore легко. Настроек немного, можете ознакомиться сами в Demo. Я посмотрел видео, чуток почитал доков (там совсем немного, сразу понятна последовательность действий) и посмотрел, как это реализовано в демке.

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

У меня для личного использования есть отдельная виртуалка с ansible, откуда я запускаю все свои плейбуки. Туда как раз будет уместно поставить Ansible Semaphore.

⇨ Сайт / Исходники

#ansible #devops
​​Автор классного ютуб канала RomNero выпустил подробное видео с разбором чат-сервера на базе протокола [matrix]. Я делал по нему заметку пару лет назад, а лет пять назад тестировал и писал статью. Ссылку не даю, так как нет смысла. Она уже сильно устарела.

Тема чатов всегда актуальна и жива, так как в среде self-hosted решений нет явного лидера. Приходится выбирать из множества имён. Я делал подборку бесплатных вариантов самых известных решений.

Недавно я успешно внедрил в небольшой компании (60-70 сотрудников) Rocket.Chat. Уже накопился некоторый опыт по настройке, поддержке, обновлению, бэкапу и т.д. Думаю, ещё немного подожду и напишу подробную статью. У этого решения есть как плюсы, так и минусы. Я остановился на нём, потому что он популярен, отзывы в целом неплохие. Плюсов больше чем минусов. Субъективно, мне кажется это наиболее подходящим вариантом на текущий момент по совокупности факторов.

Возвращаюсь к видео: Matrix messenger. Лучшая, бесплатная и ДЕЦЕНТРАЛИЗОВАННАЯ сеть для общения. Я его посмотрел целиком, было интересно, хотя почти вся информация была мне известна. Но если вы не знакомы с этим решением, то рекомендую.

Автор объяснил принцип работы протокола Matrix и чат-сервера на его основе Synapse. Он подробно разобрал установку и настройку сервера и клиентов, начиная от создания DNS записей и заканчивая просмотром логов для решения проблем.

Со стороны решение на базе Matrix выглядит привлекательно. Лично меня останавливает от его использования мало реальных отзывов и личного опыта тех, кто его использовал. Не понятно, насколько в итоге это всё удобно за пределами тестовых лабораторий, стендов и заметок с обзорами. По конкурентам такие отзывы и опыт есть (Mattermost, Zulip, Rocket.Chat).

Если у вас есть опыт внедрения и использования этого чат-сервера, поделитесь информацией. Ну а если вы подбираете себе решение для внедрения, то обратите внимание на Matrix.

#chat
Провёл небольшое исследование на тему того, чем в консоли bash быстрее всего удалить большое количество директорий и файлов. Думаю, не все знают, что очень много файлов могут стать большой проблемой. Пока с этим не столкнёшься, не думаешь об этом. Если у тебя сервер бэкапов на обычных дисках и надо удалить миллионы файлов, это может оказаться непростой задачей.

Основные проблемы будут в том, что либо команда на удаление будет выполняться очень долго, либо она вообще не будет запускаться и писать что-то типа Argument list too long. Даже если команда запустится, то выполняться может часами и вы не будете понимать, что происходит.

Я взял несколько наиболее популярных способов для удаления файлов и каталогов и протестировал скорость их работы. Среди них будут вот такие:
# rm -r test/
# rm -r test/*
# find test/ -type f -delete
# cd test/ ; ls . | xargs -n 100 rm #только для файлов работает
И последняя команда, ради которой всё затевалось:
# rsync -a --delete empty/ test/
Мы создаём пустой каталог empty/ и копируем его в целевой каталог test/ с файлами. Пустота затирает эти файлы.

Я провёл два разных теста. В первом в одном каталоге лежат 500 тыс. файлов, во втором создана иерархия каталогов одного уровня, где в каждом лежит немного файлов. Для первого теста написал в лоб такой скрипт:

#!/bin/bash

mkdir test
count=1
while test $count -le 10
do touch test/file$count-{000..50000}
count=$(( $count + 1 ))
done
ls test | wc -l

Создаю 500 000 файлов в цикле по 50 000 с помощью touch. Больше за раз не получается создать, touch ругается на слишком большой список аргументов. После этого запускаю приведённые выше команды с подсчётом времени их выполнения с помощью time:
# time rm -r test/
и т.д.

Я не буду приводить все результаты, скажу только, что вариант с rsync самый быстрый. И чем больше файлов, тем сильнее разница. Вариант с rm -r test/* в какой-то момент перестанет работать и будет ругаться на большое количество аргументов.

Для второго теста сделал такой скрипт:

#!/bin/bash

count=1
while test $count -le 10
do mkdir -p test/dir$count-{000..500}
touch test/dir$count-{000..500}/file-{000..100}
count=$(( $count + 1 ))
done
find test/ | wc -l

Создаю те же 500 000 файлов, только не в одной директории, а в 50 000, в каждой из которых внутри по 100 файлов. В такой конфигурации все команды отрабатывают примерно одинаково. Если директорий сделать те же 500 000, а суммарное количество файлов увеличить до 5 000 000, то разницы всё равно нет. Не знаю почему. Если будете тестировать, не забудьте увеличить стандартное количество inodes, быстро упрётесь в лимит в ext4.

Резюме такое. Если вам нужно удалить очень много файлов в одной директории, то используйте rsync. В остальных случаях не принципиально.

Кстати, насчёт rsync я когда-то давно писал заметку и делал мем. Как раз на тему случайного удаления полезных данных, если перепутать в аргументах источник и приёмник. Если сначала, как в моём примере, указать пустую директорию, то вы очень быстро удалите все свои полезные файлы, которые собирались скопировать.

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

#linux #bash #script #rsync
Моя публикация про утилиты для трассировки получила много полезных комментариев, так что решил их все собрать и оформить в отдельную справочную заметку.

Linux 🐧

traceroute - стандартная утилита Linux для трассировки маршрута. По умолчанию использует udp протокол. С icmp протоколом запускать вот так:
# traceroute -I ya.ru

tracepath - похожа на traceroute, использует udp протокол, сразу же в выводе по умолчанию показывает значения mtu и маршрутизаторы, где оно меняется.
# tracepath ya.ru

mtr - про эту утилиту делал отдельную заметку. Она совмещает функциональность ping и traceroute одновременно. Может использовать протоколы tcp, udp, icmp. В Windows тоже есть под названием Winmtr.

Windows 💻 

tracert - стандартная утилита в Windows для трассировки маршрута. Известна всем.
Использование:
> tracert ya.ru

pathping - это чисто виндовый аналог mtr со схожей функциональностью, но поддерживает только icmp запросы. Тоже сочетает в себе ping и tracert. Обычно есть в системе, ставить отдельно не надо.
Использование:
> pathping ya.ru

tracetcp - виндовая утилита, которая умеет делать tcp syn запросы по пути следования пакетов, чтобы проверить доступность того или иного порта. Позволяет узнать, где конкретно блокируется какой-то порт. Может делать проверки там, где icmp или udp заблокированы. Надо ставить вручную, скачав с сайта.
Использование:
> tracetcp ya.ru:443
Не знал, что есть программа с такой возможностью. Если где-то по пути порт будет заблокирован, она укажет на этот узел. На Linux аналога не знаю, хотя он бы не помешал.

#network