NetworkAdmin.ru

😐 #юмор 🧑‍💻 NetworkAdmin

Этот файл был удален пользователем Встречаемся в Москве с теми, кто отвечает за хранение данных бизнеса. Обсудим, как решить задачу со звездочкой — уберечь массивы файлов и резервных копий от атак шифровальщиков, утечки или случайной перезаписи. На бизнес-ужине эксперты провайдера ИТ-инфраструктуры Selectel расскажут: ➕как устроено хранилище S3 под капотом; ➕какие угрозы данным существуют и как выстроить многослойную систему защиты; ➕почему защита данных — это не статья расходов, а управление рисками. Будет актуально руководителям в ИТ-компаниях, старшим архитекторам, системным администраторам. Поговорим и про стратегию хранения, и про реализацию. 📆 24 сентября (чт), 18:30 📍Москва, м. Динамо ⏩Участие бесплатное, дождитесь подтверждения заявки. Смотрите полную программу и регистрируйтесь: https://slc.tl/t7ito Реклама. АО "Селектел". erid:2W5zFJz9JhX

💚 Bonding в Linux: active-backup, LACP и типовые ошибки настройки Bonding объединяет несколько сетевых интерфейсов в один логический bond0. Обычно его используют для: • резервирования сетевого подключения • распределения нагрузки • защиты от отказа кабеля, порта или сетевой карты • увеличения суммарной пропускной способности Два самых популярных режима - active-backup и 802.3ad. ▪️ Active-backup. В каждый момент работает только один интерфейс. Второй находится в резерве и включается при отказе основного.

[NetDev]
Name=bond0
Kind=bond

[Bond]
Mode=active-backup
MIIMonitorSec=100ms
Primary=eno1

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

[Bond]
Mode=802.3ad
MIIMonitorSec=100ms
LACPTransmitRate=fast
TransmitHashPolicy=layer3+4

Но на коммутаторе порты должны быть объединены в один LAG с поддержкой LACP. Важно понимать: одно TCP-соединение обычно не получит скорость двух интерфейсов. Трафик распределяется по хешу между разными потоками. Проверить состояние bonding:

cat /proc/net/bonding/bond0

Там видно:

текущий активный интерфейс состояние каждого slave скорость и duplex количество переключений состояние LACP

Дополнительно:

ip -br link
ip -s link show bond0
ethtool eno1

▪️ Типовые ошибки

• включили 802.3ad, но не настроили LAG на коммутаторе • порты подключены к разным независимым коммутаторам без MLAG/stack • IP назначен одновременно на bond0 и физические интерфейсы • интерфейсы имеют разную скорость или MTU • забыли удалить старые маршруты и конфигурации slave-интерфейсов • считают, что LACP удвоит скорость одного соединения • проверяют только link up, хотя трафик через порт не проходит

#linux #bonding #network 🧑‍💻 NetworkAdmin

👁 Linux audit rules: минимальный набор для контроля критичных файлов Обычные логи не всегда отвечают на главный вопрос: кто изменил конфигурацию и какой процесс это сделал? Для таких задач в Linux есть auditd. Он фиксирует обращения к файлам на уровне ядра и сохраняет пользователя, процесс, команду и время события. ▪️ Установка:

apt install auditd audispd-plugins
systemctl enable --now auditd

Правила лучше хранить в отдельном файле:

nano /etc/audit/rules.d/critical-files.rules

▪️ Минимальный набор:

-w /etc/passwd -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/gshadow -p wa -k identity

-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers

-w /etc/ssh/sshd_config -p wa -k ssh_config
-w /root/.ssh/ -p wa -k ssh_keys

-w /etc/systemd/system/ -p wa -k systemd_units
-w /etc/cron.d/ -p wa -k cron_changes
-w /etc/crontab -p wa -k cron_changes

-w /etc/audit/ -p wa -k audit_config

-w - файл или каталог для наблюдения -p w - запись в файл -p a - изменение атрибутов и прав -k - удобная метка для поиска ▪️ Загружаем правила:

augenrules --load

▪️ Проверяем:

auditctl -l

▪️ Примеры использования: Ищем изменения, например, SSH-конфига:

ausearch -k ssh_config -i

Посмотреть события за сегодня:

ausearch -k sudoers -ts today -i

Краткий отчет по измененным файлам:

aureport -f -i

▪️ В событии можно увидеть:

какой файл изменили UID и реального пользователя PID процесса исполняемую команду успешность операции точное время

#linux #auditd 🧑‍💻 NetworkAdmin

📁 Логирование скриптов в Windows Event Viewer Для логов PowerShell и BAT-скриптов необязательно создавать отдельные текстовые файлы. Важные события можно записывать прямо в Event Viewer. Это удобно, потому что такие записи проще искать, фильтровать и собирать централизованно через WEF, SIEM или систему мониторинга. ▪️ Сначала создадим отдельный источник событий:

New-EventLog -LogName Application -Source "MyScript"

Эту команду обычно достаточно выполнить один раз с правами администратора. ▪️ Теперь можно записать событие в журнал Application:

Write-EventLog `
  -LogName Application `
  -Source "MyScript" `
  -EntryType Information `
  -EventID 1 `
  -Message "Запущен PowerShell-скрипт проверки состояния сервера"

▪️ Для ошибок и предупреждений меняем тип события:

Write-EventLog `
  -LogName Application `
  -Source "MyScript" `
  -EntryType Error `
  -EventID 1001 `
  -Message "Не удалось подключиться к серверу"

Полезно заранее определить свою схему Event ID:

1 -запуск скрипта 2 - успешное завершение 100 - предупреждение 1001 - ошибка выполнения

▪️ Если не хочется смешивать записи с общим журналом Application, можно создать отдельный EVTX-журнал:

New-EventLog -LogName CustomPSLog -Source "PS1Script"

А затем писать события уже в него:

Write-EventLog `
  -LogName CustomPSLog `
  -Source "PS1Script" `
  -EntryType Information `
  -EventID 1 `
  -Message "Скрипт запущен"

▪️ В BAT- и CMD-скриптах для этого есть команда eventcreate:

eventcreate /t information /l application /id 1 /d "BAT script started"

Для записи ошибки:

eventcreate /t error /l application /id 1001 /d "BAT script failed"

Подробный debug-вывод удобнее оставлять в обычном текстовом логе. Хорошая схема выглядит так: детали — в файл, важные события — в Event Viewer. #windows #eventviewer 🧑‍💻 NetworkAdmin

Вы не заставите меня их закрыть. 🤩 #юмор 🧑‍💻 NetworkAdmin

NVMe VPS для рабочих и пет-проектов от DLine Media — от 300 ₽ за месяц -> Combo 1 · 1 vCPU · 1 ГБ · 10 ГБ NVMe · 100 Мбит — 300 ₽ -> Combo 2 · 2 vCPU · 4 ГБ · 25 ГБ NVMe · 300 Мбит — 750 ₽ -> Combo 3 · 4 vCPU · 8 ГБ · 50 ГБ NVMe · 500 Мбит — 1 700 ₽ В каждом тарифе: безлимитный трафик, IPv4, защита от DDoS, root, любой образ. 15 локаций — Москва, Петербург, Казань, Новосибирск, Амстердам, Франкфурт, Лондон, Токио и другие. Looking Glass, чтобы проверить сеть до оплаты. Забукировать сервер можно по ссылке

⏰ Точное время до запуска сервисов: одноразовая синхронизация через chrony Обычно синхронизация времени в Linux работает незаметно: установили chrony, systemd-timesyncd или другой NTP-клиент - и забыли. Но после загрузки виртуальной машины системное время иногда отличается на несколько минут. Служба синхронизации исправит его, однако часть сервисов к этому моменту уже может успеть запуститься. В результате появляются: • события в логах с неправильным временем • ошибки проверки сертификатов • проблемы с Kerberos и токенами • некорректный порядок событий • странности в распределенных системах и мониторинге Для обычной работы постепенная коррекция времени подходит. Но на старте иногда нужно сначала выставить часы, а уже потом запускать приложение. Для этого можно создать одноразовый systemd-unit с chronyd -q. ▪️ Устанавливаем chrony:

apt install chrony

▪️ Создаем unit:

systemctl edit --force --full chrony-once-sync.service

▪️ Добавляем:

[Unit]
Description=Initial time synchronization with chrony
Wants=network-online.target
After=network-online.target
Before=myapp.service

[Service]
Type=oneshot
ExecStart=/usr/sbin/chronyd -q -t 10

[Install]
WantedBy=multi-user.target

-q - один раз выставить время и завершить работу -t 10 - прекратить попытку через 10 секунд After=network-online.target - запускать после готовности сети Before=myapp.service - выполнить синхронизацию раньше критичного приложения ▪️ Активируем юнит:

systemctl daemon-reload
systemctl enable chrony-once-sync.service

▪️ Проверяем после перезагрузки:

systemctl status chrony-once-sync.service
journalctl -u chrony-once-sync.service -b

▪️ Посмотреть порядок запуска:

systemd-analyze critical-chain myapp.service

#linux #systemd #chrony 🧑‍💻 NetworkAdmin

Хотите выйти на зарубежный рынок, но непонятно, с чего начать? Если вы: — фрилансер и хотите работать с иностранными заказчиками; — IT-специалист или развиваете IT-компанию; — владелец digital- или маркетингового агентства; — дизайнер или руководитель дизайн-студии; — эксперт и хотите продавать свои услуги за пределами локального рынка; — предприниматель, который планирует развивать бизнес за рубежом Меня зовут Альберт Сабиров. Владелец международного digital агентства. Приглашаю вас на свой канал, где я на практике работаю с зарубежными рынками и в канале делюсь опытом, который помогает разобраться: — где искать первых клиентов за рубежом; — как выйти на иностранных заказчиков; — как адаптировать и упаковать свои услуги под зарубежный рынок; — как принимать оплату из других стран; — как открывать зарубежные счета и работать с ними; — как зарегистрировать компанию за границей; — что учитывать в договорах, налогах и законодательстве; — как выстроить маркетинг и привлечение клиентов на новом рынке; — какие ошибки могут стоить денег и времени при выходе за рубеж. Если хотите перестать зависеть только от локального рынка и понять, как системно начать работать за рубежом — присоединяйтесь. Альберт Сабиров | Зарубежный рынок

💚 Как один неверный chmod -R ломает прод сильнее, чем падение сервиса Падение сервиса обычно видно сразу. Мониторинг красный, пользователи жалуются, в логах ошибка. Перезапустили, откатили, восстановили. А вот один неверный chmod -R может сломать прод намного тише и неприятнее. Классический сценарий:

chmod -R 777 /var/www

или еще хуже:

chmod -R 755 /

Хотели быстро пофиксить права, а получили хаос. ▪️ Почему это опасно? Права в linux - это не просто можно читать или нельзя. От них зависит работа сервисов, безопасность, SSH, sudo, systemd, базы данных, веб-приложения и приватные ключи. ▪️ Что может сломаться:

• SSH перестанет принимать ключи, потому что ~/.ssh и authorized_keys стали слишком открытыми • приватные ключи начнут считаться небезопасными • nginx/apache потеряют доступ к нужным файлам или, наоборот, получат лишний доступ • база данных откажется стартовать из-за неправильных прав на data directory • sudo может начать ругаться на права конфигов • приложения начнут писать туда, куда не должны • исполняемые файлы потеряют нужные биты

▪️ Особенно опасны рекурсивные команды с переменными:

chmod -R 755 "$DIR"

Если $DIR пустой, неправильный или подставился не тот путь - последствия могут быть очень неприятными. Перед такими командами лучше явно проверять переменные:

: "${DIR:?DIR is empty}"

И сначала смотреть, куда команда попадет:

find "$DIR" -maxdepth 2 -print

Для файлов и директорий права часто должны отличаться. 🤩 Плохо:

chmod -R 755 /var/www/app

🤩 Лучше:

find /var/www/app -type d -exec chmod 755 {} +
find /var/www/app -type f -exec chmod 644 {} +

Так директории остаются проходимыми, а обычные файлы не становятся исполняемыми без необходимости. ▪️ Если нужно дать права конкретному пользователю, часто правильнее менять владельца:

chown -R www-data:www-data /var/www/app/storage

А не открывать все через 777. 777 - это почти всегда сигнал, что проблему не поняли, а просто выключили защиту. Для диагностики полезно смотреть текущие права:

ls -la
namei -l /var/www/app/storage/file.log
stat /var/www/app/storage

namei -l особенно удобен: он показывает права на каждом уровне пути. Иногда файл доступен, но один из родительских каталогов не дает пройти дальше. #linux #chmod 🧑‍💻 NetworkAdmin

😩 systemd-analyze: почему сервер долго загружается и кто виноват Иногда сервер после reboot поднимается подозрительно долго. Вроде железо нормальное, диск живой, сервисов не так много, но до нормального состояния система доходит через минуту, две или даже дольше. В systemd для такого разбора есть удобная утилита:

systemd-analyze

Она покажет общее время загрузки:

Startup finished in 5.2s (kernel) + 28.4s (userspace) = 33.6s

Здесь видно, сколько заняло ядро и сколько - userspace, то есть запуск systemd-сервисов. ▪️ Чтобы понять, какие иниты запускались дольше всего:

systemd-analyze blame

Пример вывода:

12.834s docker.service
8.421s NetworkManager-wait-online.service
6.102s postgresql.service
3.451s nginx.service

Это хороший первый ориентир, но есть важный нюанс. blame показывает длительность запуска юнитов, но не всегда показывает реального виновника. Сервисы могут запускаться параллельно, и длинный сервис не обязательно блокировал всю загрузку. ▪️ Для понимания цепочки зависимостей лучше использовать:

systemd-analyze critical-chain

Эта команда показывает критический путь загрузки - что действительно задерживало достижение нужного target. ▪️ Можно посмотреть цепочку для конкретного сервиса:

systemd-analyze critical-chain docker.service

▪️ Частые причины долгой загрузки:

ожидание сети зависший mount из /etc/fstab медленный DNS NFS/SMB mount без `nofail` долгий старт базы данных Docker/container runtime cloud-init некорректные зависимости в юнитах таймауты несуществующих устройств

▪️ Отдельно стоит проверить failed-юниты:

systemctl --failed

▪️ Логи текущей загрузки:

journalctl -b

Если проблема была на предыдущем boot:

journalctl -b -1

▪️ Еще полезная команда - построить SVG-график загрузки:

systemd-analyze plot > boot.svg

Файл boot.svg можно открыть в браузере и визуально посмотреть, какие сервисы когда стартовали и сколько длились. ▪️ Для поиска ошибок в unit-файлах:

systemd-analyze verify /etc/systemd/system/myapp.service

Это помогает поймать неправильные директивы, опечатки и странности в конфигурации. #linux #systemd 🧑‍💻 NetworkAdmin

🤩 Почему места достаточно, но приложение всё равно не может записать файл Иногда на сервере возникает странная ситуация. Проверяем диск:

df -h

Свободное место есть. Например, десятки гигабайт. Но приложение всё равно пишет: No space left on device ▪️ Первая частая причина - закончились inodes. inode - это запись о файле в файловой системе. Если маленьких файлов очень много, можно упереться не в объем, а в количество файлов. Проверить:

df -i

Если IUse% близко к 100%, новые файлы создаваться не будут, даже если свободные гигабайты еще есть. Типичные виновники: миллионы мелких cache-файлов, сессии приложения, временные файлы, мелкие логи и т.д. Найти каталоги с большим количеством файлов:

find /var -xdev -type f | cut -d/ -f1-3 | sort | uniq -c | sort -nr | head

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

quota -s

или для XFS:

xfs_quota -x -c 'report -h' /mountpoint

▪️ Третья причина - приложение пишет не туда, куда вы смотрите. Например, вы проверяете /data, а сервис пишет в /var/lib/app, /tmp или внутрь контейнера. Полезно посмотреть mount point:

df -h /path/to/file

И понять, какая файловая система реально используется. ▪️ Четвертая причина - лимиты systemd. У сервиса могут быть ограничения через unit:

systemctl cat myapp.service
systemctl show myapp.service | grep -i limit

▪️ Пятая причина - read-only файловая система. Например, после ошибок диска система могла перемонтировать раздел в ro. Проверить:

findmnt -o TARGET,OPTIONS

или:

mount | grep ' ro,'

#linux #filesystem #storage 🧑‍💻 NetworkAdmin

👀 inotifywait: реакция на изменения файлов без cron Иногда нужно выполнить действие сразу после изменения файла или каталога. Например: • изменился конфиг - перезапустить сервис • появился новый файл - обработать его • загрузили архив - распаковать • изменился сертификат - перечитать nginx • в каталог упал лог - отправить уведомление Первое решение, которое часто приходит в голову - cron. Но cron работает по расписанию. Он не реагирует на событие сразу, а просто периодически проверяет состояние. Для событий в файловой системе удобнее использовать inotifywait. ▪️ Установка:

apt install inotify-tools

▪️ Посмотреть изменения файла:

inotifywait -m /etc/nginx/nginx.conf

Ключ -m включает постоянное наблюдение. Пример вывода:

/etc/nginx/nginx.conf MODIFY

▪️ Следить за каталогом:

inotifywait -m /var/www

Рекурсивно:

inotifywait -m -r /var/www

Можно выбрать конкретные события:

inotifywait -m -e create,modify,delete /var/www

▪️ Простой пример: перезагрузить nginx после изменения конфига.

while inotifywait -e modify /etc/nginx/nginx.conf; do
  nginx -t && systemctl reload nginx
done

Смысл простой: • ждем изменение файла • проверяем конфиг • если всё нормально - reload nginx • снова ждем следующее изменение ▪️ Еще пример: обработать новые файлы в каталоге.

inotifywait -m -e close_write --format '%w%f' /data/incoming |
while read -r file; do
  echo "new file: $file"
  /opt/scripts/process-file.sh "$file"
done

Почему close_write, а не просто create? Потому что файл может появиться, но запись в него еще не закончилась. close_write срабатывает, когда файл уже записан и закрыт. ⚠️ inotifywait - не замена очередям, брокерам сообщений и нормальной event-driven архитектуре. У него есть лимиты ядра, события можно потерять при перегрузке, а рекурсивное наблюдение за огромными деревьями может быть тяжелым. Проверить лимиты можно так:

sysctl fs.inotify.max_user_watches
sysctl fs.inotify.max_user_instances

#linux #inotify 🧑‍💻 NetworkAdmin

✏️ Пишем события скриптов в Windows Event Viewer В Windows-скриптах часто делают логирование в обычные текстовые файлы:

C:\Scripts\Logs\script.log

Это рабочий вариант, но не всегда удобный. Логи могут лежать в разных папках, забываться при переносе скрипта, не попадать в централизованный сбор и быстро превращаться в зоопарк форматов. Иногда удобнее писать важные события прямо в Event Viewer. ▪️ Плюсы такого подхода: • события видны в стандартном журнале Windows; • их можно собирать через WEF, SIEM или агент мониторинга; • проще фильтровать по источнику, Event ID и уровню; • не нужно отдельно искать лог-файл скрипта; • события попадают в привычный механизм аудита и диагностики. ▪️ Например, в PowerShell можно создать отдельный источник событий:

New-EventLog -LogName Application -Source "MyScript"
После этого можно писать события в журнал Application:
Write-EventLog `
  -LogName Application `
  -Source "MyScript" `
  -EntryType Information `
  -EventID 1 `
  -Message "Запущен PowerShell-скрипт опроса состояния сервера"

В Event Viewer появится событие с источником MyScript. Тип события можно менять: -EntryType Information -EntryType Warning -EntryType Error Например, если скрипт завершился с ошибкой:

Write-EventLog `
  -LogName Application `
  -Source "MyScript" `
  -EntryType Error `
  -EventID 1001 `
  -Message "Скрипт завершился с ошибкой при подключении к серверу"

▪️ Можно использовать свою схему Event ID:

1 - старт скрипта 2 - успешное завершение 100 - предупреждение 1001 - ошибка подключения 1002 - ошибка доступа

Так потом проще строить фильтры и алерты. ▪️ Если не хочется смешивать события с общим Application, можно создать отдельный журнал:

New-EventLog -LogName CustomPSLog -Source "PS1Script"

И писать уже туда:

Write-EventLog `
  -LogName CustomPSLog `
  -Source "PS1Script" `
  -EntryType Information `
  -EventID 1 `
  -Message "PowerShell script started"

▪️ Для BAT/CMD-скриптов тоже есть вариант - команда eventcreate:

eventcreate /t information /l application /id 1 /d "BAT script started"

Для ошибки:

eventcreate /t error /l application /id 1001 /d "BAT script failed"

Event Viewer удобен не вместо всех логов, а как место для важных событий, которые должны быть видны системе мониторинга и администратору. Если скрипт делает что-то важное, он должен не просто молча выполниться. Он должен оставить понятный след: когда стартовал, чем закончился и где сломался. #windows #powershell #eventviewer 🧑‍💻 NetworkAdmin

📂 sshfs: монтируем удаленный каталог через SSH и systemd sshfs позволяет монтировать удаленную файловую систему через обычное SSH-соединение. То есть если у вас есть SSH-доступ к серверу, можно подключить его каталог как локальную директорию. Это не самый быстрый способ: SSHFS работает через FUSE в user space, плюс само SSH-соединение добавляет накладные расходы. Но для некоторых задач это очень удобно. Особенно когда: SSH уже открыт; NFS/SMB поднимать не хочется; нужен быстрый доступ к отдельному каталогу или нужно временно подключить данные ▪️ Установка:

apt install sshfs

▪️ Для автомонтирования лучше сразу настроить доступ по ключу. Генерируем ключ:

ssh-keygen -t ed25519

Копируем его на удаленный сервер:

ssh-copy-id root@10.20.1.6

Можно подключаться и по паролю, но для systemd-автомонтирования это неудобно: пароль придется вводить интерактивно. С ключом все проще и надежнее. ▪️ Пример. Допустим, нужно смонтировать каталог:

root@10.20.1.6:/etc/letsencrypt

в локальный путь:

/mnt/letsencrypt

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

mkdir -p /mnt/letsencrypt

Монтируем вручную:

sshfs root@10.20.1.6:/etc/letsencrypt /mnt/letsencrypt

Проверяем:

df -h | grep 10.20.1.6

Размонтировать можно так:

fusermount -u /mnt/letsencrypt

▪️ Теперь сделаем systemd-unit, чтобы монтировать каталог автоматически. Создаем service:

systemctl edit --force --full sshfs-letsencrypt.service

Пример unit-файла:

[Unit]
Description=Mount /etc/letsencrypt over SSHFS
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
RemainAfterExit=true

ExecStart=/usr/bin/sshfs root@10.20.1.6:/etc/letsencrypt /mnt/letsencrypt -o reconnect,ServerAliveInterval=15,ServerAliveCountMax=3
ExecStop=/usr/bin/fusermount -u /mnt/letsencrypt

[Install]
WantedBy=multi-user.target

Перечитываем systemd:

systemctl daemon-reload

Запускаем:

systemctl start sshfs-letsencrypt.service

Добавляем в автозагрузку:

systemctl enable sshfs-letsencrypt.service

Если нужно размонтировать каталог:

systemctl stop sshfs-letsencrypt.service

▪️ Полезные опции: • reconnect - Пытаться восстановить подключение при обрыве. • ServerAliveInterval=15 - Периодически проверять, живо ли SSH-соединение. • ServerAliveCountMax=3 - После нескольких неудачных проверок считать соединение мертвым. В примере все сделано от root для простоты. Для постоянной схемы лучше использовать отдельного пользователя с минимальными правами. В systemd можно указать:

User=sftp-user
Group=sftp-user

Но тогда важно, чтобы у этого пользователя были права на точку монтирования и SSH-ключи. #linux #sshfs 🧑‍💻 NetworkAdmin

📎 TCP retransmits: как понять, что сеть теряет пакеты, а не тормозит приложение Иногда приложение вроде бы работает, CPU нормальный, память есть, база живая, но пользователи жалуются: "все медленно". И начинается классика: смотрим логи приложения, nginx, базу, systemd, load average. А причина может быть ниже - на сетевом уровне. Один из важных признаков сетевых проблем - TCP retransmits. TCP - надежный протокол. Если пакет потерялся по дороге, получатель его не подтвердил, и отправитель через время отправит этот сегмент заново. Это и есть retransmission. Небольшое количество повторных передач в сети бывает всегда. Но если их много - это уже симптом: • перегруженный канал; • проблемы на интерфейсе; • плохой Wi-Fi или VPN; • перегруженный firewall/NAT; • проблемы у провайдера. Снаружи это часто выглядит не как "сеть упала", а как странная деградация: страницы открываются медленно, API иногда отвечает долго, SSH подвисает, загрузка файлов идет рывками и т.д. Первое, что можно посмотреть на linux:

netstat -s | grep -i retrans

или через ss:

ss -ti

В выводе ss -ti можно увидеть детали по TCP-соединениям, включая retrans, rtt, cwnd и другие параметры. Для конкретного направления лучше использовать tcpdump. Например, смотрим трафик между сервером и клиентом:

tcpdump -i any -nn host 203.0.113.10 and port 443

Если нужно сохранить дамп для Wireshark:

tcpdump -i any -nn host 203.0.113.10 and port 443 -w retrans.pcap

В wireshark потом удобно фильтровать:

tcp.analysis.retransmission

Также полезные фильтры:

tcp.analysis.fast_retransmission
tcp.analysis.lost_segment
tcp.analysis.duplicate_ack

Если видите много retransmission, duplicate ACK и lost segment - это уже повод смотреть сеть, а не только приложение. Быстрая проверка маршрута:

mtr -rw -c 100 203.0.113.10

Но тут важно помнить: mtr показывает потери по ICMP/UDP/TCP-проверкам, а не всегда идеально отражает конкретный TCP-трафик приложения. Зато помогает понять, где примерно начинаются проблемы. Еще полезно проверить ошибки на сетевом интерфейсе:

ip -s link

или:

ethtool -S eth0

#linux #network 🧑‍💻 NetworkAdmin

📱 getopts в bash: как нормально разбирать аргументы скрипта Многие Bash-скрипты сначала выглядят просто: ./backup.sh /data /backup А потом появляются опции: путь к конфигу, имя окружения, количество попыток, режим работы и т.д. И скрипт быстро превращается в набор странных if, где $1, $2, $3 уже никто нормально не понимает. 🤩 Плохой вариант:

SOURCE="$1"
DEST="$2"
MODE="$3"

Работает, пока аргументов мало. Но как только нужно добавить флаги, порядок начинает ломать все. Для нормального разбора коротких опций в bash есть встроенный механизм getopts. ▪️ Пример скрипта:

#!/usr/bin/env bash
set -euo pipefail

VERBOSE=0
DRY_RUN=0
CONFIG=""

usage() {
  echo "Usage: $0 [-v] [-n] [-c config] source dest"
}

while getopts ":vnc:" opt; do
  case "$opt" in
    v)
      VERBOSE=1
      ;;
    n)
      DRY_RUN=1
      ;;
    c)
      CONFIG="$OPTARG"
      ;;
    🙂
      echo "option -$OPTARG requires an argument" >&2
      usage
      exit 1
      ;;
    \?)
      echo "unknown option: -$OPTARG" >&2
      usage
      exit 1
      ;;
  esac
done

shift $((OPTIND - 1))

SOURCE="${1:-}"
DEST="${2:-}"

if [[ -z "$SOURCE" || -z "$DEST" ]]; then
  usage
  exit 1
fi

echo "source: $SOURCE"
echo "dest: $DEST"
echo "config: $CONFIG"
echo "verbose: $VERBOSE"
echo "dry-run: $DRY_RUN"

Теперь скрипт можно запускать так:

./backup.sh -v -n -c /etc/backup.conf /data /backup

или так:

./backup.sh -c /etc/backup.conf -v /data /backup

Порядок флагов уже не так важен. ▪️ Что означает строка: while getopts ":vnc:" opt; do v - флаг без значения n - флаг без значения c: - опция -c требует аргумент первый : включает более удобную обработку ошибок То есть -v и -n просто включают режимы, а -c ожидает значение:

-c /etc/backup.conf

Переменная OPTARG содержит аргумент текущей опции. Например, для:

-c /etc/backup.conf

внутри case будет:

CONFIG="$OPTARG"

После обработки флагов важна команда:

shift $((OPTIND - 1))

Она убирает уже разобранные опции из списка аргументов. После этого в $1, $2 остаются обычные позиционные аргументы: например source и dest. #bash #scripting 🧑‍💻 NetworkAdmin

🆘 BgInfo: системная информация прямо на рабочем столе Windows У Microsoft Sysinternals есть старая, но до сих пор полезная утилита - BgInfo. Она выводит системную информацию прямо поверх обоев рабочего стола. На фоне можно показать: • имя компьютера • домен • пользователя • IP-адреса • версию Windows • uptime • свободное место на дисках • AD site • любые дополнительные поля Для HelpDesk это удобно: пользователь просто смотрит на рабочий стол и диктует нужные данные. Для админа тоже полезно, особенно когда открыто много RDP-сессий на разные серверы. Сразу видно, где именно ты находишься, и меньше шансов перепутать тестовый сервер с боевым. BgInfo достаточно гибкий. Кроме стандартных полей, можно добавлять данные через: • WMI • registry • environment variables • VBS • PowerShell-скрипты ▪️ Базовая схема внедрения простая. 1️⃣ Создаем шаблон BgInfo. В GUI настраиваем: какие поля показывать, шрифт и цвет, расположение блока, формат вывода, фон и поведение. После этого сохраняем конфигурацию в файл, например: bg_config.bgi 2️⃣ Кладем файлы в SYSVOL / NETLOGON. Например:

\\domain.local\NETLOGON\Bginfo\

Внутри:

Bginfo.exe
bg_config.bgi

3️⃣ Применяем через logon script в GPO. Пример bat-файла:

reg add HKEY_CURRENT_USER\Software\Sysinternals\BGInfo /v EulaAccepted /t REG_DWORD /d 1 /f

%logonserver%\NETLOGON\Bginfo\Bginfo.exe %logonserver%\NETLOGON\Bginfo\bg_config.bgi /silent /timer:00 /nolicprompt

▪️ Что здесь происходит: • заранее принимаем EULA для пользователя • запускаем BgInfo из NETLOGON • применяем готовый .bgi шаблон • скрываем окно запуска • не показываем license prompt • сразу обновляем фон без ожидания таймера После входа пользователя на рабочий стол автоматически наносится нужная системная информация. Отдельный плюс - возможность стандартизировать внешний вид. Например, на серверах можно крупно выводить:

SERVER: SRV-APP-01 ENV: PROD IP: 10.10.20.15

А на рабочих станциях - имя ПК, пользователь, IP и версию ОС. #windows #bginfo 🧑‍💻 NetworkAdmin

❤️ systemctl edit: как правильно переопределять юниты без правки vendor-файлов В systemd часто нужно чуть-чуть изменить стандартный unit, который приехал из пакета. Например: • добавить автоматический рестарт; • изменить переменные окружения; • переопределить ExecStart; • добавить лимиты; • поменять рабочий каталог; • настроить зависимости. Плохая идея - править vendor-unit напрямую где-нибудь в:

/lib/systemd/system/

или:

/usr/lib/systemd/system/

После обновления пакета такие изменения могут потеряться или конфликтовать с новой версией юнита.Правильнее использовать override. Покажу на примере nginx.service. 1️⃣ Сначала смотрим полный unit:

systemctl cat nginx.service

Это очень удобная команда. Она показывает не только содержимое unit-файла, но и путь, откуда он загружен. Если для сервиса уже есть override-файлы, они тоже будут показаны в этом же выводе. 2️⃣ Теперь добавим автоперезапуск nginx при падении:

systemctl edit nginx.service

3️⃣ Откроется редактор. Добавляем:

[Service]
Restart=always
RestartSec=5s

4️⃣ Сохраняем и выходим. systemd сам создаст drop-in файл примерно здесь:

/etc/systemd/system/nginx.service.d/override.conf

5️⃣ Проверяем результат:

systemctl cat nginx.service

Теперь в выводе будет видно и исходный unit, и наш override. 6️⃣ После изменения обычно стоит выполнить:

systemctl daemon-reload
systemctl restart nginx.service

И проверить:

systemctl status nginx.service

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

[Service]
Restart=always
RestartSec=5s

Но если нужно переопределить параметры, которые могут иметь несколько значений, их часто нужно сначала очистить. ▪️ Классический пример - ExecStart. Если в основном unit было:

ExecStart=/usr/sbin/nginx -g 'daemon on; master_process on;'

А вы хотите заменить команду запуска, нужно сделать так:

[Service]
ExecStart=
ExecStart=/usr/sbin/nginx -g 'daemon off; master_process off;'

Первая строка очищает старое значение. Вторая задает новое. Если просто добавить новый ExecStart, systemd может выдать ошибку или оставить некорректную конфигурацию. То же часто касается параметров семейства:

ExecStart=
ExecStartPre=
ExecStartPost=
ExecReload=
ExecStop=

▪️ Аналогичная логика может понадобиться и для некоторых списочных настроек. Если override "почему-то не работает", полезно проверить итоговую конфигурацию:

systemctl cat nginx.service

И затем:

systemd-analyze verify /etc/systemd/system/nginx.service.d/override.conf

Еще полезная команда:

systemctl revert nginx.service

Она удалит локальные override и вернет unit к vendor-состоянию. #linux #systemd 🧑‍💻 NetworkAdmin

Надо наказывать, получается #юмор 🧑‍💻 NetworkAdmin