Linux: Забудь про ifconfig. Настраиваем сеть декларативно с Netplan
В современных Ubuntu и других дистрибутивах редактирование файла /etc/network/interfaces — это устаревший подход. На смену ему пришёл Netplan — декларативный инструмент для настройки сети через простой YAML-синтаксис.
Вы больше не пишете команды "как настроить". Вы описываете "какой должна быть сеть".
Задача: Настроить на сервере статический IP-адрес.
1. Находим файл конфигурации:
Все конфиги лежат в /etc/netplan/. Обычно это файл вроде 01-netcfg.yaml или 50-cloud-init.yaml.
Bash
2. Редактируем конфигурацию:
Открываем найденный файл и приводим его к следующему виду. Внимание: YAML чувствителен к отступам! Используйте два пробела.
YAML
3. Применяем конфигурацию:
Две команды для проверки и применения.
Bash
Почему это взгляд архитектора?
✅ Декларативность: Конфиг описывает конечное состояние. Его легко читать, версионировать в Git и использовать в системах автоматизации (Ansible, Terraform).
✅ Атомарность: Команда netplan apply применяет изменения атомарно. Если в конфиге ошибка, он не сломает вам сеть посреди процесса.
✅ Универсальность: Netplan — это "фронтенд", который может управлять разными "бекендами" (systemd-networkd или NetworkManager), скрывая от вас сложность их настройки.
#linux #networking #netplan #ubuntu #architect #команды
В современных Ubuntu и других дистрибутивах редактирование файла /etc/network/interfaces — это устаревший подход. На смену ему пришёл Netplan — декларативный инструмент для настройки сети через простой YAML-синтаксис.
Вы больше не пишете команды "как настроить". Вы описываете "какой должна быть сеть".
Задача: Настроить на сервере статический IP-адрес.
1. Находим файл конфигурации:
Все конфиги лежат в /etc/netplan/. Обычно это файл вроде 01-netcfg.yaml или 50-cloud-init.yaml.
Bash
ls /etc/netplan/
2. Редактируем конфигурацию:
Открываем найденный файл и приводим его к следующему виду. Внимание: YAML чувствителен к отступам! Используйте два пробела.
YAML
network:
version: 2
renderer: networkd # Используем systemd-networkd, стандарт для серверов
ethernets:
ens18: # Имя вашего интерфейса (узнать: ip a)
dhcp4: no # Отключаем DHCP
addresses:
- 192.168.1.100/24 # Статический IP и маска
gateway4: 192.168.1.1 # Шлюз
nameservers:
addresses: [8.8.8.8, 1.1.1.1] # DNS-серверы
3. Применяем конфигурацию:
Две команды для проверки и применения.
Bash
# Проверяем синтаксис файла
sudo netplan generate
# Применяем изменения
sudo netplan apply
Почему это взгляд архитектора?
✅ Декларативность: Конфиг описывает конечное состояние. Его легко читать, версионировать в Git и использовать в системах автоматизации (Ansible, Terraform).
✅ Атомарность: Команда netplan apply применяет изменения атомарно. Если в конфиге ошибка, он не сломает вам сеть посреди процесса.
✅ Универсальность: Netplan — это "фронтенд", который может управлять разными "бекендами" (systemd-networkd или NetworkManager), скрывая от вас сложность их настройки.
#linux #networking #netplan #ubuntu #architect #команды
Linux: Настрой и забудь. Автоматические обновления безопасности с Unattended-Upgrades
Обновлять пакеты вручную — хорошая практика, но на десятках или сотнях серверов она нереализуема. Пропущенное обновление безопасности может стать причиной взлома.
Архитектурно правильное решение — автоматизировать установку только критически важных обновлений безопасности, чтобы минимизировать риски простоя и обеспечить базовую защиту. В Ubuntu/Debian для этого есть unattended-upgrades.
Пошаговая настройка:
Установка (если его ещё нет):
Bash
Основная конфигурация:
Откройте файл /etc/apt/apt.conf.d/50unattended-upgrades. Найдите и раскомментируйте (уберите //) строку, отвечающую за security-апдейты:
Это разрешает установку обновлений только из репозитория безопасности.
В этом же файле можно настроить отправку отчётов на email или автоматическую перезагрузку, если она требуется.
Включение автоматического запуска:
Откройте файл /etc/apt/apt.conf.d/20auto-upgrades и убедитесь, что его содержимое выглядит так:
Первая строка включает ежедневное выполнение apt update. Вторая — ежедневный запуск unattended-upgrade.
Проверка и отладка:
Вы можете запустить процесс в "сухом" режиме, чтобы посмотреть, что именно будет обновлено:
Bash
Все логи работы хранятся в /var/log/unattended-upgrades/.
Взгляд архитектора:
Это не просто скрипт в кроне. Это компонент зрелой стратегии управления уязвимостями. Он обеспечивает постоянный базовый уровень безопасности для всего парка машин, освобождая время инженера для более сложных задач. Риск "сломать всё" минимален, так как обновления приложений и ядра (которые могут повлиять на совместимость) остаются для установки вручную.
#linux #security #automation #ubuntu #debian #гайд
Обновлять пакеты вручную — хорошая практика, но на десятках или сотнях серверов она нереализуема. Пропущенное обновление безопасности может стать причиной взлома.
Архитектурно правильное решение — автоматизировать установку только критически важных обновлений безопасности, чтобы минимизировать риски простоя и обеспечить базовую защиту. В Ubuntu/Debian для этого есть unattended-upgrades.
Пошаговая настройка:
Установка (если его ещё нет):
Bash
sudo apt update
sudo apt install unattended-upgrades
Основная конфигурация:
Откройте файл /etc/apt/apt.conf.d/50unattended-upgrades. Найдите и раскомментируйте (уберите //) строку, отвечающую за security-апдейты:
// Раскомментировать эту строку:
"${distro_id}:${distro_codename}-security";
Это разрешает установку обновлений только из репозитория безопасности.
В этом же файле можно настроить отправку отчётов на email или автоматическую перезагрузку, если она требуется.
Включение автоматического запуска:
Откройте файл /etc/apt/apt.conf.d/20auto-upgrades и убедитесь, что его содержимое выглядит так:
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
Первая строка включает ежедневное выполнение apt update. Вторая — ежедневный запуск unattended-upgrade.
Проверка и отладка:
Вы можете запустить процесс в "сухом" режиме, чтобы посмотреть, что именно будет обновлено:
Bash
sudo unattended-upgrades --dry-run --debug
Все логи работы хранятся в /var/log/unattended-upgrades/.
Взгляд архитектора:
Это не просто скрипт в кроне. Это компонент зрелой стратегии управления уязвимостями. Он обеспечивает постоянный базовый уровень безопасности для всего парка машин, освобождая время инженера для более сложных задач. Риск "сломать всё" минимален, так как обновления приложений и ядра (которые могут повлиять на совместимость) остаются для установки вручную.
#linux #security #automation #ubuntu #debian #гайд
🐧 Linux: systemd 260 убил SysV — и если у тебя ещё живёт /etc/init.d, читай срочно
Коллеги, 17 марта 2026 года вышел systemd 260 — и он сделал то, о чём предупреждали несколько лет. Наиболее разрушительное изменение: полное удаление поддержки System V init-скриптов. Компоненты systemd-sysv-generator, systemd-sysv-install и rc-local.service удалены окончательно. Никакого мягкого устаревания — мост сожжён.
Если у вас в продакшне живут legacy-сервисы со скриптами в /etc/init.d/ — они тихо перестанут запускаться после обновления. Без ошибок в журнале. Просто не стартуют.
Но в этом же релизе есть кое-что интересное: добавлен новый параметр MemoryTHP= для управления Transparent Huge Pages на уровне отдельного сервиса, а CPUSchedulingPolicy= теперь поддерживает значение ext для включения планировщика SCHED_EXT. Для высоконагруженных сервисов — это прямой рычаг тонкой настройки без правки параметров ядра глобально.
Сначала — аварийный аудит. Находим всё, что ещё на SysV:
Зачем это нужно:
Сервисы, у которых нет native unit-файлов, после обновления на systemd 260 не запустятся тихо и без предупреждений. Самый критичный action item для всех администраторов — провести аудит и мигрировать оставшиеся SysV init-скрипты до обновления. Ubuntu 26.04 LTS выходит 23 апреля и несёт systemd 260 по умолчанию. Срок — неделя.
Итог: SysV жил с 1983 года. Хватит. Если у тебя до сих пор есть /etc/init.d/что-то — это не legacy, это пожарная опасность. Миграция на unit-файл занимает 15 минут. Объяснение инциденту на встрече с Романом — значительно дольше.
#linux #systemd #sysv #sysadmin #ubuntu #admin_future
Коллеги, 17 марта 2026 года вышел systemd 260 — и он сделал то, о чём предупреждали несколько лет. Наиболее разрушительное изменение: полное удаление поддержки System V init-скриптов. Компоненты systemd-sysv-generator, systemd-sysv-install и rc-local.service удалены окончательно. Никакого мягкого устаревания — мост сожжён.
Если у вас в продакшне живут legacy-сервисы со скриптами в /etc/init.d/ — они тихо перестанут запускаться после обновления. Без ошибок в журнале. Просто не стартуют.
Но в этом же релизе есть кое-что интересное: добавлен новый параметр MemoryTHP= для управления Transparent Huge Pages на уровне отдельного сервиса, а CPUSchedulingPolicy= теперь поддерживает значение ext для включения планировщика SCHED_EXT. Для высоконагруженных сервисов — это прямой рычаг тонкой настройки без правки параметров ядра глобально.
Сначала — аварийный аудит. Находим всё, что ещё на SysV:
# Ищем живые SysV-скрипты в системе
find /etc/init.d/ -type f -not -name "README" 2>/dev/null
# Проверяем, нет ли сервисов без native unit-файла
# (до обновления на systemd 260 — sysv-generator ещё конвертировал их)
systemctl list-units --type=service --state=loaded | grep -v ".service"
# Смотрим, какие сервисы СЕЙЧАС запущены через SysV-совместимость
systemctl list-units --type=service | \
while read unit _; do
unit_file=$(systemctl show "$unit" -p FragmentPath --value 2>/dev/null)
[[ "$unit_file" == /etc/init.d/* ]] && echo "LEGACY SysV: $unit -> $unit_file"
done
# Для найденного legacy-сервиса пишем нормальный unit.
# Пример: конвертируем старый /etc/init.d/myapp
cat > /etc/systemd/system/myapp.service << 'EOF'
[Unit]
Description=My Legacy Application
After=network.target
[Service]
Type=forking
ExecStart=/usr/local/bin/myapp --daemon
ExecStop=/usr/local/bin/myapp --stop
PIDFile=/var/run/myapp.pid
Restart=on-failure
RestartSec=5s
# Новое в systemd 260: тонкая настройка памяти для сервиса
# Отключаем THP для Java-приложений (они его не любят)
MemoryTHP=never
[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload
systemctl enable --now myapp.service
systemctl status myapp.service
Зачем это нужно:
Сервисы, у которых нет native unit-файлов, после обновления на systemd 260 не запустятся тихо и без предупреждений. Самый критичный action item для всех администраторов — провести аудит и мигрировать оставшиеся SysV init-скрипты до обновления. Ubuntu 26.04 LTS выходит 23 апреля и несёт systemd 260 по умолчанию. Срок — неделя.
Итог: SysV жил с 1983 года. Хватит. Если у тебя до сих пор есть /etc/init.d/что-то — это не legacy, это пожарная опасность. Миграция на unit-файл занимает 15 минут. Объяснение инциденту на встрече с Романом — значительно дольше.
#linux #systemd #sysv #sysadmin #ubuntu #admin_future
🐧 Linux: Ubuntu 26.04 LTS вышла сегодня — что важно для сервера
Коллеги, 23 апреля 2026 — день релиза Ubuntu 26.04 LTS «Resolute Raccoon». Поддержка 5 лет бесплатно (до 2031), с Ubuntu Pro — 10 лет. Это первый LTS после 24.04.
Три вещи, важных конкретно для серверной эксплуатации:
Первое — sudo-rs теперь дефолтный sudo-провайдер. Оригинальный sudo переименован в sudo.ws. Пакет sudo-ldap удалён: LDAP-аутентификация теперь только через PAM. Если у вас sudo через LDAP — проверьте конфигурацию до апгрейда.
Второе — systemd в этом релизе убирает поддержку cgroup v1 полностью. Только унифицированная иерархия cgroup v2. Если какие-то контейнеры или легаси-сервисы у вас были привязаны к v1 — они не запустятся.
Третье — ядро Linux 7.0 из коробки. Это XFS self-healing, стабильный Rust, улучшенная производительность памяти (время аллокации больших блоков упало с 3.6 до 0.43 секунды), создание контейнеров стало на 40% быстрее.
Зачем это нужно:
Для продакшн-серверов рекомендуется подождать релиза 26.04.1 в августе 2026 — первый point release включает несколько месяцев исправлений и открывает официальный путь апгрейда с 24.04.
Итог: новые серверы — ставьте 26.04 сегодня. Продакшн 24.04 — дождитесь августа.
#linux #ubuntu #lts #sysadmin #admin_future
Коллеги, 23 апреля 2026 — день релиза Ubuntu 26.04 LTS «Resolute Raccoon». Поддержка 5 лет бесплатно (до 2031), с Ubuntu Pro — 10 лет. Это первый LTS после 24.04.
Три вещи, важных конкретно для серверной эксплуатации:
Первое — sudo-rs теперь дефолтный sudo-провайдер. Оригинальный sudo переименован в sudo.ws. Пакет sudo-ldap удалён: LDAP-аутентификация теперь только через PAM. Если у вас sudo через LDAP — проверьте конфигурацию до апгрейда.
Второе — systemd в этом релизе убирает поддержку cgroup v1 полностью. Только унифицированная иерархия cgroup v2. Если какие-то контейнеры или легаси-сервисы у вас были привязаны к v1 — они не запустятся.
Третье — ядро Linux 7.0 из коробки. Это XFS self-healing, стабильный Rust, улучшенная производительность памяти (время аллокации больших блоков упало с 3.6 до 0.43 секунды), создание контейнеров стало на 40% быстрее.
# Проверяем готовность к апгрейду с 24.04
# Смотрим есть ли sudo через LDAP
grep -r "ldap" /etc/sudo* /etc/nsswitch.conf 2>/dev/null
# Проверяем cgroup версию
stat -fc %T /sys/fs/cgroup/
# tmpfs = v1 (проблема), cgroup2fs = v2 (порядок)
# Официальный апгрейд (когда будет открыт путь 24.04→26.04):
sudo do-release-upgrade
Зачем это нужно:
Для продакшн-серверов рекомендуется подождать релиза 26.04.1 в августе 2026 — первый point release включает несколько месяцев исправлений и открывает официальный путь апгрейда с 24.04.
Итог: новые серверы — ставьте 26.04 сегодня. Продакшн 24.04 — дождитесь августа.
#linux #ubuntu #lts #sysadmin #admin_future
🐧 Linux: Rust теперь в APT — и это важнее чем кажется
Коллеги, на этой неделе случилось кое-что, о чём мало кто написал — но что касается каждого администратора Debian/Ubuntu-флота напрямую.
Два события мая 2026 окончательно переместили Rust из категории «языка будущего» в load-bearing инфраструктуру. Первое: Linux 7.0 убрал пометку experimental с Rust — теперь это официальный язык ядра наравне с C. Второе: APT maintainer Julian Klode объявил что Debian's package manager начинает требовать жёсткую зависимость от Rust начиная с мая 2026.
Что это значит практически для администратора:
APT — это package manager для Debian и каждого производного дистрибутива: Ubuntu, Linux Mint, Pop!_OS, Kali Linux, Raspberry Pi OS. Rust-компилятор, стандартная библиотека и части Sequoia PGP теперь встроены в core APT — для парсинга .deb, .ar и .tar файлов, а также HTTP signature verification.
Зачем Rust именно здесь? APT обрабатывает недоверенные данные (пакеты из интернета) на уровне root. Memory corruption в парсере пакетов — это immediate root compromise. Rust устраняет целые классы уязвимостей вроде use-after-free, которые типичны для C-кода. Это интеграция снижает реальную поверхность атаки в местах где это наиболее критично.
Для администраторов air-gapped и закрытых сред — это практическое действие сейчас: убедись что твои offline-репозитории содержат rust-пакеты. После обновления APT на системах без сети это может сломать
Итог: Rust перешёл из «интересно, но не моя проблема» в «часть базовой инфраструктуры моего дистрибутива». Пятница — хороший момент проверить offline-репы.
#linux #rust #debian #ubuntu #apt #security #sysadmin #admin_future
Коллеги, на этой неделе случилось кое-что, о чём мало кто написал — но что касается каждого администратора Debian/Ubuntu-флота напрямую.
Два события мая 2026 окончательно переместили Rust из категории «языка будущего» в load-bearing инфраструктуру. Первое: Linux 7.0 убрал пометку experimental с Rust — теперь это официальный язык ядра наравне с C. Второе: APT maintainer Julian Klode объявил что Debian's package manager начинает требовать жёсткую зависимость от Rust начиная с мая 2026.
Что это значит практически для администратора:
APT — это package manager для Debian и каждого производного дистрибутива: Ubuntu, Linux Mint, Pop!_OS, Kali Linux, Raspberry Pi OS. Rust-компилятор, стандартная библиотека и части Sequoia PGP теперь встроены в core APT — для парсинга .deb, .ar и .tar файлов, а также HTTP signature verification.
Зачем Rust именно здесь? APT обрабатывает недоверенные данные (пакеты из интернета) на уровне root. Memory corruption в парсере пакетов — это immediate root compromise. Rust устраняет целые классы уязвимостей вроде use-after-free, которые типичны для C-кода. Это интеграция снижает реальную поверхность атаки в местах где это наиболее критично.
# Проверяем Rust в APT на Ubuntu 26.04:
apt-cache show apt | grep -i rust
dpkg -l | grep -i "rust\|rustc"
# Для администраторов air-gapped сред:
# APT теперь требует rustc при сборке из исходников
# Проверяем что offline-репозиторий включает rust-пакеты:
apt-get install --dry-run apt 2>&1 | grep -i rust
# Для Debian 13 Forky (выход 2027):
# Rust будет требоваться для сборки ядра модулей через DKMS
# Уже сейчас можно подготовить offline-кэш:
apt-get download rustc cargo libstd-rust-dev
# Смотрим версию Rust в системе:
rustc --version 2>/dev/null || echo "Rust not installed"
# На Ubuntu 26.04 должно быть 1.80+ из репозитория
Для администраторов air-gapped и закрытых сред — это практическое действие сейчас: убедись что твои offline-репозитории содержат rust-пакеты. После обновления APT на системах без сети это может сломать
apt upgrade если Rust недоступен.Итог: Rust перешёл из «интересно, но не моя проблема» в «часть базовой инфраструктуры моего дистрибутива». Пятница — хороший момент проверить offline-репы.
#linux #rust #debian #ubuntu #apt #security #sysadmin #admin_future