Why does Proxmox need to be forward-compatible to future container versions?

[sdettmer]

I installed a Debian image using "Turnkey Linux" images that are available by Proxmox by default, but after a reboot the container does not come up anymore.

First let me propose to show such errors strongly visble in the web GUI, such as making the container icon in read instead of grey. The Datacenter "Summary" page shows "LXC Container" "Stopped 2", but actually it should be one stopped, one FAILED, preferably in red color. Also "Status" shows a big green "Heavy Check Mark" icon, althougn a container is missing (which could be the most important container like a DHCP or DNS server rendering the whole cluster being out of order).

The GUI shows an errror in the log view, and when I click it I just see:

()
run_buffer: 322 Script exited with status 25
lxc_init: 844 Failed to run lxc.hook.pre-start for container "102"
__lxc_start: 2027 Failed to initialize container "102"
TASK ERROR: startup for container '102' failed

so unfortunately without the error message.

I found no log files with details, and (unfortunately as ususal), systemd journalcrl also just shows "An ExecStart= process belonging to unit pve-container@102.service has exited. The process' exit code is 'exited' and its exit status is 1." but does not bother to include an error message, STDERR or anything.

Fortunately, the error was persistent, so I could run lxc-start -n 102 -F -l DEBUG -o /tmp/102.log and then I saw in the log file

lxc-start 102 20230804163854.586 DEBUG    conf - ../src/lxc/conf.c:run_buffer:311 - Script exec /usr/share/lxc/hooks/lxc-pve-prestart-hook 102 lxc pre-start produced output: unsupported debian version '12.1'

or in short unsupported debian version '12.1' and with some digging /usr/share/perl5/PVE/LXC/Setup/Debian.pm with a hard-coded version map.

Why does Proxmox need to be forward-compatible to future Debian versions?

If I create my own Debian version with my own version number, why would I need to adjust Promox as well? I don't like dependencies, sooner or later they break necks.

BTW, interesting, that Proxmox does not auto-update by default, I thought this would be required to maintain security.

 

[dietmar]

Why does Proxmox need to be forward-compatible to future Debian versions?

We modify some container sytem files on startup, so we need to know the exact OS version.

BTW, interesting, that Proxmox does not auto-update by default, I thought this would be required to maintain security.

System updates are required to maintain security. If you do them manually or atomatic is up to you.

 

[LnxBil]

BTW, interesting, that Proxmox does not auto-update by default, I thought this would be required to maintain security.

I've never seen this on critical parts of infrastructure in any company I worked for or with. PVE as a hypervisor is often part of the critical part of infrastructure. It is however common to do this in containers, VMs or even end user machines (desktops, workstation, laptops, etc.). For critical parts of your infrastructure There are always scheduled updates with a lot of people involved and unfortunately sometimes problems that lead to service downtime. Just the past 12 months, I saw 3 different brand core switches totally break down after a firmware update.

 

[sdettmer]

I've never seen this on critical parts of infrastructure in any company I worked for or with. PVE as a hypervisor is often part of the critical part of infrastructure. It is however common to do this in containers, VMs or even end user machines (desktops, workstation, laptops, etc.). For critical parts of your infrastructure There are always scheduled updates with a lot of people involved and unfortunately sometimes problems that lead to service downtime. Just the past 12 months, I saw 3 different brand core switches totally break down after a firmware update.

yes, but being totally broken is acceptable according to most "cybercybersecurity" rules

(interestingly, German BSI "IT Grundschutz" OPS.1.1.3.A3 Konfiguration von Autoupdate-Mechanismen (you surely already guessed it means "configuration of autoupdate mechanisms") says it must be defined leaving to possiblity to define not to do them at all this was different in a prior version I'm quite sure, probably they acknowledge issues regarding bad patches, however on linux and BSD systems personally luckily I have good experiences)

 

[sdettmer]

We modify some container sytem files on startup, so we need to know the exact OS version.

System updates are required to maintain security. If you do them manually or atomatic is up to you.

Thank you very much for the explanation!
I'm not sure if I like this in every imaginary case but I think I understand and it is fine for me at the moment.

 

[alexskysilk]

I've never seen this on critical parts of infrastructure in any company I worked for or with.

Just to add to this- since Microsoft insists on doing this, even on Server products, one of the core functions msp's provide is to NOT ALLOW WINDOWS UPDATES and instead control update rollouts with pre-tested policies using RMM. @LnxBil's point cannot be overstated.

 

[sdettmer]

Just to add to this- since Microsoft insists on doing this, even on Server products, one of the core functions msp's provide is to NOT ALLOW WINDOWS UPDATES and instead control update rollouts with pre-tested policies using RMM. @LnxBil's point cannot be overstated.

(OT)
well, on the other hand we see the big success Microsoft has in securing their products... Sometimes a global cloud master key gets lost, Exchange causes trouble every month, 100% EMOTET-compatible since years and even with several layers of snakeoil its far away from being safe. In case of an infection, you cannot simply restore a backup. If a patch becomes available, black hats can analyse and find an exploit, and experts say, they may need just 24 hours to do so (because they can look what the patch changes and conclude the issue). So maybe not allowing windows updates could be the bigger threat.

 

[alexskysilk]

So maybe not allowing windows updates could be the bigger threat.

No one is suggesting that; the issue is that without third party tools, controlling WHEN and WHAT is virtually impossible with what Microsoft provides. Having a server reboot in the middle of production can be costly, and preventable.

 

[sdettmer]

No one is suggesting that; the issue is that without third party tools, controlling WHEN and WHAT is virtually impossible with what Microsoft provides. Having a server reboot in the middle of production can be costly, and preventable.

yeah really, I think they need these reboots because they cannot safely overwrite open files, who knows.

 

[speedAmaster]

@sdettmer

I am having the same issue on "unsupported debian version '12.1'". How do I fix that? In "/usr/share/perl5/PVE/LXC/Setup/Debian.pm"?

 

[speedAmaster]

@sdettmer

I am having the same issue on "unsupported debian version '12.1'". How do I fix that? In "/usr/share/perl5/PVE/LXC/Setup/Debian.pm"?

I edited to if !($version >= 4 && $version <= 12.1);

 

[Neobin]

@sdettmer

I am having the same issue on "unsupported debian version '12.1'". How do I fix that? In "/usr/share/perl5/PVE/LXC/Setup/Debian.pm"?

I edited to if !($version >= 4 && $version <= 12.1);

Since:
pve-container 5.0.2 on PVE 8/Bookworm: [1]
as well as:
pve-container 4.4-5 on PVE 7/Bullseye: [2]
it is:

die "unsupported debian version '$version'\n" if !($version >= 4 && $version <= 13);

So, simply keep your PVE (with an appropriate repository: [3] configured) up-to-date...

[1] https://git.proxmox.com/?p=pve-cont...=f3f80e36518684a03ae873a350a70c6f864885c8#l40
[2] https://git.proxmox.com/?p=pve-cont...=277829f801e62cd9ab752d054a8d6abd78787499#l40
[3] https://pve.proxmox.com/wiki/Package_Repositories

 

[LnxBil]

Since:
pve-container 5.0.2 on PVE 8/Bookworm: [1]
as well as:
pve-container 4.4-5 on PVE 7/Bullseye: [2]
it is:

die "unsupported debian version '$version'\n" if !($version >= 4 && $version <= 13);

So, simply keep your PVE (with an appropriate repository: [3] configured) up-to-date...

I wondered about that too. Nice of you to have actually checked that. Thanks.