Нежно зайду и нажму кнопку «перезагрузка»

#юмор

🧑‍💻 NetworkAdmin

⚙️ Автоматизация резервного копирования

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

Ansible будет отвечать за логику: какие хосты, какие директории, куда складывать.
rsync за быструю передачу файлов.

▪️ Пример структуры проекта

backup/
├── inventory
├── playbook.yml
└── vars.yml

▪️ vars.yml

backup_src: "/var/www"
backup_dest: "/backups/{{ inventory_hostname }}/"

▪️ playbook.yml

- hosts: all
  become: yes
  vars_files:
    - vars.yml
  tasks:
    - name: Создать директорию для бэкапов
      file:
        path: "{{ backup_dest }}"
        state: directory
        recurse: yes

    - name: Rsync данных
      synchronize:
        src: "{{ backup_src }}/"
        dest: "{{ backup_dest }}"
        archive: yes
        compress: yes
        delete: no

synchronize - это модуль ansible, который под капотом использует rsync.

▪️ Планировщик на контроллере. Бэкапы можно запускать с машины-контроллера ansible через cron:

0 3 * * * ansible-playbook /opt/backup/playbook.yml

Теперь в 03:00 ночи ansible пройдет по инвентарю и снимет инкрементальные копии со всех серверов.

➕ Плюсы такого подхода

единая логика бэкапов;
легко масштабировать на новые сервера;
rsync быстро переносит только измененные файлы.

#ansible #backup

🧑‍💻 NetworkAdmin

❗️ Как сохранить команду в историю, не запуская ее

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

▪️ Как это работает

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

Alt + Shift + 3

После нажатия bash автоматически добавит символ # в начало строки. Команда будет выполнена как комментарий: фактически не запускается, потому что закомментирована, но при этом сохраняется в history вместе с #.

▪️ Как потом ее найти

Открываете поиск по истории (Ctrl + R) и просто ищете по #, нужная команда окажется первой.

Маленькая фича, но иногда очень ускоряет работу.

#bash

🧑‍💻 NetworkAdmin

🙅‍♂️ Immutable-бит в linux

Во многих файловых системах linux есть один механизм - атрибут immutable. Если установить его на файл или директорию, они становятся неизменяемыми: нельзя удалить, переименовать, записать, изменить права. Только root может установить и снять этот флаг.

▪️ Пример 1

Допустим, у вас есть директория /data/upload, куда разные сервисы записывают загружаемые файлы. Иногда часть приложений падает, начинает зацикливаться или выстреливает в ногу и создает сотни временных файлов, заполняя весь диск. Чтобы защититься от такого поведения, можно сделать директорию незаписываемой до тех пор, пока ее вручную не разблокируют администраторы.

Блокируем запись:

chattr +i /data/upload

Теперь попытка записи провалится:

echo test > /data/upload/test.txt

bash: /data/upload/test.txt: Operation not permitted

Разблокируем:

chattr -i /data/upload
echo test > /data/upload/test.txt   # теперь работает

Проверить наличие бита:

lsattr -a /data/upload
----i---------e------- /data/upload/.

▪️ Защита критичных конфигов. Например, чтобы никто (и никакие процессы) не трогал sshd_config:

chattr +i /etc/ssh/sshd_config

▪️ Защита системных файлов

Можно защитить /etc/fstab, /boot/grub/grub.cfg или любые конфиги, которые менять должен только админ.

▪️ Блокировка смены паролей. Установка immutable на /etc/shadow полностью остановит любые попытки смены пароля:

chattr +i /etc/shadow
passwd root   # не сработает

▪️ Нюансы

обновления системы могут ломаться, если immutable стоит на системных файлах;
для root это единственный простой пример, когда он не может удалить файл - хорошая загадка на собесах

#linux #filesystem

🧑‍💻 NetworkAdmin

📂 Автоматическая очистка мусора в Linux

В linux часто копится мусор: временные файлы, старые логи, кэш сервисов. Многие чистят это вручную или пишут свои крон-скрипты. Но в современных дистрибутивах есть встроенный механизм - systemd-tmpfiles. Он автоматически создает, удаляет и очищает файлы и каталоги по заданным правилам.

▪️ Что умеет tmpfiles.d. Systemd-tmpfiles читает конфиги из /usr/lib/tmpfiles.d/, /run/tmpfiles.d/ и /etc/tmpfiles.d/.

Через них можно:

очищать каталоги по времени (30 дней, 12 часов и т.п.);
ограничивать размер директорий;
автоматически создавать нужные файлы с правами и владельцами;
удалять мусор после перезагрузки;
управлять содержимым /tmp, /var/tmp, /var/log и любых других путей.

▪️ Простой пример: удаляем старые файлы

Создадим конфиг:

/etc/tmpfiles.d/cleanup.conf

И добавим правило:

# Удалять файлы старше 14 дней
D /var/tmp/mycache 0755 root root 14d

Типы команд:

D - очистка каталога, не удаляя его самого;
d - удалить и пересоздать;
R - рекурсивная очистка.

После применения правила:

systemd-tmpfiles --clean

Можно запускать вручную или ждать автоматического выполнения таймером systemd.

▪️ Автоматическая очистка /tmp. В большинстве дистрибутивов это уже настроено, но можно задать свои параметры:

d /tmp 1777 root root 7d

Файлы старше 7 дней будут удалены.

▪️ Ограничение размера каталога. Пусть кэш не разрастается:

q /var/cache/nginx 500M

Тип q ограничивает каталог 500 мегабайтами, старые файлы будут удаляться первыми.

▪️ Проверка своих правил. Перед применением:

systemd-tmpfiles --verify

#linux #files

🧑‍💻 NetworkAdmin

Придя на собеседование с данным ремнём вы будете автоматически приняты

#юмор

🧑‍💻 NetworkAdmin

⚙️ Легкая веб-панель для управления сервером

Если вам нужен простой и удобный способ управлять linux-сервером через браузер, то посмотрите в сторону Ajenti. Это не такой мощный гигант, как Webmin, и не такой корпоративный инструмент, как Cockpit, но у него есть свои сильные стороны, которые делают панель отличным выбором для небольших серверов и бытовых задач.

Ajenti - легкая, минималистичная веб-панель, написанная на Python. Ее возможности закрывают базовые потребности администратора: просмотр логов, управление службами, настройка сети, работа с файлами и пользователями. Функциональность можно расширять через плагины, устанавливаемые прямо из интерфейса.

▪️ Преимущества:

2FA по TOTP - удобно и повышает безопасность без лишних танцев.
Аутентификация по сертификатам - для тех, кто любит строгий контроль доступа.
Настраиваемые дашборды - можно собрать себе вкладки с нужными виджетами и даже запускать скрипты в один клик.
Файловый менеджер - простой и удобный, без перегрузов.
Русский язык - панель дружелюбна для тех, кто не хочет копаться в английских меню.
Адаптивный интерфейс - можно зайти с телефона и быстро поправить нужный сервис.

▪️ Установка, она элементарная:

curl https://raw.githubusercontent.com/ajenti/ajenti/master/scripts/install-venv.sh | bash -s -

Скрипт автоматически определяет ваш дистрибутив, ставит зависимости, устанавливает Ajenti через pip и создаёт systemd-службу.

После установки заходите на http://<IP>:8000, логинитесь под root и сразу генерируете самоподписанный сертификат, включив работу по HTTPS.

#linux #ajenti

🧑‍💻 NetworkAdmin

⛔️ Скрываем SSH без VPN и Fail2Ban

SSH на 22-м порту - это первая цель для ботов и сканеров. Даже если вы используете сложный пароль или ключи, сервер всё равно получает тысячи попыток входа. Но есть способ исчезнуть, не ставя VPN и не играясь с Fail2Ban, это Port Knocking.

Это техника, при которой порт SSH по умолчанию закрыт, а открывается только после правильной последовательности простуков - попыток подключения к заранее выбранным портам.

▪️ Как это работает

Все внешние порты закрыты.
Админ отправляет секретную последовательность: например, попытки подключения к портам 7001 → 5022 → 2345.
Firewall фиксирует эту последовательность и открывает доступ к порту 22 только для вашего IP.
После таймаута порт снова закрывается.
Для сканера сервер выглядит мертвым: никакого SSH, никакого 22 порта, ноль шансов на брутфорс.

▪️ Настройка на firewalld (пример). Установим knockd:

apt install knockd

Конфиг /etc/knockd.conf:

[openSSH]
sequence    = 7001,5022,2345
seq_timeout = 10
command     = firewall-cmd --add-rich-rule='rule family="ipv4" source address="%IP%" port protocol="tcp" port="22" accept'
tcpflags    = syn

[closeSSH]
sequence    = 2345,5022,7001
seq_timeout = 10
command     = firewall-cmd --remove-rich-rule='rule family="ipv4" source address="%IP%" port protocol="tcp" port="22" accept'
tcpflags    = syn

Включаем сервис:

systemctl enable --now knockd

▪️ Использование с клиента

Открыть SSH:

knock server.ip 7001 5022 2345

Закрыть обратно:

knock server.ip 2345 5022 7001

Теперь можно заходить:

ssh user@server.ip

#linux #security

🧑‍💻 NetworkAdmin

⏸ Как поставить вывод терминала на паузу

Есть одна старая, но очень полезная фишка терминала, про которую многие либо не знают, либо вспоминают слишком поздно.

Ситуация знакомая: в bash запущен процесс, который постоянно пишет в stdout. Экран бесконечно обновляется, строки летят вниз, а вам нужно прочитать сообщение об ошибке, которое уже убежало вверх. Пытаетесь прокрутить терминал и каждый раз его тут же возвращает в самый низ. Раздражает.

▪️ Классический пример: просмотр логов в реальном времени:

tail -f /var/log/nginx/access.log

С tail это не критично, его можно просто остановить. Но есть куда более неприятные сценарии. Например, вы запустили Docker-контейнер не в -d, он активно пишет логи, где-то мелькнула ошибка, а остановить процесс нельзя - контейнер завершится. То же самое при сборке Dockerfile, запуске большого docker-compose или долгом скрипте с подробным выводом.

▪️ Решение, неожиданно простое:

Ctrl + S - ставит вывод терминала на паузу. Новые строки перестают появляться, и вы спокойно можете прокрутить экран вверх и прочитать нужное место.
Ctrl + Q - возвращает терминал в обычный режим, вывод продолжается.

Это не фича bash, а управление потоком вывода (XON/XOFF), которое работает почти в любом терминале.

Маленькая комбинация клавиш, которая закрывает реально раздражающую проблему и заметно упрощает жизнь в консоли.

#linux #terminal

🧑‍💻 NetworkAdmin

🐧 Как искать проблемы через journalctl

В современных дистрибутивах пингвина все системные логи по умолчанию собирает systemd-journald. Вместо десятков файлов в /var/log вы получаете единый журнал, с которым удобно работать через journalctl. Если сервер ведет себя странно, это первое место, куда стоит смотреть.

▪️ Просмотр логов

journalctl

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

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

journalctl -b

Полезно после падения или перезагрузки сервера.

▪️ Предыдущая загрузка

journalctl -b -1

Позволяет понять, что пошло не так до ребута.

▪️ Логи конкретного сервиса

journalctl -u nginx
journalctl -u ssh

Можно сразу увидеть ошибки запуска, рестарты и падения.

▪️ Фильтрация по времени

journalctl --since "2026-01-22 10:00" --until "2026-01-22 10:30"

▪️ Онлайн-просмотр (аналог tail -f)

journalctl -u docker -f

▪️ Только ошибки

journalctl -p err
journalctl -p warning

Можно комбинировать с -b и -u.

▪️ Кто писал в лог

journalctl _PID=1234
journalctl _COMM=sshd

▪️ Постоянное хранение логов. Если после перезагрузки логи пропадают:

mkdir -p /var/log/journal
systemctl restart systemd-journald

#systemd #journalctl

🧑‍💻 NetworkAdmin

Пришел в театр, чтобы отвлечься от работы, а тут..

#юмор

🧑‍💻 NetworkAdmin

🌐 OSPF и BGP для небольших сетей

Когда в сети появляется больше одного маршрутизатора, статические маршруты быстро превращаются в боль. Даже в небольших инфраструктурах нужен динамический роутинг. Здесь выручает FRRouting (FRR) - open-source стек маршрутизации для линукс.

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

Поддерживаемые протоколы:

OSPFv2 / OSPFv3
BGP
IS-IS
RIP
static routing
VRF

Для небольших сетей чаще всего интересны именно OSPF и BGP.

▪️ Почему FRR удобен для небольших сетей

работает на обычном линукс без спецжелеза;
конфигурация похожа на cisco (vtysh);
можно автоматизировать через ansible;
легко интегрируется с iptables/nftables и policy routing;
отлично подходит для виртуалок и VPN-туннелей.

▪️ Простой пример: OSPF. Устанавливаем пакет и заходим в CLI:

apt install frr
vtysh

Минимальная настройка:

configure terminal
router ospf
 network 10.0.0.0/24 area 0
exit
write

После этого маршрутизаторы начнут автоматически обмениваться маршрутами внутри зоны.

▪️ BGP для своих префиксов. BGP в FRR часто используют:

для мультихоминга;
в VPN.

Пример:

router bgp 65001
 neighbor 10.0.0.2 remote-as 65002
 network 192.168.100.0/24
exit

▪️ Где FRR особенно хорош

небольшие офисы и филиалы;
VPN на WireGuard/IPsec;
тестовые стенды;
self-hosted инфраструктура без дорогих маршрутизаторов.

FRR хороший способ понять и использовать динамическую маршрутизацию без cisco, juniper и железных коробок. Для малых и средних сетей его возможностей более чем достаточно.

#networking #frr

🧑‍💻 NetworkAdmin

🛡 Простой контроль доступа к сервисам в linux

В Linux есть простой и почти забытый механизм ограничения сетевого доступа к сервисам - TCP Wrappers. Сегодня его используют редко, потому что он сильно уступает по гибкости iptables и nftables, но инструмент до сих пор работает и иногда может быть полезен. Основан он на библиотеке libwrap и действует на уровне приложений, которые ее поддерживают.

Суть проста: доступ контролируется через два файла: /etc/hosts.allow и /etc/hosts.deny.

▪️ Пример. Допустим, нужно закрыть SSH для всех, кроме нескольких локальных подсетей.

Для этого в /etc/hosts.allow добавляем:

sshd : 10.10.0.0/24
sshd : 172.16.50.0/24

А в /etc/hosts.deny:

sshd : ALL

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

journalctl -u ssh -n 10
sshd[814]: refused connect from 172.31.8.45 (172.31.8.45)

Можно дополнительно логировать все заблокированные подключения:

sshd : ALL \
: spawn /usr/bin/echo "$(/bin/date +"%%d-%%m-%%y %%T") SSH access blocked from %h" >> /var/log/libwrap

В итоге в /var/log/libwrap появится понятная запись:

21-01-26 10:03:05 SSH access blocked from 172.31.8.45

Важно: сервис обязан поддерживать libwrap. Проверить это можно так:

ldd /usr/sbin/sshd | grep libwrap

Очевидно, что полноценный файрвол будет более надежным решением. Но TCP Wrappers могут быть полезны в простых сценариях, как дополнительный уровень защиты или страховка на случай ошибки в правилах файрвола. Полезно хотя бы знать, что такой механизм существует и как он работает.

#linux #security

🧑‍💻 NetworkAdmin

🌀 Как работает перезагрузка linux в эпоху systemd

Раньше в linux было несколько классических способов перезагрузки системы: shutdown -r, reboot, halt. Сейчас вся эта разница по сути исчезла: в современных дистрибутивах всем управляет systemd.

Если посмотреть внимательнее, окажется, что привычные команды - это всего лишь обертки:

whereis reboot
ls -la /usr/sbin/reboot

и аналогично для shutdown. В итоге обе команды являются символьными ссылками на /bin/systemctl. То есть не важно, что именно вы набрали - reboot, shutdown -r или systemctl reboot - запрос все равно уйдет в systemd.

Иногда можно встретить рекомендации перезагружать сервер именно так:

systemctl reboot

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

Возникает логичный вопрос: как systemctl понимает, что от него хотят - перезагрузку или выключение, если бинарник один и тот же? Все просто: при запуске программа знает имя, под которым ее вызвали. Это стандартный механизм execve. Например, в shell имя команды доступно через $0. Внутри systemctl есть проверка, которая определяет, был ли вызов через reboot, shutdown или напрямую.

Кроме привычных команд, перезагрузку можно инициировать и через цели systemd:

systemctl start reboot.target
systemctl start ctrl-alt-del.target

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

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

echo b > /proc/sysrq-trigger

Это эквивалент жесткого нажатия кнопки reset: без graceful shutdown, но зато работает даже в самых тяжелых ситуациях.

#systemd #reboot

🧑‍💻 NetworkAdmin

Беспощадный кастом

#юмор

🧑‍💻 NetworkAdmin

🖥 Ускоряем сетевые шары в локалке

SMB/CIFS - это один из самых популярных протоколов для файловых шар в локальных сетях. По умолчанию он далеко не всегда работает быстро. Часто жалобы на медленную работу сетевых папок связаны не с дисками или сетью, а с настройками.

Первое, на что стоит обратить внимание: версия протокола. SMB1 давно устарел и медленный, к тому же небезопасный. В современных системах стоит использовать SMB2 или SMB3. На samba это явно задается параметрами server min protocol = SMB2 и server max protocol = SMB3.

Второй момент: размеры буферов и асинхронный ввод-вывод. В samba полезно включать: aio read size и aio write size
socket options = TCP_NODELAY SO_RCVBUF=... SO_SNDBUF=...

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

Для локальной сети важно отключать лишнее. Например, SMB signing нужен для недоверенных сетей, но в домашней или офисной локалке он дает заметный оверхед. Если безопасность позволяет - его можно выключить.

Также стоит учитывать тип нагрузки. Много мелких файлов - одно поведение, большие архивы - другое. Иногда помогает включение sendfile или, наоборот, его отключение в зависимости от файловой системы.

Со стороны клиента тоже есть нюансы. В linux можно монтировать шары с опциями vers=3.1.1, cache=loose, rsize и wsize. В windows проверить, не включен ли старый SMB1 ради совместимости.

И напоследок банальное, но важное: гигабитная сеть, нормальный MTU и исправный DNS влияют на SMB не меньше, чем конфиги. Прежде чем тюнить samba, убедитесь, что сама сеть не узкое место.

Правильно настроенный SMB в локалке легко выдает скорости, близкие к дисковым, без экзотики и лишних костылей.

#smb #networking

🧑‍💻 NetworkAdmin

🔍 Сканирование уязвимостей через Nmap NSE

Nmap - это не только сканер портов. У него есть еще одна часть - NSE (Nmap Scripting Engine), которая позволяет выполнять сотни готовых скриптов для поиска уязвимостей, ошибок конфигурации и опасных сервисов.

Все NSE-скрипты разбиты по категориям: vuln, safe, auth, default, discovery и другие. Для быстрого старта обычно используют стандартный набор:

nmap -sC -sV target

Эта команда запускает default-скрипты и определяет версии сервисов. Уже на этом этапе можно найти слабые места: анонимный FTP, открытые админки, устаревшие демоны.

Для целенаправленного поиска уязвимостей применяется категория vuln:

nmap --script vuln target

Такой запуск проверяет сервисы на известные CVE: уязвимости в SMB, SSL, HTTP, базах данных и сетевых службах. Например, скрипты могут выявить MS17-010 (EternalBlue), слабые TLS-настройки или небезопасные HTTP-методы.

Полезный прием - запуск скриптов для конкретного сервиса:

nmap -p 443 --script ssl-* target

Это помогает быстро оценить состояние TLS: версии протоколов, шифры, сертификаты.

Важно понимать ограничения NSE. Это не полноценный vulnerability scanner, а инструмент первичной проверки. Он не эксплуатирует уязвимости и не гарантирует 100% точность, но отлично подходит для быстрого аудита и поиска очевидных проблем.

⚠️ Используйте NSE аккуратно: сканирование может быть заметно в логах и иногда создает нагрузку на сервисы.

#nmap #security

🧑‍💻 NetworkAdmin

⭐️ Простой бэкап конфигураций MikroTik без костылей

Если нужно регулярно сохранять конфигурации MikroTik, есть аккуратный и удобный инструмент - Pupirka. Это небольшая утилита от Кирилла Васильева, которая делает ровно то, что нужно: подключается к устройству по SSH, выполняет экспорт конфигурации и складывает результат в структурированный каталог. Без самописных скриптов и хаоса.

Работает все максимально просто. Скачиваете один бинарник под свою ОС, делаете его исполняемым и запускаете. При первом старте Pupirka сама создает рабочую структуру: каталоги для бэкапов, описаний устройств, логов, SSH-ключей и базовый JSON-конфиг.

Для добавления MikroTik достаточно положить в каталог device JSON-файл с параметрами подключения: адрес, логин и пароль (или ключ). После этого один запуск и конфигурация устройства автоматически экспортируется. Бэкап сохраняется в отдельную папку устройства, а лог операции пишется рядом. По строке Backup complete легко понять, что все прошло успешно.

Из приятного - поддержка хуков. Например, после каждого бэкапа можно автоматически отправлять конфиги в git-репозиторий. Это удобно для версионирования и аудита изменений.

Хотя Pupirka чаще всего используют именно для MikroTik, она не ограничена только ими. В конфиге можно указать команду, вывод которой нужно сохранять. Фактически, инструмент можно применять и для сбора информации с серверов или сетевых устройств по SSH.

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

Ссылка на GitHub 😺

#mikrotik #backup

🧑‍💻 NetworkAdmin

🔄 Копируем файлы между серверами без прямого SSH-доступа

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

Самые очевидные варианты обычно такие:

1️⃣ Копировать через себя

Скачать данные с первого сервера локально, а потом залить их на второй. Работает всегда, но если у вас медленный канал или большой объем данных - вариант так себе. Иногда вместо себя используют промежуточный сервер с хорошим интернетом, но это тоже костыль.

2️⃣ Настроить SSH-доступ между серверами

Создать ключи, раскидать их, включить парольную аутентификацию и т.д. Иногда это избыточно, иногда просто запрещено политиками безопасности.

3️⃣ Более простой способ - проброс SSH-агента (ssh-agent forwarding). Никаких изменений на серверах, все делается со своей рабочей машины.

▪️ Запускаем ssh-agent. ssh-agent уже входит в состав SSH-клиента. Запускаем его и сразу подгружаем переменные окружения:

eval $(ssh-agent)

Проверяем, что агент работает:

env | grep SSH_

▪️ Добавляем ключи. Загружаем свои SSH-ключи в агент:

ssh-add

Проверить, какие ключи добавлены:

ssh-add -l

▪️ Разрешаем проброс агента. Теперь нужно явно разрешить проброс агента для нужных серверов. Делается это в ~/.ssh/config:

Host 1.2.3.4
  ForwardAgent yes

Host srv-01
  ForwardAgent yes

Важно: включайте ForwardAgent только для конкретных хостов, а не глобально.

▪️ Подключаемся и проверяем

ssh root@1.2.3.4

Если проброс работает, на сервере появится сокет агента:

ls /tmp | grep ssh-

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

rsync -av /var/www/ root@5.6.7.8:/var/www/

Файлы копируются напрямую с сервера на сервер, без скачивания к вам и без настройки SSH-доступа между ними.

▪️ Что важно помнить про безопасность

Когда вы заходите на сервер с включенным пробросом агента, пользователь root этого сервера получает доступ к вашему ssh-agent и может использовать его для подключений.

Поэтому:

не используйте agent forwarding на чужих или сомнительных серверах;
не включайте его глобально;
отключайте, когда он не нужен.

#ssh #rsync

🧑‍💻 NetworkAdmin

🤝 Автологин, автозагрузка и unit override в systemd

▪️ Автологин в консоль (getty) - иногда нужно, чтобы система автоматически логинилась в tty (например, для тестового стенда). Делается это через override для getty:

systemctl edit getty@tty1

Добавляем:

[Service]
ExecStart=
ExecStart=-/sbin/agetty --autologin user --noclear %I $TERM

Перезагружаем:

systemctl restart getty@tty1

▪️ Автозагрузка сервисов. В systemd нет автозапуска в классическом смысле - есть юниты и таргеты. Включить сервис при загрузке:

systemctl enable nginx

Проверить состояние:

systemctl is-enabled nginx
systemctl status nginx

Отключить автозапуск:

systemctl disable nginx

Фактически enable создает симлинк юнита в нужный *.target.

▪️ Unit override: меняем поведение безопасно. Править файлы в /lib/systemd/system - плохая идея. Обновления их перезапишут. Вместо этого используют override-файлы. Для этого создаем override:

systemctl edit nginx

Пример: увеличим лимит открытых файлов:

[Service]
LimitNOFILE=65536

Применяем изменения:

systemctl daemon-reexec
systemctl restart nginx

Посмотреть итоговую конфигурацию:

systemctl cat nginx

Systemd покажет базовый unit + все override.

#systemd #linux

🧑‍💻 NetworkAdmin