🔄 LXQt 2.3.0: больше поддержки Wayland и удобства в работе с файлами

Вышла новая версия LXQt — лёгкого десктопного окружения на основе Qt. Основной фокус релиза на улучшение работы с Wayland, протоколом, который постепенно заменяет X11.

В файловом менеджере PCManFM-Qt появилась функция Safely Remove для безопасного извлечения съёмных носителей, и теперь можно отключить подсказки при наведении на файлы на рабочем столе.

В целом это релиз для тех, кто работает на Wayland или просто хочет больше удобства в повседневной работе с ОС.

➡️ Release notes

🐸 Библиотека devops'a

#пульс_индустрии

🤨 Service mesh в проекте на трёх подах — это перебор

Команды сразу ставят Istio, Cilium, кастомные CNI. Хотят mTLS, продвинутый роутинг, observability из коробки. Но не понимают, как работает базовая сетка Kubernetes.

Что происходит

Под не может достучаться до другого пода. Вы не знаете, это проблема в CNI, в service mesh, в DNS, или в самом Kubernetes. Дебажите три дня, гуглите ошибки Istio. Потом удаляете Istio — всё работает.

Service mesh добавляет sidecar в каждый под, свой control plane, свои CRD. Каждый слой — новая точка отказа.

Как исправить

Начните с простого:

apiVersion: v1
kind: Service
metadata:
  name: backend
spec:
  selector:
    app: backend
  ports:
  - port: 80
    targetPort: 8080

Разберитесь, как поды находят друг друга через DNS. Как ClusterIP балансирует запросы. Как работает Ingress.

Когда поймёте базу, добавьте Ingress-NGINX для внешнего трафика.

🐸 Библиотека devops'a

#арсенал_инженера

🧑‍💻 Ошибка неуязвимого

Kubernetes по умолчанию не строгий. Можно запустить контейнер от root, использовать image:latest, дать всем cluster-admin. Кластер работает — зачем что-то менять?

Что происходит

Контейнер от root может сбежать на ноду через уязвимость. Тег :latest означает, что в prod может задеплоиться любая версия — вчера работало, сегодня нет. Роль cluster-admin даёт права удалить весь кластер.

Как исправить

Настройте RBAC. Создайте роли с минимальными правами:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]

Добавьте Pod Security Standards:

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted

Теперь в namespace нельзя запустить контейнер от root, с privileged, без securityContext.

Если нужна более гибкая политика — Kyverno или OPA Gatekeeper. Напишете правило один раз — оно будет работать для всех подов.

🐸 Библиотека devops'a

#арсенал_инженера

🔄 Обновления недели

Неделя была богата на релизы, вспомним её богатства:

— Consul 1.22

— Wine 10.18

— Grafana Mimir 3.0

— Devuan 6 Excalibur

— LXQt 2.3.0

🐸 Библиотека devops'a

#дайджест_недели

👨‍💻 Как добить поды, если они зависли

Вы удалили ReplicationController с дюжиной подов. Большинство исчезли. Но несколько упрямцев остались висеть в состоянии Terminating, игнорируя ваши попытки удаления.

Когда Kubernetes удаляет под, kubelet выполняет аккуратное завершение: отправляет SIGTERM, ждёт до истечения terminationGracePeriodSeconds, останавливает контейнеры, размонтирует тома и сетевые пространства имён. Финальный шаг — удаление пода с ноды и из API.

Но если размонтирование не удаётся из-за ошибки "device or resource busy", процесс завершения зависает. API-объект остаётся в лимбо состояния Terminating навсегда.

Корень проблемы обычно один: рантайм контейнера оставил утечку — смонтированный том или процесс, который по-прежнему держит файловые дескрипторы.

Быстрая диагностика

Посмотреть есть ли на поде финализаторы:

kubectl get pod <POD> -o jsonpath='{.metadata.finalizers}'

Если они есть — не рубите их сплеча. Это обычно finalizer-ы хранилища (PVC, CSI), которые блокируют удаление до завершения очистки.

Нет финализаторов? Тогда ищем утечку монтирования на уровне хоста.

Подключитесь к ноде, где запускался под:

POD=pod-186o2
NS=default
UID=$(kubectl get pod $POD -n $NS -o jsonpath='{.metadata.uid}')

# На ноде смотрим, что смонтировано
grep -F "$UID" /proc/mounts || true
findmnt | grep "$UID" || true

Если видите записи типа /var/lib/kubelet/pods/<UID>/volumes/... — это ваш виновник.

Теперь узнаем, кто держит монтирование:

lsof +D /var/lib/kubelet/pods/$UID 2>/dev/null | head

Чистим руками

Для Docker:

docker ps --no-trunc | grep $POD
docker stop <containerID>
# Если совсем ничего не помогает (лаха!):
systemctl restart docker

Для containerd:

crictl ps | grep $POD
crictl stopp <containerID>
crictl rmp <containerID>
# Последняя линия защиты:
systemctl restart containerd

Если контейнер мёртв, но монтирование остаётся:

umount -l /var/lib/kubelet/pods/$UID/volumes/<driver>/<vol> || true

Теперь, когда освободили держание:

kubectl delete pod $POD -n $NS

Если всё ещё не уходит:

kubectl delete pod $POD -n $NS --grace-period=0 --force

Это API-уровневый молот. Безопасен для очистки зависшей записи, но используйте только после того, как разобрались с утечками на ноде. С особой осторожностью для StatefulSet.

Видите Terminating, который не уходит? Не спешите с --force. В девяти случаях из десяти kubelet вам что-то говорит: что-то остаётся смонтированным или используется.

🐸 Библиотека devops'a

#арсенал_инженера

🔄 Обновление firewalld

Вышел релиз firewalld версии 2.4.0 — динамически управляемого межсетевого экрана для Linux.

Основные новшества:

• Добавлен набор правил gateway, обеспечивающий функциональность типового домашнего маршрутизатора: NAT, обработка conntrack и перенаправление трафика между зонами.

• Введён флаг disable, который можно применять в XML-конфигурациях, через командную строку и D-Bus для отключения отдельных правил и наборов правил.

• Максимальная длина имён правил увеличена с 17 до 128 символов.

➡️ Release notes

🐸 Библиотека devops'a

#пульс_индустрии

▶️ Запуск CI из Jira

Часто нужно запустить специфичную джобу для конкретной задачи: пересчитать метрики, перепроверить безопасность, прогнать дополнительные тесты. Обычно мы идём в Jenkins или GitHub Actions, ищем нужную джобу, вводим параметры.

Информация о нужном действии находится в Jira, но инструмент для его выполнения — отдельно. Хочется проще: добавил лейбл к задаче и всё запустилось автоматически.

Что можно сделать:

Jira отправляет вебхук с информацией о лейблах в GitHub через repository_dispatch. GitHub Actions ловит это событие, парсит лейблы и запускает нужные шаги. На примере ниже: если в Jira добавили лейбл rebuild-docker, GitHub Actions пересобирает Docker образ. После выполнения можно написать результат комментарием обратно в Jira.

name: Jira Triggered Job

on:
  repository_dispatch:
    types: [jira-trigger]

jobs:
  handle-trigger:
    runs-on: ubuntu-latest
    steps:
      # Парсим labels из payload'a
      - name: Parse Jira event
        id: parse
        run: |
          LABELS="${{ fromJSON(github.event.client_payload).labels }}"
          ISSUE="${{ fromJSON(github.event.client_payload).issueKey }}"
          
          echo "issue=$ISSUE" >> $GITHUB_OUTPUT
          echo "labels=$LABELS" >> $GITHUB_OUTPUT
          echo "Получены labels: $LABELS для issue: $ISSUE"
      
      # Если в labels есть 'rebuild-docker', запускаем пересборку
      - name: Rebuild Docker
        if: contains(steps.parse.outputs.labels, 'rebuild-docker')
        run: |
          echo "🐳 Пересобираем Docker для ${{ steps.parse.outputs.issue }}"
          docker build -t myapp:latest .
          docker push myapp:latest
          echo "DOCKER_STATUS=✅ Docker образ успешно пересобран" >> $GITHUB_ENV
      
      # Если в labels есть 'run-tests', запускаем тесты
      - name: Run Tests
        if: contains(steps.parse.outputs.labels, 'run-tests')
        run: |
          echo "✅ Запускаем тесты для ${{ steps.parse.outputs.issue }}"
          npm test
          echo "TESTS_STATUS=✅ Тесты пройдены успешно" >> $GITHUB_ENV
      
      # Если в labels есть 'security-scan', запускаем проверку безопасности
      - name: Security Scan
        if: contains(steps.parse.outputs.labels, 'security-scan')
        run: |
          echo "🔒 Security scan для ${{ steps.parse.outputs.issue }}"
          npm audit
          echo "SECURITY_STATUS=✅ Security scan завершен" >> $GITHUB_ENV
      
      # Пишем результаты комментарием в Jira
      - name: Comment in Jira
        if: always()
        uses: actions/github-script@v7
        with:
          script: |
            const issue = context.payload.client_payload.issueKey;
            const labels = context.payload.client_payload.labels;
            
            let comment = '🤖 Автоматизированные действия:\n\n';
            
            if (labels.includes('rebuild-docker')) {
              comment += '✅ rebuild-docker: Docker образ пересобран\n';
            }
            if (labels.includes('run-tests')) {
              comment += '✅ run-tests: Тесты запущены\n';
            }
            if (labels.includes('security-scan')) {
              comment += '✅ security-scan: Проверка безопасности завершена\n';
            }

Затем добавьте триггер в Jira, который будет отправлять пейлод:

{
  "event_type": "jira-trigger",
  "client_payload": {
    "issueKey": "{{issue.key}}",
    "labels": "{{issue.labels}}"
  }
}

на урл:

https://api.github.com/repos/ВАШ_НИК/ВАШ_РЕПО/dispatches

с headers:

Authorization: token ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Accept: application/vnd.github.v3+raw+json
Content-Type: application/json

Замените ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxx на ваш GitHub токен, который можно получить по пути GitHub → Settings → Developer settings → Personal access tokens → Tokens.

Это особенно полезно в больших командах, где не все имеют доступ к GitHub Actions, но все работают с Jira. QA может добавить security-scan — и проверка запустится автоматически.

🐸 Библиотека devops'a

#арсенал_инженера

🐸 Библиотека devops'a

#пятничный_деплой

💾 На полке в университете нашли Unix

В хранилище Университета Юты нашли магнитную ленту 1973 года с надписью «UNIX Original From Bell Labs V4». Если это действительно четвёртая версия Unix, то это один из самых важных артефактов в истории программирования.

V4 — это первая версия Unix, написанная на языке C вместо ассемблера. Именно это сделало Unix портируемым: код можно было скомпилировать для разных компьютеров почти без изменений.

Полная копия V4 долго считалась потеряной. Остались только куски кода и справочные страницы. Третья и пятая версии хорошо документированы, а четвёртая — пропуск в истории. Между тем она знаменует момент, когда операционная система превратилась из эксперимента Bell Labs в систему, которую можно переносить и учиться на ней.

➡️ Источник

🐸 Библиотека devops'a

#пульс_индустрии

🛠 Изоляция тестовых данных

Изоляция тестов — критичный момент в стабильном тестировании с базами данных. Проблемы возникают когда тесты используют общие ресурсы или порядок запуска влияет на результат из-за утечки состояния.

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

export TEST_SCHEMA="t_$(uuidgen | tr -d '-')"
psql -c "CREATE SCHEMA ${TEST_SCHEMA};"
pytest --db-schema="${TEST_SCHEMA}" ; rc=$?
psql -c "DROP SCHEMA ${TEST_SCHEMA} CASCADE;"
exit $rc

Схема создаётся перед тестами, используется, например, в pytest через параметр --db-schema, а затем удаляется.

🐸 Библиотека devops'a

#root@prompt

🤩 MX Linux наконец стал systemd-friendly

Вышла MX Linux 25 «Infinity» — первая версия, построенная на Debian 13 «Trixie».

Главное изменение: если раньше MX позиционировал себя как systemd-free дистрибутив, то теперь все ISO идут с systemd по умолчанию. Это не значит, что сторонников sysVinit выгнали — для Xfce и Fluxbox есть sysVinit варианты.

Инсталлятор получил поддержку 64-bit UEFI Secure Boot. Теперь можно ещё и настроить zram swap-устройства. Доступны три десктопа: Xfce 4.20, KDE Plasma 6.3.6 и Fluxbox 1.3.

➡️ Release notes

🐸 Библиотека devops'a

#пульс_индустрии

🔒 Статистика паролей за 2025 год

В 2025 году наибольший слив паролей случился с утечкой 16 миллиардов паролей — одна из крупнейших в истории. При этом 94% пользователей повторяют пароли на разных сервисах, что усиливает риски.

Три четверти паролей не соответствуют базовым требованиям безопасности, а простые пароли типа «123456» до сих пор в лидерах по использованию.

💬 Какие практики применяются у вас на проекте? Находили листочки с паролями на мониторе? Делитесь в комментах👇

➡️ Статистика по паролям

🐸 Библиотека devops'a

#разбор_полётов

❓ Как внедрить zero-trust между микросервисами

Для внедрения zero-trust между микросервисами в DevOps нужно последовательно наложить несколько ключевых слоёв безопасности.

Первое — включить mTLS с распределённой идентичностью на уровне ворклоадов с помощью SPIFFE/SPIRE. Это значит каждой службе присваивается короткоживущий X.509-сертификат (SVID), который автоматически ротацируется и используется для взаимной аутентификации и шифрования трафика.

Такой подход исключает хранение статичных сертификатов и полностью автоматизирует управление ими.

Далее — построить авторизацию по идентичности, используя RBAC или Open Policy Agent (OPA). Это даёт возможность задавать политики доступа в зависимости от конкретной сущности-сервиса, а не на уровне IP или сети. Ещё слой сетевых ограничений добавляют Kubernetes NetworkPolicy, которые ограничивают коммуникацию только разрешёнными путями.

В Kubernetes для реализации zero-trust-mTLS удобно использовать сервис-меши типа Istio, Linkerd или Ambient Mesh (sidecarless). Для мультикластера нужна федерация trust domains, чтобы распространять доверие и идентификацию между кластерами, а также централизованный аудит для мониторинга и инцидент-реакции.

🐸 Библиотека devops'a

#задача_со_звёздочкой