NetworkAdmin.ru

📺 Скриншот рабочего стола пользователя через PowerShell и PsExec Иногда техподдержке нужно быстро понять, что происходит на рабочем месте пользователя. Например: • пользователь не может нормально описать ошибку; • окно с сообщением быстро исчезает; • приложение зависло в нестандартном состоянии; • нужно увидеть текущий экран без полноценного подключения по RDP/AnyDesk; • удаленный просмотр экрана в компании не используется или ограничен. В таких случаях можно сделать простой механизм: по заявке и с согласия пользователя получить скриншот его текущего рабочего стола и сохранить PNG-файл в сетевую папку. Один из вариантов - PowerShell-скрипт, который делает снимок экрана в интерактивной сессии пользователя, и удаленный запуск через PsExec. Пример запуска: .\PsExec.exe -s -i 1 \\pk-ww01 powershell.exe ` -ExecutionPolicy Bypass ` -WindowStyle Hidden ` -File "\\fs01\scripts\PS-Capture-Local-Screen.ps1" \\pk-ww01 - удаленная рабочая станция -s - запуск от имени Local System -i 1 - запуск в интерактивной сессии пользователя powershell.exe - выполнение PowerShell-скрипта \\fs01\scripts\... - путь к скрипту на файловом сервере Сам скрипт делает снимок рабочего стола и сохраняет файл, например, в общую сетевую папку: \\fs01\support\screenshots\. И дальше сотрудник техподдержки может открыть PNG-файл и посмотреть, что было на экране в момент обращения. #powershell #psexec 🧑‍💻 NetworkAdmin

📎 rsync: полезные ключи для бэкапов и аккуратной синхронизации rsync - одна из тех утилит, которые годами живут в админских скриптах и не теряют актуальности. Ее любят за простую идею: сравнить источник и приемник, а потом скопировать только то, что реально изменилось. Особенно хорошо rsync показывает себя на каталогах с большим количеством файлов. Если нужно синхронизировать два хранилища с сотнями тысяч или миллионами объектов, обычное копирование быстро превращается в боль. У rsync есть минусы. Главный - он не становится магически многопоточным. Но для задач, где нужно копировать файлы как есть, без упаковки, дедупликации и сложных backup-форматов, это все еще очень удобный инструмент. Ниже несколько ключей, которые полезно помнить. ▪️ --backup и --backup-dir. Обычно при синхронизации мы хотим привести приемник к состоянию источника. Например: rsync -av --delete source/ dest/ Но для бэкапов часто важно не просто удалить старые или измененные файлы, а сохранить их отдельно. Для этого есть связка: --backup --backup-dir=/path/to/old-files Пример: rsync -av --delete --backup \ --backup-dir="/mnt/data/backup/bases_increment/$(date +%F)/" \ back_user@10.20.5.22:/var/lib/pgpro/backup/ \ /mnt/data/backup/bases/ \ >> "/var/log/rsync/1Csrv-$(date +%F).log" • новые файлы попадут в основной каталог бэкапа; • файлы, которые должны быть удалены или заменены, будут перемещены в backup-dir; • изменения за конкретный день окажутся в отдельной папке; • глубину хранения можно потом регулировать через find. Это удобно, если нужно видеть, что именно изменилось между запусками. Например, если на сайте кто-то заменил несколько файлов, при очередном бэкапе старые версии можно будет найти в отдельном каталоге. ▪️ --progress. Ключ показывает прогресс копирования файлов: rsync -av --progress source/ dest/ В логе будет видно размер, скорость и время передачи. Это удобно для крупных файлов: дампов баз, архивов, образов. Но если файлов очень много и они мелкие, --progress может сильно засорить вывод. В таких случаях лучше использовать более спокойный режим: rsync -av --info=progress2 source/ dest/ или вообще убрать прогресс из cron-задачи. ▪️ --ignore-existing. Этот ключ полезен, когда нужно восстановить только отсутствующие файлы и не трогать то, что уже есть в целевой директории. Например, кто-то удалил часть файлов в /var/www, а мы хотим вернуть недостающее из бэкапа: rsync -av --ignore-existing \ back_user@10.30.7.5:/mnt/backup/www/ \ /var/www/ • отсутствующие файлы будут скопированы; • существующие файлы не будут перезаписаны; • даже если в бэкапе версия новее, rsync ее не тронет. Это хороший вариант для аккуратного "докинуть недостающее". ▪️ --update. Копирует файл только если версия в источнике новее, чем в приемнике. rsync -av --update \ back_user@10.30.7.5:/mnt/backup/www/ \ /var/www/ Если файла в приемнике нет - он будет скопирован. Если файл уже есть и он новее, rsync его не перезапишет. Этот ключ полезен, когда данные собираются из разных источников и нужно оставить самые свежие версии файлов. ▪️ --dry-run. Один из самых важных ключей, особенно если в команде есть --delete. rsync -av --delete --dry-run source/ dest/ или короче: rsync -avn --delete source/ dest/ --dry-run показывает, что rsync сделал бы, но ничего реально не меняет. Это спасает от классической ошибки: перепутали источник и приемник - и удалили не там. Перед первой настройкой бэкапа или синхронизации лучше всегда запускать тестовый прогон. ▪️ Отдельно стоит помнить про слеш в конце пути. rsync -av /data/source/ /backup/source/ копирует содержимое каталога source. А так: rsync -av /data/source /backup/ копирует сам каталог source внутрь /backup. На первый взгляд мелочь, но из-за этого часто получают не ту структуру директорий. #linux #rsync 🧑‍💻 NetworkAdmin

🌀 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 🧑‍💻 NetworkAdmin

▶️ 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 🧑‍💻 NetworkAdmin

За пачку вискаса все настрою 😮 #юмор 🧑‍💻 NetworkAdmin

⚙️ 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 🧑‍💻 NetworkAdmin

🔥 Короткий вывод 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 🧑‍💻 NetworkAdmin

🔖 DNS TTL: почему запись поменяли, а пользователи всё еще идут на старый IP Классическая ситуация при миграции сервиса: DNS-запись уже поменяли. На авторитативном DNS новый IP виден. А часть пользователей все равно попадает на старый сервер. Первое желание - это сказать: "DNS не обновился." Но чаще всего DNS как раз работает правильно. Просто сработал TTL. TTL - это Time To Live, время жизни DNS-записи в кэше. Когда резолвер получил ответ, он имеет право хранить его указанное количество секунд и не спрашивать авторитативный DNS заново. Например: app.networkadmin.ru. 3600 IN A 203.0.113.10 3600 означает, что запись можно кэшировать 3600 секунд, то есть 1 час. Если вы поменяли IP через 5 минут после того, как чей-то DNS-резолвер закэшировал старый ответ, он может продолжать отдавать старый IP до истечения TTL. И это нормально. ▪️ Где может застрять старый DNS-ответ: • recursive DNS провайдера • корпоративный DNS • DNS-кэш на роутере • локальный кэш ОС • браузер • приложение с собственным DNS-кэшем • контейнер или runtime • CDN / reverse proxy Поэтому один пользователь уже видит новый IP, а другой - старый. ▪️ Проверка. Проверять лучше не просто через ping, а через dig. Посмотреть текущий ответ обычного резолвера: dig app.networkadmin.ru Спросить конкретный публичный DNS: dig @8.8.8.8 app.networkadmin.ru dig @1.1.1.1 app.networkadmin.ru Спросить авторитативный DNS напрямую: dig NS networkadmin.ru dig @ns1.networkadmin.ru app.networkadmin.ru Во время диагностики важно смотреть не только IP, но и оставшийся TTL: app.networkadmin.ru. 1842 IN A 203.0.113.10 Если TTL уменьшается - это кэшированный ответ. Если на авторитативном DNS уже новый IP, а у клиента старый - значит где-то по пути еще живет старый кэш. ▪️ Как правильно готовить миграцию: • Заранее уменьшить TTL, например до 60–300 секунд. • Подождать старый TTL, чтобы старые кэши успели обновиться. • Поменять DNS-запись. • Проверить ответы с разных резолверов. • Не выключать старый сервер сразу. Например, если сейчас TTL был 24 часа, нельзя просто поставить TTL 60 и через минуту ждать мгновенного переключения. Сначала нужно дождаться, пока старое значение TTL доживет в кэшах. ▪️ Частая ошибка: • Сегодня в 12:00 TTL был 86400 • Сегодня в 12:05 поставили TTL 60 • Сегодня в 12:10 поменяли IP А пользователи все еще могут ходить на старый IP до следующего дня, потому что часть резолверов закэшировала запись еще с TTL 86400. #dns #ttl #network 🧑‍💻 NetworkAdmin

💚 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

🌟 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

⚙️ 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