Re: [DNG] OT: Patching De*an based systems at scale
On Fri, Oct 27, 2017 at 10:50:36AM -0500, dev wrote: > On 10/26/2017 04:53 PM, Adam Borowski wrote: > > You may additionally install apt-listchanges and configure it to show > > changelogs, that will fetch relevant (and only those!) changelog entries of > > packages you're about to install. > > Thank you for that information. Is the email and apt-listchanges the > only way? apt-listchanges sends notifications from every system. That's > 60 duplicate emails in my case, for many packages such as OpenSSH. "dpkg-reconfigure apt-listchanges", it has quite a few options to alter how notifications are presented. I for one consider mail to be uncomfortable here, as knowing what was installed only after the fact is pretty pointless (there's dpkg.log too), thus on systems where I have apt-listchanges installed it's configured to use pager, letting me ^C if I want to abort the upgrade. > The DSA mail cuts down the noise but I'm assuming I may be getting > mailed about packages that do not pertain to any systems I'm running, > correct? Yeah but the mail volume is so low I don't consider this a problem. And you get them once no matter how many systems you admin. > I'm trying to avoid what I always end up doing; a perl screen scraper > which I cross-reference with apt-get upgrade --dry-run and then parse > the pertinent package info into a CSV file that can everyone wants > emailed to them, for each server... maybe this is the only way ? I'd parse "apt-cache policy" instead, it's much easier to read. Or even "dpkg --get-selections" so you have the set of packages only, which can then be used to filter notifications centrally. But then, the quality of Debian security updates has been so high (at least for server packages) that I'm not paid well enough to pore through every changed line. I somewhat dislike completely unattended upgrades, thus I run a script that does, for every machine, serialized: apt-get update && apt-get -y upgrade && apt-get dist-upgrade && apt-get clean. Doing it serially rather than in parallel means I can see that upgrading the first machine ran into trouble; extra time it takes doesn't matter as I do other work on the other monitor/terminal in the meantime. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Laws we want back: Poland, Dz.U. 1921 nr.30 poz.177 (also Dz.U. ⣾⠁⢰⠒⠀⣿⡁ 1920 nr.11 poz.61): Art.2: An official, guilty of accepting a gift ⢿⡄⠘⠷⠚⠋⠀ or another material benefit, or a promise thereof, [in matters ⠈⠳⣄ relevant to duties], shall be punished by death by shooting. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OT: Patching De*an based systems at scale
On 10/26/2017 04:53 PM, Adam Borowski wrote: > You're not insane enough to run an unreleased version on a production > server, right? I would never do that! ;) Seriously though, I might do it in a test environment, so good to know. > You may additionally install apt-listchanges and configure it to show > changelogs, that will fetch relevant (and only those!) changelog entries of > packages you're about to install. Thank you for that information. Is the email and apt-listchanges the only way? apt-listchanges sends notifications from every system. That's 60 duplicate emails in my case, for many packages such as OpenSSH. The DSA mail cuts down the noise but I'm assuming I may be getting mailed about packages that do not pertain to any systems I'm running, correct? I'm trying to avoid what I always end up doing; a perl screen scraper which I cross-reference with apt-get upgrade --dry-run and then parse the pertinent package info into a CSV file that can everyone wants emailed to them, for each server... maybe this is the only way ? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OT: Patching De*an based systems at scale
On Thu, Oct 26, 2017 at 11:12:08AM -0500, dev wrote: > Hi All, > I'd like to have a discussion about how to scale patch management on > De*an based systems. > Is there a better way to get information about patch fixes other than > digging up the Changelogs from a web browser? You're not insane enough to run an unreleased version on a production server, right? If so, every single update is accompanied by a DSA mail (subscribe to debian-security-annou...@lists.debian.org) or a point release (debian-announce). As you specified "De*an", these apply to both distributions matching this wildcard: if *=bi, to every package, if *=vu, ones with a systemd dependency might face a slight delay (but less than 0.1% of packages have such dependency). Both DSA and point releases do list everything that has changed in packages being updated. You may additionally install apt-listchanges and configure it to show changelogs, that will fetch relevant (and only those!) changelog entries of packages you're about to install. On a system running testing or unstable, apt-listchanges is the only way. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Laws we want back: Poland, Dz.U. 1921 nr.30 poz.177 (also Dz.U. ⣾⠁⢰⠒⠀⣿⡁ 1920 nr.11 poz.61): Art.2: An official, guilty of accepting a gift ⢿⡄⠘⠷⠚⠋⠀ or another material benefit, or a promise thereof, [in matters ⠈⠳⣄ relevant to duties], shall be punished by death by shooting. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] OT: Patching De*an based systems at scale
Hi All, I'd like to have a discussion about how to scale patch management on De*an based systems. Right now, my methodology is looping over my servers in a script and saving the output from 'apt list --upgradable'. This seems to be a utility which will display packages needing updates regardless of whether you use apt-get, apt-get dist-upgrade, or apt-get upgrade. Thing is, when I had 20 servers, this method worked quite well. Most of the servers were LAMP stacks. I now host around 60 servers with various software installed, not just Apache and Mysql anymore. The patch list gets complex and involves various software components. I don't always have time to patch right away so I need to plan for potential downtime of the more critical systems and prioritize system patches based on the criticality of the affected software. Knowing why the patch is needed or what was fixed becomes a priority. Are there any utilities out there for making patch management "easier" when dealing with multiple De*an systems? Is there a better way to get information about patch fixes other than digging up the Changelogs from a web browser? Thanks! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
