Bug#875858: pkgsel: Offer to install/manage unattended-upgrades
You can tell me if I am 'beating a dead horse' but for the sake of argument, let us see where this goes On 12/11/2017 11:41 AM, Wouter Verhelst wrote: On Sun, Dec 10, 2017 at 12:22:07PM -0400, Raymond Burkholder wrote: I think its totally adequate to assume people want automatic security updates, on all kinds of systems, unless they opt out. Security updates, yes. Automated, no. Desktops, maybe. Servers, no. Are you advocating for having servers with known-security-buggy services running all over the Internet, then? hmm, almost like being asked to answer the question 'have you stopped beating your yet?'. One can't win by answering. But things depend: * servers can't can't be rebooted willy nilly * when a package is updated with files open, the active process gets the existing files, and new processes get the new files, and is the patched package functional simultaneously in both activities (file formats, database schemas, )? * does the patch introduce a functional change which may break operations (inverting logic on something, removing a flag, ... ) which breaks dependencies elsewhere For my infrastructure, updates, of what ever kind, need to be incorporated into the test/build/roll-out cycle. If you have a test/build/roll-out cycle, then you presumably have a local mirror (and if you don't, well, why not?) Just make sure your servers only pull from that local mirror, and you're done. I do have the local mirror (more like a package proxy at the moment), But this mechansim does require a certain finesse. running apt update && apt upgrade against that local mirror/proxy may cause it to update to versions not quite desired, which leads to a specialized mirror with pre-cleared packages, but, well, I'm not that sophisticated quite yet. [...] So, as an accommodation, a flag in the preseed mechanism to enable/disable would be helpful. But would need to be exposed in maybe the expert mode menus, which I think was already mentioned. What Raphaël was proposing is exactly that, yes. Also, there is absolutely *no* technical difference between "the preseed mechanism", "a low-priority debconf question", and "something in the expert mode menus". None. Zero. Zilch. -- Raymond Burkholder r...@oneunified.net https://blog.raymond.burkholder.net -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Bug#875858: pkgsel: Offer to install/manage unattended-upgrades
On 12/11/2017 11:51 AM, Steve McIntyre wrote: On Mon, Dec 11, 2017 at 04:41:38PM +0100, Wouter Verhelst wrote: On Sun, Dec 10, 2017 at 12:22:07PM -0400, Raymond Burkholder wrote: I think its totally adequate to assume people want automatic security updates, on all kinds of systems, unless they opt out. Security updates, yes. Automated, no. Desktops, maybe. Servers, no. Are you advocating for having servers with known-security-buggy services running all over the Internet, then? That's the point here, yes. We've had this discussion already several times, and it was triggered by needs/desires of cloud providers. As a *default*, it makes sense to have automated security updates to cover the users who don't care, or don't know any better. Users with more knowledge and hard requirements about downtime etc. should already be managing this. I think I got thrown off by the title 'unattended upgrades'. If this is limited to security updates, I am more for it, but still scared of it. Security updates tend to come in packages which have already have had other regular patches applied (except, I suppose in 'stable' versions), and sometimes one can get caught in functional changes. I guess that is my greatest fear, breakages due to updates. But my experience has mostly been with regular package updates. I haven't focused much on security updates. Can security updates be applied with out generating dependency chains and their updates? -- Raymond Burkholder r...@oneunified.net https://blog.raymond.burkholder.net -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Bug#875858: pkgsel: Offer to install/manage unattended-upgrades
On Mon 11 Dec 2017 at 17:46:44 +, Steve McIntyre wrote:
> On Mon, Dec 11, 2017 at 06:20:55PM +0100, Christian PERRIER wrote:
> >Quoting Raymond Burkholder (r...@oneunified.net):
> >> > > So, as an accommodation, a flag in the preseed mechanism to
> >> > enable/disable would be helpful.
> >> >
> >> > You mean something like:
> >> >
> >> > Template: pkgsel/update-policy
> >> > Type: select
> >> > Default: unattended-upgrades
> >> >
> >> > pkgsel/update-policy=none thus seem the perfect preseed choice for your
> >> > use case.
> >> >
> >>
> >> Yes, thank you, that works for me.
> >>
> >> Is there a dictionary somewhere where I can look these things up? From
> >> where did you get your Template extract?
> >
> >No, there is no such dictionary. Sadly, documenting all possible
> >presseding options really lacks a dedicated effort. There was one, in
> >the past, when the D-I team was much bigger, and, still the
> >Installation Guiide does document the most important options, but
> >those that have been "recently" added ("recentlly" means "last years")
> >shoudl be added there.
> >
> >I got the template extractfrom the package source itself (pkgsel
> >package, here).
>
> As a trivial lookup, sources.debian.net will show all the template
> files in Debian:
>
>
> https://codesearch.debian.net/search?q=Template%3A+path%3Adebian%2F.*.template
>
> but it's a large set in just sid: ("761 files grepped (4453 results)")...
apt-extracttemplates is a useful utility in apt-utils. For a set of
udebs
apt-extracttemplates -t $PWD *.udeb
will extract any templates files in the udebs.
rm *.config.*
deletes unneeded files.
All that is needed for a "dictionary" is to tidy up the templates files.
Perhaps
https://wiki.debian.org/DebianInstaller/Preseed#Preseeding_and_the_installer.27s_debconf_templates
helps?
--
Brian.
Bug#875858: pkgsel: Offer to install/manage unattended-upgrades
On Mon, Dec 11, 2017 at 06:20:55PM +0100, Christian PERRIER wrote:
>Quoting Raymond Burkholder (r...@oneunified.net):
>> > > So, as an accommodation, a flag in the preseed mechanism to
>> > enable/disable would be helpful.
>> >
>> > You mean something like:
>> >
>> > Template: pkgsel/update-policy
>> > Type: select
>> > Default: unattended-upgrades
>> >
>> > pkgsel/update-policy=none thus seem the perfect preseed choice for your
>> > use case.
>> >
>>
>> Yes, thank you, that works for me.
>>
>> Is there a dictionary somewhere where I can look these things up? From
>> where did you get your Template extract?
>
>No, there is no such dictionary. Sadly, documenting all possible
>presseding options really lacks a dedicated effort. There was one, in
>the past, when the D-I team was much bigger, and, still the
>Installation Guiide does document the most important options, but
>those that have been "recently" added ("recentlly" means "last years")
>shoudl be added there.
>
>I got the template extractfrom the package source itself (pkgsel
>package, here).
As a trivial lookup, sources.debian.net will show all the template
files in Debian:
https://codesearch.debian.net/search?q=Template%3A+path%3Adebian%2F.*.template
but it's a large set in just sid: ("761 files grepped (4453 results)")...
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...
Bug#875858: pkgsel: Offer to install/manage unattended-upgrades
Quoting Raymond Burkholder (r...@oneunified.net):
> > > So, as an accommodation, a flag in the preseed mechanism to
> > enable/disable would be helpful.
> >
> > You mean something like:
> >
> > Template: pkgsel/update-policy
> > Type: select
> > Default: unattended-upgrades
> >
> > pkgsel/update-policy=none thus seem the perfect preseed choice for your
> > use case.
> >
>
> Yes, thank you, that works for me.
>
> Is there a dictionary somewhere where I can look these things up? From
> where did you get your Template extract?
No, there is no such dictionary. Sadly, documenting all possible
presseding options really lacks a dedicated effort. There was one, in
the past, when the D-I team was much bigger, and, still the
Installation Guiide does document the most important options, but
those that have been "recently" added ("recentlly" means "last years")
shoudl be added there.
I got the template extractfrom the package source itself (pkgsel
package, here).
signature.asc
Description: PGP signature
Bug#875858: pkgsel: Offer to install/manage unattended-upgrades
On Mon, Dec 11, 2017 at 04:41:38PM +0100, Wouter Verhelst wrote: >On Sun, Dec 10, 2017 at 12:22:07PM -0400, Raymond Burkholder wrote: >> > >> > I think its totally adequate to assume people want automatic security >> > updates, on all kinds of systems, unless they opt out. >> >> Security updates, yes. Automated, no. Desktops, maybe. Servers, no. > >Are you advocating for having servers with known-security-buggy services >running all over the Internet, then? That's the point here, yes. We've had this discussion already several times, and it was triggered by needs/desires of cloud providers. As a *default*, it makes sense to have automated security updates to cover the users who don't care, or don't know any better. Users with more knowledge and hard requirements about downtime etc. should already be managing this. -- Steve McIntyre, Cambridge, UK.st...@einval.com We don't need no education. We don't need no thought control.
Bug#875858: pkgsel: Offer to install/manage unattended-upgrades
On Sun, Dec 10, 2017 at 12:22:07PM -0400, Raymond Burkholder wrote: > > > > I think its totally adequate to assume people want automatic security > > updates, on all kinds of systems, unless they opt out. > > Security updates, yes. Automated, no. Desktops, maybe. Servers, no. Are you advocating for having servers with known-security-buggy services running all over the Internet, then? > For my infrastructure, updates, of what ever kind, need to be > incorporated into the test/build/roll-out cycle. If you have a test/build/roll-out cycle, then you presumably have a local mirror (and if you don't, well, why not?) Just make sure your servers only pull from that local mirror, and you're done. [...] > So, as an accommodation, a flag in the preseed mechanism to > enable/disable would be helpful. But would need to be exposed in > maybe the expert mode menus, which I think was already mentioned. What Raphaël was proposing is exactly that, yes. Also, there is absolutely *no* technical difference between "the preseed mechanism", "a low-priority debconf question", and "something in the expert mode menus". None. Zero. Zilch. -- Could you people please use IRC like normal people?!? -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab
Bug#884108: regression: after 1.0.93 can't install lucid
Package: debootstrap Version: 1.0.93 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? 1) upgraded debootstrap to latest version 1.0.93 2) run command debootstrap --arch=amd64 --variant=minbase --no-check-gpg lucid out/ubuntu-10.04 http://old-releases.ubuntu.com/ubuntu * What was the outcome of this action? this command failed with status $? = 2 and log ands with: ... I: Retrieving zlib1g 1:1.2.3.3.dfsg-15ubuntu1 I: Validating zlib1g 1:1.2.3.3.dfsg-15ubuntu1 I: Chosen extractor for .deb packages: dpkg-deb I: Extracting adduser... I: Extracting base-files... I: Extracting base-passwd... I: Extracting bash... I: Extracting bsdutils... I: Extracting busybox-initramfs... I: Extracting coreutils... I: Extracting cpio... I: Extracting dash... # cat out/ubuntu-10.04/debootstrap/debootstrap.log tar: ./bin/sh: Cannot create symlink to 'dash': File exists tar: ./usr/share/man/man1/sh.1.gz: Cannot create symlink to 'dash.1.gz': File exists tar: Exiting with failure status due to previous errors # -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.21.1-openvz-042stab123.9-amd64 (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages debootstrap depends on: ii wget 1.19.2-1 Versions of packages debootstrap recommends: ii debian-archive-keyring 2017.6 ii gnupg 2.1.18-8~deb9u1 debootstrap suggests no packages. -- no debconf information
Bug#875858: pkgsel: Offer to install/manage unattended-upgrades
> > So, as an accommodation, a flag in the preseed mechanism to > enable/disable would be helpful. > > You mean something like: > > Template: pkgsel/update-policy > Type: select > Default: unattended-upgrades > > pkgsel/update-policy=none thus seem the perfect preseed choice for your > use case. > Yes, thank you, that works for me. Is there a dictionary somewhere where I can look these things up? From where did you get your Template extract? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
