71–77 of 77 posts
Earlier quoted context omitted.
"employed by"
Note that that's gperciva not cperciva . I believe the person's name is Graham Percival, and I am fairly sure Colin Percival is still called Colin Percival. They may well be related, but I'm pretty sure that's a bona fide "employed by" :-).
Earlier quoted context omitted.
"employed by"
Note that that's gperciva not cperciva . I believe the person's name is Graham Percival, and I am fairly sure Colin Percival is still called Colin Percival. They may well be related, but I'm pretty sure that's a bona fide "employed by" :-).
Earlier quoted context omitted.
> Have mandatory reboots, never be afraid of reboots. Yes! It is not a badge of honor to have a server that's been online for 365+ days -- it just means you haven't applied any kernel security updates for a long, long time. :-p
> Yes! It is not a badge of honor to have a server that's been online for 365+ days The badges come at 1000 days and every 500 after that. If you have a minimal kernel, and a limited software set, many kernel security bugs found won't apply to your system and you don't need to reboot for them. Not that you need to be scared of reboots, and you should probably schedule some reboots so you can be confident your systems…
I don't want to wait for a power failure to find out whether my services still recover from a cold boot.
Earlier quoted context omitted.
> Yes! It is not a badge of honor to have a server that's been online for 365+ days The badges come at 1000 days and every 500 after that. If you have a minimal kernel, and a limited software set, many kernel security bugs found won't apply to your system and you don't need to reboot for them. Not that you need to be scared of reboots, and you should probably schedule some reboots so you can be confident your systems…
1000 days of uptime is 1000 days of configuration drift since the last time you confirmed your services still boot properly. I don't want to wait for a power failure to find out whether my services still recover from a cold boot.
When you make a boot time config change (which, in my mind, includes kernel version and OS version to some extent), decide if it's nice to have or needs to have. If it's needs to have, well everything gets rebooted and no badges for a while. If it's nice to have, group hosts by kernel version and hardware spec and reboot one or two hosts with median uptime; your config will be tested, and you can still earn badges.
If you can't tell what configs are boot time or not, just reboot a median uptime host in each group once a week. If you can't tell what's important enough to reboot everything, I guess you can just reboot everything every 49.7 days, but you'll never get badges that way. You also won't get production data comparing current kernel to older kernel to see if any new software would have worked better on older kernels, so you have some data to start with when you hit new bottlenecks.
These experiences are relatively common, we just don't see writeups that often. Kudos to the author for writing this up. I do disagree with some of the lessons here. You want to switch operating systems on your server? 1. Set up monitoring. If you don't have monitoring already, hack something together with simple scripts. 2. Start up a new server. 3. Migrate services and data from your existing server to your new ser…
I would also setup a reverse proxy on the old server so it would forward all traffics to the new server, and finally kill the old server once the reverse proxy no longer see any legitimate requests.
Then you can just remount it on the new OS