Виправлення помилок apt update на Proxmox: DNS, репозиторії та GPG-ключі (покроково)

January 26, 2026 • February 3, 2026 • Читання: 9 хв • Views: 7

Було корисно?

Коли apt update ламається на вузлі Proxmox, це рідко «тільки apt». Зазвичай це DNS. Або вибір репозиторію. Або проксі, що непомітно переписує TLS. Або ключ, що закінчився о 02:00 в неділю, ніби його встановив хтось, хто не любить спати.

Цей посібник написано для людей, які керують продукційними кластерами і не мають часу милуватися повідомленнями про помилки. Ви швидко діагностуєте, внесете чисті зміни й зробите вузол більш передбачуваним, ніж він був раніше.

Швидкий план діагностики

Якщо вам потрібен один набір перевірок, який швидко знайде вузьке місце — робіть їх у цьому порядку. Зупиняйтеся, щойно знайдете перший зламаний шар. Накладання виправлень без розуміння — це шлях до «працює на цьому вузлі, але не на тому» на наступний рік.

1) Доступність мережі (чи є взагалі шлях?)

Перевірте IP-адресу, маршрут за замовчуванням і стан інтерфейсу.
Пропінгуйте ваш gateway і відомий публічний IP.
Якщо ви не можете дістатися до IP-адрес, не чіпайте apt, репозиторії або ключі поки що.

2) Розв’язування DNS (чи знає вузол імена?)

Розв’язуйте імена репозиторіїв через getent і resolvectl.
Шукайте split DNS, stub-резолвери або резолвер, що вказує на 127.0.0.1 без слухача.

3) Коректність репозиторіїв (чи звертаєтесь ви до правильного сервера для вашої дистрибуції?)

Перевірте, чи кодова назва Debian відповідає вашому релізу Proxmox.
Переконайтеся, що ви випадково не використовуєте enterprise репозиторій без підписки.
Переконайтеся, що ви не скопіювали рядок з Ubuntu до Debian — таке трапляється.

4) TLS/сертифікати/поведінка проксі (чи дозволено вам завантажувати?)

Перевірте на наявність MITM корпоративного проксі, captive portal або помилок TLS.
Підтвердіть, що системний час адекватний (поганий час робить TLS «непрацюючим»).

5) GPG-підписи (чи може apt перевірити те, що завантажив?)

Шукайте NO_PUBKEY або «signed by unknown key».
Використовуйте per-repo keyrings, а не старий підхід «розбризкувати ключі в apt-key».

Парафраз ідеї Вернера Фогельса (CTO Amazon): «Як побудував — так і експлуатуєш». Тобто ви також відлагоджуєте це в незручний час.

Цікаві факти та контекст (для допитливих і постраждалих)

Верифікація підписів APT стала менш опціональною з часом. Ранні робочі процеси era Debian орієнтувались на apt-key; сучасні рекомендації переходять на per-repository keyrings для обмеження довіри.
Proxmox базується на Debian, а не «Debian-like». Плутанина з репозиторіями виникає, коли люди ставляться до нього як до загального аплайанса й дивуються, чому резолюція залежностей тане.
Proxmox розділяє репозиторії за моделлю підтримки. Enterprise-репозиторій захищений; репозиторій no-subscription відкритий, але не гарантує такої ж стабільності.
DNS-помилки — найпоширеніша «apt-проблема» в дата-центрах. Бо DNS — одна з тих речей, яку всі вважають «має працювати».
Системний час — прихована залежність менеджера пакетів. TLS, вікно дійсності ключа й деякі проксі залежать від коректного годинника.
IPv6 може бути й порятунком, й проблемою одночасно. Якщо вузол віддає перевагу IPv6, а ваша мережа його напівпідтримує, ви отримаєте повільні таймаути й випадкові збої.
HTTP 401/403 від репозиторіїв Proxmox зазвичай політика, а не тимчасовий збій. Часто це означає «не той репозиторій для вашого стану підписки».
Файли Release і імена suite мають значення. Одна неправильна кодова назва (наприклад, bullseye vs bookworm) може викликати «Release file changed», «does not have a Release file» або конфлікти залежностей.

Що насправді означає «apt update failed» на Proxmox

apt update — це конвеєр:

Розв’язування імен (DNS, /etc/hosts, systemd-resolved, локальні кешуючі резолвери).
Підключення до серверів (маршрутизація, фаєрвол, правила проксі).
Неготіація TLS (ланцюг сертифікатів, системний час, інтерцепція проксі).
Завантаження метаданих (файли Release/InRelease).
Перевірка підписів (GPG-ключі і конфігурація довіри).
Аналіз метаданих репозиторію і побудова індексу пакетів.

Ваше повідомлення про помилку каже, на якому етапі стався збій, але тільки якщо ви вмієте його читати. «Temporary failure resolving» означає DNS; «The following signatures couldn’t be verified» — значить ключі; «401 Unauthorized» — ви стукаєте у двері enterprise без бейджа.

Жарт №1: DNS — як кисень: ніхто не звертає уваги, поки він не зникне, а потім усі миттєво стають респіраторними спеціалістами.

Практичні завдання: команди, виводи та рішення (серцевина)

Нижче — практичні завдання, які можна виконати на вузлі Proxmox. Кожне завдання містить команду, реалістичний вивід, що це означає, і яке рішення прийняти далі. Виконуйте їх у порядку, якщо не знаєте, який шар дає збій.

Завдання 1: Переконайтеся у відповідності версій Proxmox і Debian

cr0x@server:~$ pveversion -v
proxmox-ve: 8.2.2 (running kernel: 6.8.12-2-pve)
pve-manager: 8.2.4 (running version: 8.2.4/2a1b3c0c)
pve-kernel-6.8: 6.8.12-2
pve-kernel-helper: 8.1.0
pve-kernel-libc-dev: 6.8.12-2
pve-qemu-kvm: 8.1.5
pve-container: 5.0.1
ceph-fuse: 16.2.15-pve1
corosync: 3.1.8-pve1
cr0x@server:~$ . /etc/os-release && echo "$PRETTY_NAME"
Debian GNU/Linux 12 (bookworm)

Що це означає: PVE 8 відповідає Debian 12 (bookworm). Це ваша базова припущення щодо suite репозиторіїв.

Рішення: Якщо ваша ОС — Debian 11, а ви намагаєтеся використовувати PVE 8 репозиторії (або навпаки), зупиніться і виправте невідповідність перед тим, як чіпати ключі.

Завдання 2: Зафіксуйте точну помилку apt без «виправлень»

cr0x@server:~$ apt-get update
Hit:1 http://deb.debian.org/debian bookworm InRelease
Err:2 https://enterprise.proxmox.com/debian/pve bookworm InRelease
  401  Unauthorized [IP: 51.91.38.34 443]
Reading package lists... Done
E: Failed to fetch https://enterprise.proxmox.com/debian/pve/dists/bookworm/InRelease  401  Unauthorized [IP: 51.91.38.34 443]
E: The repository 'https://enterprise.proxmox.com/debian/pve bookworm InRelease' is not signed.

Що це означає: Мережа й DNS окей. Ви дісталися до enterprise репозиторію, але не авторизовані. Рядок «not signed» — побічний ефект неможливості отримати підписаний Release-файл, а не однозначно проблема з ключем.

Рішення: Виправте вибір репозиторію (enterprise vs no-subscription) перш ніж ганятися за GPG-ключами.

Завдання 3: Перевірте базові інтерфейс і маршрутизацію

cr0x@server:~$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
vmbr0            UP             10.20.30.41/24 fe80::a00:27ff:fe4e:1122/64
cr0x@server:~$ ip route
default via 10.20.30.1 dev vmbr0
10.20.30.0/24 dev vmbr0 proto kernel scope link src 10.20.30.41

Що це означає: Інтерфейс піднятий, маршрут за замовчуванням є, і ви не в якійсь дивній ситуації «без шлюзу».

Рішення: Якщо маршрут за замовчуванням відсутній або вказує на неправильний інтерфейс (часто після перейменування bridge), виправляйте мережу перш ніж продовжувати. Apt не може перехитрити фізику.

Завдання 4: Доведіть, що до інтернету можна дістатися по IP (незалежно від DNS)

cr0x@server:~$ ping -c 2 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=1.78 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=1.72 ms

--- 1.1.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 1.721/1.750/1.780/0.029 ms

Що це означає: Маршрутизація до зовнішнього світу працює.

Рішення: Якщо це не працює, дивіться правила фаєрволу, upstream маршрутизацію або VLAN-тегі. Не чіпайте джерела apt, поки базова конективність не відновлена.

Завдання 5: Перевірте розв’язування DNS так, як його використовує apt

cr0x@server:~$ getent ahosts deb.debian.org | head
2a04:4e42:83::644 deb.debian.org
2a04:4e42:83::644 STREAM deb.debian.org
2a04:4e42:83::644 DGRAM  deb.debian.org
2a04:4e42:83::644 RAW    deb.debian.org
146.75.106.132 deb.debian.org
146.75.106.132 STREAM deb.debian.org

Що це означає: Служба імен працює. Ви отримуєте відповіді як по IPv6, так і по IPv4.

Рішення: Якщо getent не працює, але dig працює, у вас проблема з NSS/systemd-resolved. Виправляйте стек резолверів, а не список репозиторіїв.

Завдання 6: Перевірте конфігурацію резолвера (systemd-resolved vs /etc/resolv.conf)

cr0x@server:~$ readlink -f /etc/resolv.conf
/run/systemd/resolve/stub-resolv.conf
cr0x@server:~$ resolvectl status | sed -n '1,35p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.20.30.10
       DNS Servers: 10.20.30.10 10.20.30.11
Fallback DNS Servers: 1.1.1.1 8.8.8.8

Що це означає: Ви використовуєте systemd-resolved, який вказує на внутрішні DNS-сервери з fallback’ами.

Рішення: Якщо «Current DNS Server» пустий або вказує на недоступний адрес, виправте мережеві налаштування (часто в /etc/network/interfaces для Proxmox) або налаштування DHCP/static DNS.

Завдання 7: Виявіть затримки та збої, пов’язані з IPv6

cr0x@server:~$ apt-get -o Acquire::ForceIPv4=true update
Hit:1 http://deb.debian.org/debian bookworm InRelease
Hit:2 http://deb.debian.org/debian-security bookworm-security InRelease
Err:3 https://download.proxmox.com/debian/pve bookworm InRelease
  Temporary failure resolving 'download.proxmox.com'
Reading package lists... Done
W: Failed to fetch https://download.proxmox.com/debian/pve/dists/bookworm/InRelease  Temporary failure resolving 'download.proxmox.com'
W: Some index files failed to download. They have been ignored, or old ones used instead.

Що це означає: Примус IPv4 змінив поведінку. Якщо примус IPv4 робить усе працюючим (або швидше падає), ваш IPv6 шлях або резолвер може бути ненадійним.

Рішення: Якщо IPv6 ламає apt, або виправте IPv6 правильно (переважно), або тимчасово примусьте apt використовувати IPv4, поки координуєте виправлення мережі.

Завдання 8: Виявте налаштування проксі, що змінюють поведінку apt

cr0x@server:~$ grep -R "Acquire::http::Proxy\|Acquire::https::Proxy" -n /etc/apt/apt.conf /etc/apt/apt.conf.d 2>/dev/null
/etc/apt/apt.conf.d/99proxy:1:Acquire::http::Proxy "http://proxy.corp.local:3128";
/etc/apt/apt.conf.d/99proxy:2:Acquire::https::Proxy "http://proxy.corp.local:3128";

Що це означає: Apt явно використовує проксі для HTTP і HTTPS. Якщо цей проксі перехоплює TLS або вимагає автентифікації, ваші помилки виглядатимуть як TLS або проблеми з репозиторієм.

Рішення: Перевірте доступність проксі і чи підтримує він CONNECT для HTTPS. Якщо це Proxmox-хост, розгляньте можливість точкового застосування проксі — проксі, що переписує вміст, дає багато несподіванок.

Завдання 9: Перевірте системний час (TLS і дійсність ключів залежить від нього)

cr0x@server:~$ timedatectl
               Local time: Thu 2025-12-26 10:14:11 UTC
           Universal time: Thu 2025-12-26 10:14:11 UTC
                 RTC time: Thu 2025-12-26 10:14:10
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Що це означає: Годинник синхронізований. Гарно — TLS не впаде через датування 1970 чи 2038.

Рішення: Якщо синхронізація — no, виправте NTP спочатку. Неправильний час породжує «certificate is not yet valid» і «key expired» як відволікальні повідомлення.

Завдання 10: Перегляньте джерела apt для Proxmox і Debian

cr0x@server:~$ grep -R --line-number --no-messages 'deb ' /etc/apt/sources.list /etc/apt/sources.list.d/*.list
/etc/apt/sources.list:1:deb http://deb.debian.org/debian bookworm main contrib
/etc/apt/sources.list:2:deb http://deb.debian.org/debian bookworm-updates main contrib
/etc/apt/sources.list:3:deb http://security.debian.org/debian-security bookworm-security main contrib
/etc/apt/sources.list.d/pve-enterprise.list:1:deb https://enterprise.proxmox.com/debian/pve bookworm pve-enterprise

Що це означає: Вузол налаштований на використання enterprise репозиторію. Якщо у вас немає підписки, отримаєте 401 помилки. Якщо підписка є, але ви все одно отримуєте 401, перевірте встановлення ключа підписки й автентифікацію через проксі.

Рішення: Вирішіть, який Proxmox-репозиторій вам потрібен. Для лабораторій і багатьох невеликих організацій — no-subscription. Для регульованих середовищ — enterprise із реальною підтримкою.

Завдання 11: Переключення з enterprise репозиторію на no-subscription (за потреби)

cr0x@server:~$ sed -i 's/^deb /# deb /' /etc/apt/sources.list.d/pve-enterprise.list
cr0x@server:~$ cat >/etc/apt/sources.list.d/pve-no-subscription.list <<'EOF'
deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription
EOF
cr0x@server:~$ apt-get update
Hit:1 http://deb.debian.org/debian bookworm InRelease
Hit:2 http://security.debian.org/debian-security bookworm-security InRelease
Hit:3 http://deb.debian.org/debian bookworm-updates InRelease
Get:4 http://download.proxmox.com/debian/pve bookworm InRelease [2,768 B]
Get:5 http://download.proxmox.com/debian/pve bookworm/pve-no-subscription amd64 Packages [312 kB]
Fetched 315 kB in 1s (451 kB/s)
Reading package lists... Done

Що це означає: Тепер ви використовуєте правильний репозиторій для конфігурації без підписки, і apt може звантажити метадані.

Рішення: Якщо це працює, ви вирішили проблему авторизації репозиторію. Перейдіть до гігієни ключів і запобігання регресам.

Завдання 12: Діагностика «NO_PUBKEY» та помилок підписів акуратно

cr0x@server:~$ apt-get update
Get:1 http://download.proxmox.com/debian/pve bookworm InRelease [2,768 B]
Err:1 http://download.proxmox.com/debian/pve bookworm InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 7BF2812E8A6E88E0
Reading package lists... Done
W: GPG error: http://download.proxmox.com/debian/pve bookworm InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 7BF2812E8A6E88E0
E: The repository 'http://download.proxmox.com/debian/pve bookworm InRelease' is not signed.

Що це означає: Репозиторій досяжний, але apt відмовляється йому довіряти, бо ключ підпису відсутній у налаштованих keyring’ах.

Рішення: Встановіть підписний ключ Proxmox у виділеному keyring-файлі й посилайтеся на нього через signed-by. Не використовуйте apt-key add, якщо не любите глобальної довіри й минуле «я» ненавидітиме теперішнє «я».

Завдання 13: Встановіть ключ репозиторію Proxmox сучасним способом (виділений keyring)

cr0x@server:~$ install -d -m 0755 /etc/apt/keyrings
cr0x@server:~$ wget -qO /etc/apt/keyrings/proxmox-archive-keyring.gpg /usr/share/keyrings/proxmox-archive-keyring.gpg && echo "ok"
ok
cr0x@server:~$ chmod 0644 /etc/apt/keyrings/proxmox-archive-keyring.gpg
cr0x@server:~$ cat >/etc/apt/sources.list.d/pve-no-subscription.list <<'EOF'
deb [signed-by=/etc/apt/keyrings/proxmox-archive-keyring.gpg] http://download.proxmox.com/debian/pve bookworm pve-no-subscription
EOF
cr0x@server:~$ apt-get update
Hit:1 http://deb.debian.org/debian bookworm InRelease
Hit:2 http://security.debian.org/debian-security bookworm-security InRelease
Hit:3 http://deb.debian.org/debian bookworm-updates InRelease
Hit:4 http://download.proxmox.com/debian/pve bookworm InRelease
Reading package lists... Done

Що це означає: Apt тепер довіряє репозиторію Proxmox через явний ключ, обмежений для цього репозиторію.

Рішення: Тримайте ключі в окремих зонах довіри. Якщо ключ одного репозиторію буде скомпрометовано, бажано мати обмежену зону ураження, а не глобальний хаос.

Завдання 14: Відлагодження «Release file changed» і невідповідності suite

cr0x@server:~$ apt-get update
Err:1 http://deb.debian.org/debian stable InRelease
  404  Not Found [IP: 151.101.130.132 80]
Reading package lists... Done
E: The repository 'http://deb.debian.org/debian stable InRelease' does not have a Release file.

Що це означає: Ваші джерела неправильні. «stable» інколи працює, але на інфраструктурних вузлах краще використовувати явну кодову назву, щоб уникнути сюрпризів під час переходу Debian stable.

Рішення: Замініть stable на правильну кодову назву (наприклад, bookworm) у всіх відповідних рядках. Узгодженість важливіша за «кмітливість».

Завдання 15: Виявлення проблем перехоплення TLS та ланцюга сертифікатів

cr0x@server:~$ apt-get update
Err:1 https://download.proxmox.com/debian/pve bookworm InRelease
  Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown.  Could not handshake: Error in the certificate verification. [IP: 144.217.225.162 443]
Reading package lists... Done
W: Failed to fetch https://download.proxmox.com/debian/pve/dists/bookworm/InRelease  Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown.  Could not handshake: Error in the certificate verification.
W: Some index files failed to download. They have been ignored, or old ones used instead.

Що це означає: Або ваш CA-бандл пошкоджений/застарілий, або час системи неправильний, або корпоративний проксі перехоплює TLS й підставляє власний CA, якого вузол не довіряє.

Рішення: Не відключайте верифікацію сертифікатів. Виправте довіру до CA правильно (встановіть корпоративний root CA у системний стор для довіри, якщо вам потрібно використовувати інтерцепцію), або обійдіть проксі для доменів репозиторіїв.

Завдання 16: Перевірте пакет CA certificates і оновіть його

cr0x@server:~$ dpkg -l ca-certificates | awk 'NR==1 || $1 ~ /^ii/ {print}'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name            Version         Architecture Description
ii  ca-certificates 20230311        all          Common CA certificates
cr0x@server:~$ update-ca-certificates | tail -n 5
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.

Що це означає: Пакет CA присутній і сховище сертифікатів оновлено. Якщо TLS все ще падає, підозрюйте інтерцепцію або зламаний проксі-путь.

Рішення: Якщо ви в корпоративній мережі з перехопленням TLS, встановіть корпоративний CA (правильно) або налаштуйте apt йти напряму.

Завдання 17: Перевірте pinning і hold’и, які можуть створювати враження «поломки» оновлень

cr0x@server:~$ apt-mark showhold
pve-kernel-6.8.12-2-pve
cr0x@server:~$ apt-cache policy pve-kernel-6.8.12-2-pve | sed -n '1,25p'
pve-kernel-6.8.12-2-pve:
  Installed: 6.8.12-2
  Candidate: 6.8.12-2
  Version table:
 *** 6.8.12-2 500
        500 http://download.proxmox.com/debian/pve bookworm/pve-no-subscription amd64 Packages
        100 /var/lib/dpkg/status

Що це означає: Hold-и не ламають apt update, але можуть створити питання «чому не оновлюється?» після того, як оновлення відновлено.

Рішення: Знімайте hold-и тільки якщо розумієте, навіщо вони були встановлені. Hold-и ядра можуть бути навмисними (драйвери сховища, out-of-tree модулі або консервативні вікна змін).

Завдання 18: Переконайтеся, що apt може записувати свої списки (місце на диску та права)

cr0x@server:~$ df -h /var
Filesystem                         Size  Used Avail Use% Mounted on
/dev/mapper/pve-root                94G   92G     0 100% /
cr0x@server:~$ apt-get update
E: Write error - write (28: No space left on device)
E: Failed to fetch http://deb.debian.org/debian/dists/bookworm/InRelease  Write error - write (28: No space left on device)
E: Some index files failed to download. They have been ignored, or old ones used instead.

Що це означає: Ваш кореневий файловий розділ заповнений. Apt не може оновити свої списки, і навіть якщо зміг би — ви навряд чи зможете встановити будь-що.

Рішення: Звільніть місце (логи, старі ядра, перенесіть ISO за межі root). Тільки потім повторіть apt.

Завдання 19: Подивіться, що саме apt збирається завантажувати (debug acquisition)

cr0x@server:~$ apt-get -o Debug::Acquire::https=true update 2>&1 | sed -n '1,30p'
Acquire::https::download.proxmox.com:443: Server supports multiplexing
Acquire::https::download.proxmox.com:443: Negotiating SSL
Acquire::https::download.proxmox.com:443: Verify-Peer: 1
Acquire::https::download.proxmox.com:443: Cipher: TLS_AES_256_GCM_SHA384
Get:1 https://download.proxmox.com/debian/pve bookworm InRelease [2,768 B]
Fetched 2,768 B in 0s (14.2 kB/s)
Reading package lists... Done

Що це означає: Корисно, коли поведінка проксі/TLS дивна. Ви бачите хендшейк і рішення щодо верифікації.

Рішення: Якщо бачите повторні перепідключення, проблеми з SNI або зміну верифікації, ймовірно маєте справу з інтерцепуючим проксі або зламаним CA-ланцюгом.

Завдання 20: Перевірте, що рядки репозиторію Proxmox не дублюються й не конфліктують

cr0x@server:~$ awk 'NF && $1 != "#" {print FILENAME ":" NR ":" $0}' /etc/apt/sources.list /etc/apt/sources.list.d/*.list
/etc/apt/sources.list:1:deb http://deb.debian.org/debian bookworm main contrib
/etc/apt/sources.list:2:deb http://deb.debian.org/debian bookworm-updates main contrib
/etc/apt/sources.list:3:deb http://security.debian.org/debian-security bookworm-security main contrib
/etc/apt/sources.list.d/pve-no-subscription.list:1:deb [signed-by=/etc/apt/keyrings/proxmox-archive-keyring.gpg] http://download.proxmox.com/debian/pve bookworm pve-no-subscription

Що це означає: Один чіткий набір Debian, один чіткий Proxmox-набір. Немає дублів, немає застарілого enterprise репозиторію, що ще активний.

Рішення: Якщо бачите кілька рядків Proxmox для різних suite або одночасно enterprise і no-subscription — почистіть їх. Apt не «вибере правильний» — воно вибере хаос.

Жарт №2: Помилки APT — як корпоративні листи: технічно інформативні, емоційно не допомагають і завжди приходять, коли ви вже зайняті.

Чеклісти / покроковий план

Ось практична послідовність, яку я використовую в продукції. Вона зменшує ймовірність «виправляння не тієї речі» й залишає сліди для наступного оператора.

Чекліст A: Виправлення помилок apt, пов’язаних з DNS

Підтвердіть маршрутизацію (Завдання 3–4). Якщо IP-конективність зламана, зупиніться тут.
Підтвердіть розв’язування імен через NSS (Завдання 5). Якщо getent падає, не довіряйте dig як доказу, що apt працюватиме.
Перегляньте стан systemd-resolved (Завдання 6). Переконайтеся, що поточні DNS-сервери доступні.
Перевірте, чи DNS зламано лише для зовнішніх доменів (поширено при split DNS). Спробуйте внутрішні й зовнішні імена.
Вирішіть стратегію резолвера:
- Переважно: виправте upstream DNS і DHCP/static конфіг.
- Допустимо тимчасово: вкажіть явні резолвери в мережевій конфігурації, щоб Proxmox-вузли не залежали від робочих DHCP-скоупів.
Повторіть apt update і підтвердіть, що клас помилки змінився. Якщо нічого не змінилося — ви виправили не той шар.

Чекліст B: Виправлення проблем з репозиторіями та suite

Визначте версію Proxmox і кодову назву Debian (Завдання 1).
Виведіть всі рядки репозиторіїв (Завдання 10, Завдання 20). Шукайте:
- Неправильну кодову назву (bullseye на Debian 12).
- Використання stable замість явної кодової назви (Завдання 14).
- Enterprise репозиторій увімкнено без підписки (Завдання 2).
- Змішані протоколи та дублікати.
Прийміть одне рішення по репозиторіям:
- Enterprise репозиторій, якщо у вас є підписка й ви цінуєте підтримку.
- No-subscription репозиторій, якщо підписки немає. Будьте чесні з собою і налаштуйте відповідно.
Вимкніть репозиторій, який не використовуєте (закоментуйте, не видаляйте; це важливо для аудиту).
Запустіть apt update знову і переконайтеся, що fetch-и показують Hit/Get, а не Err.

Чекліст C: Виправлення ключів і перевірки підписів правильно

Підтвердіть, що збій дійсно пов’язаний з підписами (Завдання 12). Якщо ви отримуєте HTTP 401/404 — ключі не причина.
Створіть /etc/apt/keyrings (Завдання 13). Це сучасна конвенція.
Використовуйте per-repo keyring і signed-by (Завдання 13). Обмежуйте довіру.
Запустіть apt update. Якщо все ще падає — перевірте час (Завдання 9) і інтерцепцію TLS (Завдання 15–16).

Чекліст D: Виправлення проксі і TLS без відключення безпеки

Знайдіть конфігурацію проксі (Завдання 8). Налаштування проксі для apt може бути в кількох файлах.
Підтвердіть, що проксі підтримує HTTPS CONNECT. Якщо ні — HTTPS-репозиторії падатимуть із хендшейк-помилками.
Виправте довіру до CA правильно:
- Якщо організація перехоплює TLS, встановіть корпоративний root CA у OS trust store.
- Якщо організація може дозволити прямий доступ до доменів репозиторіїв — обійдіть проксі для них.
Перевірте за допомогою debug-виводу apt (Завдання 19). Зробіть це нудним.

Поширені помилки: симптом → причина → виправлення

Це трапляється регулярно в Proxmox-середовищах, бо люди копіюють конфіги репозиторіїв між вузлами і UI Proxmox робить легко натиснути неправильну кнопку.

1) «Temporary failure resolving ‘download.proxmox.com’»

Симптом: Apt падає з помилками розв’язування; ping по IP працює.
Причина: DNS неправильно налаштовано; systemd-resolved stub не має слухача; фаєрвол блокує UDP/TCP 53; split DNS ламає зовнішнє розв’язування.
Виправлення: Перевірте через getent і resolvectl status; виправте DNS-сервери в мережевому конфігу; забезпечте доступність резолверів; повторно протестуйте.

2) «401 Unauthorized» від enterprise.proxmox.com

Симптом: Звернення до enterprise репозиторію завершується 401, інколи з подальшим «not signed».
Причина: Enterprise репозиторій увімкнено без підписки; або проксі видаляє авторизацію; або ключ підписки не встановлено там, де очікується.
Виправлення: Вимкніть enterprise, якщо підписки немає, і увімкніть no-subscription; якщо підписка є — перевірте статус підписки в Proxmox і поведінку проксі.

3) «NO_PUBKEY … The repository is not signed»

Симптом: Apt може дістатися репозиторію, але відмовляється довіряти метаданим.
Причина: Відсутній ключ архіву, неправильний keyring або застаріла конфігурація довіри.
Виправлення: Використовуйте per-repo keyring у /etc/apt/keyrings і signed-by; не покладайтеся на застарілий глобальний підхід.

4) «Certificate verification failed: issuer unknown»

Симптом: TLS хендшейк падає; apt повідомляє про невідомого видавця або недовірений сертифікат.
Причина: Корпоративна інтерцепція TLS без встановленого root CA; зламаний CA-бандл; неправильний час; проксі підміняє сертифікат.
Виправлення: Виправте синхронізацію часу; оновіть CA-бандл; встановіть корпоративний CA при потребі; уникайте відключення верифікації.

5) «does not have a Release file»

Симптом: 404 або «Release file missing», часто після зміни міток suite Debian.
Причина: Неправильна suite/codename, неправильний дистрибутив, опечатка в рядку репозиторію або використання репозиторію, що не підходить для вашого релізу Debian.
Виправлення: Підтвердіть кодову назву Debian; виправте рядок репозиторію; уникайте stable на інфраструктурних вузлах, якщо хочете передбачувану поведінку під час переходів Debian.

6) apt update працює, але оновлення згодом ламають залежності

Симптом: apt update успішний; apt full-upgrade хоче видалити Proxmox-пакети або відкласти критичні пакети.
Причина: Змішані репозиторії з різних suite; дублікати; випадкові testing/unstable рядки; застаріла комбінація enterprise/no-subscription.
Виправлення: Очистіть джерела до однієї кодової назви Debian і одного каналу Proxmox; видаліть випадкові рядки; використовуйте apt-cache policy для перевірки походження пакетів.

7) «Write error (28: No space left on device)»

Симптом: Apt не може записувати файли списків; оновлення падає.
Причина: Кореневий розділ заповнений (логи, дампи, завантажені ISO, старі ядра).
Виправлення: Звільніть місце, потім повторіть update; розгляньте перенесення великих даних з кореня і налаштуйте політику зберігання логів.

Три корпоративні історії з практики

Міні-історія 1: Інцидент через неправильне припущення

У них був акуратний Proxmox-кластер у colo: три вузли, невеликий Ceph-пул і вікно змін, що завжди починалося пізно через зустрічі. Під час рутинного патчу один вузол відмовився оновлюватися. Помилка виглядала як проблема з ключем, тож оператор пішов шукати GPG-виправлення.

Неправильне припущення: «Якщо apt каже ‘not signed’, це завжди проблема ключа». Ні. У вузлі був увімкнений enterprise рядок у .list, бо хтось скопіював той самий файл з підписаного середовища місяці тому. У поточному середовищі підписки не було. Apt отримав 401, а потім поскаржився, що не може перевірити файл, якого взагалі не отримав.

Команда спробувала три імпорти ключів, додала виняток для проксі і ледь не відключила верифікацію. На щастя, останній крок заблокував суворий інженер з безпеки, який цього разу мав рацію. Коли вони нарешті прочитали перший рядок помилки уважно — 401 Unauthorized — вони вимкнули enterprise репозиторій і увімкнули no-subscription. Проблема вирішилась за кілька хвилин.

Справжня вартість була у часі і в довірі. Вузол довше залишався без оновлень безпеки. Крім того, коли ви «виправляєте» випадково, важко пояснити пізніше, яка зміна допомогла. Після інциденту вони додали просту перевірку перед патчем: grep на enterprise-рядки і відмова джоба, якщо вони знайдені на непідписаних кластерах.

Міні-історія 2: Оптимізація, що обернулась проти

Інша компанія тримала вузли Proxmox у мережі зі строгими правилами egress. Щоб прискорити оновлення, хтось додав HTTP(S) кешуючий проксі і примусив весь Debian/Proxmox-трафік йти через нього. На папері: швидше завантаження, менше зовнішніх з’єднань, легший аудит. Ідея, яка чудово виглядає в слайдах.

Але реальність наздогнала. Проксі мав увімкнену інтерцепцію TLS для «сканування безпеки». Linux-команда не встановила корпоративний root CA на Proxmox-вузлах, бо «це тільки оновлення пакетів, буде нормально». Ні, не було. Apt почав падати з помилками issuer unknown — переривчасто — залежно від того, який проксі в пулі відповідав.

Вони «оптимізували» ще більше, дозволивши fallback на HTTP для деяких репозиторіїв. Помилки зникли, поки хтось не помітив, що метадані й пакети йдуть мережею без TLS. Серйозний перегляд інциденту з безпеки й швидкий неприємний відкат відбувся.

Виправлення було нудним: встановити корпоративний root CA правильно, обходити інтерцепцію для доменів репозиторіїв, де політика дозволяє, і тримати все по HTTPS. Вони і далі використовували проксі для кешування, але припинили дозволяти йому видавати себе за інтернет. Продуктивність залишилась, але оновлення стали передбачуваними.

Міні-історія 3: Сумна, але правильна практика, що врятувала день

Ще одна команда мала звичку, яка здавалася надміру обережною: кожен Proxmox-вузол мав однаковий layout репозиторіїв, однаковий шлях keyring і однаковий preflight-скрипт перед патчем. Ніякої героїчної відладки в вікні змін — бо більшість проблем виловлювалась раніше.

Однієї ночі вузол почав падати з «Temporary failure resolving». Але їхній preflight не просто робив apt update; він також запускав getent перевірки для доменів репозиторіїв, фіксував стан резолверів і підтверджував синхронізацію часу. Вивід автоматично додавався до тикета.

Коли on-call відкрив тикет, вони не гадали. Вони побачили, що вузол після мережевого обслуговування змінив DNS-сервери і вказував на резолвер, що обслуговував внутрішні зони, але блокував зовнішню рекурсію. Apt не ламався; політика DNS — так.

Виправили, відновивши правильні резолвери в конфігурації вузла, і оновили мережевий playbook, щоб майбутні зміни не залишали інфраструктуру на «internal-only» DNS. Нудна практика не лише пришвидшила вирішення — вона зробила інцидент менш стресовим. Менше стресу — менше поганих рішень. Менше поганих рішень — менше повторних інцидентів. Ось у чому суть.

Питання та відповіді

1) Чи слід використовувати enterprise репозиторій чи no-subscription?

Якщо у вас є підписка і ви цінуєте підтримку та курований потік оновлень — використовуйте enterprise. Якщо підписки немає — вимкніть enterprise і використовуйте no-subscription. Запуск enterprise без прав просто марнує ваш час на 401 помилки.

2) Чому apt каже «repository is not signed» після HTTP-помилки?

Бо apt очікує підписані метадані (InRelease/Release.gpg). Якщо його не вдається отримати — через 401/404/мережу — він може повідомити про проблему з підписом як наступний симптом. Читайте перший рядок «Err:»; зазвичай він і є реальною причиною.

3) Чи годиться встановити `Acquire::https::Verify-Peer "false";`?

Ні. Це спосіб навчити вашу інфраструктуру приймати підроблені пакети. Виправте довіру до CA або поведінку проксі. Якщо потрібно зробити тимчасову міру в аварійній ситуації — задокументуйте її, обмежте область дії і видаліть відразу після завершення.

4) Я виправив DNS, але apt інколи все ще падає. Чому переривчасто?

Поширені причини: кілька DNS-серверів з непоєднаними правилами рекурсії, зламаний IPv6-шлях, ненадійний балансувальник проксі або проблеми MTU, що призводять до зупинок TLS-хендшейку. Переривчастість означає «існує два шляхи і один з них поганий».

5) Який найбезпечніший спосіб керувати apt-ключами на Proxmox?

Використовуйте per-repository keyring-файли під /etc/apt/keyrings і посилайтеся на них через signed-by= у рядку репозиторію. Уникайте глобальних хранилищ довіри, якщо не хочете, щоб один скомпрометований ключ благословив усе.

6) Чи можна змішувати Debian-репозиторії з різних релізів на Proxmox?

Можна, але не слід. Змішування suite веде до конфліктів залежностей і непередбачуваних оновлень. Тримайте одну кодову назву Debian і один канал Proxmox. Нудьга перемагає.

7) Чому примус IPv4 інколи «виправляє» apt update?

Якщо вузол віддає перевагу IPv6, а ваша мережа неправильно маршрутизує IPv6 або фільтрує його, з’єднання можуть зависати або падати. Примус IPv4 — діагностичний інструмент; реальне виправлення — налагодити IPv6 або послідовно вимкнути його.

8) apt update успішний, але GUI Proxmox все одно скаржиться на репозиторії. Чому?

GUI може попереджати про конфігурацію enterprise, стан підписки або невідповідність каналів. Перевірте фактичні файли в /etc/apt/sources.list.d, щоб упевнитися, що вони відповідають намірам, а потім оновіть інтерфейс.

9) Що робити, якщо вузол відрізаний від інтернету або без виходу вмережу?

Тоді apt update повинен вказувати на внутрішнє дзеркало, яким ви керуєте, з коректними підписними ключами і передбачуваною доступністю. Ставте це дзеркало як продакшн-інфраструктуру. Якщо воно ненадійне — ваші оновлення будуть ненадійні.

Наступні кроки (щоб не повертатися до проблеми)

Якщо apt update працює, не зупиняйтеся на «зеленому»

Стандартизуйте файли репозиторіїв на всіх вузлах. Одна кодова назва Debian, одне рішення щодо Proxmox, без дублів.
Обмежуйте довіру через signed-by keyrings. Це чистіше, безпечніше й легше для аудиту.
Зробіть DNS і синхронізацію часу обов’язковими залежностями. Моніторте доступність резолверів і статус NTP так само, як латентність сховища.
Документуйте поведінку проксі. Якщо є інтерцепція TLS — вбудуйте встановлення CA у процес provisioning. Не перетворюйте це на племінні знання.
Додайте preflight-скрипт. Запускайте його перед вікнами патчів: маршрутизація, DNS через getent, синхронізація часу, перевірка репозиторіїв, вільне місце на диску.

Якщо ви зробите це, наступного разу, коли хтось скаже «apt не працює», ви вже будете знати, який шар бреше.

Схожі статті

Proxmox “pve-apt-hook failed”: чому оновлення блокуються й як безпечно розблокувати Proxmox «could not resolve host»: швидкий робочий процес для виявлення причин (DNS/IPv6/проксі)