@rzr said:
Hi @andrew, thank you for your feedback, the fallback option you're suggesting will work but it will downgrade the security of your system, we suggested to update clients:
If users need to take action, I would rather recommend users to do something that raises the security floor, like generating new keys with newer, future-looking ciphers, like ed25519:
ssh-keygen -t ed25519 -C "<email>"
for server in $servers do ; ssh-copy-id $server; done
All vms still on host 1 after setting Migration cooldown time to 0 this morning.
Maybe bug or just ui bug. When set to 0 save config when you load the page the "Fill information" for Migration Cooldown setting is unchecked but 0 is still applied. If set to 1. and reload the box is check as expected.
And to really round this out, the MTBF for any of these is in the millions of hours (1.2-3M), that's a use time of 136.968 - 342.46 years respectively.
Basically, if a drive dies, just replace it no matter what, but in the end the reliability of these drives is meant to outlast all of us.
Unless you actually need some specific function provided in some form-factor or model, don't bother.
