✍️ Быстрый способ выпустить свой HTTPS-сертификат через собственный CA

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

Гораздо удобнее выпустить свой корневой CA, добавить его в доверенные и генерировать сертификаты под любые домены/IP с любым сроком (хоть на 9999 дней). Покажу, как сделать это для Nginx.

В примере выпускаем сертификат для домена zabbix.internal и IP 192.168.77.55.

1️⃣ Создаем свой CA

mkdir ~/tls && cd ~/tls
openssl ecparam -out myCA.key -name prime256v1 -genkey
openssl req -x509 -new -nodes -key myCA.key -sha256 -days 9999 -out myCA.crt

На вопросы можно отвечать что угодно, это локальный CA.

2️⃣ Генерируем ключ и CSR для сервера

openssl genrsa -out zabbix.internal.key 2048
openssl req -new -key zabbix.internal.key -out zabbix.internal.csr

3️⃣ Создаем файл расширений

mcedit zabbix.internal.ext

Добавляем:

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names

[alt_names]
IP.1 = 192.168.77.55
DNS.1 = zabbix.internal

4️⃣ Выпускаем сертификат

openssl x509 -req -in zabbix.internal.csr -CA myCA.crt -CAkey myCA.key \
-CAcreateserial -out zabbix.internal.crt -days 9999 -sha256 -extfile zabbix.internal.ext

5️⃣ Копируем сертификаты в nginx

mkdir /etc/nginx/certs
cp zabbix.internal.crt /etc/nginx/certs/
cp zabbix.internal.key /etc/nginx/certs/

Создаем DH-параметры:

openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

6️⃣ Настраиваем виртуальный хост nginx

listen 443 http2 ssl;
server_name zabbix.internal 192.168.77.55;
ssl_certificate /etc/nginx/certs/zabbix.internal.crt;
ssl_certificate_key /etc/nginx/certs/zabbix.internal.key;
ssl_dhparam /etc/ssl/certs/dhparam.pem;

Перезапуск:

nginx -t
nginx -s reload

7️⃣ Делаем CA доверенным

Передайте файл myCA.crt на свой ПК и добавьте в хранилище доверенных сертификатов.

Если нужно доверить CA прямо на Debian:

cp myCA.crt /usr/local/share/ca-certificates/
update-ca-certificates

Теперь можно заходить на сайт по доменному имени или IP, браузер будет полностью доверять сертификату.

#webserver

🧑‍💻 NetworkAdmin

🔓 Ansible Vault: хранение секретов и паролей

Если вы работаете с Ansible, рано или поздно возникает вопрос: куда девать пароли, ключи, токены и прочее? Хранить их в открытом виде в репозитории - явно плохая идея. Для этого существует Ansible Vault - встроенный механизм шифрования файлов и переменных.

Vault позволяет безопасно хранить секреты прямо в плейбуках или отдельных файлах, а ansible будет расшифровывать их при выполнении. Все просто, удобно и без лишних зависимостей.

▪️ Шифруем файл. Создадим защищенный файл с переменными:

ansible-vault create secrets.yml

Откроется редактор, куда можно вписать переменные, например:

db_user: admin
db_pass: S3cretP@ss

Файл автоматически сохранится в зашифрованном виде.

▪️ Редактируем зашифрованный файл

ansible-vault edit secrets.yml

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

ansible-vault decrypt secrets.yml

И обратно:

ansible-vault encrypt secrets.yml

▪️ Использование в плейбуках. Зашифрованный файл подключается как обычно:

vars_files:
  - secrets.yml

А запуск плейбука выглядит так:

ansible-playbook site.yml --ask-vault-pass

▪️ Частичное шифрование (опционально). Можно зашифровать только нужные переменные:

ansible-vault encrypt_string 'P@ssw0rd!' --name 'db_pass'

#ansible

🧑‍💻 NetworkAdmin

📱 Тестирование производительности PostgreSQL

Если нужно быстро оценить, как PostgreSQL чувствует себя на разных типах дисков, файловых системах или конфигурациях виртуалок, необязательно глубоко погружаться в тюнинг СУБД. Достаточно воспользоваться встроенной утилитой pgbench, она идет в комплекте с PostgreSQL и позволяет получить базовые, но показательные метрики.

▪️ Установка и подготовка среды. Устанавливаем PostgreSQL:

apt install postgresql

Проверяем работу службы:

systemctl status postgresql

Создаем тестовую базу:

su - postgres
psql
create database test_db;
\q

Инициализируем тестовые данные, увеличив объём в 10 раз:

pgbench -i test_db -s 10

▪️ Запуск теста нагрузки. Прогоняем тест: 5 клиентов, 2 потока, 60 секунд, вывод статистики каждые 5 секунд:

pgbench test_db -c 5 -j 2 -P 5 -T 60

Пример результата:

number of transactions actually processed: 219950
latency average = 1.362 ms
tps = 3665.930847

СУБД обработала 219 950 транзакций со скоростью ~3666 TPS, это и есть показатель, который удобно использовать для сравнения.

▪️ Что именно тестирует pgbench?

По умолчанию запускается смесь операций, напоминающая TPC-B: внутри одной транзакции идут SELECT, UPDATE и INSERT. Можно использовать свои сценарии, создавая кастомные SQL-скрипты. В документации PostgreSQL (в том числе русской) всё подробно описано.

#postgresql

🧑‍💻 NetworkAdmin

🖥 RemoteApp на Windows 10/11

Если вам нужно, чтобы пользователи запускали через RDP не целый рабочий стол, а только определенное приложение, то для этого подойдет режим RemoteApp. Он чаще ассоциируется с серверами windows, но его реально настроить и на обычной win 10/11.

▪️ Что нужно сделать на сервере (удаленном Windows).

1. Включить RDP-доступ.
2. Установить нужное приложение и добавить пользователя в группу Remote Desktop Users или дать право через политику безопасности.
3. Разрешить запуск неопубликованных программ как RemoteApp: либо через групповые политики, либо через реестр:

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v fAllowUnlistedRemotePrograms /t REG_DWORD /d 1

Перезагрузить компьютер.

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

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\TSAppAllowList\Applications\<AppName> с указанием пути, иконки и имени.

▪️ Как пользователь подключается

Открываете стандартный RDP-клиент (mstsc.exe) и настраиваете подключение, затем сохраняете его как файл .RDP.

Открываете .RDP в текстовом редакторе и добавляете в конец:

remoteapplicationmode:i:1  
RemoteApplicationName:s:Имя_окна  
RemoteApplicationProgram:s:"C:\path\to\app.exe"  
DisableRemoteAppCheck:i:1  
PromptForCredentials:i:0  
alternate shell:s:rdpinit.exe

При запуске этого файла на клиенте откроется только окно указанного приложения так, словно оно запускается локально.

Если нужно передать аргументы запуска, можно добавить строку RemoteApplicationCmdLine:s:....

▪️ Что важно

Хотя RemoteApp официально поддерживается на серверах с ролью RDS, этот способ работает и на win 10/11.

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

Для работы может потребоваться RDP Wrapper или другие обходы, если Windows пытается ограничить одновременные сеансы.

#windows #remoteapp

🧑‍💻 NetworkAdmin

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

#юмор

🧑‍💻 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