6 ms·

I definitely agree with OP on this and do my best to minimize maintenance burden for most of my projects. This has worked out pretty well in that almost everyth

I definitely agree with OP on this and do my best to minimize maintenance burden for most of my projects. This has worked out pretty well in that almost everything I've published[0] can chug along in the background for months or years without me touching them at all (some of them earn a few hundred dollars per month[1]) >On the server I run Ubuntu LTS until it's near the end of its supported lifetime. Every two years I run do-release-upgrade and move to the next one. This cost is shared over many jefftk.com projects, so it isn't too bad. I was surprised by this part because running your own server seems like a big maintenance burden. I'd expect that you have to regularly upgrade your packages to protect yourself from security vulnerabilities. I've avoided this by using PaaS solutions like AppEngine or static hosting + cloud functions. The closest thing I have to a VPS is publishing Docker containers, but that's basically my last resort. [0] https://mtlynch.io/projects/ https://mtlynch.io/projects/ [1] https://mtlynch.io/retrospectives/2021/09/#legacy-projects https://mtlynch.io/retrospectives/2021/09/#legacy-projects

christophilus 5y ago
Application of security patches can be automated, and depending on your application’s dependencies, can be done without worry. I run about 10 bare metal transcoding servers, and it’s zero hassle.
- mtlynch 5y ago
  Can you share more about your setup? Is it cronjobs to just apt-get update && apt-get upgrade -y? How do you handle packages that require reboots?
  - christophilus 5y ago
    I haven’t had a reboot required in over a year, I think. The service is a Go program, and the only OS-managed dependency is ffmpeg. If a reboot interrupts the transcoding jobs, they just retry, so it’s really zero maintenance.
  - stevekemp 5y ago
    If you're running Debian/Ubuntu then you should look at the "unattended-upgrades" package.
    - mtlynch 5y ago
      Cool, thanks for the tip! I hadn't seen that package before.
  - giantrobot 5y ago
    In my experience precious few packages on the Ubuntu LTS releases (I'm sure it applies to other distros too) require reboots. It's basically only been kernel upgrades. There's few user space packages I imagine even benefiting from a reboot. Restarting a long running daemon is pretty painless. Also on a warm running system you've got an active page cache so all the unchanged files that service wants to open are likely cached in RAM rather than read from disk. While I appreciate the flexibility low effort VMs provide I think they've negatively affected the views of Linux users. Long uptime is fine and restarting a whole machine is rarely necessary. At the same time modern systems with crazy fast SSDs make a reboot take little longer than just restarting a service.
    - chousuke 5y ago
      There's honestly very little reason not to run VMs nowadays. It's like using LVM for disks on Linux; virtually zero overhead and you'll be happy you went with it when you do need the flexibility it provides. I'd pretty much run bare metal only if every server is used for a singular purpose that uses 100% of the available resources. Lots of hardware servers spend several minutes initializing themselves on boot. a RHEL 8 VM on a reasonably powerful host reboots in less than 5 seconds; a service restart causes approximately the same downtime that a reboot does.
  - ehou 5y ago
    Not OP. My servers get this: $ apt install unattended-upgrades # /etc/apt/apt.conf.d/99unattended-upgrades-custom Unattended-Upgrade::Sender "Root at servername.domain.tld <servername.domain.tld@servicesdomain.tld>"; Unattended-Upgrade::Mail "services@servicesdomain.tld"; Unattended-Upgrade::MailReport "on-change"; Unattended-Upgrade::Automatic-Reboot "true"; Unattended-Upgrade::Automatic-Reboot-Time "05:00"; $ sudo systemctl edit apt-daily.timer # Opens a new file /etc/systemd/system/apt-daily.timer.d/override.conf, paste this content: [Timer] # Reset the system calendar config first OnCalendar= # Set a new calendar timer with a 60 minute threshold OnCalendar=*-*-* 03:00 RandomizedDelaySec=30m $ sudo systemctl edit apt-daily-upgrade.timer # Opens a new file /etc/systemd/system/apt-daily-upgrade.timer.d/override.conf, paste this content: [Timer] # Reset the system calendar config first OnCalendar= # Set a new calendar timer with a 60 minute threshold OnCalendar=*-*-* 04:00 RandomizedDelaySec=30m .. and are auto-updated. When a reboot is needed after an update, it gets rebooted automatically.

christophilus 5y ago

Application of security patches can be automated, and depending on your application’s dependencies, can be done without worry. I run about 10 bare metal transcoding servers, and it’s zero hassle.

mtlynch 5y ago
Can you share more about your setup? Is it cronjobs to just apt-get update && apt-get upgrade -y? How do you handle packages that require reboots?
- christophilus 5y ago
  I haven’t had a reboot required in over a year, I think. The service is a Go program, and the only OS-managed dependency is ffmpeg. If a reboot interrupts the transcoding jobs, they just retry, so it’s really zero maintenance.
- stevekemp 5y ago
  If you're running Debian/Ubuntu then you should look at the "unattended-upgrades" package.
  - mtlynch 5y ago
    Cool, thanks for the tip! I hadn't seen that package before.
- giantrobot 5y ago
  In my experience precious few packages on the Ubuntu LTS releases (I'm sure it applies to other distros too) require reboots. It's basically only been kernel upgrades. There's few user space packages I imagine even benefiting from a reboot. Restarting a long running daemon is pretty painless. Also on a warm running system you've got an active page cache so all the unchanged files that service wants to open are likely cached in RAM rather than read from disk. While I appreciate the flexibility low effort VMs provide I think they've negatively affected the views of Linux users. Long uptime is fine and restarting a whole machine is rarely necessary. At the same time modern systems with crazy fast SSDs make a reboot take little longer than just restarting a service.
  - chousuke 5y ago
    There's honestly very little reason not to run VMs nowadays. It's like using LVM for disks on Linux; virtually zero overhead and you'll be happy you went with it when you do need the flexibility it provides. I'd pretty much run bare metal only if every server is used for a singular purpose that uses 100% of the available resources. Lots of hardware servers spend several minutes initializing themselves on boot. a RHEL 8 VM on a reasonably powerful host reboots in less than 5 seconds; a service restart causes approximately the same downtime that a reboot does.
- ehou 5y ago
  Not OP. My servers get this: $ apt install unattended-upgrades # /etc/apt/apt.conf.d/99unattended-upgrades-custom Unattended-Upgrade::Sender "Root at servername.domain.tld <servername.domain.tld@servicesdomain.tld>"; Unattended-Upgrade::Mail "services@servicesdomain.tld"; Unattended-Upgrade::MailReport "on-change"; Unattended-Upgrade::Automatic-Reboot "true"; Unattended-Upgrade::Automatic-Reboot-Time "05:00"; $ sudo systemctl edit apt-daily.timer # Opens a new file /etc/systemd/system/apt-daily.timer.d/override.conf, paste this content: [Timer] # Reset the system calendar config first OnCalendar= # Set a new calendar timer with a 60 minute threshold OnCalendar=*-*-* 03:00 RandomizedDelaySec=30m $ sudo systemctl edit apt-daily-upgrade.timer # Opens a new file /etc/systemd/system/apt-daily-upgrade.timer.d/override.conf, paste this content: [Timer] # Reset the system calendar config first OnCalendar= # Set a new calendar timer with a 60 minute threshold OnCalendar=*-*-* 04:00 RandomizedDelaySec=30m .. and are auto-updated. When a reboot is needed after an update, it gets rebooted automatically.