On Mon, Aug 15, 2016 at 09:56:43AM -0400, Adam Holt wrote: > "yum update" on CentOS regularly tells me that "yum-cron" should > likely be installed+run instead. Does anyone have experience / > informal recommendations (or just tricks-of-the-trade, no matter how > hacky) around yum-cron or dnf-automatic or similar, in Debian-land > or all around? Ideally some such/ similar would: > > (1) be patient enough to deal with developing world servers being > offline for many months at a time, yet smart enough to grab security > updates quickly when Internet appears unpredictably every few weeks > or months (or years, such server are almost inherently > re/distributed re/donated re/sold Without centralized > control...Internet-of-Things / IoT "anarchy" fears are indeed > relevant+real ;)
Already implemented; a scriptlet is run by Network Manager when the connection appears, and begins download of updates. Downside is that the connection may have been made for a reason other than downloading updates, and it can be quite irritating to the site user to share their bandwidth with the updates. As bandwidth increases for the 1% more such upstream policy decisions are taken. Removing agency from the owner. > (2) Ideally only download "security" updates (however informally > managed, anything closer to LTS than constant upgrades of > major/minor packages!) Is CentOS catching up to RHE on this front, > or does Red Hat intentionally differentiate its products such that > Red Hat Enterprise gets security updates faster or in a cleaner way? Having been a Red Hat Enterprise support engineer; yes, Red Hat customers do get security updates faster than CentOS does (of cour$e), but the delay will vary. From point of view of a CentOS user, worst delay is where a Red Hat customer has asked for the issue to be fixed and been given an early fix, and best delay is for a well known and announced update. > (3) Avoid bloating smaller (e.g. 120GB) SSD drives & 128GB MicroSD > cards driving RPi3's and similar? Sometimes I see ~100MB/week of > updates from "yum update" which makes me wonder if yum is smart > enough to fully delete not just deprecate older/unused packages?? > Hopefully I am wrong to fear disk bloat. Or does this truly > represent an estimated ~5GB/year of disk bloat in recent years, > purely for OS-level updates? (Part of a larger challenge on how to > manage bloat of log files, content files, tmp files, user files for > sure!) Already implemented; old version of files are deleted when update is applied, and downloads are deleted afterwards. If you have disk bloat, it will be some other cause. > (4) Email the owner of the machine (offline is increasingly online, > no matter how we slice it: offline servers will increasingly be at > risk for years to come sad to say!) Some kind of interface to Gmail > or a similar online notification service should be possible when the > server reappears online, without running a mail server heaven > forbid? For moments when truly-more-critical-intervention's > required -- with the obvious risk that excessive "nagware" and > "liabilityware" warnings will be ignored or far worse -- when local > (often less-literate) operators even exist at all within developing > world schools, trying their best! Already implemented; several things provide this kind of service, and a mail server is not required on the system. > PS there's no perfect solution for sure -- Apple/Microsoft/Google > spend many, many millions on their security-auto-updating infra > (nevermind associated UX's) we just don't have. Offline security > updates on a quasi-monthly basis may be one answer, if older > quasi-offline solutions from the 1990s also/still have legit hope & > lessons for us all? What should such services cost, if it comes > down to money? As much as the market will pay. Which can be from zero to lots. > As real-world challenges evolve: what practical non-puritanical > compromises are evolving out there in CentOS-land / Debian-land / > Etc as "offline increasingly becomes online" ? (as serious online > risks increasingly reach offline servers, IoT devices, etc...what > quasi-automatic security update regimes should we be looking at for > the coming decade, realistically?) Thanks for ideas facing up to > these existential challenges uniting us all, knowing there's a > serious diversity of opinions / tripwires / threat models / > mitigations out there quite naturally! Go for a shorter planning horizon than a decade. -- James Cameron http://quozl.netrek.org/ _______________________________________________ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel