NetworkAdmin.ru
前往频道在 Telegram
Авторский блог про сетевое и системное администрирование. Сайт: networkadmin.ru Реклама: @dad_admin Биржа: https://telega.in/c/networkadminru
显示更多
网络:4 708
订阅者
-124 小时
-67 天
无数据30 天
数据加载中...
相似频道
标签云
进出提及
---
---
---
---
---
---
吸引订阅者
九月 '26
九月 '26
+7
在0个频道中
八月 '26
+61
在10个频道中
Get PRO
七月 '26
+30
在2个频道中
Get PRO
六月 '26
+49
在5个频道中
Get PRO
五月 '26
+27
在0个频道中
Get PRO
四月 '26
+25
在0个频道中
Get PRO
三月 '26
+19
在0个频道中
Get PRO
二月 '26
+30
在0个频道中
Get PRO
一月 '26
+89
在5个频道中
Get PRO
十二月 '25
+152
在12个频道中
Get PRO
十一月 '25
+114
在2个频道中
Get PRO
十月 '25
+123
在7个频道中
Get PRO
九月 '25
+181
在15个频道中
Get PRO
八月 '25
+19
在0个频道中
Get PRO
七月 '25
+95
在11个频道中
Get PRO
六月 '25
+70
在5个频道中
Get PRO
五月 '25
+72
在1个频道中
Get PRO
四月 '25
+560
在24个频道中
Get PRO
三月 '25
+127
在6个频道中
Get PRO
二月 '25
+205
在8个频道中
Get PRO
一月 '25
+409
在19个频道中
Get PRO
十二月 '24
+69
在0个频道中
Get PRO
十一月 '24
+88
在1个频道中
Get PRO
十月 '24
+598
在8个频道中
Get PRO
九月 '24
+1 046
在26个频道中
Get PRO
八月 '24
+1 013
在24个频道中
Get PRO
七月 '24
+311
在7个频道中
Get PRO
六月 '240
在1个频道中
Get PRO
五月 '240
在0个频道中
Get PRO
四月 '240
在0个频道中
Get PRO
三月 '240
在0个频道中
Get PRO
二月 '240
在0个频道中
Get PRO
一月 '24
+472
在3个频道中
| 日期 | 订阅者增长 | 提及 | 频道 | |
| 16 九月 | 0 | |||
| 15 九月 | +1 | |||
| 14 九月 | +1 | |||
| 13 九月 | 0 | |||
| 12 九月 | 0 | |||
| 11 九月 | 0 | |||
| 10 九月 | +2 | |||
| 09 九月 | 0 | |||
| 08 九月 | 0 | |||
| 07 九月 | +2 | |||
| 06 九月 | +1 | |||
| 05 九月 | 0 | |||
| 04 九月 | 0 | |||
| 03 九月 | 0 | |||
| 02 九月 | 0 | |||
| 01 九月 | 0 |
频道帖子
| 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 |
