On 2018-07-31 07:24:58, Noah Meyerhans wrote: > Thanks, Tomasz, for putting together the summary. Sorry I couldn't be > there. > > On Tue, Jul 31, 2018 at 12:37:51PM +0200, Tomasz Rybak wrote: > > There was intensive discussion related to automated/unattended > > upgrades of our images: whether we should do it at all (there may be > > run in environment w/o internet access), when (usage needs, avoiding > > killing mirror when thousands of machines try to perform upgrade at > > once, etc.). > > I probably shouldn't be surprised by this, but I am. The installation of > unattended-upgrades by default was something we decided on, and > announced to -devel, two years ago. I'll restate my previous position on > this: > > On a well-maintained system, u-u is trivial to disable if that's the > admin's desire. On a non well-maintained system, u-u is essential for > the safety of the user, the cloud provider, and the internet at large. I'd like to chime in as well. I fully agree with Noah and it was my understanding as well that we are going to implement it. IMO if not consensus can be found for default images we as Cloud Team should diverge. I don't think that this is going to be a big deal as there is already quite strong support on d-d for this action. Debian recently enabled Apparmor in default image as a safety feature automatic upgrades are equally important as outdated Apparmor is not going to do much good. So I suggest that we as Cloud Team use unattended-upgrades for security upgrades on cloud images by default and I suggest to do it from the next images build for Buster. > If there are changes we can make to the configuration we install in > cloud environments, those can be discussed, but as far as I'm concerned > the basic default availability of u-u is beyond debate. > > > Some vendors upgrade during restart, but it lengthens boot time, which > > matters when VM is run for short time (common use case for clouds). No > > consensus was found - but we should check what Ubuntu does. Even if this is the case admins maintaining deployments should know about it and if this is something undesirable they will be able to switch it off. Just a point about big deployments and overwhelming mirrors, as far as I know most cloud providers are having Debian mirror(s) located on their cloud (but I may be wrong as I didn't use them all), with deb.debian.org we're already able to route a hole lot of traffic via CDNs. Maybe it's worth considering adding more CDNs into the mix? I know that we're using AWS and Fastly I'm not sure if Waldi was successful in setting up CDN on Google. Also having more stats on CDNs use would be beneficial to have for this discussion. -- |_|0|_| | |_|_|0| "Panta rei" | |0|0|0| -------- kuLa -------- | gpg --keyserver pgp.mit.edu --recv-keys 0x686930DD58C338B3 3DF1 A4DF C732 4688 38BC F121 6869 30DD 58C3 38B3
Attachment:
signature.asc
Description: PGP signature