=== ikonia_ is now known as ikonia === genii_ is now known as genii === thegodsq- is now known as thegodsquirrel === y0sh- is now known as y0sh_ [20:10] rbasak: ping [20:52] teward: o/ [21:21] Howdy! So at work we discovered the inability to schedule ubuntu updates in aws ssm.. forgive me as I dont recall the exact terms but its due to canonicals lack of an update schedule (or there abouts). Anyway, all of our processes and config mgmt tasks are for Ubuntu, both on-prem and in aws. I sit here entirely irritated theres no apparent resolution to this other than rolling landscape and even thats an if at this point. [21:21] If anyone has advice on this please HMU [21:25] skeer: we do have a schedule: we try very hard to only release security updates monday through thursday. I'm less sure about bugfix updates, but I bet not many of those happen saturday and sunday [21:27] sarnold: ... is that published anywhere? I did a tiny bit of digging last week but after seeing AWS's docs mention that auto-aproval for Ubu server isnt supported https://docs.aws.amazon.com/systems-manager/latest/userguide/create-baseline-console-linux.html [21:31] skeer: hmm, that sounds like it's unrelated to a release schedule [21:36] sarnold: Maybe thats the problem..I/we might be understanding this incorrectly. [21:37] I guess I should have asked first, is it possible to have a scheduled patch baseline with auto-approval for Ubu Server in AWS? (I do realize this channel is *not* for AWS, but Ubu users I'd hope frequent here regardless of hosting platform) [21:40] skeer: I think the folks I've seen who wanted something like that used their own aptly mirrors configured to move packages in based on rules there, rather than managing it on the clients [21:40] skeer: of course if the amazon approach works for your own distros, having a completely different thing for ubuntu might be too frustrating :/ [21:41] sarnold: TBF we are pricing Landscape as an option.. however the MSRP of 75 per node is steep just for Updates. But yeah your aptly comment, can you tell me more about that? [21:42] I only mention Landscape in relation to doing something different for Ubu [21:44] https://ubuntu.com/tutorials/updating-ubuntu-pro-servers-automatically-with-aws-systems-manager#1-overview [21:45] skeer: I'm a bit fuzzy on aptly, I've never used it myself, but you can move packages into your own mirror on your own schedule https://www.aptly.info/doc/why/ === justache is now known as justache_test === justache_test is now known as justache [21:49] sarnold: Ah ok so in essence its a local mirror where you can limit inclusion in a bunch of ways. [21:49] skeer: yeah [21:49] tomreyn: TY! [21:52] sarnold: So that might be a viable alternative. So we're apparently wanting to push updates to a test group like, say 7 days before the rest. There some missing info there in official repos, I'm told, that makes this impossible. [21:52] To me a simple timer based on first group, but I guess that's not possible. [21:53] But maybe this aptly thing could be made to work [21:53] you're welcome, but i guess this tutorial is just a start, you may want / need to do a bit more scripting, and it won't cover your need for local mirroring either [21:53] Oh defintely. It's no silver bullet (and surprisingly just like AWS's docs, showing the newest version as 20.10) lol [21:55] skeer: yeah, I have to imagine some canary testing in aptly wouldn't be too hard to get going; I don't know if it's the *best* way to get there, but I do think it's meant to do those things [21:57] Ugh this is hard to nail down.. what AWS means I mean, with the release schedule being "unreliable" [21:59] skeer: so, I *think* what they're mentioning there, is that our package release lists don't say which date each specific package was updated [21:59] skeer: they could fake the data themselves by grabbing the lists daily and comparing the changes.. [22:00] skeer: but I suspect they don't want to :) so here we are [22:00] they == canonical? [22:00] or.. blah nevermind lol [22:00] Yeah so check this out.. [22:00] https://usercontent.irccloud-cdn.com/file/IO28M3s1/image.png [22:01] https://usercontent.irccloud-cdn.com/file/z8lZuNFD/image.png [22:01] that is the issue I'm trying to fight [22:02] And admittedly, it's more than likely no fault of Ubu's [22:05] In any event, thanks guys for the suggestions and info. I'm certainly open to any others while I dig. I don't relish the idea of switching distros one bit. [22:07] The required information is available via the Launchpad API [22:07] You can get the publication date for any package and version [22:07] But of course they'd need to retrieve it that way [22:08] eg. https://launchpad.net/ubuntu/+source/openssh/1:8.2p1-4ubuntu0.2 - has a publication date on the right column, and that's retrievable by API, too [22:10] rbasak: hah, that's an idea [22:10] I knew that checking logs was one way.. the Launchpad API I did not so that's cool. So that would be say, a lambda call polling an apt update list [22:11] rbasak: that is indeed interesting [22:19] Additional thought: a pri and sec mirrors. Since SSM doesn't want to allow scheduling based on group. One could run a test group against the pri repo which would be latest. Then run updates for group 2 based on Secondary repo which is rule-based set to pull updates from officifal sources X days later. [23:28] https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-patch-baselines.html -> "There is no wait before approval because reliable release dates aren't available in the repositories." [23:29] so AWS + SSM does not provide this functionality (which is offered for the Amazon Linux 2 AMIs) [23:31] see also https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchRule.html -> "ApproveAfterDays" -> " Not supported on Debian Server or Ubuntu Server." [23:35] sounds like a good selling point for ubuntu pro, if it can be extended to support this, such as with a custom patch baseline https://docs.aws.amazon.com/systems-manager/latest/userguide/create-baseline-console-linux.html which talks to launchpad to retireve this information.