<div dir="ltr"><div><div><div><div>"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:<br></div><br>(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 ;)<br><br>(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?<br></div></div><div><br>(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!)<br></div><br>(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!<br><br></div>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?<br><br>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!<br clear="all"><br>--<br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Unsung Heroes of OLPC, interviewed live @ <a href="http://unleashkids.org" target="_blank">http://unleashkids.org</a> !</div></div>

</div>