NetworkAdmin.ru
Kanalga Telegram’da o‘tish
Авторский блог про сетевое и системное администрирование. Сайт: networkadmin.ru Реклама: @dad_admin Биржа: https://telega.in/c/networkadminru
Ko'proq ko'rsatish
Tarmoq:4 708
Obunachilar
-124 soatlar
-67 kun
Ma'lumot yo'q30 kun
Ma'lumot yuklanmoqda...
O'xshash kanallar
Taglar buluti
Kirish va chiqish esdaliklari
---
---
---
---
---
---
Obunachilarni jalb qilish
Sentabr '26
Sentabr '26
+7
0 kanalda
Avgust '26
+61
10 kanalda
Get PRO
Iyul '26
+30
2 kanalda
Get PRO
Iyun '26
+49
5 kanalda
Get PRO
May '26
+27
0 kanalda
Get PRO
Aprel '26
+25
0 kanalda
Get PRO
Mart '26
+19
0 kanalda
Get PRO
Fevral '26
+30
0 kanalda
Get PRO
Yanvar '26
+89
5 kanalda
Get PRO
Dekabr '25
+152
12 kanalda
Get PRO
Noyabr '25
+114
2 kanalda
Get PRO
Oktabr '25
+123
7 kanalda
Get PRO
Sentabr '25
+181
15 kanalda
Get PRO
Avgust '25
+19
0 kanalda
Get PRO
Iyul '25
+95
11 kanalda
Get PRO
Iyun '25
+70
5 kanalda
Get PRO
May '25
+72
1 kanalda
Get PRO
Aprel '25
+560
24 kanalda
Get PRO
Mart '25
+127
6 kanalda
Get PRO
Fevral '25
+205
8 kanalda
Get PRO
Yanvar '25
+409
19 kanalda
Get PRO
Dekabr '24
+69
0 kanalda
Get PRO
Noyabr '24
+88
1 kanalda
Get PRO
Oktabr '24
+598
8 kanalda
Get PRO
Sentabr '24
+1 046
26 kanalda
Get PRO
Avgust '24
+1 013
24 kanalda
Get PRO
Iyul '24
+311
7 kanalda
Get PRO
Iyun '240
1 kanalda
Get PRO
May '240
0 kanalda
Get PRO
Aprel '240
0 kanalda
Get PRO
Mart '240
0 kanalda
Get PRO
Fevral '240
0 kanalda
Get PRO
Yanvar '24
+472
3 kanalda
| Sana | Obunachilarni jalb qilish | Esdaliklar | Kanallar | |
| 16 Sentabr | 0 | |||
| 15 Sentabr | +1 | |||
| 14 Sentabr | +1 | |||
| 13 Sentabr | 0 | |||
| 12 Sentabr | 0 | |||
| 11 Sentabr | 0 | |||
| 10 Sentabr | +2 | |||
| 09 Sentabr | 0 | |||
| 08 Sentabr | 0 | |||
| 07 Sentabr | +2 | |||
| 06 Sentabr | +1 | |||
| 05 Sentabr | 0 | |||
| 04 Sentabr | 0 | |||
| 03 Sentabr | 0 | |||
| 02 Sentabr | 0 | |||
| 01 Sentabr | 0 |
Kanal postlari
| 2 |  Этот файл был удален пользователем
Встречаемся в Москве с теми, кто отвечает за хранение данных бизнеса. Обсудим, как решить задачу со звездочкой — уберечь массивы файлов и резервных копий от атак шифровальщиков, утечки или случайной перезаписи.
На бизнес-ужине эксперты провайдера ИТ-инфраструктуры Selectel расскажут:
➕как устроено хранилище S3 под капотом;
➕какие угрозы данным существуют и как выстроить многослойную систему защиты;
➕почему защита данных — это не статья расходов, а управление рисками.
Будет актуально руководителям в ИТ-компаниях, старшим архитекторам, системным администраторам. Поговорим и про стратегию хранения, и про реализацию.
📆 24 сентября (чт), 18:30
📍Москва, м. Динамо
⏩Участие бесплатное, дождитесь подтверждения заявки. Смотрите полную программу и регистрируйтесь: https://slc.tl/t7ito
Реклама. АО "Селектел". erid:2W5zFJz9JhX | 555 |
| 3 | 💚 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 | 444 |
| 4 | 👁 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 | 514 |
| 5 | 📁 Логирование скриптов в 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 | 793 |
| 6 |  Вы не заставите меня их закрыть. 🤩
#юмор
🧑💻 NetworkAdmin | 925 |
| 7 |  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, чтобы проверить сеть до оплаты.
Забукировать сервер можно по ссылке | 655 |
| 8 | ⏰ Точное время до запуска сервисов: одноразовая синхронизация через 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 | 797 |
| 9 |  Хотите выйти на зарубежный рынок, но непонятно, с чего начать?
Если вы:
— фрилансер и хотите работать с иностранными заказчиками;
— IT-специалист или развиваете IT-компанию;
— владелец digital- или маркетингового агентства;
— дизайнер или руководитель дизайн-студии;
— эксперт и хотите продавать свои услуги за пределами локального рынка;
— предприниматель, который планирует развивать бизнес за рубежом
Меня зовут Альберт Сабиров. Владелец международного digital агентства. Приглашаю вас на свой канал, где я на практике работаю с зарубежными рынками и в канале делюсь опытом, который помогает разобраться:
— где искать первых клиентов за рубежом;
— как выйти на иностранных заказчиков;
— как адаптировать и упаковать свои услуги под зарубежный рынок;
— как принимать оплату из других стран;
— как открывать зарубежные счета и работать с ними;
— как зарегистрировать компанию за границей;
— что учитывать в договорах, налогах и законодательстве;
— как выстроить маркетинг и привлечение клиентов на новом рынке;
— какие ошибки могут стоить денег и времени при выходе за рубеж.
Если хотите перестать зависеть только от локального рынка и понять, как системно начать работать за рубежом — присоединяйтесь.
Альберт Сабиров | Зарубежный рынок | 581 |
| 10 | 💚 Как один неверный 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 | 720 |
| 11 | 😩 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 | 687 |
| 12 | 🤩 Почему места достаточно, но приложение всё равно не может записать файл
Иногда на сервере возникает странная ситуация. Проверяем диск:
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 | 1 032 |
| 13 | 👀 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 | 999 |
| 14 | ✏️ Пишем события скриптов в 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 | 983 |
| 15 | 📂 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 | 956 |
| 16 | 📎 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 | 1 072 |
| 17 | 📱 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 | 1 125 |
| 18 | 🆘 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 | 1 447 |
| 19 | ❤️ 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 | 1 263 |
| 20 |  Надо наказывать, получается
#юмор
🧑💻 NetworkAdmin | 1 440 |
