[SOLVED] Enterprise Repo Only Works for 1 Run

Jan 29, 2018
15
3
3
34
I have two clusters, one with 7 nodes and one with 12 nodes. Every host in both clusters has this problem and all 19 hosts have a community edition ProxMox license/subscription attached to them.

The first apt update will always fail like below. However, once I run `pvesubscription update` and then run `apt update`. Everything works as expected. However, this only fixes our issues for a few minutes before we start getting access denied to the enterprise repos.

root@vmhost17:~# pveversion
pve-manager/5.4-6/aa7856c5 (running kernel: 4.15.18-12-pve)
root@vmhost17:~# apt update
Hit:1 http://deb.debian.org/debian stretch-backports InRelease
Hit:2 http://apt.puppetlabs.com stretch InRelease
Hit:3 http://security.debian.org stretch/updates InRelease
Ign:4 http://ftp.us.debian.org/debian stretch InRelease
Hit:5 http://ftp.us.debian.org/debian stretch Release
Hit:6 http://packages.icinga.com/debian icinga-stretch InRelease
Ign:8 https://enterprise.proxmox.com/debian/pve stretch InRelease
Err:9 https://enterprise.proxmox.com/debian/pve stretch Release
401 Unauthorized
Reading package lists... Done
E: The repository 'https://enterprise.proxmox.com/debian/pve stretch Release' does no longer have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
root@vmhost17:~# pvesubscription update
root@vmhost17:~# apt update
Hit:1 http://security.debian.org stretch/updates InRelease
Hit:2 http://apt.puppetlabs.com stretch InRelease
Ign:3 http://ftp.us.debian.org/debian stretch InRelease
Hit:4 http://ftp.us.debian.org/debian stretch Release
Hit:5 http://deb.debian.org/debian stretch-backports InRelease
Hit:7 http://packages.icinga.com/debian icinga-stretch InRelease
Get:8 https://enterprise.proxmox.com/debian/pve stretch InRelease [2,081 B]
Get:9 https://enterprise.proxmox.com/debian/pve stretch/pve-enterprise amd64 Packages [312 kB]
Fetched 314 kB in 0s (356 kB/s)
Reading package lists... Done
Building dependency tree
Reading state information... Done
2 packages can be upgraded. Run 'apt list --upgradable' to see them.
 
Hi,
have you correctly set the key by `pvesubscription set <key>`?
 
Hi,
have you correctly set the key by `pvesubscription set <key>`?

I have set them all in the interface. If I run the following it works just fine. I don't want to leak the keys publically here.

root@vmhost17:~# pvesubscription get | grep status
status: Active

The whole cluster shows it to be good too.

upload_2019-6-4_10-58-49.png
 
Hi,
have you correctly set the key by `pvesubscription set <key>`?

Also, I am not sure but this does appear to have fixed my issue on two systems I tested this on.

pvesubscription get | grep key | cut -d : -f2 | xargs -I {} pvesubscription set {}

Essentially, just a one line command to take the key that is already present and set it to the same key. I just want to wait to hear back before I roll this out to more servers.
 
Also, I am not sure but this does appear to have fixed my issue on two systems I tested this on.

pvesubscription get | grep key | cut -d : -f2 | xargs -I {} pvesubscription set {}

Essentially, just a one line command to take the key that is already present and set it to the same key. I just want to wait to hear back before I roll this out to more servers.

Actually, it turns out that it was Puppet doing this via the https://github.com/puppetlabs/puppetlabs-apt module.

Puppet Apt Version 5.0 made a change via this commit to default to a blank auth.conf file https://github.com/puppetlabs/puppetlabs-apt/pull/752/files

Puppet Apt Version 6.3 added this parameter. https://github.com/puppetlabs/puppetlabs-apt/pull/831/files

Long story short, this fixed us.

Adding this to the top of our manifest we use for managing our ProxMox hosts.

class { 'apt':
manage_auth_conf => false,
}

And then running `pvesubscription get | grep key | cut -d : -f2 | xargs -I {} pvesubscription set {}` on the host.