I think a number of problems have been exposed with the topic and not all directly related to the GCE specific images. Speaking as a consumer of the work of the Debian Cloud team I felt the GCE changes were too absurd to not comment on but only in a straw that broke the camel's back way. > Why are you trying to suggest that sys admins are not capable of carrying for > it on their own? Managing automated changes in Debian is not complicated but > should be left for local admin. This is a very valid question and the answer is quite simple: Google isn't wrong, they know exactly who their customer is going to be, and they know their customers have no idea what apt-get is. They have done extensive research to identify the market and know what they are getting into. I can all but guarantee that the arguments Google has been providing are extremely good for Google and Google's customers. When Google says they hope that Debian will lead the way in automatic updates my opinion is that they mean "We hope Debian will change to fit our model for what a Cloud OS will do and since our product is based on Debian/Stable we expect that change now." What is also being demonstrated is a lack of respect for the Debian project as a whole as well as an expectation that Google can live by different rules. But in fact this is not activity limited to Google and I suspect Debian is going to have to learn to guard itself against the economic pressures of large commercial organizations trying to bend Debian to their will. But this problem is not limited only to commercial entities: the entire cloud team seems to think that it can live by a different set of standards as to what Stable and Testing mean. > However, I > think that most if not all cloud images developed here are still in testing > phase, even if they can be quite usable and even if they are based on Debian > stable. Thus, the fast release cycle is not a design goal, it only reflects > the state of our cloud projects in general. This problem could be alleviated by stopping development and testing work on the official Debian/Wheezy images. Please evaluate the process the cloud team has gone through over the past 9 months or so while iterating the Debian/Wheezy images. There was an original implementation that was good enough for basic things; it was reliable and mostly bug free. But that configuration wasn't good enough for the cloud team because it wasn't cloud compatible enough so it had to change by incorporating technology created by another party. In fact, it seems that the belief is the images have to change a lot. The most beneficial effort would come from what I suggested earlier: having Debian/Wheezy cloud images be the bare minimum required to operate on the cloud above and beyond what an install CD does. This includes the ability to install the root keys at first boot, pass in arbitrary bootstrap scripts, such as user data scripts, but does not include tools to help maintain the system. I do not like that the cloud team has overloaded the Debian/Stable name to mean "testing". Why are you testing on stable? Why are any improvements made outside of the scope of the larger community: this would help both in identifying bad ideas as well as making sure actual improvements work their way into Debian as a whole. Are there so many cloud specific issues that the cloud team doesn't need to work with the rest of Debian to make sure the OS is improved generally and not just for some specific vendors? Google is certainly free to do what ever they want. The cloud teams efforts are appreciated. I take exception that products labeled as Debian/Wheezy should have unexpected behavior or that vendor specific Debian produced releases (of which every single cloud image is) should behave in any way thats not decidedly the current version of Stable. Tyler On Apr 12, 2014, at 2:13 AM, Marcin Kulisz <debian@kulisz.net> wrote: > Greetings > > On 2014-04-11 11:43:45, Matt Alexander wrote: >> To clarify for Debian on GCE, we'd like to have only *security* >> updates enabled by default (the case when installing the >> unattended-upgrades package), with information in motd and documented >> elsewhere so that admins that don't want security updates can disable >> them. > > As explained before none updates are automated in Debian except those switched > on by sys admins them selfs. We should stick what is default in official Debian > image. > >> There's no perfect solution here since there's always the potential >> that a security patch could break something for users. However, I >> believe there's a "greater good" argument to be made for keeping users >> more secure by default at the expense of the rare failure. > > Why are you trying to suggest that sys admins are not capable of carrying for > it on their own? Managing automated changes in Debian is not complicated but > should be left for local admin. > >> Having >> automatic security updates becomes even more important in the Cloud >> scenario where users pay much less attention to the OS layer than a >> typical sysadmin might that's running Debian servers at their company. > > I won't agree with it, but if they don't pay attention to servers they are > responsible for, sorry but it's not our problem but theirs and they change > their mind set. All systems need care cause 'cookies need love'. > >> For the case of "I don't want my MySQL service restarting without my >> knowledge", it's easy for an admin to add MySQL to the >> Unattended-Upgrade::Package-Blacklist section of >> /etc/apt/apt.conf.d/50unattended-upgrades, for example. > > It's easy to setup automated upgrades for security too and from my experience > opt-in is in many border cases much better solution then opt-out specially when > you're not in the position to forecast what problems it may cause on highly > customised systems. > >> It'd be great to see Debian lead the way among distros of changing the >> default expectation to "I get security updates automatically and >> therefore don't have to spend time worrying about tracking and >> applying security patches for my apps". I don't see this as "trying >> to think for our users", but more about making their OS easier to >> manage and staying secure by default. > > As I wrote above I won't agree with this point of view for many reasons. For me > it'll create more problems specially on systems loaded 24/7. > > I can agree that opt-out and opt-in are similarly easy to setup but > consequences of those to approaches are very different on production systems > and in my opinion it's better to be save (spend a bit more time to apply > updates) then sorry when 12h running DB query for CEO report will fail because > of it and the board meeting is in 4h. > -- > > |_|0|_| | > |_|_|0| "Heghlu'Meh QaQ jajVam" | > |0|0|0| -------- kuLa --------- | > > gpg --keyserver pgp.mit.edu --recv-keys 0x58C338B3 > 3DF1 A4DF C732 4688 38BC F121 6869 30DD 58C3 38B3
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail