Recent content by BobhWasatch

IOW, if the box is checked, you pass.

Windows is a largest virus platform. Therefore it is also the largest anti-virus platform. Even Linux anti-virus products mostly check for Windows viruses. Which makes sense if you're serving files to Windows users. On a Linux-based hypervisor it is just useless overhead. Yes, I am aware that...

Linux is an inferior antivirus platform. If you want to run your antivirus really well, the best bet is to install Windows.

Nov 14 17:31:59 pve kernel: Generic FE-GE Realtek PHY r8169-0-200:00: attached PHY driver (mii_bus:phy_addr=r8169-0-200:00, irq=MAC) Nov 14 17:31:59 pve kernel: r8169 0000:02:00.0 enp2s0: Link is Down Nov 14 17:31:59 pve kernel: vmbr0: port 1(enp2s0) entered blocking state Nov 14 17:31:59 pve...

Possibilities that come to mind: You installed NUT from somewhere besides the Debian repository and the driver needs to be rebuilt. You installed NUT from Debian repositories but something changed in the config file between v12 and v13 (you would have got a warning about that during the upgrade...

Nov 14 15:30:06 pve systemd[1]: nut-driver@apc.service: Control process exited, code=exited, status=1/FAILURE Nov 14 15:30:06 pve systemd[1]: nut-driver@apc.service: Failed with result 'exit-code'. Nov 14 15:30:06 pve systemd[1]: Failed to start nut-driver@apc.service - Network UPS Tools -...

Never used it, but it is in the Debian repository. Which means that if it does break anything it should be easy to remove.

Why do you care about source IP? I'm talking just blocking all inbound to port 8006 on the host IP and leaving 22 open. It will then work like you want without hacking around on PVE. It might break stuff, but so might your way. I've seen comments here before from Proxmox staff that it isn't...

You could just enable the firewall.

I guess I should have put <sarcasm> tags on that. No, I don't think it makes any sense. It is a lot of effort for basically no return. It is a silly idea in the vast majority of cases. I'm not saying no one should ever do this, but it is ridiculous to think it should be the default or on the GUI.

Yes, the Linux kernel scheduler is total garbage and you need to manually tell it what to do. For "performance". Of the hardware I guess, since this scheme will hinder the performance of the admins having to maitain it.

It looks reasonable, yes. Do updates work now? If so you could edit your first post and mark the thread solved.

I suppose you mean that you have to fstrim them once in a while to reclaim unused space? Yeah, forgot to mention that.

That's right. The difference is that the root volume is "thick provisioned", it takes up the full amount of space that is allocated and you can't allocate more than you have available. It is a fixed allocation. The volumes under pve/data are thin, meaning they only take up the space that's used...

I guess your volume group is "pve" and the thin pool is "data", so let's create a volume called "backups" and mount it. You'll want to verify that my assumptions and syntax are correct... lvcreate -V 100G --thinpool pve/data -n backups mkfs -t ext4 /dev/mapper/data-backups mount...