And these backups are on the PBS you gave in PDM or did I miss something? Even with an offsite PBS you would have the same issue: A single pane of glass ( including the offsite PBS ) with the associated riscs or you have backups but no PBS in the PDM
Proxmox (as a company) - what the HELL are you doing? Kernel update to 7 broke networking IN A VM
- Thread starter Kingneutron
- Start date
note that you can configure the token permissions to have only audit access for monitoring, without backup/restore permissions. (I'm not sure about default permissions when pdm is generating the pbs token)
Good point with the permissions, thanks for the hint. I'm not sure either how the defaults are either, When I tried this (with an older PDM and PBS version) the created permissions were very permissive. I might remember wrong though
I also remember that Thomas Lamprecht mentioned in the PDM release thread, that they will release some guidance on securing PDM/PVE/PBS deployments in the future but that part of the doc would still need some time:The PDM is certainly a "lucrative" target due to being a single point of entry to one's whole Proxmox infrastructure, that's actually a big reason for it's a pull based design, i.e., the PDM can be hosted on a secure private location because it will connect to the PVE and PBS hosts, not vice versa. Some how-tos for better practice make sense to have in the midterm, for now I'd recommend blocking all incoming traffic to the PDM that isn't really necessary, using client-side encrypted backups of the PDM host to avoid that access to backups gives access to anything else and potentially also think about using a secure VPN to access remotes through a insecure network (e.g., WireGuard). Making that all a bit more convenient to set up is one of the goals for the midterm though.
Great workOne thing which bothers me: I'm missing documentation on best practices for security and permissions I need to give the API tokens used for the PVE and PBS remotes. Let's say I'm running the datacenter manager and have full admin permissions to the PVE and PBS remotes, then an attacker could take over the PDM instance and also use this to get access to the PVE and PBS infrastructure. Now taking over PVE is not the big deal in my book (yes it might happen, but on the other hand the whole point of the PDM is to have an unified interface for administration so that's a risc...
But even with audit-only permissions you need to allow access to the Port 8007 of the PBS from the PDM. If you disable access to your offsite PBS completly by closing it's port 8007 with iptables/nftables (since pull-syncs on the remote PBS don't need itk), any bad actor can't do anything from the PDM acker even if they know of an exploit for PBS or managed to get the admin credentials from another source (e.g. social engineering, mitm-attack on an admin notebook etc)
Don't get me wrong: Of course you could still use PDM for your local PBS (which already needs to have an open port 8007 because otherwise backups won't work) and limit connections to a dedicated backup or management vpn so only your PVE nodes (for their backup), your PDM and your admin notebooks can acess it. One might also argue that your threat model can accept the riscs coming from host in the same network or location and thus you can live with the riscs of a PBS managed from PDM. But adding your offsite backup server to PDM is only asking for trouble in my book. YMMV
Last edited:
BTW I'm using no-subscription and haven't enabled any test repo, and today when doing "apt upgrade" it tried to auto-install proxmox-kernel-7.0 and proxmox-kernel-7.0.0-3-pve-signed.
That is now a dependency of proxmox-default-kernel, so it will be installed w/o asking and without the user (necessarily) having the intention of testing anything.
That is now a dependency of proxmox-default-kernel, so it will be installed w/o asking and without the user (necessarily) having the intention of testing anything.
Its also not a test kernel anymore.
jep, just installed it. got here via google. had to pin the old 6.17.13-4-pve kernel to get networking back - on the Host!, Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 05) if that helps....
you might blame realtek instead of proxmox. Realtek is known for coding the sh...tiest drivers in the world ! You'd better us "real" ... nics ;-)
Older installation? Asking because we're only defaulting to pinning network interface names to the mac address of the interface since the PVE 9.0 ISO installer and the new kernel might have cause a rename of the interface name as per systemd/udev default policy.
You could check the system log of the previous boot to confirm that, e.g.
journalctl -b-1 (or web UI -> Node -> System Log)If that was indeed the root cause, you can use our the pve-network-interface-pinning tool once to pin the network interface names to avoid this from happening again, see:
https://pve.proxmox.com/pve-docs/chapter-sysadmin.html#network_override_device_names
If not, see if there is an actual error in the system log from the previous boot.
I upgraded to kernel 7.0. I don't know the exact model of my Ethernet card, but lspci lists it as "Realtek RTL8111/8168/8211/8411 (r8169)". It worked, and it continues to work, as a charm.
Just to report my example of Realtek:
Driver
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 06)Driver
r8169, Interface name enp4s0. Updated the host to the current no-subscription repo packages (incuding proxmox-kernel-7.0.0-3-pve) just fine, no problems and no renaming of the interface (or the Intel e1000e interfaces at enp2s0 and enp3s0) occurred when upgraded kernel from 6.17.x to 7.0.0.
Last edited:
Yes initial installation was 8.x, upgraded via offical upgrade guide. I'll check the rest later (currently bussy) and report back
Just noting later versions of PVE 8 and PBS 3 both have a NIC name pinning tool. We did that before upgrading.
Edit:
https://pve.proxmox.com/pve-docs-8/pve-admin-guide.html#network_override_device_names
https://pbs.proxmox.com/wiki/Upgrade_from_3_to_4#Network_Interface_Name_Change
Edit:
https://pve.proxmox.com/pve-docs-8/pve-admin-guide.html#network_override_device_names
https://pbs.proxmox.com/wiki/Upgrade_from_3_to_4#Network_Interface_Name_Change
Last edited:
Without knowing this thread, I updated two instances of PBS to version 4.2 earlier today - and used the
Paying attention sometimes does indeed pay off.
proxmox-network-interface-pinning tool (and updated /etc/network/interfaces accordingly) to make sure kernel 7 won't change my interfaces names to something else.Paying attention sometimes does indeed pay off.
As it seems relevant here: We've been running our CI/CD for PVE9 with Kernel 7 since it was announced on the forum and have not had any issues.
Note that our testing is targeted at storage rather than networking functionality of the PVE.
Cheers
Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
Note that our testing is targeted at storage rather than networking functionality of the PVE.
Cheers
Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox