💿 WinPE не видит диски: загрузка драйверов

В WIM-образе WinPE содержится только минимальный набор универсальных драйверов. Их хватает для базового обнаружения оборудования, но в реальных инфраструктурах этого часто недостаточно.

Поэтому иногда возникает ситуация, когда: установщик Windows, загрузочная среда WinPE или среда восстановления WinRE не видят локальные диски или сетевые адаптеры.

▪️ Типичный пример - миграция виртуальной машины. После переноса ВМ с ESXi на Proxmox в гостевой Windows может не оказаться драйверов VirtIO. В этом случае при загрузке система падает с ошибкой:

0x0000007B: INACCESSIBLE_BOOT_DEVICE

Причина простая: Windows не понимает, как работать с новым SCSI-контроллером. Лучшее решение - установить VirtIO-драйверы в систему до начала миграции. Но если это уже произошло, проблему можно исправить через WinPE.

▪️ Загрузка драйвера прямо в WinPE. Смонтируйте ISO с драйверами VirtIO и загрузите нужный драйвер вручную:

drvload d:\vioscsi\2k22\amd64\vioscsi.inf

Команда загружает драйвер в память среды WinPE.

Проверить, что драйвер появился:

pnputil /enum-drivers

После этого WinPE должен увидеть диск с установленной Windows.

▪️ Добавляем драйвер в офлайн систему. Чтобы Windows смогла нормально загрузиться, добавим драйвер прямо в офлайн-образ системы:

DISM /Image:C:\ /Add-Driver /Driver:D:\vioscsi\2k22\amd64\vioscsi.inf

После этого драйвер VirtIO будет установлен в систему, и Windows сможет корректно работать с паравиртуализированным SCSI-контроллером.

⚠️ Такой подход полезен не только для VirtIO. Через drvload и DISM можно подгружать сетевые, RAID и NVMe драйверы, если WinPE их не распознает.

#windows #winpe

🧑‍💻 NetworkAdmin

🤔 Idempotency: как не сломать прод повторным запуском

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

Именно здесь важна идемпотентность. Идемпотентный сценарий - это когда команду, скрипт или automation можно запускать повторно, а результат будет тем же, что и после первого успешного запуска. Проще говоря: повторный запуск не должен ломать систему.

▪️ Где чаще всего все ломается:

useradd без проверки - пользователь уже существует
echo ... >> file - строки дублируются при каждом запуске
mkdir dir без -p - ошибка на втором запуске
правила firewall добавляются снова и снова
конфиг не заменяется, а “дописывается сверху”
миграция БД запускается повторно без защиты

▪️ Плохой пример:

echo "backup enabled" >> /etc/myapp.conf
useradd deploy
systemctl restart myapp

На первом запуске вроде все нормально. На втором в конфиге уже дубль, useradd падает, поведение становится непредсказуемым.

▪️ Более здоровый подход:

grep -q "^backup enabled$" /etc/myapp.conf || echo "backup enabled" >> /etc/myapp.conf
id deploy >/dev/null 2>&1 || useradd deploy
systemctl try-restart myapp

Смысл простой: сначала проверка состояния, потом изменение только если нужно.

Вот главный принцип идемпотентности в админке: не "сделай действие", а "приведи систему к нужному состоянию".

То есть не: создай каталог, добавь строку или создай пользователя
а: убедись, что каталог существует, убедись, что строка есть в конфиге, убедись, что пользователь создан.

Именно поэтому Ansible так любят: он по умолчанию мыслит состоянием, а не одноразовыми действиями.

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

проверки перед изменением
безопасные команды вроде mkdir -p
ln -sfn вместо слепого ln -s
шаблоны конфигов вместо бесконечного echo >>
явная логика: если уже сделано - пропусти
аккуратная работа с exit code

Очень частая ошибка - считать, что скрипт нормальный, если он успешно отработал один раз.

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

Идемпотентность не означает, что скрипт вообще ничего не делает при повторном запуске. Она означает, что он не вносит лишних изменений и не уводит систему в другое состояние. Когда automation пишется без этого принципа, любой повторный запуск превращается в лотерею.

#linux #automation

🧑‍💻 NetworkAdmin

👀 Security Onion/Wazuh: стоит ли тащить SIEM в небольшую сеть

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

Wazuh и Security Onion - это не одно и то же.

Wazuh - это open source платформа с упором на XDR/SIEM, агентский сбор событий, контроль целостности, уязвимости и корреляцию. У нее есть all-in-one deployment, который сам вендор считает подходящим небольших сред.

Security Onion - это уже более тяжелая история про network visibility, IDS, логи, кейс-менеджмент и полноценный security stack. Даже standalone-установка требует минимум 24 GB RAM, 4 vCPU и 200 GB диска, а для небольшого объема трафика сами разработчики советуют скорее 32 GB RAM и выше.

▪️ Что это значит по-простому:

• если у вас 10–50 серверов/рабочих станций и нужен порядок в логах, алертах и FIM - чаще разумнее смотреть в Wazuh. Для маленькой команды он обычно реалистичнее по железу и внедрению, плюс у него есть all-in-one и даже Docker single-node с порогом от 4 CPU, 8 GB RAM и 50 GB диска.

• если вы хотите именно сетевой мониторинг, IDS/NDR и разбор трафика, тогда Security Onion интереснее, но и цена входа по ресурсам и сопровождению заметно выше.

Главная ошибка маленьких сетей - тащить SIEM потому что так надо, а потом:

никто не разбирает алерты
retention урезан до боли
storage забивается за пару дней
ложные срабатывания быстро надоедают
платформа живет сама по себе, без реальной пользы

Вывод примерно такой:

в небольшую сеть SIEM стоит тащить только если есть конкретная цель: контроль критичных логов, аудит, FIM, базовая корреляция, расследование инцидентов.

Wazuh в такой роли обычно выглядит практичнее. Security Onion - уже когда вам действительно нужен сетевой security monitoring, а не просто хотим SIEM как у больших.

#security #siem

🧑‍💻 NetworkAdmin

👇 Типовые ошибки при монтировании дисков

/etc/fstab - один из тех файлов, которые выглядят безобидно ровно до первой ошибки. Одна кривая строка и после перезагрузки сервер может внезапно уйти в emergency mode вместо нормальной загрузки. Поэтому fstab - это не то место, где стоит править на глаз.

Что обычно описывают в fstab:

локальные диски;
LVM-разделы;
UUID устройств;
NFS/SMB-шары;
swap;
временные файловые системы.

Типовая строка выглядит так:

UUID=xxxx-xxxx  /data  ext4  defaults  0  2

▪️ Где чаще всего ошибаются:

1️⃣ Используют /dev/sdX вместо UUID. После перезагрузки или изменения порядка устройств диск может стать уже не sdb, а sdc. И mount сломается. Лучше так:

blkid

И в fstab использовать UUID=.

2️⃣ Путают точку монтирования. Каталог /data должен существовать заранее. Если его нет, система может не примонтировать раздел как ожидалось.

3️⃣ Ошибаются в типе файловой системы. Написали ext4 вместо xfs, xfs вместо ext4 - получили ошибку на загрузке.

4️⃣ Бездумно ставят defaults везде подряд. Для локального диска это нормально, но для NFS, CIFS, removable media или специальных mount’ов часто нужны отдельные опции.

5️⃣ Ломают загрузку сетевыми маунтами. Очень частая история: добавили NFS или SMB в fstab, сеть при старте еще не поднялась, и система зависает на boot.

Для таких случаев обычно используют:

_netdev,nofail,x-systemd.automount

6️⃣ Забывают про nofail для некритичных дисков. Если том не жизненно важен, лучше не валить из-за него загрузку всей системы.

7️⃣ Неправильно ставят последние два поля. Напоминание: предпоследнее - dump, а последнее - порядок fsck

Обычно для обычных разделов так: 0 2
Для root: 0 1
Для swap и многих специальных маунтов: 0 0

▪️ Что делать безопасно после правки: никогда не проверять только перезагрузкой.

Сначала:

mount -a

Если команда отработала молча - уже хороший знак. Если есть ошибка, увидите ее сразу, а не после reboot.

Еще полезно проверить:

findmnt

или

systemctl daemon-reload

если используете systemd-специфичные опции.

#linux #fstab

🧑‍💻 NetworkAdmin

Играл в настройки. Проиграл.

#юмор

🧑‍💻 NetworkAdmin

☄️ Быстрый поиск по логам, конфигам и проектам

Когда нужно быстро что-то найти в логах, конфигах или коде, многие по привычке используют grep -R. Рабочий вариант, но на больших каталогах он быстро начинает раздражать: шумный вывод, медленный поиск, лишние файлы. Для таких задач есть ripgrep (rg) - быстрый и удобный инструмент для поиска по тексту. По сути это современный grep, который хорошо подходит и для админки, и для разработки.

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

apt install ripgrep

▪️ Самый простой пример:

rg nginx

Команда найдет все вхождения nginx в текущем каталоге и покажет: путь к файлу, номер строки и совпадение в контексте.

▪️ Почему ripgrep так любят:

1️⃣ Работает быстро. Особенно заметно на больших деревьях каталогов.
2️⃣ По умолчанию умнее обычного grep. Игнорирует .gitignore, скрытые мусорные каталоги, временные файлы и бинарники.
3️⃣ Удобный вывод. Сразу видно файл, строку и совпадение без лишней возни.

На практике это очень удобно.

▪️ Примеры:

Ищем ошибку в логах:

rg "connection refused" /var/log

Ищем параметр в конфигах:

rg "proxy_pass" /etc/nginx

Ищем использование переменной в проекте:

rg "DB_HOST" /opt/myapp

▪️ Полезные флаги:

без учета регистра

rg -i error /var/log

только список файлов с совпадением

rg -l "server_name" /etc/nginx

искать только по определенным типам файлов

rg "listen 443" -t conf /etc

искать в скрытых файлах тоже

rg -uu "token"

показать несколько строк контекста

rg -C 2 "fatal" /var/log

▪️ Очень полезный сценарий - искать сразу по нескольким шаблонам:

rg "error|failed|denied" /var/log/auth.log

Или находить TODO/FIXME в проекте:

rg "TODO|FIXME" ~/projects

#linux #ripgrep

🧑‍💻 NetworkAdmin

🤩 Почему delete не всегда освобождает место на диске

Одна из неприятных ситуаций на сервере выглядит так: удалили большой файл, а место на диске не появилось. rm отработал, файла уже нет, но df -h показывает почти то же самое заполнение. Кажется, что что-то сломалось, но обычно проблема не в диске, а в том, как устроено удаление файлов.

Важно понять простую вещь: когда вы делаете rm, файл не исчезает с диска мгновенно. Удаляется ссылка на файл из файловой системы. Но если какой-то процесс все еще держит этот файл открытым, его данные продолжают занимать место.

То есть для ядра ситуация выглядит так:

имени файла уже нет;
в каталоге он не виден;
но процесс все еще пишет или читает его через открытый file descriptor.

Пока этот дескриптор не будет закрыт, место не освободится.

▪️ Типичный сценарий:

приложение пишет большой лог;
лог удалили вручную;
процесс продолжает держать файл открытым;
du файл уже не видит;
df показывает, что место все еще занято.

Именно поэтому иногда возникает странная картина:

du -sh /var/log

показывает одно, а

df -h

говорит, что диск почти заполнен.

▪️ Как найти такие файлы:

lsof | grep deleted

Или точнее:

lsof +L1

Эта команда показывает открытые файлы, у которых уже удалена ссылка из файловой системы.

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

▪️ Что делать дальше:

самый правильный вариант - перезапустить процесс, который держит файл
иногда достаточно корректно перечитать логи через systemctl reload
в крайнем случае: restart сервиса

Например, если это nginx, rsyslog, java-процесс или postgres, после перезапуска место обычно сразу возвращается.

▪️ Почему это важно знать:

Админ может удалить 20 ГБ логов и не понять, почему сервер все равно задыхается. А потом начать искать битую файловую систему, хотя проблема всего лишь в открытом удаленном файле.

du считает то, что видно в дереве каталогов.
df показывает то, что реально занято на файловой системе.

Если файл удален, но открыт процессом, du его уже не увидит, а df - да.

#linux #storage

🧑‍💻 NetworkAdmin

👍 Split-horizon DNS: как не сломать внутренний и внешний доступ

Иногда один и тот же домен должен по-разному резолвиться изнутри и снаружи.

Например:

с интернета app.networkadmin.ru должен вести на публичный IP
из локальной сети - на внутренний адрес
внутри VPN - вообще на отдельный хост или балансировщик

Для этого и используют split-horizon DNS.

Его суть простая: разным клиентам DNS-сервер отдает разные ответы на один и тот же запрос.

▪️ На практике это выглядит так:

внешние клиенты получают публичный IP
внутренние - приватный IP
пользователи ходят по одному и тому же имени, но попадают разными маршрутами

Пример: app.networkadmin.ru
Снаружи: 203.0.113.10
Изнутри: 10.10.20.15

▪️ Зачем это нужно:

не гонять внутренний трафик через внешний периметр;
не упираться в NAT loopback / hairpin NAT;
использовать один и тот же FQDN для всех пользователей;
разделять внутренние и внешние сервисы без лишнего зоопарка имен;

Звучит удобно, но именно здесь часто начинаются проблемы.

▪️ Что обычно ломают:

внутренний и внешний DNS живут разной жизнью. Снаружи запись уже поменяли, внутри забыли. В итоге часть пользователей ходит на старый IP.
сертификаты и TLS. Если внутри и снаружи используются разные имена для удобства, потом начинаются сюрпризы с HTTPS, redirect и SSO.
внутренний адрес недоступен части клиентов.Например, ноутбук без VPN получает внутренний DNS-ответ, но до приватного IP дотянуться не может.
отладка становится сложнее. У одного пользователя сервис работает, у другого - нет. И оба резолвят один и тот же домен, но в разные адреса.

▪️ Классический безопасный сценарий:

одно и то же DNS-имя;
внешний DNS отдает публичный IP;
внутренний DNS отдает приватный IP;
приложение и сертификаты рассчитаны на один FQDN.

▪️ Проверять это лучше явно:

dig app.networkadmin.ru
dig @internal-dns app.networkadmin.ru
dig @8.8.8.8 app.networkadmin.ru

Так сразу видно, какие ответы получают разные резолверы.

#dns #network

🧑‍💻 NetworkAdmin

🗂 Как быстро собирать временные файловые слои

overlayfs - это удобный механизм в linux, когда нужно наложить один каталог поверх другого и получить единое дерево файлов, не копируя все данные целиком.

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

▪️ Типичная схема такая:

lowerdir - базовый слой только для чтения
upperdir - все новые изменения
workdir - служебный каталог overlayfs
merged - итоговая точка монтирования

▪️ Пример:

mkdir -p /tmp/overlay/{lower,upper,work,merged}
echo "base config" > /tmp/overlay/lower/app.conf

mount -t overlay overlay \
  -o lowerdir=/tmp/overlay/lower,upperdir=/tmp/overlay/upper,workdir=/tmp/overlay/work \
  /tmp/overlay/merged

Теперь в /tmp/overlay/merged будет виден базовый файл app.conf.

Если изменить его через merged:

echo "new config" > /tmp/overlay/merged/app.conf

то исходный файл в lower не поменяется. Изменение попадет в upper, а overlay покажет уже новую версию файла.

▪️ Почему это удобно:

не нужно копировать весь каталог ради теста;
можно быстро делать временные изменения;
исходные данные остаются нетронутыми;
удобно для sandbox-сценариев, chroot, build-окружений и контейнеров.

▪️ Размонтировать:

umount /tmp/overlay/merged

▪️ Важно учитывать:

upperdir и workdir должны быть на одной файловой системе;
lowerdir может быть read-only;
удаление файлов тоже идет через overlay-механику, а не по-настоящему из нижнего слоя;
это не замена снапшотам и не полноценный backup-механизм.

#linux #overlayfs

🧑‍💻 NetworkAdmin

❓ Что происходит на перегруженном TCP-сервере

Когда TCP-сервер начинает захлебываться под нагрузкой, проблема не всегда в CPU, памяти или плохом приложении. Иногда упирается сам механизм приема новых соединений. Чтобы понять, что происходит, полезно знать три вещи: SYN flood, backlog и somaxconn

▪️ Как выглядит обычное TCP-подключение:

клиент отправляет SYN
сервер отвечает SYN-ACK
клиент присылает ACK
соединение считается установленным

Но между "клиент постучался" и "приложение приняло соединение" есть очереди ядра.

▪️ Что может пойти не так:

SYN flood. Сервер получает огромное количество SYN, но рукопожатие не завершается. Это может быть атака, кривой балансировщик, сетевые потери или просто всплеск нагрузки. В итоге очередь полуоткрытых соединений заполняется, и новые клиенты начинают теряться.

backlog. Когда приложение вызывает listen(), оно указывает размер очереди ожидающих подключений.
Если приложение не успевает быстро принимать новые соединения через accept(), очередь переполняется.
Тогда часть клиентов начинает видеть: таймауты, connection refused, повторные SYN, странные задержки на подключении.

somaxconn. Это системный лимит ядра на максимальный backlog. Даже если приложение просит большую очередь, ядро все равно ограничит ее значением net.core.somaxconn.

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

sysctl net.core.somaxconn

А заодно часто смотрят:

sysctl net.ipv4.tcp_max_syn_backlog

Первый параметр влияет на очередь установленных, но еще не принятых приложением соединений. Второй на очередь полуоткрытых SYN.

▪️ Что происходит на перегруженном сервере на практике:

приложение медленно вызывает accept()
очередь backlog заполняется
новые подключения начинают отваливаться
если сверху еще идет SYN flood, ситуация усугубляется
снаружи кажется, что сервер то работает, то нет

▪️ Как смотреть симптомы:

ss -lnt
netstat -s | grep -i listen
dmesg | grep -i syn

▪️ Что обычно помогает:

увеличить somaxconn;
проверить backlog самого приложения;
поднять tcp_max_syn_backlog;
включить или проверить SYN cookies;
разбираться, почему приложение медленно принимает соединения;
выносить защиту от flood на firewall/LB;

Например:

sysctl -w net.core.somaxconn=4096
sysctl -w net.ipv4.tcp_max_syn_backlog=4096

Но увеличение очередей не лечит корень проблемы. Если приложение не успевает обрабатывать подключения, вы просто делаете буфер больше. Это даст время, но не бесконечную защиту. Хорошая диагностика здесь начинается с простого вопроса: сервер не справляется с валидной нагрузкой или его забивают незавершенными SYN? Потому что снаружи это выглядит одинаково: TCP-порт открыт, а подключиться нормально уже нельзя.

#tcp #network

🧑‍💻 NetworkAdmin

Всегда на шаг впереди 😎

#юмор

🧑‍💻 NetworkAdmin