NetworkAdmin.ru

💚 Linux capabilities: как дать процессу нужные права без полного root Одна из старых проблем linux- приложение либо работает от обычного пользователя, либо получает полный root. Но на практике многим сервисам нужен всего один привилегированный доступ. Например: • открыть порт ниже 1024; • работать с raw-сокетами; • менять сетевые настройки; • выполнять отдельные системные операции. Давать ради этого полный root - не лучшая идея. Для таких случаев в Linux существуют capabilities. Они разбивают привилегии суперпользователя на отдельные возможности, которые можно выдавать выборочно. К примеру, веб-серверу нужен только доступ к 80 порту. Без root обычный пользователь не сможет открыть этот порт:

python3 -m http.server 80

# Получим ошибку: Permission denied``` Но можно выдать только capability для привязки к привилегированным портам:

setcap cap_net_bind_service=+ep /usr/bin/python3

Проверяем:

getcap /usr/bin/python3

Результат:

/usr/bin/python3 cap_net_bind_service=ep

Теперь процесс сможет слушать порт 80 без запуска от root. Еще несколько популярных capabilities: • CAP_NET_BIND_SERVICE - порты ниже 1024 • CAP_NET_RAW - raw sockets, ping и подобные инструменты • CAP_SYS_TIME - изменение системного времени • CAP_NET_ADMIN - управление сетью • CAP_SYS_ADMIN - очень широкие административные возможности (почти mini-root) Посмотреть capabilities процесса:

cat /proc/<PID>/status | grep Cap

Или использовать:

capsh --print

Удалить capability:

setcap -r /usr/bin/python3

Очень полезны capabilities и в systemd. Например, сервис работает от непривилегированного пользователя:

[Service]
User=nginx
AmbientCapabilities=CAP_NET_BIND_SERVICE

В итоге процесс не получает root, но может слушать 80 и 443 порты. Это гораздо безопаснее, чем запускать весь сервис от суперпользователя. Но не все capabilities одинаково безопасны. Например: CAP_SYS_ADMIN настолько мощная, что ее часто называют новым root. Поэтому принцип тот же, что и с правами пользователей: выдаем минимум необходимого. Если приложению нужен только доступ к порту 80 - выдаем только CAP_NET_BIND_SERVICE. Не нужно на всякий случай раздавать весь набор возможностей. #linux #security #capabilities 🧑‍💻 NetworkAdmin

С ДНЕМ СИСАДМИНА! 👍 По традиции в этот великий день мы смотрим классику 🎬 😎 localhost › IT-юмор

С днём системного администратора! 🏆 Пусть серверы не падают, бэкапы восстанавливаются, мониторинг молчит, а пользователи хотя бы иногда пробуют перезагрузить компьютер до обращения в поддержку. Желаю стабильного аптайма, спокойных дежурств, крепких нервов и достойной зарплаты. За localhost! 🍻🍷 🧑‍💻 NetworkAdmin

Лапшу заказывали? #юмор 🧑‍💻 NetworkAdmin

Стикерпак вместо тысячи слов в чате Сегодня День сисадмина, и Яндекс 360 отметил его по-своему — собрал набор «esc от стресса». «Работает? Не трогай» и «F» отвечают на большинство рабочих вопросов быстрее, чем развёрнутое сообщение. Со стрессом Яндекс 360 помогает справляться и вне чатов: сотрудники, права и сервисы управляются из одной админки — снять доступы уходящему одно действие, а не обход всех панелей. Поставить стикерпак себе тут. Реклама ООО «Яндекс», ИНН 7736207543, erid: 2W5zFJDFTSZ

❓ SSHFS-Win: подключаем Linux-каталог как диск в Windows В Windows можно подключать каталоги с удаленного linux/unix-сервера как обычный сетевой диск. Не через SMB, не через FTP и не через WebDAV, а по защищенному SSH-соединению. Для этого есть SSHFS-Win - порт SSHFS-клиента для Windows. Он позволяет монтировать удаленную файловую систему по SSH так, будто это обычный диск в Проводнике. После установки SSHFS-Win каталог можно подключить прямо из Проводника Windows. Например, UNC-путь:

\\sshfs.r\administrator@192.168.158.100\remote_folder

sshfs.r - тип подключения administrator - пользователь на удаленном сервере 192.168.158.100 - адрес сервера remote_folder - удаленный каталог Можно смонтировать диск и из командной строки:

net use M: \\sshfs.r\administrator@192.168.158.100\ps /user:administrator

После этого в системе появится диск M:, с которым можно работать как с обычным сетевым диском. Если нужна SSH-аутентификация по ключу, можно использовать другой префикс:

\\sshfs.k\administrator@192.168.158.100\remote_folder

Префикс sshfs.k говорит SSHFS-Win использовать ключевую аутентификацию. Это удобнее и безопаснее, чем постоянно вводить пароль, особенно если доступ нужен регулярно. Пример подключения по ключу:

net use M: \\sshfs.k\administrator@192.168.158.100\remote_folder

Отключить диск можно стандартно:

net use M: /delete

▪️ Где SSHFS-Win особенно полезен: • админ работает на Windows, а серверы linux; • нужно быстро открыть /var/log или /etc; • нет желания поднимать samba; • нужен доступ к файлам через уже разрешенный SSH; • удобно подключать dev/test каталоги; • нужно временно смонтировать удаленную папку без лишней инфраструктуры. SSHFS-Win - это не замена нормальному файловому серверу для большой команды. Для постоянной совместной работы, офисных файлов и тяжелой нагрузки чаще лучше использовать SMB/NFS/специализированное хранилище. Но для админских задач SSHFS-Win очень удобен: есть SSH-доступ - есть и сетевой диск в windows. Главное - использовать ключи, ограничивать права пользователя на сервере и не монтировать под root то, что можно открыть обычной учеткой. #windows #sshfs 🧑‍💻 NetworkAdmin

👍 Sysinternals без скачивания: подключаем как сетевой диск Короткая, но полезная штука для админов Windows. У Sysinternals есть live-каталог, который можно подключить как сетевой диск и запускать утилиты напрямую, без ручного скачивания архива. Команда простая:

net use S: http://live.sysinternals.com/tools

Если все прошло нормально, Windows ответит: Команда выполнена успешно. После этого у вас появляется диск S:, где лежат утилиты Sysinternals. Переходим на него:

S:

И запускаем нужный инструмент:

procexp64.exe

Для тех, кто не пользовался Sysinternals: это старый и очень известный набор утилит microsoft для диагностики и администрирования windows. ▪️ Что там особенно полезно: • Process Explorer. Расширенный менеджер процессов. Показывает дерево процессов, потоки, DLL, handles, параметры запуска, цифровые подписи, сетевую активность и много другой информации.

procexp64.exe

• TCPView. Показывает сетевые соединения: какой процесс, куда подключился, какой порт использует и в каком состоянии соединение.

tcpview.exe

• Autoruns. Один из лучших инструментов для разбора автозагрузки. Показывает Run-ключи, службы, драйверы, scheduled tasks, shell extensions и многое другое.

Autoruns.exe

• PsExec. Утилита для удаленного запуска процессов на Windows-хостах.

PsExec.exe

• Handle. Помогает понять, какой процесс держит файл или каталог.

handle.exe

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

net use S: /delete

❗️ Запускать инструменты напрямую из интернета удобно, но не всегда уместно. В корпоративной среде могут быть ограничения: прокси, firewall, AppLocker / WDAC, запрет WebDAV, требования к контролю версий утилит и т.д. #windows #sysinternals 🧑‍💻 NetworkAdmin

MPLS для корпоративных сетей: мифы, реальность и практика. Бесплатный урок курса «Сетевой инженер. Продвинутый уровень» MPLS уже много лет используется для построения корпоративных и операторских сетей, однако вокруг этой технологии до сих пор существует немало заблуждений. Одни считают MPLS универсальным решением для любых задач, другие — слишком сложной технологией, которую используют только провайдеры. На практике всё зависит от требований сети и понимания того, какие сервисы предоставляет MPLS. На открытом уроке 3 августа в 20:00 разберём базовые принципы работы MPLS и применение технологии в корпоративных сетях. Поговорим об основных сервисах MPLS, сравним сценарии их использования и на практике настроим один из сервисов. Отдельно обсудим, в каких случаях MPLS действительно даёт преимущества, а когда можно обойтись более простыми решениями. Урок не для тех, кто выбирает сетевые технологии по привычке или без понимания их особенностей. Будет полезен сетевым инженерам, архитекторам и всем, кто хочет глубже разобраться в современных корпоративных сетях. 👉 Записаться:https://otus.pw/4TvS/ Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

🌟 psmisc toolkit: fuser, pstree, killall в реальной админке psmisc - небольшой набор утилит, которые часто оказываются полезнее, чем кажутся на первый взгляд. Обычно пакет ставят ради трех команд: fuser, pstree, killall ▪️ Установка:

apt install psmisc
# или:
yum install psmisc

▪️ fuser: кто держит файл, порт или mount point. fuser показывает процессы, которые используют файл, каталог, сокет или файловую систему. Например, не получается размонтировать диск:

umount /mnt/backup

А в ответ: target is busy Смотрим, кто держит mount point:

fuser -vm /mnt/backup

Можно увидеть PID, пользователя и тип доступа. Если нужно аккуратно завершить процессы:

fuser -k /mnt/backup

Но с -k лучше не спешить. Сначала посмотреть, потом убивать. Еще полезный пример - кто держит TCP-порт:

fuser -v 8080/tcp

Или UDP:

fuser -v 53/udp

▪️ pstree: дерево процессов вместо каши. ps aux часто превращается в простыню. pstree показывает процессы в виде дерева: кто кого запустил и где родительский процесс.

pstree

С PID:

pstree -p

Для конкретного пользователя:

pstree -u username

Для конкретного процесса:

pstree -p 1234

Это очень удобно, когда нужно понять: • какой процесс породил дочерние • кто держит worker’ы • почему после остановки сервиса остались потомки • откуда запущен странный процесс • что происходит внутри shell-сессии или скрипта

Например, при зависшем deploy можно быстро увидеть цепочку:

sshd───bash───deploy.sh───rsync

И уже понятно, кого действительно нужно трогать. ▪️ killall: завершить процессы по имени. killall убивает процессы по имени, а не по PID. Например:

killall nginx

или мягко через TERM:

killall -TERM nginx

Если процесс не реагирует:

killall -KILL nginx

Но KILL - это крайний вариант. Сначала лучше отправлять TERM, чтобы процесс мог корректно завершиться. Можно посмотреть, что будет затронуто:

pgrep -a nginx

А уже потом использовать killall. killall работает по имени процесса. Если на сервере есть несколько процессов с одинаковым именем, можно задеть лишнее. Особенно осторожно с короткими именами и системными процессами. Хороший порядок в админке такой:

fuser -vm /mnt/backup
pstree -p
pgrep -a process_name
killall -TERM process_name

Сначала понять, кто держит ресурс. Потом посмотреть дерево процессов. И только потом что-то завершать. #linux #psmisc 🧑‍💻 NetworkAdmin

😑 tmpfs: где ускоряет систему, а где создает проблемы tmpfs - это файловая система, которая хранит данные в оперативной памяти. Проще говоря, вы монтируете каталог как обычную файловую систему, но файлы физически лежат не на диске, а в RAM. При необходимости часть данных может быть вытеснена в swap, если он включен. ▪️ Посмотреть текущие tmpfs:

df -h -t tmpfs

/run
/dev/shm
/tmp

Главный плюс tmpfs - скорость. Операции чтения и записи обычно быстрее, чем на диске, особенно если это много мелких временных файлов. ▪️ Где tmpfs полезен: • временные файлы приложения; • build-кэши; • сокеты и runtime-файлы; • промежуточные данные, которые не нужны после перезагрузки; • тестовые стенды; • ускорение операций с большим количеством мелких файлов. Например, можно смонтировать отдельный каталог:

mkdir -p /mnt/ramtmp

mount -t tmpfs -o size=2G tmpfs /mnt/ramtmp

Теперь /mnt/ramtmp будет tmpfs с лимитом 2 ГБ. Для постоянного подключения через /etc/fstab:

tmpfs /mnt/ramtmp tmpfs defaults,size=2G,noatime 0 0

▪️ tmpfs легко становится источником проблем. Первая проблема - данные исчезают после перезагрузки. Если приложение случайно пишет туда то, что должно храниться постоянно, после ребута будет сюрприз. Вторая проблема - расход RAM. Если задать слишком большой tmpfs или не ограничить его размер, временные файлы могут начать конкурировать с приложениями за память. Проверить использование:

df -h /mnt/ramtmp

И отдельно смотреть память:

free -h

Третья проблема - OOM. Если приложение активно пишет во временный каталог на tmpfs, можно неожиданно упереться в память. Особенно на серверах с тяжелыми сервисами, контейнерами или сборками. Четвертая проблема - swap. Если swap включен, tmpfs не всегда означает "только RAM". Под давлением памяти часть страниц может уехать в swap, и внезапно "быстрый tmpfs" станет не таким быстрым. ▪️ Где лучше быть осторожным: • /tmp на серверах с непредсказуемыми задачами; • директории аплоадов; • временные файлы баз данных; • CI/CD-сборки без лимитов; • контейнеры с активной записью; • любые каталоги, где размер данных заранее неизвестен. Для systemd-сервисов можно использовать временные каталоги аккуратнее:

[Service]
PrivateTmp=true

Это даст сервису отдельный /tmp и /var/tmp, чтобы он не мешал другим процессам. А если нужен runtime-каталог:

[Service]
RuntimeDirectory=myapp

Тогда systemd создаст каталог в /run, который обычно тоже находится на tmpfs. #linux #tmpfs 🧑‍💻 NetworkAdmin

🤖 Программирование — ВСЁ? В 2026 году голым кодингом уже никого не удивишь - рутину за секунды набрасывают нейросети. Новая и прибыльная перспектива - разработка ИИ-агентов и автоматизация процессов. Хватит тратить токены на генерацию картинок и базовых текстов, пора внедрять ИИ в реальный продакшн. Ловите канал, который тащит только отборное технологическое мясо: 👨‍💻 ИИнтеллигенция • Нейросети - канал для бэкендеров, автоматизаторов и инди-хакеров. Глубокие разборы ИИ-инструментов, промпт-инжиниринг и архитектура агентов без хайпа и копипасты. ⚡️ Разборы софта: от консольных плагинов вроде Claude SEO до платформ от NVIDIA. ⚡️ Экономика токенов: честные тесты, где Grok 4.5 или DeepSeek выгоднее, чем дорогие модели. ⚡️ Практика: как разворачивать бэкграунд-воркеров и автоматизировать рутину до одной кнопки. ⬇️ Вступай и качай навыки будущего: @clucai

⚙️ Windows предпочитает IPv6: почему старые сервисы могут ломаться Если для удаленного хоста доступны и IPv4, и IPv6, Windows по умолчанию может выбрать IPv6. То есть если DNS или mDNS в локальной сети вернул сразу две записи:

A     -> IPv4-адрес
AAAA  -> IPv6-адрес

то подключение с windows-клиента часто пойдет именно по IPv6-адресу из AAAA. В обычной современной сети это нормально. IPv6 - не лишний протокол, а полноценная часть сетевого стека Windows. Но иногда из-за этого начинаются странные проблемы. Например: • имя хоста резолвится нормально; • ping может работать; • по IPv4 сервис доступен; • но приложение пытается подключиться по IPv6; • а сам сервис IPv6 не слушает или работает с ним криво. Особенно часто это всплывает со старыми приложениями, самописными сервисами, легаси-софтом, SMB-сценариями в рабочих группах и внутренними утилитами, которые всегда жили на IPv4.

Симптомы могут выглядеть так: по IP 192.168.x.x все открывается по имени хоста - ошибка соседний компьютер виден, но сервис не отвечает приложение пишет timeout в логах видно попытку подключения к IPv6

Первый импульс - полностью отключить IPv6. Но это плохая идея. Microsoft не рекомендует полностью отключать IPv6 в Windows, потому что часть компонентов системы рассчитывает на его наличие. Более аккуратный обходной путь - поднять приоритет IPv4 над IPv6 в prefix policy. Посмотреть текущую таблицу префиксов:

netsh interface ipv6 show prefixpolicies

Увеличить приоритет IPv4-mapped адресов можно так:

netsh interface ipv6 set prefix ::ffff:0:0/96 55 4

В некоторых инструкциях также встречается настройка для ::/96:

netsh interface ipv6 set prefix ::/96 60 3

После изменения стоит проверить таблицу еще раз:

netsh interface ipv6 show prefixpolicies

Смысл этих настроек в том, что винда меняет предпочтения при выборе адреса назначения. IPv6 остается включенным, но при наличии IPv4 и IPv6 система может начать чаще выбирать IPv4. Проверить резолвинг можно так:

nslookup hostname

А доступность порта:

Test-NetConnection hostname -Port 445

#windows #network 🧑‍💻 NetworkAdmin

Этот мир уже не будет прежним #юмор 🧑‍💻 NetworkAdmin

📱 Nginx map: отдельные логи для 404 и 5xx без костылей Иногда нужно не просто писать общий access log, а отдельно сохранять конкретные типы запросов. Например: все 404, все 5xx, запросы от конкретных ботов, отдельные URI, нестандартные методы, трафик из определенных стран. Можно потом парсить общий лог через grep, awk или SIEM. Но в Nginx часто есть более аккуратный способ - использовать map. map позволяет создать переменную на основе другой переменной Nginx. А потом использовать эту переменную в логах, блокировках, редиректах и другой логике. ▪️ Пример: пишем 404 и 5xx в отдельные файлы. В секции http добавляем:

map $status $to404log {
    404     1;
    default 0;
}

map $status $to5xxlog {
    ~^5     1;
    default 0;
}

Теперь в нужном виртуальном хосте:

access_log /var/log/nginx/404.log combined if=$to404log;
access_log /var/log/nginx/5xx.log combined if=$to5xxlog;

▪️ Что получится: • запросы со статусом 404 попадут в /var/log/nginx/404.log • ответы 500, 502, 503, 504 и другие 5xx попадут в /var/log/nginx/5xx.log • при этом общий access log можно оставить как есть Например:

access_log /var/log/nginx/access.log combined;

▪️ Как это работает: • Nginx смотрит на встроенную переменную $status • если статус 404, переменная $to404log получает значение 1 • если статус начинается с 5, переменная $to5xxlog получает значение 1 • директива access_log ... if= пишет запись только если переменная не равна 0 Так можно быстро отделить интересные события без внешней обработки логов. ▪️ map полезен не только для логов. Например, можно помечать нежелательные User-Agent:

map $http_user_agent $block_useragent {
    default        0;
    ~*semrushbot   1;
    ~*ahrefs       1;
    ~*rss2tg       1;
    ~*seznambot    1;
    ~*AspiegelBot  1;
    ~*BLEXBot      1;
    ~*MASHIAH      1;
}

А в виртуальном хосте вернуть 403:

if ($block_useragent) {
    return 403;
}

Да, if в Nginx часто ругают, но для простого return внутри server это нормальный и распространенный сценарий. По такой же логике можно делать условия по другим переменным:

$request_method
$request_uri
$remote_addr
$host
$geoip_country_code
$http_referer

Например: • отдельно логировать POST-запросы • блокировать конкретные URI для некоторых User-Agent • писать подозрительные запросы в отдельный лог • ограничивать доступ по стране через GeoIP • включать разные upstream’ы по признакам запроса #nginx #linux 🧑‍💻 NetworkAdmin

02:17. Pager разрывается. Продакшн падает. А вы — дежурный SRE. Успеете среагировать за 15 минут? Мы сделали интерактивный симулятор реального инцидента: API отвечает 500-й ошибкой, задержка растёт, разработчики спят, а бизнес уже требует ответов. Вам предстоит принять 5 решений — ровно так, как это делают дежурные инженеры в проде: ⏩ что проверить первым ⏩ какую метрику считать критичной ⏩ когда объявлять инцидент ⏩ что написать пользователям ⏩ что делать после того, как всё починили ❗️Никакой теории — только реальная ситуация и разбор каждого шага сразу после ответа. В конце узнаете, насколько ваш подход похож на мышление настоящего SRE, и получите список навыков, которые стоит прокачать. Проверьте, спасли бы вы продакшн⬇️ ЗАБРАТЬ СИМУЛЯТОР

💚 AppArmor vs SELinux: что проще внедрять в обычной инфраструктуре Когда говорят про безопасность в linux, часто вспоминают SELinux и AppArmor. Оба инструмента решают похожую задачу: ограничивают, что процесс может делать в системе, даже если у него уже есть обычные Unix-права. То есть если приложение скомпрометировали, оно не должно автоматически получить возможность читать все подряд, писать куда угодно и трогать чужие файлы. Это дополнительный слой защиты поверх пользователей, групп и прав доступа. Но подход у них разный. ▪️ SELinux работает через labels и security contexts. У файлов, процессов, портов и других объектов есть контексты, а политики описывают, кому с чем можно взаимодействовать. Проверить статус:

sestatus

Посмотреть контексты файлов:

ls -Z

Посмотреть контекст процесса:

ps auxZ

SELinux мощный и гибкий, но за это приходится платить сложностью. Если что-то заблокировано, нужно разбираться в контекстах, политиках, AVC denial, boolean’ах и audit2allow. Типичный разбор:

ausearch -m avc -ts recent
audit2why
audit2allow

Для больших корпоративных инфраструктур, особенно на RHEL-подобных системах, SELinux - сильный и зрелый вариант. ▪️ AppArmor устроен проще для понимания. Он обычно привязывает профиль к конкретному исполняемому файлу и описывает, к каким путям, возможностям и сетевым действиям процесс имеет доступ. Проверить статус:

aa-status

Перевести профиль в complain-режим:

aa-complain /etc/apparmor.d/usr.sbin.nginx

Вернуть enforcement:

aa-enforce /etc/apparmor.d/usr.sbin.nginx

В complain-режиме AppArmor не блокирует действие, а только пишет, что было бы запрещено. Это удобно при внедрении: сначала наблюдаем, потом включаем реальные ограничения. ⁉️ Где AppArmor обычно проще: • быстрее понять логику профиля; • проще привязка к путям; • легче внедрять точечно; • удобнее для небольших команд; • меньше порог входа для обычного админа. ⁉️ Где SELinux сильнее: • более строгая модель через labels; • лучше подходит для больших стандартизированных сред; • глубже интегрирован в RHEL/CentOS/Rocky/Alma; • мощнее при сложных многоуровневых политиках; • меньше зависит от путей к файлам. ▪️ Практичный вывод такой: если у вас Ubuntu/Debian и нужно аккуратно усилить отдельные сервисы - часто проще начать с AppArmor. Если у вас RHEL-like инфраструктура и SELinux уже включен по умолчанию-— лучше не отключать его, а научиться с ним жить. Самая плохая практика:

setenforce 0

или полное отключение SELinux/AppArmor просто потому, что сервис не стартует. Это не решение проблемы, а выключение защитного слоя. Лучше временно перевести в мягкий режим и разобраться:

setenforce 0

для диагностики SELinux, но не как постоянное состояние. Для AppArmor аналогично:

aa-complain /etc/apparmor.d/profile-name

#linux #security 🧑‍💻 NetworkAdmin

👾 Policy Based Routing: несколько шлюзов без хаоса Обычная маршрутизация отвечает на вопрос: куда отправить пакет по адресу назначения? Но иногда этого мало. Например, на linux-сервере есть два провайдера, два интерфейса или несколько VPN. И нужно, чтобы часть трафика шла через один шлюз, а часть - через другой. Вот здесь появляется Policy Based Routing. PBR позволяет маршрутизировать трафик не только по destination IP, но и по дополнительным условиям: • source IP • интерфейс • fwmark • отдельная таблица маршрутизации • правила из ip rule ▪️ Классический пример:

eth0 -> 192.168.1.10/24 -> gateway 192.168.1.1
eth1 -> 10.10.10.10/24  -> gateway 10.10.10.1

Обычный default route может быть только один основной. А нам нужно, чтобы ответы с адреса 10.10.10.10 уходили обратно через 10.10.10.1, а не через первый шлюз. Создаем отдельную таблицу маршрутизации:

echo "100 isp2" >> /etc/iproute2/rt_tables

Добавляем маршрут в эту таблицу:

ip route add 10.10.10.0/24 dev eth1 src 10.10.10.10 table isp2
ip route add default via 10.10.10.1 dev eth1 table isp2

Теперь добавляем правило:

ip rule add from 10.10.10.10/32 table isp2

Смысл такой: если пакет идет от source IP 10.10.10.10, использовать таблицу isp2. Проверить правила:

ip rule show

Проверить маршруты в таблице:

ip route show table isp2

Проверить, как ядро выберет маршрут:

ip route get 8.8.8.8 from 10.10.10.10

Это одна из самых полезных команд при отладке PBR. ▪️ Где Policy Based Routing реально нужен: • сервер с несколькими провайдерами • отдельный выход в интернет для VPN-клиентов • маршрутизация по source IP • разделение служебного и пользовательского трафика • multi-WAN • асимметричные схемы • маршрутизация через разные туннели Можно использовать и fwmark, если нужно направлять трафик по меткам firewall. Например, пометить пакеты через iptables:

iptables -t mangle -A OUTPUT -p tcp --dport 443 -j MARK --set-mark 10

И отправить такие пакеты в отдельную таблицу:

ip rule add fwmark 10 table isp2

Так можно строить более гибкую логику: не только от какого IP, но и какой именно трафик. ❗️ При PBR особенно важно проверять не только маршруты, но и правила:

ip route # маршруты

ip rule # правила

Потому что решение принимает не одна таблица маршрутизации, а связка: rule -> table -> route #network #routing 🧑‍💻 NetworkAdmin

🎥 Вебинар: Выбор между Serverless и Kubernetes для AI-ворклоадов: как определить оптимальную платформу под задачу На открытом уроке рассмотрим: - В чем различаются Serverless-подходы и Kubernetes при работе с AI-ворклоадами; - Какие преимущества и ограничения есть у каждого подхода с точки зрения масштабируемости, стоимости и сложности эксплуатации; - Какие трейдоффы нужно учитывать при выборе платформы: холодный старт, управление состоянием, поддержка GPU; - Как обосновывать выбор архитектуры для разных AI-сценариев на практическом воркшопе. После занятия вы будете знать: - Как сравнивать Serverless и Kubernetes для различных AI-задач; - Как выбирать платформу оркестрации в зависимости от требований к нагрузке, бюджету и архитектуре решения; - Как учитывать ключевые технические ограничения при проектировании AI-инфраструктуры; - Как аргументированно обосновывать выбор платформы для задач масштабирования, потоковой обработки данных и построения гибридных сред. ⚠ Открытый урок проходит в преддверии старта курса «ИИ-архитектор».  👉Для участия зарегистрируйтесь: https://otus.pw/vtWN/ Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

systemd.path: запуск действия при изменении файла У systemd есть удобный механизм, о котором часто забывают - systemd.path. Он позволяет следить за событиями в файловой системе и запускать нужный .service, когда файл или каталог изменился. Например: изменился конфиг - перезапустить сервис появился файл - запустить обработчик обновился сертификат - скопировать его и сделать reload ▪️ Пример: реагируем на изменение конфига. Допустим, нужно выполнить действие при изменении файла:

/etc/daemon/daemon.conf

Создаем unit:

/etc/systemd/system/daemon.path
[Unit]
Description=Watch /etc/daemon/daemon.conf for changes

[Path]
PathModified=/etc/daemon/daemon.conf

[Install]
WantedBy=multi-user.target

Этот .path будет следить за изменением файла. ▪️ Сервис, который запустится по событию. Теперь создаем:

/etc/systemd/system/daemon.service

[Unit]
Description=Run action after daemon.conf change

[Service]
Type=oneshot
ExecStart=/bin/sh -c 'echo "daemon config changed at $(date)" >> /etc/daemon/restart.date'

Для примера сервис просто пишет дату события в файл:

/etc/daemon/restart.date

На практике в ExecStart можно указать любой скрипт: • перезапуск сервиса; • reload nginx; • копирование файла; • отправка алерта; • валидация конфига. ▪️ Включаем и запускаем

systemctl daemon-reload
systemctl enable --now daemon.path

Проверяем статус:

systemctl status daemon.path

Теперь изменяем файл:

echo "# test" >> /etc/daemon/daemon.conf

И смотрим результат:

cat /etc/daemon/restart.date

Должна появиться новая строка с текущей датой. ▪️ Почему это удобно. Главный плюс- все работает через systemd. Значит, события и ошибки можно смотреть привычно:

journalctl -u daemon.path
journalctl -u daemon.service

Не нужно писать отдельный бесконечный watcher на bash или городить cron. ▪️ Полезные директивы

[Path]
PathModified=/path/file

Срабатывает при изменении файла.

PathChanged=/path/file

Срабатывает после закрытия файла, в который была запись.

PathExists=/path/file

Срабатывает, когда файл или каталог появился.

PathExistsGlob=/path/*.conf

То же самое, но с маской.

DirectoryNotEmpty=/path/dir

Срабатывает, когда в пустом каталоге появился файл. #linux #systemd 🧑‍💻 NetworkAdmin