tgindex

NetworkAdmin.ru

описание

Авторский блог про сетевое и системное администрирование. Сайт: networkadmin.ru Реклама: @dad_admin Биржа: https://telega.in/c/networkadminru

← к каналу@networkadminru
4 708
подписчиков
Охват к подписчикам
22,2%
ERR
Реакции к просмотрам
0,76%
485 на 50 постов
Пересылки к просмотрам
3,05%
1 952
Постов в день
0,7
всего 119

Где отзываются чаще

доля реакций к просмотрам
  • 5 авг.🔥 Короткий вывод IP-адресов без простыни В linux давно уже привычнее смотреть сетевые настройки через ip, а не через старый ifconfig. Обычно для просмотра адресов используют: ip a Команда рабочая, подробная, показывает все. Но иногда этого "все" слишком много. Нужно быстро увидеть: • интерфейсы • их состояние • IPv4/IPv6 адреса • без лишних строк и простыни вывода Для этого у ip есть очень удобный ключ: ip -br a -br означает brief, то есть краткий вывод. ▪️ Пример: ip -br a lo UNKNOWN 127.0.0.1/8 ::1/128 eth0 UP 172.18.107.235/20 fe80::215:5dff:fe0d:7101/64 eth1 UP 192.168.101.2/24 fe80::215:5dff:fe0d:7105/64 docker0 DOWN 172.17.0.1/16 Сразу видно, какой интерфейс поднят, какой адрес назначен и где есть IPv6. ▪️ Если нужны только IPv4-адреса: ip -br -4 a lo UNKNOWN 127.0.0.1/8 eth0 UP 172.18.107.235/20 eth1 UP 192.168.101.2/24 docker0 DOWN 172.17.0.1/16 ▪️ Только IPv6: ip -br -6 a Это реально удобнее, когда на сервере много интерфейсов: физические NIC, VLAN, bridge, docker-сети, loopback. Не нужно глазами вылавливать IP среди десятков строк. Краткий режим работает не только с адресами. ▪️ Посмотреть интерфейсы и MAC-адреса: ip -br link или короче: ip -br l ▪️ Посмотреть соседей ARP/Neighbor Cache: ip -br neigh или: ip -br n ▪️ Маршруты, как обычно: ip r А если нужно понять, куда ядро отправит пакет до конкретного адреса: ip route get 8.8.8.8 Это часто полезнее, чем просто смотреть всю таблицу маршрутизации. ▪️ Что стоит запомнить: ip -br a ip -br -4 a ip -br -6 a ip -br l ip -br n ip r ip route get 8.8.8.8 #linux #network 🧑‍💻 NetworkAdmin1,97%
  • 31 июл.С ДНЕМ СИСАДМИНА! 👍 По традиции в этот великий день мы смотрим классику 🎬 😎 localhost › IT-юмор1,67%
  • 10 авг.▶️ systemd socket activation: запуск сервиса только при реальном запросе Обычно сервис в linux запускается заранее и постоянно висит в памяти: systemctl start myapp Даже если к нему никто не обращается, процесс уже работает, занимает ресурсы и ждет подключения. Но в systemd есть другой подход - socket activation. Идея простая: • systemd заранее открывает socket или порт; • сам сервис пока не запущен; • приходит первый запрос; • systemd стартует сервис; • сервис получает уже открытое соединение или socket. То есть приложение запускается не на всякий случай, а только когда к нему реально обратились. Классический пример - ssh.socket, cups.socket, docker.socket и разные локальные демоны. Посмотреть активные сокеты: systemctl list-sockets Статус конкретного socket-unit: systemctl status myapp.socket ▪️ Пример. Создаем /etc/systemd/system/myapp.socket: [Unit] Description=MyApp socket [Socket] ListenStream=8080 [Install] WantedBy=sockets.target И сервис /etc/systemd/system/myapp.service: [Unit] Description=MyApp service [Service] ExecStart=/usr/local/bin/myapp Включаем именно сокет, а не service: systemctl daemon-reload systemctl enable --now myapp.socket Теперь порт 8080 уже слушается, но сам myapp.service может быть не запущен. Проверяем: ss -lntp | grep 8080 systemctl status myapp.service Как только придет подключение на порт 8080, systemd запустит myapp.service. ▪️ Зачем это нужно: • экономия ресурсов; • ленивый запуск редко используемых сервисов; • ускорение boot-процесса; • возможность принимать соединения до старта приложения; • меньше ручной логики вокруг кто должен стартовать первым; • удобная модель для локальных демонов и admin-инструментов. Особенно удобно, когда сервис нужен редко, но должен быть доступен сразу при обращении. Socket activation работает не только с TCP-портами. Можно слушать Unix socket: [Socket] ListenStream=/run/myapp.sock Это часто используют для локального взаимодействия между процессами. #systemd #socketactivation 🧑‍💻 NetworkAdmin1,47%
  • 29 июл.👍 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 🧑‍💻 NetworkAdmin1,32%
  • 31 июл.С днём системного администратора! 🏆 Пусть серверы не падают, бэкапы восстанавливаются, мониторинг молчит, а пользователи хотя бы иногда пробуют перезагрузить компьютер до обращения в поддержку. Желаю стабильного аптайма, спокойных дежурств, крепких нервов и достойной зарплаты. За localhost! 🍻🍷 🧑‍💻 NetworkAdmin1,28%
  • 11:25👁 Conntrack в Linux: как stateful firewall может стать узким местом Когда на linux работает NAT или stateful firewall, почти всегда где-то рядом есть conntrack. Conntrack - это механизм ядра, который отслеживает сетевые соединения. Он нужен, чтобы firewall понимал не только отдельный пакет, но и его состояние: • это новое соединение; • это ответ на уже разрешенное соединение; • это часть существующей сессии; • это странный или неожиданный пакет. Именно поэтому в iptables/nftables часто встречается логика: -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT или в nftables: ct state established,related accept Смысл простой: если соединение уже разрешено, ответы по нему пропускаем автоматически. Без conntrack не было бы привычного NAT, нормального stateful firewall и многих схем с masquerade. Но у conntrack есть цена. Каждое отслеживаемое соединение попадает в таблицу conntrack. Если соединений много, таблица растет. Если таблица переполнена, начинаются неприятности. ▪️ Типичные симптомы: • новые подключения отваливаются; • NAT начинает работать нестабильно; • часть клиентов не может открыть сайт; • DNS-запросы теряются; • в логах появляются сообщения про переполнение conntrack; • снаружи кажется, что "сеть иногда моргает". ▪️ Проверить текущий лимит: sysctl net.netfilter.nf_conntrack_max Посмотреть текущее количество записей: cat /proc/sys/net/netfilter/nf_conntrack_count Если значение nf_conntrack_count регулярно подходит к nf_conntrack_max, система близка к проблемам. Еще можно посмотреть события в kernel log: dmesg | grep -i conntrack Типичная ошибка: nf_conntrack: table full, dropping packet. Это уже прямой сигнал: таблица заполнена, новые пакеты начинают отбрасываться. ▪️ Посмотреть записи conntrack можно так: conntrack -L Но на нагруженных серверах с этим осторожно: вывод может быть огромным. Для общей статистики лучше: conntrack -S Где conntrack часто становится узким местом: • NAT-шлюзы • Kubernetes-ноды • Docker-хосты • DNS-рекурсоры • reverse proxy под большой нагрузкой • серверы с большим количеством коротких соединений ▪️ Самый очевидный способ лечения - это увеличить лимит: sysctl -w net.netfilter.nf_conntrack_max=262144 Для постоянной настройки: echo "net.netfilter.nf_conntrack_max=262144" > /etc/sysctl.d/99-conntrack.conf sysctl --system Но просто поднять лимит не всегда решение. Нужно понимать, почему таблица растет: слишком много коротких соединений, DDoS или сканирование, долгие таймауты или что-то другое. Иногда помогает настройка timeout’ов. Например, для TCP established: sysctl net.netfilter.nf_conntrack_tcp_timeout_established Для UDP: sysctl net.netfilter.nf_conntrack_udp_timeout sysctl net.netfilter.nf_conntrack_udp_timeout_stream Но менять таймауты нужно аккуратно. Слишком короткие значения могут ломать нормальные долгоживущие соединения. #linux #network #conntrack 🧑‍💻 NetworkAdmin1,26%
  • 6 авг.⚙️ MBR2GPT: как перевести Windows с Legacy BIOS на UEFI без переустановки Иногда windows на современном железе оказывается установленной в режиме Legacy BIOS / CSM. Работает и ладно. Но есть нюанс: для нормальной UEFI-загрузки нужен диск с таблицей разделов GPT, а не старый MBR. Почему вообще стоит переходить на UEFI + GPT: • поддержка дисков больше 2 ТБ; • больше 4 основных разделов без костылей; • современный механизм загрузки; • поддержка Secure Boot; • меньше зависимости от режима совместимости CSM. Secure Boot особенно важен: он помогает защититься от подмены загрузчика и запуска вредоносного кода до старта ОС. Если Windows уже установлена в legacy-режиме, не всегда нужно переустанавливать систему. Начиная с Windows 10 1703, есть встроенная утилита: mbr2gpt Она умеет конвертировать системный диск из MBR в GPT без удаления данных. Сначала проверяем, в каком режиме загружена Windows: $env:firmware_type Если видим: Legacy, значит система загружена в режиме совместимости. ▪️ Проверяем разметку диска и разделы: Get-Disk | Get-Partition Важно: на системном MBR-диске обычно должно быть не больше 3 первичных разделов, потому что mbr2gpt нужно место для создания EFI System Partition. ▪️ Проверяем возможность конвертации: mbr2gpt /validate /allowFullOS ▪️ Если проверка прошла успешно, запускаем конвертацию: mbr2gpt /convert /allowFullOS После этого утилита: • проверит структуру диска • создаст EFI-раздел • сконвертирует MBR в GPT • добавит UEFI-загрузчик Windows • обновит загрузочные данные Дальше нужно перезагрузить компьютер или сервер и зайти в настройки прошивки. Там меняем режим загрузки: Legacy / CSM -> UEFI Если есть опция boot order, выбираем Windows Boot Manager для нужного диска. После успешной загрузки можно снова проверить режим: $env:firmware_type Теперь должно быть: UEFI #windows #uefi #gpt 🧑‍💻 NetworkAdmin1,23%
  • 11 авг.🌀 Retry-логика в bash: как аккуратно повторять нестабильные операции В админских скриптах не все ошибки означают, что все окончательно сломалось. Иногда команда падает из-за временной проблемы: • сеть моргнула; • API вернул timeout; • DNS не ответил с первого раза; • файл еще не появился; • сервис еще не успел подняться; • удаленный хост временно недоступен. В таких случаях полезна retry-логика - аккуратный повтор операции несколько раз перед тем, как считать задачу проваленной. 🤩 Плохой вариант: curl -fsS https://api.networkadmin.ru/deploy Если запрос один раз упал - весь скрипт завершился. 🤩 Лучше сделать повтор: for i in {1..5}; do if curl -fsS https://api.networkadmin.ru/deploy; then echo "success" break fi echo "attempt $i failed, retrying..." sleep 5 done Но у такого варианта есть проблема: после всех неудачных попыток скрипт может продолжить работу, если явно не обработать итог. 🤩 Более аккуратный вариант - вынести retry в функцию: retry() { local max_attempts="$1" local delay="$2" shift 2 local attempt=1 until "$@"; do if (( attempt >= max_attempts )); then echo "command failed after $attempt attempts: $*" >&2 return 1 fi echo "attempt $attempt failed, retrying in ${delay}s..." >&2 sleep "$delay" ((attempt++)) done } Теперь можно использовать так: retry 5 3 curl -fsS https://api.networkadmin.ru/health Или дождаться доступности сервиса: retry 10 2 nc -z 127.0.0.1 5432 5 или 10 - количество попыток 3 или 2 - пауза между попытками дальше идет команда, которую нужно повторять ▪️ Для операций с сетью часто полезен backoff - увеличение паузы после каждой ошибки: retry_backoff() { local max_attempts="$1" local delay="$2" shift 2 local attempt=1 until "$@"; do if (( attempt >= max_attempts )); then echo "command failed after $attempt attempts: $*" >&2 return 1 fi echo "attempt $attempt failed, retrying in ${delay}s..." >&2 sleep "$delay" delay=$((delay * 2)) ((attempt++)) done } Пример: retry_backoff 5 2 curl -fsS https://api.networkadmin.ru/status Паузы будут примерно такими: 2s -> 4s -> 8s -> 16s Это лучше, чем агрессивно долбить нестабильный сервис каждые 100 мс. #bash #automation 🧑‍💻 NetworkAdmin1,19%
  • 2 апр.без подписи0,99%
  • 28 июл.🌟 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 🧑‍💻 NetworkAdmin0,97%
  • 19 маябез подписи0,96%
  • 3 авг.💚 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 🧑‍💻 NetworkAdmin0,95%