Trippy: посмотреть ответы узлов по пути к серверу

Trippy совмещает traceroute и ping: показывает узлы маршрута и обновляет статистику ответов каждого из них. В документации для запуска приведена команда:

sudo trip example.com

Подставьте свой адрес. Повышенные права обычно нужны для raw sockets. В таблице можно сопоставить отправленные и полученные пробы, задержку и долю ответов по узлам. На ролике из репозитория также видно, как меняются данные при выборе другого узла и цели. Это демонстрация версии 0.12.0.

Строка No response или 100% в Loss% у промежуточного узла сама по себе не доказывает потерю прикладного трафика. Следующие узлы могут отвечать. Для диагностики сопоставьте несколько строк маршрута.

Taplo: проверка TOML по синтаксису и схеме

Taplo проверяет синтаксис TOML и такие ошибки, как повторное определение ключа. Для файла проекта запустите:

taplo check foo.toml

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

Для проверки требований к структуре подключите подходящую JSON Schema Draft 4 через --schema. В документации адрес схемы дан как пример, поэтому нужен реальный адрес схемы вашего формата. Отдельно можно настроить каталог схем через --schema-catalog. Такую проверку можно запускать перед коммитом конфигурации.

Lazydocker: выбрать контейнер и открыть его логи

Когда нужно сопоставить состояние нескольких контейнеров с их логами, Lazydocker показывает это в одном терминальном интерфейсе. После установки и настройки доступа к Docker daemon запустите:

lazydocker

Выберите сервис слева: справа появятся его логи, состояние и другие доступные панели. Переключайтесь между сервисами, чтобы посмотреть логи нужного контейнера. Текущий README указывает требование Docker 29.0.0 или новее. Docker Compose нужен только для соответствующих сценариев.

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

gron: найти путь к полю в незнакомом JSON

Когда значение спрятано глубоко в ответе API, gron помогает найти его обычным текстовым поиском. Режим --json превращает документ в поток строк с путями и значениями. В примере проекта ищут поле likes:

gron --json testdata/two.json | grep likes

Так видно, к какой ветви относятся совпадения. Чтобы собрать найденную часть обратно в JSON, в документации используют тот же режим при обратном преобразовании:

gron --json testdata/two.json | grep likes | gron --json --ungron

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

Dive: почему удаление файла не уменьшило образ

Удаление файла в новом слое Docker-образа не убирает его из предыдущего слоя. В Dive можно проследить, где файл появился, менялся или был удалён. Откройте свой существующий образ:

dive <your-image-tag>

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

Dive помогает найти, где место может тратиться впустую, но сам не уменьшает образ. Его image efficiency — экспериментальная оценка, а не обещание достижимой экономии. В README инструмент отмечен как beta quality, поэтому выводы стоит проверять по составу слоёв, а не по одному проценту.

chezmoi: проверить изменения dotfiles перед применением

chezmoi хранит исходное состояние конфигурации отдельно от файлов в домашнем каталоге. Команда edit меняет управляемую копию. Изменения в домашнем каталоге нужно применять отдельно, поэтому их можно сначала просмотреть.

Если chezmoi уже установлен и инициализирован, а нужные файлы добавлены под управление, выполните:

chezmoi diff
chezmoi -n -v apply

Первая команда покажет различия, вторая подробно выведет действия без записи. Флаг -n включает dry run, -v — подробный вывод. Если изменений нет, diff может быть пустым.

Обычный apply без -n уже меняет файлы. Переходите к нему после просмотра изменений. По умолчанию исходное состояние хранится в ~/.local/share/chezmoi. На карточке — исходное состояние и команды проверки.

Проверить JSON-запрос до отправки с xh

В xh есть режим --offline: клиент собирает HTTP-запрос и выводит его в терминал, не обращаясь к серверу. Удобно, когда нужно сначала проверить типы полей в JSON и заголовки.

xh --ignore-stdin --offline POST https://example.com/users name=anna age:=24

--ignore-stdin отключает чтение тела из stdin. С name=anna в JSON попадёт строка, с age:=24 — число. Оператор == задаёт параметр query string, двоеточие — заголовок. В выводе можно проверить, куда попало каждое значение.

После проверки уберите --offline и укажите свой тестовый адрес. В этом режиме вы проверяете только состав запроса. Ответ сервера и правила валидации API он не покажет. Синтаксис похож на HTTPie, однако xh поддерживает не все его возможности и не имеет системы плагинов.

Cosign: подпись образа нужно связать с ожидаемым автором

Проверяя скачанный контейнерный образ через Cosign, заранее задайте, чью подпись вы готовы принять. В keyless-сценарии документация требует проверить и личность подписанта, и OIDC-провайдера.

За личность отвечает --certificate-identity, за провайдера — --certificate-oidc-issuer. Проверяйте оба значения: просто найти подпись у образа недостаточно, если вам нужен артефакт конкретного проекта. Ожидаемые значения берите из доверенного процесса выпуска, а не из самого непроверенного файла.

По умолчанию Cosign также сверяет digest образа с digest в подписанных данных. Это связывает подпись с конкретным содержимым. Успешная проверка подтверждает эти условия, но не подтверждает отсутствие уязвимостей в образе.

sccache и промахи кэша из-за пути к проекту

Два CI-задания собирают один код, но checkout лежит в разных абсолютных каталогах. Для sccache это существенная разница: по умолчанию абсолютные пути должны совпадать, чтобы использовать сохранённый результат компиляции.

В README описан SCCACHE_BASEDIRS. Он позволяет убрать выбранный префикс пути перед вычислением ключа кэша. В качестве базового каталога нужен абсолютный путь. Инструмент нормализует пути в исходнике после препроцессинга и подходящих аргументах компилятора, но не вырезает произвольные совпадения из любого текста.

Это настройка для повторных сборок с разными корнями checkout. Она не делает любую компиляцию кэшируемой: например, у Rust не кэшируются инкрементальные сборки и crates, вызывающие системный линкер. Проверяйте попадания и промахи по статистике sccache.

Найти тяжёлый каталог с gdu и запретить удаление

Если нужно разобраться, что занимает место в проекте, gdu покажет размеры каталогов и файлов. Для первичного осмотра можно сразу отключить удаление и получить текстовый отчёт по текущему каталогу:

gdu -n --no-delete .

Флаг -n выбирает неинтерактивный режим, --no-delete запрещает удаление. В интерактивном интерфейсе без этого ограничения есть клавиши удаления и очистки каталога, поэтому режим осмотра стоит выбрать заранее.

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

Версии Rust для сборки и запуска nextest

cargo-nextest — отдельный запускатель тестов Cargo. Перед добавлением в CI проверьте, собираете ли вы сам nextest из исходников или используете готовую утилиту: в README для этих случаев указаны разные требования.

Минимальная версия Rust для сборки nextest — 1.91. Для запуска указан Rust 1.41, но авторы отдельно оговаривают, что столь старые версии не тестируют. Они ожидают совместимость с версиями Rust, выпущенными за последний год. Старый номер в таблице не стоит читать как гарантию для давно замороженного CI-образа.

В репозитории также есть библиотеки runner, metadata и filtering. Если вам нужен именно инструмент запуска тестов, ориентируйтесь на пакет cargo-nextest. Подробный выбор тестов и режимов вынесен в руководство проекта.

jwt-cli для разбора токена в терминале

При отладке авторизации бывает нужно увидеть заголовок и claims JWT: например, проверить, какое значение передаёт тестовый клиент. jwt-cli декодирует их локально, без вставки токена на сторонний сайт.

Утилита принимает токен из стандартного ввода. В примере из README сначала создаётся токен с заведомо учебным секретом, затем сразу разбирается:

jwt encode --secret=fake '{"hello":"world"}' | jwt decode -

Аргумент - означает чтение из stdin. Такой способ подходит и для цепочки команд, которая уже получила тестовый JWT. Не подставляйте рабочие токены и секреты в пример или общий журнал команд.

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

cargo-audit проверяет версии из Cargo.lock по RustSec

Перед обновлением Rust-проекта cargo-audit помогает найти зависимости с описанными в RustSec уязвимостями. Проверка относится к конкретным версиям из Cargo.lock, поэтому отчёт удобно разбирать вместе с изменением lockfile.

Смотрите, какая версия затронута и какие условия описаны в advisory. Наличие записи в базе ещё не показывает, вызываете ли вы уязвимый API или включили нужную для проблемы feature. Обычная проверка не обновляет зависимости. Экспериментальное автоматическое исправление — отдельный режим, который меняет Cargo.toml.

Запускайте Cargo только в доверенных проектах. Если lockfile отсутствует, cargo-audit может вызвать Cargo для его создания. Для чужого lockfile README предлагает передавать файл явно и работать из каталога вне недоверенного проекта. Утилите нужен Rust 1.74 или новее.

Vegeta задаёт темп HTTP-нагрузки

Для тестового сервиса полезно проверить поведение при заданной частоте запросов. Vegeta позволяет задать темп и длительность отдельно, а результаты передать в генератор отчёта. Небольшой пример для вашего локального HTTP-сервера на порту 8080:

printf 'GET http://127.0.0.1:8080/\n' | vegeta attack -rate=2/s -duration=2s | vegeta report

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

У -duration есть важная деталь: это время выдачи запросов. Весь процесс может идти дольше, пока приходят последние ответы. Такой тест отвечает на вопрос о выбранном темпе на конкретном стенде. Он не доказывает предельную пропускную способность сервиса.

Проверка конфигурации GoReleaser до выпуска

После изменения настроек релиза запустите check у GoReleaser. Команда читает конфигурацию и проверяет её допустимость, без запуска публикации.

В корне Git-проекта с файлом конфигурации:

goreleaser check

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

В репозитории GoReleaser есть ссылки на инструкции для локальной машины и CI. Поведение check также видно в открытом исходнике команды. После правки YAML сначала проверьте настройки, затем отдельно — сборку и доставку артефактов.

bandwhich показывает сетевую активность процессов

Общая скорость соединения не объясняет, какое приложение передаёт данные. bandwhich раскладывает текущую сетевую активность по процессам, соединениям и удалённым адресам. Это помогает проверить, связан ли трафик со сборкой, браузером или отдельным фоновым процессом.

Утилита захватывает пакеты выбранного интерфейса и сопоставляет их с процессами. Для этого она использует /proc в Linux, lsof в macOS и WinAPI в Windows. Имена хостов определяет обратным DNS-запросом, когда это возможно.

Для захвата нужны соответствующие права. README отдельно предупреждает: постоянные capabilities в Linux открывают мониторинг всем пользователям машины, которым доступна утилита. На общей машине учитывайте, кто сможет наблюдать чужой трафик. Проект находится в пассивном сопровождении: критические проблемы исправляют, новые функции сейчас не разрабатывают.

cargo-deny сверяет зависимости с правилами проекта

Сообщения об уязвимостях — только одна причина отклонить зависимость. Если проект разрешает определённые лицензии или источники crates, cargo-deny проверяет соответствие графа зависимостей этим правилам.

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

Это отличается от узкой проверки Cargo.lock по RustSec: здесь вы сначала определяете собственную политику, затем проверяете соответствие ей. Разрешённая лицензия и доверенный источник не означают отсутствия уязвимостей. В README указан минимальный Rust 1.88.0. Авторы отдельно предупреждают: результат cargo-deny не является юридической консультацией.

hey: ограничить число запросов и параллелизм

Если нужно отправить небольшую фиксированную серию запросов к своему HTTP-стенду, у hey для этого есть два отдельных параметра. Один задаёт общий объём, другой — число параллельных исполнителей.

Для локального сервера на порту 8080:

hey -n 12 -c 2 http://127.0.0.1:8080/

Будет отправлено 12 запросов с двумя параллельными workers. В итоговом отчёте можно посмотреть распределение времени ответов и статусы. Общее число запросов не может быть меньше числа workers.

Это сценарий с ограниченным числом запросов, а не расписание с заданным общим темпом, как у Vegeta. У hey есть и ограничитель -q, но он задаёт QPS на каждого worker, а не на весь запуск. Если выбираете режим по длительности -z, значение -n игнорируется.

dist собирает бинарник, установщик и данные о выпуске

Скомпилированный CLI ещё нужно передать пользователям: подготовить архивы под платформы, установщики и описание артефактов. dist, прежде известный как cargo-dist, связывает эти задачи в процесс распространения бинарников.

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

В полном варианте dist генерирует CI-процесс: по тегу определяет приложения для выпуска, готовит план, собирает артефакты и размещает их. Название cargo-dist сохранилось у пакета и в части адресов документации, но сам README называет инструмент dist. Сначала решите, нужен ли вам полный процесс публикации или только повторяемая упаковка.

Baseline в Gitleaks выделяет новые находки

Первый запуск Gitleaks по старому репозиторию может дать длинный список возможных секретов. Если нужно следить за новыми находками, инструмент умеет использовать прежний отчёт как baseline и исключать уже записанные совпадения из следующего отчёта.

Это удобно после первичного разбора: отдельно хранится перечень известных находок, а CI показывает новые. Baseline не исправляет старые утечки и не доказывает, что их безопасно игнорировать. Он только меняет, какие совпадения попадут в отчёт.

У Gitleaks есть разные области сканирования. Режим git читает патчи истории, dir проверяет файлы и каталоги, stdin — входной поток. Для поиска секрета, удалённого из рабочей копии, важен именно просмотр истории.

При выборе инструмента учтите статус проекта: автор объявил Gitleaks функционально завершённым. Новых возможностей не планирует, будущие релизы — только исправления безопасности.