Телеграм канал «Linux Ready | DevOps»

В Linux можно найти процессы, использующие конкретный порт или файл, без просмотра полного списка открытых дескрипторов!

Для этого есть fuser из пакета psmisc. Он удобен, когда сервис не запускается из-за занятого порта:
sudo fuser -v -n tcp 8080

Команда покажет процессы, связанные с TCP-портом 8080. А если нужно узнать, кто использует файл или каталог:
sudo fuser -v /var/log/myapp.log

Есть и более интересный сценарий: выяснить, какие процессы мешают размонтировать файловую систему:
sudo fuser -vm /mnt/data

Здесь -m ищет процессы, использующие файлы на той же файловой системе, что и указанный путь. Это полезно при ошибке target is busy.

🔥 fuser позволяет быстро перейти от проблемного ресурса к процессу, который его использует. Что полезно при отладке занятых портов и размонтировании файловых систем.

🚪 Linux Ready | #совет

📂 Шпаргалка по протоколу NTP!

Например, NTP позволяет синхронизировать системное время компьютеров и серверов, а временные метки T1–T4 помогают рассчитать сетевую задержку и смещение часов.

На картинке — принцип работы NTP, основные формулы, режимы синхронизации и иерархия NTP-серверов.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

В Linux можно диагностировать загрузку динамических библиотек ещё до запуска самой программы!

Если приложение падает с ошибкой cannot open shared object file, проблема часто не в отсутствии библиотеки, а в том, где именно загрузчик её ищет.

У динамического загрузчика Linux есть собственные диагностические возможности:
LD_DEBUG=libs ./myapp

Команда покажет поиск библиотек по каталогам, включая пути из RPATH, RUNPATH, переменных окружения и системных настроек.

А если нужно проверить зависимости без запуска main(), можно вызвать загрузчик напрямую:
/lib64/ld-linux-x86-64.so.2 --list ./myapp

Он покажет, какие зависимости удалось разрешить и какие файлы библиотек будут использованы.

Полезно при отладке программ, которые работают на машине разработчика, но не запускаются на сервере или внутри контейнера.
# Посмотреть диагностические данные загрузчика
/lib64/ld-linux-x86-64.so.2 --list-diagnostics ./myapp

Последняя возможность доступна в glibc начиная с версии 2.33. Путь к загрузчику зависит от архитектуры и дистрибутива, а диагностика LD_DEBUG может быть ограничена для защищённых исполняемых файлов.

🔥 В следующий раз, когда приложение не найдёт .so, не спешите создавать симлинки и менять LD_LIBRARY_PATH. Сначала посмотрите, где загрузчик ищет библиотеку.

🚪 Linux Ready | #совет

🔥 Мастхев подборка для каждого айтишника

Держите подборку авторских IT-каналов по всем направлениям: курсы, гайды, статьи, практики, примеры кода, шпаргалки и прохождение собесов.

▪️ Python: @python
▪️ Frontend: @frontend
▪️ Java: @java
👨‍💻 Go: @golang
▪️ ИБ & Хакинг: @hacking
▪️ C/C++: @cplusplus
▪️ C# & GameDev: @gamedev
▪️ Data Science: @datascience
▪️ DevOps: @devops
▪️ Linux: @linux
▪️ IT Курсы: @courses
▪️ Вайбкодинг: @vibecoding
▪️ Весь айти: @itnews

⏱️ Успей подписаться пока не удалили!

👩‍💻 SSH отключился, а команда продолжает работать!

Запустили резервное копирование, обработку данных или длительный скрипт через SSH, но соединение неожиданно оборвалось? Обычный процесс может получить сигнал SIGHUP и завершиться вместе с терминальной сессией. В Linux есть простой способ защитить задачу от такого сценария — nohup.

Как работает:
• nohup запускает команду с игнорированием сигнала SIGHUP, позволяя ей продолжать работу после отключения терминала;

• & отправляет задачу в фон, освобождая терминал для других команд;

• 2>&1 объединяет стандартный вывод и ошибки в одном лог-файле;

• pgrep -af помогает найти работающий процесс, а tail -f — наблюдать за его выводом в реальном времени.

Приём полезен для резервного копирования, длительных скриптов, миграций и других задач на удалённых серверах. Главное — заранее перенаправить ввод и вывод: nohup защищает от SIGHUP, но не от перезагрузки сервера или принудительного завершения процесса.

🚪 Linux Ready | #фишка

Как запустить процесс в отдельном сетевом пространстве Linux?

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

В линукс для этого предусмотрены network namespaces. Каждый такой namespace имеет собственные сетевые интерфейсы, таблицы маршрутизации, сокеты и ряд других сетевых настроек.

Создадим отдельное сетевое пространство:
sudo ip netns add isolated

Проверим список:
ip netns list

В выводе появится:
isolated

Теперь посмотрим сетевые интерфейсы внутри нового namespace:
sudo ip netns exec isolated ip addr

По умолчанию в нём будет только интерфейс lo, который изначально находится в состоянии DOWN.

Включим loopback:
sudo ip netns exec isolated ip link set lo up

После этого проверим его адрес:
sudo ip netns exec isolated ip addr show lo

На интерфейсе обычно уже назначен стандартный адрес 127.0.0.1/8. Включение lo позволяет использовать его для локального сетевого взаимодействия.

Попробуем выполнить запрос во внешнюю сеть:
sudo ip netns exec isolated \
ping -c 3 1.1.1.1

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

Теперь запустим внутри namespace простой HTTP-сервер. Чтобы не раздавать файлы текущего каталога, создадим отдельный пустой каталог:
mkdir -p /tmp/netns-http

Запустим сервер:
sudo ip netns exec isolated \
python3 -m http.server 8080 \
--bind 127.0.0.1 \
--directory /tmp/netns-http

В другом терминале проверим, что сервер отвечает:
sudo ip netns exec isolated \
curl -i http://127.0.0.1:8080

Сервер вернёт HTTP-ответ, поскольку клиент и сервер используют одно сетевое пространство. Для пустого каталога это будет страница со списком файлов.

Но если выполнить аналогичный запрос из основной системы:
curl http://127.0.0.1:8080

Подключиться к серверу внутри isolated не получится, если в основном namespace нет собственного listener на этом адресе и порту. Причина в том, что loopback-интерфейсы разных network namespaces независимы друг от друга.

Это позволяет запускать приложения на одинаковых адресах и портах без конфликтов между сетевыми пространствами. Проверим прослушивающие TCP-порты внутри namespace:
sudo ip netns exec isolated ss -tlnp

В выводе будет присутствовать HTTP-сервер, прослушивающий 127.0.0.1:8080.

При этом обычная команда в основной системе:
sudo ss -tlnp

Не покажет этот listener, поскольку ss просматривает сокеты текущего сетевого пространства.

Посмотрим процессы, использующие созданный namespace как основное сетевое пространство:
sudo ip netns pids isolated

Команда выведет их PID, включая процесс HTTP-сервера.

Также можно проверить сетевое пространство конкретного процесса. Подставим PID сервера из предыдущего вывода:
sudo readlink /proc/<PID>/ns/net

В результате получим идентификатор вида:
net:[4026532456]

Число в квадратных скобках идентифицирует объект namespace. У процессов в одном network namespace ссылки /proc/<PID>/ns/net указывают на один и тот же объект.

Для удаления окружения сначала остановим HTTP-сервер через Ctrl+C, затем удалим namespace:
sudo ip netns del isolated

🔥 Удаление имени namespace не завершает автоматически процессы, которые его используют. Само сетевое пространство сохраняется, пока на него существуют ссылки.

🚪 Linux Ready | #практика

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

Для защиты от таких сценариев CURATOR запустил CURATOR.IDENTITY — облачное решение для управления доступом и аутентификацией.

Что оно умеет:
🔹 подключать MFA и SSO для корпоративных сервисов, VPN и веб-приложений;
🔹 настраивать права доступа для разных категорий пользователей;
🔹 учитывать контекст входа и устройство;
🔹 защищать пользовательские сессии и выстраивать Zero Trust-сценарии.

Решение расширяет защиту CURATOR: теперь она охватывает не только инфраструктуру и приложения, но и доступ к ним.

👉 Подробнее о CURATOR.IDENTITY