База 🪄

#юмор

🧑‍💻 NetworkAdmin

🕜 Как timezone ломает логи, cron и расследование инцидентов

Timezone кажется мелочью ровно до первого инцидента. Сервис упал в 03:10. Мониторинг сработал в 00:10. В логах приложения ошибка в 05:10. А cron, который точно должен был запуститься ночью, вообще отработал не тогда. И начинается расследование не аварии, а вопроса: "чье это вообще время?" Проблема в том, что в инфраструктуре легко получить несколько разных временных реальностей:

• сервер живет в UTC;
• приложение пишет логи в локальном времени;
• контейнер использует другой timezone;
• база хранит timestamp без offset;
• мониторинг показывает время браузера;
• cron работает по системному времени хоста;
• разработчик смотрит все из своей локальной зоны.
•
В итоге события вроде бы относятся к одному инциденту, но на таймлайне разъезжаются на 2–3 часа.

▪️ Проверить timezone на Linux:

timedatectl

Посмотреть текущую дату с зоной:

date

Проверить UTC:

date -u

Для systemd-журнала удобно явно указывать временное окно:

journalctl --since "2026-05-29 03:00" --until "2026-05-29 03:30"

Но важно понимать: это окно интерпретируется в локальном времени системы, с которой вы работаете.

С cron тоже есть нюанс. Если на сервере стоит Europe/Moscow, то запись:

0 3 * * * /opt/scripts/backup.sh

запустится в 03:00 по времени этого сервера.

Если такой же cron стоит на другом сервере в UTC, задача фактически поедет на несколько часов.

▪️ Что помогает не страдать:

• хранить серверное время в UTC;
• писать логи с timezone или offset;
• использовать ISO 8601 формат;
• не хранить timestamp без понимания зоны;
• явно документировать, в каком времени работает cron;
• синхронизировать время через NTP;
• при расследовании сразу строить единый таймлайн.

▪️ Хороший timestamp выглядит примерно так:

2026-05-29T03:10:42Z
# или так:
2026-05-29T06:10:42+03:00

🤩 Плохой timestamp:

2026-05-29 03:10:42

Потому что без timezone непонятно, это UTC, Москва, Хельсинки, время контейнера или фантазия приложения.

#linux #timezone

🧑‍💻 NetworkAdmin

📎 mergerfs: объединяем несколько дисков в одну точку монтирования

Иногда нужно быстро объединить несколько разных дисков в один общий каталог, но без RAID, LVM и сложной перестройки хранилища. Например, есть два диска, смонтированные так:

/mnt/sda
/mnt/sdb

А хочется получить одну общую точку: /mnt/storage. Чтобы приложения видели это как единое хранилище, а файлы физически раскладывались по исходным дискам. Для такой задачи хорошо подходит mergerfs. Это не RAID и не замена бэкапам. Это именно логическое объединение каталогов в одну файловую систему поверх уже существующих маунт поинтов.

▪️ Где это может пригодиться:

• видеосервер с архивом камер. Можно объединить несколько разнородных дисков и указать видеосерверу один общий путь.
• сервер со статикой или кэшем. Когда отказоустойчивость не критична, но нужно удобно расширять объем.
• backup-хранилище. Для некоторых сценариев бэкапов логическое объединение дисков вполне допустимо.
• сервер с дисками разного размера. Например, есть 2 ТБ + 3 ТБ, и хочется получить один общий каталог без плясок с RAID-массивами.

▪️ Пример на практике. Допустим, у нас есть два диска /dev/sda и /dev/sdb. Создаем разделы, файловые системы и монтируем их:

cfdisk /dev/sda
cfdisk /dev/sdb

mkfs.ext4 /dev/sda1
mkfs.ext4 /dev/sdb1

mkdir -p /mnt/sda1 /mnt/sdb1
mount /dev/sda1 /mnt/sda1
mount /dev/sdb1 /mnt/sdb1

Проверяем:

df -h

Теперь ставим mergerfs:

apt install mergerfs

Создаем общую точку монтирования:

mkdir -p /mnt/storage

И объединяем два диска:

mergerfs -o defaults,allow_other,category.create=mfs,moveonenospc=true,minfreespace=1G \
  /mnt/sda1:/mnt/sdb1 /mnt/storage

После этого /mnt/storage будет показывать суммарный объем двух дисков. Проверяем:

df -h | grep storage

▪️ Что означают опции:

allow_other - Позволяет видеть файловую систему не только root, но и другим пользователям.
category.create=mfs - Новые файлы создаются там, где больше свободного места. mfs - most free space.
moveonenospc=true - Если при записи на выбранном диске закончилось место, mergerfs попробует перенести файл на другой диск.
minfreespace=1G - Если на диске осталось меньше 1 ГБ, новые файлы туда больше не пишутся.

▪️ Проверить распределение можно простыми файлами:

dd if=/dev/zero of=/mnt/storage/tempfile1 bs=1M count=1000
dd if=/dev/zero of=/mnt/storage/tempfile2 bs=1M count=1000

ls /mnt/storage
ls /mnt/sda1
ls /mnt/sdb1

Файлы будут видны в общей точке /mnt/storage, но физически лежать на одном из исходных дисков. Это важное отличие от RAID: каждый файл хранится целиком на конкретном диске, а не размазывается блоками по всем устройствам.

▪️ Плюсы такого подхода:

• можно объединять диски разного размера
• не нужно пересобирать массив
• легко добавить новый диск
• файлы остаются читаемыми напрямую с исходных mount point’ов
• удобно для статичных данных, кэша, архивов и бэкапов

▪️ Но есть и ограничения. Если один диск умрет, вы потеряете файлы, которые лежали именно на нем. Остальные диски при этом останутся читаемыми.
То есть mergerfs дает удобство единого пространства, но не дает отказоустойчивость. Для постоянного подключения mergerfs можно добавить в /etc/fstab или оформить через systemd mount. Это уже зависит от того, как вы привыкли управлять маунтами.

#mergerfs #storage

🧑‍💻 NetworkAdmin

📷 QR-код прямо в консоли Linux или Windows Terminal

Иногда нужно быстро передать ссылку, Wi-Fi пароль, токен для теста или короткий текст с сервера на телефон. Можно не открывать браузер и не генерировать картинку. QR-код можно вывести прямо в терминале. В linux для этого удобно использовать qrencode.

▪️ Установка:

apt install qrencode

▪️ Сгенерировать QR-код в консоли:

qrencode -t ANSIUTF8 "https://networkadmin.ru"

В терминале появится QR-код, который можно сразу отсканировать телефоном.

Если нужен PNG-файл:

qrencode -o qrcode.png "https://networkadmin.ru"

Можно передавать данные из pipe:

echo "ssh user@10.10.10.5" | qrencode -t ANSIUTF8

▪️ В Windows Terminal тоже можно использовать этот подход через WSL. Например, в Ubuntu внутри WSL:

sudo apt install qrencode
qrencode -t ANSIUTF8 "https://networkadmin.ru"

Если WSL нет, можно использовать PowerShell-модуль или сторонние утилиты, но через WSL обычно быстрее и проще.

⚠️ Не стоит выводить в QR-код секреты, которые могут попасть в историю команд, скриншоты терминала или логи. Для чувствительных данных лучше отключать сохранение истории или использовать временные файлы аккуратно.

#terminal #qrcode

🧑‍💻 NetworkAdmin

🔒 Почему стандартной парольной политики AD часто недостаточно

В Active Directory можно настроить длину пароля, срок действия, историю и требования к сложности. Но есть неприятный нюанс: стандартная политика сложности не понимает, что такое плохой, но формально сложный пароль. Например:

Qwerty123
P@ssw0rd
Company2026
Admin@123

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

Фактически - это словарные и шаблонные пароли, которые легко угадываются или быстро подбираются. Проблема в том, что стандартная парольная политика AD проверяет структуру пароля, но плохо понимает его смысл. То есть пароль вида: P@ssw0rd2026! может выглядеть сложным для политики, но быть очень слабым с точки зрения реальной безопасности.

▪️ Как это можно исправить? В Windows смена пароля проходит через LSA. На контроллере домена в цепочку проверки можно добавить дополнительный password filter - компонент, который будет проверять новый пароль перед установкой. Такой фильтр может запретить пароль, если он:

• входит в список запрещенных слов
• похож на название компании
• содержит имя пользователя
• совпадает с типовыми шаблонами
• найден в базе скомпрометированных паролей
• слишком предсказуемо меняется по годам или сезонам

▪️ Из open-source решений для AD часто смотрят в сторону:

• PassFiltEx
• Lithnet Password Protection for Active Directory

Оба варианта позволяют расширить стандартную проверку паролей и отсеивать то, что обычная политика AD пропускает. Например, можно запретить пароли, связанные с: названием компании, доменом, брендами, городами, типовыми словами вроде Password, Qwerty, Admin, годовыми шаблонами вроде 2025, 2026, известными утечками паролей. Это особенно полезно в инфраструктурах, где пользователи любят обновлять пароль по принципу: Winter2025! Spring2026! Company2026!

С точки зрения пользователя - пароль новый. С точки зрения атакующего - почти тот же самый шаблон.

#windows #activedirectory

🧑‍💻 NetworkAdmin

Трезвый DevOps - уже не DevOps

#юмор

🧑‍💻 NetworkAdmin

Как смотреть потоки процесса через ps, /proc и strace

Обычно при работе с ps мы смотрим процесс по PID или грепаем по имени:

ps -p 524 -o %mem,%cpu,cmd
ps ax | grep prometheus

Но часто удобнее сразу указать имя процесса через -C. Например, посмотрим потоки prometheus:

ps -T -C prometheus

PID   SPID TTY      TIME     CMD
525   525  ?        00:55:34 prometheus
525   803  ?        00:03:10 prometheus
525   808  ?        00:09:22 prometheus
525   1054 ?        00:08:44 prometheus

PID - ID основного процесса
SPID - ID конкретного потока

▪️ Посчитать количество потоков

ps -T -C zabbix_server | wc -l

Важно: количество потоков и количество процессов - не одно и то же. Например:

ps -T -C zabbix_server | wc -l
ps ax | grep zabbix_server | wc -l

Результаты могут сильно отличаться.

▪️ Посмотреть нагрузку по потокам. Если приложение тормозит, полезно вывести CPU/MEM с разбивкой по потокам. Например, для процесса с PID 508:

ps -L -o spid,%mem,%cpu,cmd 508

SPID  %MEM  %CPU  CMD
1070  0.6   0.0   /usr/bin/python3 /usr/bin/fail2ban-server -xf start
1071  0.6   0.1   /usr/bin/python3 /usr/bin/fail2ban-server -xf start
1077  0.6   0.3   /usr/bin/python3 /usr/bin/fail2ban-server -xf start

Так можно увидеть, какой именно поток ест CPU.

▪️ Найти подробности потока через /proc. Если знаем PID процесса и SPID потока:

cat /proc/508/task/1077/stat

В начале строки можно увидеть имя потока, например:

1077 (f2b/f.wp-login)

У Fail2ban это может подсказать, какой jail сейчас нагружает систему. Больше информации:

cat /proc/508/task/1077/status

▪️ Подключить strace к конкретному потоку. strace умеет подключаться не только к PID процесса, но и к SPID потока:

strace -p 1077

На нагруженном сервере вывод быстро завалит консоль, поэтому лучше писать в файл:

strace -p 1077 -o ~/strace.out

Можно ограничить типы системных вызовов. Открытие файлов и чтение:

strace -p 1077 -e trace=openat,read

Запись:

strace -p 1077 -e trace=write

Сеть:

strace -p 1077 -e trace=connect,recvfrom,sendto

▪️ Через htop. В htop тоже можно смотреть трейсы. Выберите нужный процесс или поток и нажмите: s. Если strace установлен, htop покажет системные вызовы в реальном времени.

#linux #htop

🧑‍💻 NetworkAdmin

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

👾 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

💚 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

📱 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

Этот мир уже не будет прежним

#юмор

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

😑 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

🌟 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

👍 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

❓ 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

Лапшу заказывали?

#юмор

🧑‍💻 NetworkAdmin

С днём системного администратора! 🏆

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

Желаю стабильного аптайма, спокойных дежурств, крепких нервов и достойной зарплаты. За localhost! 🍻🍷

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