5 ms·

> maintenance is actually quite low. I do hope you regularly patch and reboot your systems.

biztos 6y ago
I hope so too, but it's not like a fleet of fine-tuned EC2 instances running CentOS 6.5 is going to be patched and rebooted regularly without a similar amount of sysadmin attention. (Not picking on CentOS, just using it as a placeholder for $REQUIRED_OS_BECAUSE_OF_CUSTOM_SOFTWARE.)
- mr_toad 6y ago
  Automatic unattended updates are totally possible (I haven’t tried it in CentOS but it works fine on Ubuntu). Even kernel updates can now be done without a reboot. And with the proper setup even reboots can be automated.
  - mrweasel 6y ago
    But that's not limited to cloud, you can do that for on-premise stuff.
    - twic 6y ago
      There's a cognitive failure i see a lot where people incorrectly conflate two different new hotnesses like this. Cloud? Automatically updating operating systems. On-prem? Must be stuck on an old version. Microservices? You can release to production in minutes. Monolith? Must take you weeks to get a release out. Go? Simple self-contained deployables. Java? Must need a JDK and Tomcat installed on the server. It always seem to come up when the leading term is something dubious (cloud, microservices, Go), but the following term is something unequivocally good. Or maybe that's just when i notice it.
  - Conan_Kudo 6y ago
    This is totally possible on CentOS. Up to CentOS 7, yum-cron lets you do this. With CentOS 8, this has been replaced with dnf-automatic, which offers a lot more flexibility on how to configure automatic updates.
  - m01 6y ago
    How do you do kernel updates without a reboot? I've looked several times and found different technologies over time (kexec, (Oracle's) ksplice, kGraft, kpatch, livepatch). They do appear to have some use-cases, e.g. delaying the need for a reboot by being able to install a critical vulnerability fix/workaround so that the reboot can be done at a more convenient time. Because many of the patch mechanisms are function-based, they don't appear to solve the general problem in such a way that reboots can be avoided all together for arbitrary large kernel changes. From my reading of the solutions none are at the level of unattended upgrades using apt/yum-cron or similar in a way that "most" can benefit from them without worrying too much about it (ksplice might do it, but not sure how much you need to pay for it for server use and therefore how accessible it is). kexec helps with skipping the bootloader/BIOS, but I'm not sure if it ends up restaring all the systemd services or going up/down the runlevels, some places suggest it reduces downtime but doesn't eliminate it. I've not experimented with any of these myself yet... so I'd be happy to be proven wrong and in any case learn more! References: - http://jensd.be/651/linux/linux-live-kernel-patching-with-kpatch-on-centos-7 http://jensd.be/651/linux/linux-live-kernel-patching-with-kp... - https://linux-audit.com/livepatch-linux-kernel-updates-without-rebooting/ https://linux-audit.com/livepatch-linux-kernel-updates-witho... - https://wiki.archlinux.org/index.php/Kernel_live_patching https://wiki.archlinux.org/index.php/Kernel_live_patching - https://wiki.archlinux.org/index.php/Kexec https://wiki.archlinux.org/index.php/Kexec EDIT: forgot to mention livepatch
    - heavenlyblue 6y ago
      You don’t need to avoid reboot if you have enough machines
- close04 6y ago
  The main difference is in admin effort even with the same amount of automation. It doesn't scale linearly because of economy of scales. With reasonable automation a relatively small team can handle a pretty large cloud fleet. For smaller on-prem fleets the scale down might not be ideal though.

I hope so too, but it's not like a fleet of fine-tuned EC2 instances running CentOS 6.5 is going to be patched and rebooted regularly without a similar amount of sysadmin attention. (Not picking on CentOS, just using it as a placeholder for $REQUIRED_OS_BECAUSE_OF_CUSTOM_SOFTWARE.)

mr_toad 6y ago
Automatic unattended updates are totally possible (I haven’t tried it in CentOS but it works fine on Ubuntu). Even kernel updates can now be done without a reboot. And with the proper setup even reboots can be automated.
- mrweasel 6y ago
  But that's not limited to cloud, you can do that for on-premise stuff.
  - twic 6y ago
    There's a cognitive failure i see a lot where people incorrectly conflate two different new hotnesses like this. Cloud? Automatically updating operating systems. On-prem? Must be stuck on an old version. Microservices? You can release to production in minutes. Monolith? Must take you weeks to get a release out. Go? Simple self-contained deployables. Java? Must need a JDK and Tomcat installed on the server. It always seem to come up when the leading term is something dubious (cloud, microservices, Go), but the following term is something unequivocally good. Or maybe that's just when i notice it.
- Conan_Kudo 6y ago
  This is totally possible on CentOS. Up to CentOS 7, yum-cron lets you do this. With CentOS 8, this has been replaced with dnf-automatic, which offers a lot more flexibility on how to configure automatic updates.
- m01 6y ago
  How do you do kernel updates without a reboot? I've looked several times and found different technologies over time (kexec, (Oracle's) ksplice, kGraft, kpatch, livepatch). They do appear to have some use-cases, e.g. delaying the need for a reboot by being able to install a critical vulnerability fix/workaround so that the reboot can be done at a more convenient time. Because many of the patch mechanisms are function-based, they don't appear to solve the general problem in such a way that reboots can be avoided all together for arbitrary large kernel changes. From my reading of the solutions none are at the level of unattended upgrades using apt/yum-cron or similar in a way that "most" can benefit from them without worrying too much about it (ksplice might do it, but not sure how much you need to pay for it for server use and therefore how accessible it is). kexec helps with skipping the bootloader/BIOS, but I'm not sure if it ends up restaring all the systemd services or going up/down the runlevels, some places suggest it reduces downtime but doesn't eliminate it. I've not experimented with any of these myself yet... so I'd be happy to be proven wrong and in any case learn more! References: - http://jensd.be/651/linux/linux-live-kernel-patching-with-kpatch-on-centos-7 http://jensd.be/651/linux/linux-live-kernel-patching-with-kp... - https://linux-audit.com/livepatch-linux-kernel-updates-without-rebooting/ https://linux-audit.com/livepatch-linux-kernel-updates-witho... - https://wiki.archlinux.org/index.php/Kernel_live_patching https://wiki.archlinux.org/index.php/Kernel_live_patching - https://wiki.archlinux.org/index.php/Kexec https://wiki.archlinux.org/index.php/Kexec EDIT: forgot to mention livepatch
  - heavenlyblue 6y ago
    You don’t need to avoid reboot if you have enough machines
close04 6y ago
The main difference is in admin effort even with the same amount of automation. It doesn't scale linearly because of economy of scales. With reasonable automation a relatively small team can handle a pretty large cloud fleet. For smaller on-prem fleets the scale down might not be ideal though.