Repositories and subscriptions

Why this matters in production

Patches and security fixes flow through APT. The wrong repository configuration means you either miss updates or apply unstable ones. The subscription also unlocks the enterprise repository, which is generally more thoroughly tested than the no-subscription one.

Available repositories

Proxmox VE exposes four APT repositories in /etc/apt/sources.list.d/:

Subscription vs no-subscription

Both repositories ship stable code. The differences:

Configuring repositories

The default install configures both enterprise and no-subscription repositories. The no-subscription one is enabled by default; the enterprise one requires a subscription key.

ls /etc/apt/sources.list.d/ && cat /etc/apt/sources.list.d/*.list /etc/apt/sources.list.d/*.sources

mv /etc/apt/sources.list.d/pve-no-subscription.list /etc/apt/sources.list.d/pve-no-subscription.list.disabled

apt update

Subscription key

pvesubscription set <key>

pvesubscription status

The subscription file lives at /etc/pve/subscription/<node>.conf. The key is per-cluster, not per-node, but the file is local on each node.

Test repository

The test repository contains pve-manager builds from the current development branch and “experimental” packages. Enabling it on a production node is a way to volunteer for QA work without intending to.

ls /etc/apt/sources.list.d/pvetest* 2>/dev/null && echo WARNING: test repo enabled || echo OK: test repo not enabled

Production considerations

Common mistakes

• Leaving the test repository enabled “in case I need it.” Disable it after testing.
• Believing the subscription enables features. It does not.
• Disabling the enterprise repo without disabling the nag. The nag is cosmetic, but a clean configuration is better.

Key takeaways

• One PVE repository at a time is enough.
• Disable the test repo on production.
• A subscription is support, not features.

Knowledge check