Установка Cockpit на Debian 13 (Trixie) делается через стандартные репозитории, но для полноценной работы (особенно модулей виртуализации) нужно включить несколько пакетов и настроить firewall. Ниже — полный, аккуратный, технически корректный набор команд, ориентированный на твой стиль работы.

🖥️ Установка Cockpit на Debian 13

1) Обнови систему

Код

sudo apt update && sudo apt upgrade -y

2) Установи Cockpit

Debian 13 уже содержит пакет в официальных репозиториях:

Код

sudo apt install cockpit -y

3) Установи полезные модули Cockpit

Код

sudo apt install cockpit-pcp cockpit-networkmanager cockpit-storaged cockpit-packagekit -y

Если планируешь виртуализацию:

Код

sudo apt install cockpit-machines qemu-system libvirt-daemon-system libvirt-clients -y
sudo systemctl enable --now libvirtd

Если используешь контейнеры:

Код

sudo apt install cockpit-podman podman -y

🔐 4) Разреши доступ к веб‑панели

Cockpit слушает порт 9090.

Если у тебя включён UFW:

Код

sudo ufw allow 9090/tcp

Если используется firewalld:

Код

sudo firewall-cmd --add-service=cockpit --permanent
sudo firewall-cmd --reload

🚀 5) Запусти Cockpit

Cockpit использует systemd socket activation, поэтому запускать вручную не нужно, но можно проверить:

Код

sudo systemctl status cockpit.socket

Открой в браузере:

Код

https://<IP_сервера>:9090

Вход — обычный системный пользователь с sudo.

📦 6) (Опционально) Включи мониторинг PCP

Это даст графики CPU, RAM, IO, сеть:

Код

sudo systemctl enable --now pcp

Для возможности устанавливать виртуальные машины стоит добавть..

Коротко: Ошибка означает, что libvirt default network не запущена, поэтому установка виртуальной машины через Cockpit/libvirt завершается неудачно. На Proxmox это нормально, потому что PVE не использует libvirt, и его default‑сеть обычно отключена.

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

Libvirt пытается использовать виртуальную сеть default, но:

• она не активна,
• она не создана (часто на Proxmox),
• или libvirt вообще не должен использоваться, потому что Proxmox работает через pvedaemon и qemu-server, а не через libvirt.

🟢 Решение (если хочешь использовать libvirt в Cockpit)

Активируй сеть:

Код

sudo virsh net-start default
sudo virsh net-autostart default

Если сети нет — создай её:

Код

sudo virsh net-define /usr/share/libvirt/networks/default.xml
sudo virsh net-start default
sudo virsh net-autostart default

🔴 Важно для Proxmox

На Proxmox VE:

• libvirt не используется для виртуалок,
• Cockpit‑модуль cockpit-machines не работает с Proxmox VM,
• любые попытки создать VM через Cockpit → ошибки libvirt.

То есть ошибка нормальная, потому что ты пытаешься использовать libvirt в системе, где виртуализация управляется Proxmox.

Ещё нюанс

Понял, Alex — ты поставил Cockpit на реальную машину, а не на Proxmox‑хост. Это полностью меняет картину: libvirt на обычном Debian/Ubuntu работает нормально, но ошибка указывает на конкретную проблему — AppArmor блокирует доступ QEMU к ISO в твоём домашнем каталоге.

Сеть default у тебя активна, всё ок:

Код

default   active   yes   yes

Но VM всё равно не создаётся, потому что QEMU не может открыть ISO из /home/alex/images/.

🧩 Почему это происходит на реальной машине

Даже на обычном Debian:

• libvirt запускает QEMU под профилем AppArmor
• AppArmor запрещает доступ к /home/
• QEMU может читать ISO только из разрешённых директорий, например:
  • /var/lib/libvirt/images/
  • /var/lib/libvirt/boot/
  • /var/lib/libvirt/filesystems/

Cockpit → libvirt → QEMU → AppArmor → Permission denied

🟢 Решение: перемести ISO в разрешённый каталог

1) Создай каталог (если нет)

Код

sudo mkdir -p /var/lib/libvirt/images

2) Перемести ISO

Код

sudo cp /home/alex/images/debian-13.5.0-amd64-netinst.iso /var/lib/libvirt/images/

3) Дай правильные права

Код

sudo chown libvirt-qemu:libvirt-qemu /var/lib/libvirt/images/debian-13.5.0-amd64-netinst.iso

4) Проверка

Код

ls -l /var/lib/libvirt/images/

После этого Cockpit сможет создать VM.

🧩 Почему Cockpit не может использовать ISO из /home

Потому что AppArmor профили libvirt содержат правило:

Код

deny /home/** r,

Это сделано для безопасности, чтобы QEMU не мог читать пользовательские файлы.

🟣 Если хочешь отключить AppArmor для libvirt (не рекомендую)

Можно временно перевести профиль в complain‑mode:

Код

sudo aa-complain /etc/apparmor.d/usr.sbin.libvirtd

Но лучше не трогать AppArmor, а просто использовать правильный каталог.

🟢 Итог

• Cockpit на реальной машине работает нормально.
• Сеть default активна — всё хорошо.
• Ошибка вызвана AppArmor → ISO в /home → Permission denied.
• Перемести ISO в /var/lib/libvirt/images/ → VM создастся.

Если Cockpit работает через реверс-прокси, важно учесть один момент

Короткий вывод: у тебя включён cockpit-tls, и это гарантированно вызывает бесконечный редирект при работе через Apache reverse proxy. Cockpit в твоей конфигурации сам поднимает HTTPS, хотя ты уже завернул его в HTTPS через Apache. В итоге:

• браузер → Apache (HTTPS)
• Apache → Cockpit (HTTP)
• Cockpit видит HTTP → делает редирект на HTTPS
• Apache → снова HTTP → Cockpit → снова редирект
• цикл

Это 100% причина твоей проблемы.

🔥 Что показывает твой cockpit.service

Вот ключевая строка:

Код

ExecStart=/usr/lib/cockpit/cockpit-tls

Это означает:

❌ Cockpit работает в режиме TLS

❌ Cockpit сам генерирует сертификат

❌ Cockpit слушает HTTPS через socket activation

❌ Cockpit будет перенаправлять HTTP → HTTPS всегда

Это несовместимо с reverse proxy.

✔ Как должно быть в правильной конфигурации

Cockpit должен запускаться так:

Код

ExecStart=/usr/lib/cockpit/cockpit-ws --no-tls

То есть:

• Cockpit работает только HTTP
• TLS полностью обрабатывает Apache
• Cockpit получает заголовки X-Forwarded-*
• Нет редиректов

🧱 Почему у тебя включён cockpit-tls

Потому что в твоём cockpit.service есть строки:

Код

Requires=cockpit-wsinstance-http.socket cockpit-wsinstance-https-factory.socket
ExecStartPre=+/usr/lib/cockpit/cockpit-certificate-ensure --for-cockpit-tls
ExecStart=/usr/lib/cockpit/cockpit-tls

Это означает:

• Cockpit автоматически включает HTTPS‑фабрику
• Cockpit генерирует сертификаты
• Cockpit запускает TLS‑обёртку поверх cockpit-ws

Это стандартная конфигурация Debian/Ubuntu, но она не подходит для reverse proxy.

🛠 Как исправить (пошагово)

1) Создать override для cockpit.service

Код

systemctl edit cockpit.service

Вставить:

Код

[Service]
ExecStart=
ExecStart=/usr/lib/cockpit/cockpit-ws --no-tls

Сохранить.

2) Отключить HTTPS‑фабрику

Код

systemctl disable --now cockpit-wsinstance-https-factory.socket

3) Перезапустить Cockpit

Код

systemctl daemon-reload
systemctl restart cockpit

4) Проверить

Код

ss -tlnp | grep cockpit

Должно быть:

Код

LISTEN ... 9090 cockpit-ws

И не должно быть:

Код

LISTEN ... 9091 cockpit-tls
LISTEN ... 9090 cockpit-tls

🧩 После этого твой Apache‑конфиг будет работать идеально

Но обязательно добавь WebSocket‑проксирование:

Код

ProxyPass "/socket" "ws://192.168.0.162:9090/socket"
ProxyPassReverse "/socket" "ws://192.168.0.162:9090/socket"

И заголовки:

Код

RequestHeader set X-Forwarded-Proto "https"
RequestHeader set X-Forwarded-SSL "on"

Полная очистка Cockpit в Debian 13 (идеальный порядок)

Коротко: это нормально, что cockpit-session и cockpit-tls не находятся — в Debian 13 эти компоненты не существуют как отдельные пакеты. Но если твоя цель — полностью очистить систему от Cockpit, включая ВСЕ юниты, каталоги, сертификаты, сокеты, PAM‑конфиги и остаточные файлы, то я дам тебе полный, гарантированно рабочий чек‑лист, который удаляет Cockpit целиком, без единого следа.

🎯 Полная очистка Cockpit в Debian 13 (идеальный порядок)

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

🧹 1. Удаление всех пакетов Cockpit

Debian 13 содержит только эти реальные пакеты:

Код

apt purge cockpit cockpit-ws cockpit-system cockpit-networkmanager cockpit-packagekit cockpit-storaged cockpit-bridge cockpit-doc

Пакетов:

• cockpit-session
• cockpit-tls
• cockpit-pcp

в Debian нет, поэтому ошибки — нормальны.

🧹 2. Авто‑удаление зависимостей

Код

apt autoremove --purge

🧹 3. Удаление всех каталогов Cockpit

Код

rm -rf /etc/cockpit
rm -rf /usr/lib/cockpit
rm -rf /usr/share/cockpit
rm -rf /run/cockpit
rm -rf /var/lib/cockpit
rm -rf /var/log/cockpit

🧹 4. Удаление всех systemd‑юнитов Cockpit

Debian ставит юниты в /usr/lib/systemd/system/:

Код

rm -f /usr/lib/systemd/system/cockpit.service
rm -f /usr/lib/systemd/system/cockpit.socket
rm -f /usr/lib/systemd/system/cockpit-wsinstance-http.socket
rm -f /usr/lib/systemd/system/cockpit-wsinstance-https-factory.socket
rm -f /usr/lib/systemd/system/cockpit-issue.service
rm -f /usr/lib/systemd/system/cockpit-certificate-ensure.service

🧹 5. Удаление кастомных юнитов и override

Код

rm -rf /etc/systemd/system/cockpit.service.d
rm -f /etc/systemd/system/cockpit.service
rm -f /etc/systemd/system/cockpit.socket
rm -f /etc/systemd/system/cockpit-wsinstance-http.socket
rm -f /etc/systemd/system/cockpit-wsinstance-https-factory.socket

🧹 6. Удаление PAM‑конфига Cockpit

Код

rm -f /etc/pam.d/cockpit

🧹 7. Удаление сертификатов Cockpit

Код

rm -rf /etc/cockpit/ws-certs.d

🧹 8. Перезагрузка systemd

Код

systemctl daemon-reload
systemctl reset-failed

🧹 9. Проверка, что Cockpit полностью исчез

Код

systemctl list-unit-files | grep cockpit
systemctl status cockpit
systemctl status cockpit.socket
dpkg -l | grep cockpit

Все команды должны показывать пусто.

✔ Итог

После выполнения всех шагов:

• Cockpit полностью удалён
• ни одного юнита
• ни одного сокета
• ни одного каталога
• ни одного сертификата
• ни одного PAM‑конфига
• ни одного процесса
• ни одной зависимости

Система полностью чистая.